Die technische Umsetzung eines Data Warehouses

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Blackbox Tech Podcast von Digitalkompakt. Ich bin Joel Gatschmarek und mit mir sitzt wieder der fabulöse Johannes. Grüß dich, Johannes.

Johannes Schaback: Hallo, Joel.

Joel Kaczmarek: Und wir sind heute nicht allein. Es geht nicht nur um ein spannendes Thema, sondern wir haben auch einen spannenden Gast dabei. Eigentlich sind Gäste hier immer spannend. Das ist Zugangsvoraussetzung. Für mich ist das ein ganz besonderer Moment, muss ich sagen, weil der junge Mann, der neben mir sitzt, hat vor mir, ich glaube sogar noch deutlich vor mir, Gründerszene groß gemacht. Und ich habe immer seine Meriten teilweise erzählt bekommen. Von daher, das finde ich sehr, sehr schön. Stell dich doch mal ganz kurz vor.

Michael Franzkowiak: Ja, hallo, mein Name ist Michael Franzkowiak. Schön, dass ich heute hier sein kann. Vielen Dank für die Einladung. Ich bin jetzt so seit, ich glaube, sieben, acht Jahren in der Berliner Startup-Szene unterwegs, immer auch mit einem großen Fokus, glaube ich, auf technische Themen. Jetzt seit knapp vier Jahren mit Contiamo unterwegs, unserer Company, wo wir eine Datenplattform entwickelt haben und damit unter anderem Unternehmen wie der Telekom und einigen anderen größeren Unternehmen, dabei helfen, ihre Daten zentral zusammenzubringen und auswertbar zu machen. Und ich freue mich sehr, heute über diese Thematik auch so ein bisschen zu sprechen.

Joel Kaczmarek: Genau in diese Richtung soll es gehen. Und zwar reden wir heute über Data Warehouses. Der eine oder andere hat ja vielleicht auch unseren Podcast mit Kollegen Heinemann schon dazu gehört im Business Building Bereich. Da ging es ja mehr so ein bisschen was für Marketingzahlen aggregiere ich? Wie kriege ich das in die Organisation gebracht? Wie baue ich das ein in mein eigenes Business Building? Wir wollen jetzt natürlich ein bisschen technisch werden. Das heißt, wir wollen ein bisschen gucken, was sind teilweise die Unterschiede zwischen verschiedenen Ansätzen? Was ist zum Beispiel ein Data Lake versus ein Data Warehouse? Welche Software gibt es? Wie baue ich so eine Architektur und so weiter und so fort? Da bist du natürlich die Nummer eins. Wir haben uns das so ein bisschen strukturiert in Daten sammeln, Daten zusammenführen, Daten nutzen und wollen nach hinten raus ein bisschen über Best Practices reden. Und du bist ja, glaube ich, sehr, sehr gut für geeignet. Du hast einfach ein bisschen unterschlagen. Du hast so spannende Daten, eigentlich Sachen auch mal auch, also nicht nur in deiner eigenen Firma, sondern du hast ja auch irgendwie Rocket-Zeiten ein bisschen erlebt. Alex hat da was gesehen. Magst du eigentlich mal ein, zwei Sätze dazu sagen?

Michael Franzkowiak: Ja, also wir haben ja natürlich selber in den ersten Rocket-Tagen auch einiges mitbekommen. Da schon auch immer gesehen, wie gut natürlich und wie wichtig es ist, eben auch ein Unternehmen sehr datengetrieben zu führen und wie viel davon eigentlich auch davon abhängt, wie die Architektur aufgesetzt ist und auf welche Infrastruktur man zurückgreifen kann und dass das definitiv ein ganz wichtiger, entscheidender, kompetitiver Vorteil ist. Jetzt sitzen wir hier Luftlinie, was ist das, knapp 1000 Meter von Zalando entfernt, wo ich auch glaube, dass man definitiv sagen kann, dass ein guter Teil des Erfolges eben daher rührt, wie gut dort mit Daten gearbeitet wird und eben auch welche Inhouse-Expertise da seit Tag 1 eigentlich aufgebaut wurde. Insofern eigentlich bestes Beispiel dafür. Danach habe ich dann ein bisschen eher auf der Investorenseite auch Firmen begleitet und da war uns natürlich auch immer wichtig, dass wenn wir in Firmen investiert haben, dass wir wussten, dass unsere Euros auch gut genutzt wurden und gut angelegt wurden in die richtigen Kampagnen, in die richtigen Produkte und auch dafür natürlich auch aus Investorensicht ganz entscheidend, wie gut ist das Unternehmen aufgestellt, wie gut kann es da Entscheidungen treffen, auch in der Breite über die Organisation hinweg, also von den verschiedenen Entscheidern in den unterschiedlichen Abteilungen.

Joel Kaczmarek: Cool, also da haben wir schon mal so ein bisschen Gefühl dafür bekommen, was Data Warehousing eigentlich für Anwendungsgebiete hat. Magst du mal ganz simpel einsteigen, mal als Definition, was ist eigentlich so ein Data Warehouse, wenn man das eher im technischen Sinne betrachtet?

Michael Franzkowiak: Ich würde das aus meiner Sicht so beschreiben, dass es der Ort ist, wo ich Daten für langfristige Speicherungen ablege. Und insbesondere in einer Art und Weise, dass sie sehr sauber sind, also sehr verlässlich. Verlässlichkeit ist mit Sicherheit eine der wichtigsten Eigenschaften eines guten Data Warehouses. Und dass sie eben in einer Struktur gespeichert sind, die für Abfragen großer Mengen aggregierter Daten optimiert ist. Und damit eben auch einen definitiven Unterschied zu den operativen Systemen, wo ich ja im Grunde genommen immer Einzeltransaktionen vornehme. Also wenn eine Bestellung passiert, ein Datensatz aktualisiert wird, wo ich einzelne Aufrufe vielleicht auch noch weiche, aber wo auf jeden Fall auch die Abfrageart eine ganz andere ist.

Johannes Schaback: Manche Leute sprechen ja über Data Warehouses im Sinne der Datensenke. Write once, read multiple times. Ist das auch eine zulässige Definition eines Data Warehouses, dass ich im Grunde historische Daten einfach einmal ablege, sie zwar zigmal lese, aber ja, nie wieder anfasse?

Michael Franzkowiak: Genau, also auf jeden Fall. Das zeichnet definitiv eine gute Architektur aus. Also ich muss mir definitiv Gedanken machen, wenn ich in meinem Data Warehouse auf die Idee komme, Aktualisierungen vorzunehmen. Im Grunde genommen sollte das, man sagt so schön, Append-Only sein. Ich hänge neue Datensätze an und arbeite dann damit.

Johannes Schaback: Es gibt ja seit Kürzerem den Begriff des Data Lakes. Was ist genau der Unterschied zwischen Data Lake, also im Sinne des Sees, und Data Warehouse?

Michael Franzkowiak: Also für mich habe ich das immer so definiert, dass im Grunde genommen der Data Lake eine Art von Rohdatenspeicher ist, wo ich im ersten Schritt mal alles ablege in der granularsten Form, wie ich es überhaupt verfügbar habe. um so einen Ort zu haben, der für mich auch das Interface darstellt, für alle Leute, die mit Daten arbeiten wollen, zu sagen, da kann ich hingehen, da habe ich auf alle Daten Zugriff in der granularsten Form, kann sie von dort aus verarbeiten, kann sie transformieren, dann auch in das Data Warehouse schreiben, kann aber jederzeit wieder zurückgehen, kann diese Transformation noch einmal ausführen und weiß einfach, dass ich keine unterschiedlichen Schnittstellen zu den einzelnen Tools verstehen muss, sondern mich immer an diesen Data Lake wenden kann.

Johannes Schaback: Vielleicht können wir auch nochmal etwas konkreter beschreiben, wie sieht ein Data Warehouse eigentlich aus? Weil zurzeit ist Data Lake und Data Warehouse noch sehr abstrakte Begriffe. Und ich könnte mir vorstellen, dass es für viele Hörer interessant ist zu verstehen, was ist denn das jetzt eigentlich technisch? Also wenn ich mir das jetzt mal räumlich als irgendein geometrisches Objekt oder als irgendetwas, was ich mir vorstelle, als Programm, was ich laufen lasse. Was ist denn so ein Data Lake oder Data Warehouse? Wie kann ich mir das vorstellen als Nicht-Techie, um das irgendwie besser zu beschreiben? Abends beim Bier.

Michael Franzkowiak: Also es ist definitiv eine Datenbank, es sind Tabellen. Ich habe Datensätze mit Spalten und Verknüpfungen zwischen den unterschiedlichen Tabellen. Ich habe zum Beispiel Fakten über Besucher auf meiner Seite, über Produkte, die verkauft wurden, über bestimmte Transaktionen, die ich durchgeführt habe, Versendungen, all solche Sachen. und habe die verknüpft mit den Entitäten, also mit den Objekten oder Personen, die für mein Businessmodell relevant sind, die mit jeweils diesen Vorgängen dann zu tun haben. Also an einer Bestellung hängt dann der Kunde, der gekauft hat, das Produkt, was verkauft wurde und solche Sachen.

Johannes Schaback: Wir gehen jetzt auch schon in diesen ersten Track sammeln. Lass uns noch ein bisschen über die Daten sprechen, die da reingehen. Im Florian Heinemann Podcast wurde ja schon ein bisschen darüber genannt, was ist jetzt in der Online-Marketingwelt insbesondere für Daten da reingehen. Was sind aus deiner Praxiserfahrung heraus häufige Daten, die in so ein klassisches Data Warehouse gehen, neben Online-Marketing-Themen?

Michael Franzkowiak: Ich würde sagen, aus meiner Erfahrung sind die beiden ganz wichtigen Quellen, die als erstes in einem Data Warehouse zusammengeführt werden und reinfließen, die Daten und die Datenströme, die Nutzerverhalten, Bewegungsdaten abbilden, die ich da zusammenführe mit meinen Transaktionen, Daten aus meinen Backend-Systemen.

Johannes Schaback: Also zum Beispiel könnte man sich das so vorstellen, immer wenn ein Nutzer eine Seite aufruft, eine URL aufruft, dann wird ja ein Request sozusagen bearbeitet vom Webserver. Und dieses Event, es ist folgende URL aufgerufen worden mit dem und dem Session-Cookie, das wäre so ein Datenpunkt. Und dazu könnte man noch alle möglichen Informationen wie Lifetime-Cookie, wie lange hat es gedauert, diesen Datenpunkt zu verarbeiten oder diesen Request zu verarbeiten. Solche Daten wären dann so Tracking-Daten, also auf dem rohen Niveau, so weit unten.

Michael Franzkowiak: So würde ich sie definitiv in einem Data Lake sammeln und dann gegebenenfalls aggregiert ins Data Warehouse überspielen. weil ich im Data Warehouse nicht notwendigerweise alle einzelnen Sessions haben muss, weil mein Business Analyst am Ende Leute, die eher auf Entscheider-Ebene unterwegs sind, ja nicht in die einzelne Session runtergehen müssen, sondern sie wollen Entwicklungen sehen darüber. Wenn ich dann allerdings sage, ich möchte Automatisierung vornehmen, Recommendation Engines bauen etc., dann brauche ich die Rohdaten und würde das eben aus dem Data Lake heraus machen. Und um nochmal auf deine Frage zurückzukommen, also unter Bewegungsdaten, Nutzungsdaten verstehe ich eigentlich alles, was mit Interaktionen, Kontaktpunkten mit Kunden zu tun hat oder mit Nutzern oder potenziell Interessierten. Also das bezieht sich natürlich ganz stark jetzt auf Business-Modelle, die eher so im B2C-Bereich angesiedelt sind, wo ich sehr viele Kontaktpunkte auch habe. Im B2B-Bereich, wenn ich jetzt ganz hohen Einkaufsvolumen und relativ wenigen Kunden hantiere, habe ich ganz, ganz andere Fragestellungen.

Johannes Schaback: Aber dafür hast du möglicherweise Robotik, Sensordaten, Verarbeitungsdaten, Verschleißdaten.

Michael Franzkowiak: Genau, genau, genau. Wie ist das eigentlich, wenn man noch ein bisschen über Daten spricht?

Johannes Schaback: Also man will ja, das hast du eingangs gesagt, eigentlich alle Daten zentral an einem Ort haben für eine Firma. Zumindest möchte man sie auswerten können. Und solche Sachen wie HR, also Mitarbeiterzahlen, Churn, Financial Data, gehört das auch da rein?

Michael Franzkowiak: Idealerweise definitiv. Idealerweise habe ich natürlich im Data Warehouse ein umfassendes Bild der Gesamtperformance und der Gesamtgesundheit des Unternehmens über Bereiche hinweg. Das ist aber immer ein Ziel, dem man, glaube ich, ein Stückchen hinterherläuft, weil sich Organisationen einfach auch, wenn sie wachsen, nochmal mehr verändern und damit auch die Datenlandschaft sich immer verändert. Insofern muss da, denke ich, auch mal ganz stark natürlich priorisiert werden, was auch zum jeweiligen Stadium des Unternehmens dann passt.

Joel Kaczmarek: Aber ist es so ein Fall von viel hilft viel? Also dass du sagst, möglichst viele Rohdaten in so ein Lake reinkippen, damit ich hinterher jeden möglichen denkbaren Fall habe, den ich analysieren kann? Oder macht das gar nicht so viel Sinn, wenn man sich eigentlich selber überfordert?

Michael Franzkowiak: Also ich halte das für absolut sinnvoll und relevant, das möglichst früh aufzusetzen und auch für den Fall, dass man eigene Backend-Systeme entwickelt, sicherzustellen, dass man daraus saubere Datenexporte, saubere Dumps jederzeit in den Data Lake einspielen kann, dass man Drittanbieter so auswählt, dass man sauberen Zugriff auf die Rohdaten hat. damit man sich da einfach alle Optionen offen hält für die Zukunft. Und ganz wichtig ist definitiv zu sagen, dass man schon eine Common-Sense-Auswahl trifft von den Daten, die man dort ablegt. Aber immer wenn es um Bewegungsdaten geht, wenn es um Daten von Tools geht, die irgendwo eine Business-Relevanz haben, weil ich darüber Geld ausgebe, weil ich darüber mein Fulfillment tracke, all solche Sachen, dann sollte ich definitiv als Auswahlkriterium auch mit einbeziehen, wie gut komme ich an die Daten? und die Daten möglichst früh dann auch historisch korrekt ablegen und verfügbar machen für weitere Fragestellungen, die sich in der Zukunft ergeben.

Johannes Schaback: Wie kriege ich meine Daten eigentlich in so ein Data Lake rein? Also stell dir mal vor, ich bin jetzt so ein mittelständischer Schraubenhersteller. Ich habe etliche Daten irgendwie rumliegen, teilweise in Excel, teilweise in MySQL-Datenbanken, teilweise in Google Analytics. Ich will jetzt diesen wunderbaren Zustand von zentraler Datenverwaltung und Zugriff und Cross-Referencing herstellen. Was mache ich jetzt? Wie kriege ich diese Daten rein?

Michael Franzkowiak: Ich glaube, das sind natürlich zwei Teile. Auf der einen Seite muss ich einen entsprechenden Data Lake aufgesetzt haben, also die Storage. Im Grunde genommen kann man sich das vorstellen wie ein verteiltes Dateisystem, was einen fast unendlichen Speicherplatz zur Verfügung stellt. Und auf den lege ich im Grunde genommen große Dateien. Dateien, die die Rohdaten aus den entsprechenden Quellen enthalten. Das kann ich mir entweder in-house aufsetzen, indem ich mir so ein Hadoop-Cluster aufsetze, Ich kann das auf allen von den großen Cloud-Anbietern tun, die da auch ganz, ganz viel investieren, um einfach sehr gute Infrastruktur aufzusetzen. Und wo ganz klare Empfehlung von meiner Seite wäre, zu sagen, wenn man sich da nicht einen definitiv großen Operations-Overhead ins Haus holen möchte, dann sollte man definitiv in Erwägung ziehen, auf einen dieser Anbieter zu setzen. Das ist das eine. Also ich brauche den Data Lake, diesen Storage, in dem ich das ablegen kann. Und das andere ist natürlich, ich muss die Daten aus den Schnittstellen holen, ich muss sie gegebenenfalls transformieren und ich muss sie dann ablegen. Das ist der so schön benannte ETL-Prozess. Das ist der dreckigste Teil der ganzen Data Pipeline. Das ist das, wo mit Sicherheit am meisten Stunden draufgehen, wo der meiste Ärger lauert. Und wo es ganz, ganz, ganz entscheidend ist, dass wenn man kann, man auch die richtigen Schnittstellen von vornherein zur Verfügung hat. Weil wenn das Kind mal in den Brunnen gefallen ist, wenn man irgendwelche Legacy-Systeme drin hat, wenn man einfach Tools hat, die gegebenenfalls sogar für den Datenexport nochmal Rechnung stellen, weil man nur mit einem bestimmten Connector auch wirklich skalierbar an die Daten kommt, dann ist man gefangen. Und dann ist man gefangen sowohl in Hinsicht auf Kosten, wenn man sich diesen Zugang auf die eigenen Daten eigentlich erstmal kaufen muss, aber auch in Bezug auf, wie viel Zeit dann zu investieren ist, um das Ganze aufzusetzen. Und das darf man auch nicht unterschätzen in Sachen Aufwand, um das Ganze zu monitoren und sicherzustellen, dass die Datenqualität hoch bleibt.

Joel Kaczmarek: Ich habe mal geguckt, wenn man irgendwie Data Warehouse mal bei AdWords checkt auf Suchcluster, was wird am meisten gesucht, dann ist immer Data Warehouse ETL sehr, sehr weit vorne. Kannst du vielleicht nochmal für jeden, der jetzt nicht so technisch bewandert ist, ein bisschen sagen, was so ein ETL-Prozess genau ist und wie man den vielleicht am besten in den Griff bekommt?

Michael Franzkowiak: Ja, das ist definitiv ein Thema, wo wir auch ganze Nachmittage drüber sprechen könnten. Insofern versuche ich das relativ einfach zu halten und es gibt auch keine Patentrezepte. Das ist einfach ein Bereich, wo viel Aufwand und definitiv an einigen Stellen Fachwissen notwendig ist. ETL steht ja erstmal für Extract, Transform, Load. Was, wenn man diesen drei Buchstaben folgt, bedeutet Extrahieren der Daten. Ich muss erstmal überhaupt drankommen. Dann habe ich die Daten in einer Struktur, wie sie mir von den Schnittstellen zur Verfügung gestellt werden, was vielleicht gar nicht die Struktur ist, in der ich sie dann auch für die Langzeitspeicherung ablegen möchte. Ich transformiere die Daten also, das ist der T-Bestandteil und dann Load, man könnte hier auch sagen persistieren, Storage, dann lege ich die Daten ab und dafür gibt es Diverse Tools am Markt. Es gibt ETL-Tools, die das Ganze in einer sehr grafischen Art und Weise abbilden, wo ich also Graphen bauen kann und meine Datenflüsse dann auch sehr schön visuell modellieren kann. Daneben gibt es natürlich so das, was, glaube ich, jedem Entwickler als erstes einfallen würde, nämlich Skripte zu schreiben, die ich dann mit einem gewissen Scheduling regelmäßig ausführe. Ganz traditionell laufen solche Sachen dann alle paar Stunden jeweils in der Nacht ab. greifen auf die Daten zu, transformieren die dann, legen sie irgendwo ab. Und ich glaube, was da jeder aus Erfahrung kennt, der in dem Bereich mal aktiv war, ist, man fasst solche ETL-Jobs relativ häufig an. Nämlich dann immer, wenn sich etwas verändert, wenn mal die Schnittstelle nicht zur Verfügung stand, wenn ich also auf einmal von den letzten paar Tagen nochmal wieder was hinterher importieren muss. Und dann fängt der Knatsch eigentlich erst so richtig an, weil ich dann eben schauen muss, was habe ich schon drin, was fehlt mir noch. Wo gab es vielleicht auch mal Daten, die falsch importiert wurden? Das ist so fast einer der Super-GAUs, wenn ich das erst mal drin habe in meinem Data Warehouse. Also da hängt relativ viel dran. Deshalb die absolut wichtigste Empfehlung aus meiner Sicht ist, immer zu schauen von vornherein, wenn man sich neue Sachen anschafft, wie gut komme ich an die Daten und wie sauber komme ich dran? Wenn man erst mal eingeloggt ist, ist es ganz schwierig. Da gibt es auch keinen Silver Bullet, wie man so schön sagt.

Johannes Schaback: Bei uns ist das intern benannt mit Datenhomogenisierung. Eine weitere Herausforderung, die wir immer wieder bei uns bei Lahnzeile intern feststellen, ist, dass die Unit oder die Einheit, in der die Daten kommen, auch gar nicht klar sind. Also die klare Definition, was ist das eigentlich, was ist das genau für ein Datenstrom? Jede einzelne Zahl genau zu verstehen, wie ist die zu interpretieren? oder ist die möglicherweise sogar schon voraggregiert? Bei welchem Zeitraum wurde diese Zahl, diese Metrik erfasst? Was ist das genau für eine Metrik? Das ist auch etwas, was immer in diesen ETL-Prozessen mit einspielt. Wenn dann wirklich eine ganz klare Definition vorliegt und genaues Verständnis, was sind diese Ausgangsdaten, dann fange ich an, einen Wolf zu transformieren und transformiere die eigentlich komplett falsch, schreibe sie falsch in mein Data Warehouse, werte sie dann aber auch entsprechend auf einer falschen Annahme aus. Und das ist etwas, was wir auch immer wieder merken, dass wir ganz sicher stellen müssen, wir haben genau verstanden, wie wurden diese Daten erfasst und was ist diese Definition eines einzelnen Datenpunktes.

Joel Kaczmarek: Ist es nicht eigentlich auch problematisch, was du gerade gesagt hast, wenn man das nur einmal in der Nacht irgendwie einlädt? Also mittlerweile ist man doch eigentlich auf einem Level angekommen, wo man Data Warehousing in Echtzeit machen will, so wie ich das mitkriege, oder?

Michael Franzkowiak: Ja, ich würde sagen, also in fast Echtzeit. Ich glaube, es macht keinen großen Unterschied in einem Data Warehouse, wenn man jetzt wirklich darüber spricht, dass ich hier visuelle Reports zur Verfügung stelle und meinen Business-Nutzern Entscheidungshilfen an die Hand gebe. Da ist es nicht so relevant, dass das Ganze innerhalb von, ich sage mal, unter einer Minute zur Verfügung steht. Für Veränderungen, die ich da entdecke, habe ich hoffentlich Alerting, habe ich Monitoring, auch auf den Business-Metriken. Und für alles, was so in Richtung Personalization, Recommendation geht, da habe ich sowieso hoffentlich andere Pipelines aufgesetzt. Aber klar, das Ziel muss sein, dass ich diese Reports in sehr kurzem Zeitraum aktualisierbar halte. Und insofern ist aus meiner Sicht natürlich jetzt auch gerade in den letzten Jahren ganz klar so ein Trend zu erkennen, dass viele gute Systeme auch Event-Streams zur Verfügung stellen. Gerade wenn es eben um die Nutzungs-, Bewegungsdaten, Vorfälle im Allgemeinen geht, Wo ich natürlich dann, wenn ich quasi einzelne Events, die bei mir ankommen, nacheinander verarbeiten kann, fast immer auf dem quasi aktuellsten Stand bin und damit auch ein anderes Modell habe als dieses nächtliche oder alle paar Stunden vorgenommene Batch-Transformationen.

Joel Kaczmarek: Lass uns doch da mal so ein bisschen in den Bereich Zusammenführen rüber wechseln. Also wir haben jetzt viel über Daten sammeln gesprochen. Vielleicht können wir mal als Brücke das Thema Technologie nehmen, weil du eben auch schon gesagt hast, es gibt teilweise ETL-Software-Tools, die viele benutzen. Ich weiß, die Leute, die sich das anhören, die sind immer heiß darauf zu wissen, was empfiehlst du für Tools, was für welchen Teil. Vielleicht können wir mal da so ein bisschen irgendwie reintauchen und mal versuchen, was sind so typische Technologien für moderne Data Warehouses? und dann vielleicht auch, was gibt es da für ganz konkrete Lösungen, die sich empfehlen.

Michael Franzkowiak: Also ich bin definitiv ein großer Fan von den großen Cloud-Anbietern, wenn es um das Thema Infrastruktur geht, weil ich einfach glaube, dass man sich da schon sehr, sehr viel Zeit sparen kann. Gerade wenn man intern, in-house jetzt nicht das ganz große BI-Programm und Data Engineering Team zur Verfügung hat. Und ich würde auch da definitiv vielleicht etwas höhere Kosten oder gefühlt hohe Kosten am Anfang akzeptieren, einfach um zu sagen, man spart sich die Zeit und man kann sich auf das Wichtige konzentrieren.

Johannes Schaback: Also das sind so Amazon Redshift und Google BigQuery, ne?

Michael Franzkowiak: Genau, also ich würde jeweils dann sagen, wir haben natürlich die Möglichkeit eben auf, bei Amazon wäre es S3, die Rohdaten abzulegen und da einfach, ich glaube, wenn man so einen Terabyte an Daten pro Monat ablegt, ist man irgendwo bei knapp 40 Euro. Also das ist absolut im grünen Bereich. 40 Euro pro Monat. 40 Euro pro Monat für einen Terabyte an Storage, was eben auch ausfallsicher gut verfügbar für weitere Transformationen dann da vorliegt. Und woraus ich dann eben auch meine Transformationen vornehmen kann, um sie in eine Datenbank, in ein Data Warehouse zu überführen. Das wäre im Falle von Amazon dann Redshift als eine verteilte SQL-Datenbank, die im Grunde genommen Postgres ist, als ein Interface von der Natur her ist und damit eben auch sehr schön kompatibel ist für diverse BI-Tools, die eben darauf aufsetzen und Visualisierungen und Reports dann erstellen können. Azure von Microsoft, Google haben ähnliche Technologien, arbeiten auch genau an den gleichen äquivalenten Angeboten. Dazu kommt dann die Möglichkeit, Streams zu verarbeiten. Bei Amazon wäre das Kinesis und Firehose, um die Daten direkt weiter ins Data Warehouse zu pipen oder eben gleichzeitig auf S3, also im Data Lake abzulegen. Und da merkt man schon, dass da auch eben sehr ganzheitlich gedacht wird, indem wir diese einzelnen Komponenten zusammenarbeiten. Und häufig denkt man sich, glaube ich, gerade wenn man aus einer sehr technischen Seite kommt, dieser Service, den können wir selber bauen oder selber zumindest aufsetzen. Es ist ja auch vieles davon als Open-Source-Technologie verfügbar. Ich glaube, der große Mehrwert kommt dann, wenn man eben mehrere dieser Angebote nutzt und die eben sehr, sehr schön zusammenstecken kann. Weil da wird es dann irgendwann schon sehr, sehr aufwendig, diese Ops auch wirklich aufzusetzen.

Johannes Schaback: Gibt es trotzdem Unterschiede, die du benennen kannst? Also Google, zumindest preislich, hat ja einen anderen Ansatz als ein Redshift schon noch. Das ist ja manchmal ein Eindruck, dass auf Google Cloud durchaus versucht wird, preislich Amazon anzugreifen. Es gibt ja richtige so religious wars zwischen diesen zwei Lagern. Ist es jetzt BigQuery versus Redshift? Unabhängig von der Open-Source-Community. Wie würdest du, wenn ich jetzt vor der Entscheidung stehe, mich links oder rechts zu entscheiden, was würdest du sagen? Was sind so Kriterien, die ich prüfen müsste? Welche Technologie die richtige für mich ist?

Michael Franzkowiak: Du hast jetzt auch Azure noch vergessen, die gerade in dem Big Data Bereich enorm viel investiert haben. Und auch ein ganz, ganz spannendes Angebot, glaube ich ehrlich, in dem ganzen Machine Learning Bereich draufgesetzt haben jetzt, wo sie vielleicht sogar an einigen Stellen ein Stück weiter sind. Das glaubt man nicht, aber es ist definitiv auch einer der Bereiche, wo Microsoft sehr, sehr innovativ vorgegangen ist und sehr viele schöne Sachen jetzt verfügbar gemacht hat. Man kann definitiv sagen, Amazon Web Service ist so ein bisschen ein Safe Bet. Das ist mit Sicherheit das, wo ganz viele auch Techies einfach drauf gucken, wo ich auch immer, denke ich, ganz gut Leute finden kann, die sagen, habe ich schon mal was mitgemacht, habe ich schon mal gesehen. Also ein ganz bisschen so ein sicherer Standard geworden, einfach als First Mover, als derjenige, der auch ganz viel investiert immer und investiert hat. in das ganze Thema Developer Relations etc. Und insofern aus meiner Sicht mit Sicherheit das, was ich immer auch mit als erstes evaluieren würde, um dann zu schauen, was kriege ich bei den anderen beiden an Möglichkeiten. Wenn ich jetzt als Startup unterwegs bin, kann es da definitiv auch sehr, sehr aggressive Förderprogramme geben, wo ich von Microsoft gegebenenfalls für drei Jahre 300, 400.000 Dollar an Credits bekomme. Was dann auch definitiv zu der Entscheidung führen kann, zu sagen, da gehe ich jetzt erstmal hin und halte mir aber möglichst auch Optionen offen, natürlich eines Tages nochmal wechseln zu können.

Joel Kaczmarek: Ist das, wenn man sich einmal verheiratet hat, kommt man nicht mehr zurück?

Michael Franzkowiak: Ich denke, man kann schon nochmal zurückkommen. Das hängt natürlich davon ab, wie man das Ganze aufsetzt, wie viel man auch dann bereit ist zu investieren. Die Hoffnung ist natürlich, dass da ein starker Log-In-Effekt bleibt und dass einfach der Preisunterschied am Ende nicht so groß ist, dass da nochmal eine Migration stattfindet. Aber es investieren auf jeden Fall alle sehr, sehr stark gerade da rein. Und wenn man sich geschickt anstellt, kann man bei Microsoft und Google, insbesondere bei Microsoft, mit sehr, sehr hohen Credits arbeiten und hat damit auch nicht die schlechteste Lösung, definitiv.

Joel Kaczmarek: Aber hat jetzt nicht Techie hier am Tisch, also sprich ich, das jetzt richtig verstanden, dass irgendwie Amazon, Google, Microsoft jetzt eher das Thema Data Lake wären, also es wäre eher eine Softwaregeschichte, wo ich die Daten sozusagen hinlege und der eigentliche Data Warehouse Prozess wäre sozusagen nochmal ein anderer Softwareanbieter.

Michael Franzkowiak: Ich würde im ersten Schritt genau die Daten auf deren jeweilige Rohdaten Speicher legen, um von dort aus dann Daten zu transformieren und sie in die jeweiligen Data Warehouse Lösungen zu überführen. Das bedeutet, bei Azure würde ich sie in Azure SQL überführen, bei Amazon gegebenenfalls in Redshift und bei Google in BigQuery, die jeweils ein bisschen andere Angle haben. Ich glaube, das geht jetzt vielleicht ein bisschen zu weit ins Detail, die einzelnen zu besprechen, aber die sehr, sehr vergleichbar sind. Und es arbeiten auch alle drei daran, da wirklich kompetitiv zu bleiben. Und dazu kommt natürlich, und das ist eben auch wirklich wichtig aus meiner Sicht, es verschiebt sich immer mehr in Richtung Stream Processing. Und insofern dieses Konzept eines Data Lakes, wo ich also statische Daten zusammenführe und so einen Langzeitspeicher habe, das kann man eigentlich mittlerweile erweitern um so eine Art von, ich nenne es mal Data River oder ein Hub, wo eigentlich alles an Streams auch erst einmal zusammenführt, sodass ich weiß, wenn ich historische Daten anzapfen möchte, dann gehe ich zu meinem Data Lake, da liegt alles, alles an Rohdaten, da kriege ich alles raus. Wenn ich in Real-Time an einzelne Events dran möchte, irgendwas, was irgendwo in meiner Firma passiert, irgendwelche Vorfälle, ich stelle mir das immer so vor, man steht an so einem Fluss oder an so einer Autobahn und sieht eigentlich alles, was im Unternehmen gerade passiert, so an sich vorbeifahren, dann würde ich das eben in meinem Event-Hub machen. Und dafür gibt es dann solche Sachen wie Amazon Kinesis.

Johannes Schaback: Das ist ganz interessant, Lanza hat vor anderthalb Jahren sich entschieden, ein neues Data Warehouse aufzubauen oder eine neue Dateninfrastruktur, so wie wir das nennen. Und für uns war es sehr wichtig, dass wir modular geblieben sind, also dass wir die einzelnen Komponenten dieses ganzen Konglomerats, was nachher ein Data Warehouse ausmacht, im Grunde ersetzen können und sind, weil wir von Haus aus immer unsere eigene Hardware kaufen, den Weg gegangen, Open-Source-Lösungen zu verwenden. Also wir verwenden nämlich als Data Mass Storage Hadoop, das Hadoop File System, und lassen im Grunde darüber verteilt Impala laufen. Impala ist im Grunde dieses Repshift-System. Äquivalent, wenn man so will. Du hast eine SQL-Interface auf deine statisch abgelegten Daten, die du auch nicht mehr schreiben kannst. Du kannst sie nur noch lesen, aber sie sind indexiert. Das heißt also, es ist relativ schnell, solche beliebigen Abfragen zu schreiben. Und darüber der Visualisierungslayer, über den wir ja noch jetzt gar nicht gesprochen haben, weil wir erst im Nutzen-Track darüber sprechen werden. Der Visualisierungslayer ist bei uns dann Spotfire. Und das ist wirklich ganz interessant. Wir haben auch diese Kostenkalkulation gemacht und für uns war das schon wirklich ein erheblicher Teil. Ich glaube aber auch, wenn du wirklich von scratch anfängst und noch gar nichts hast, dann macht es total Sinn, sich so eine Hosted-Lösung zu nehmen. Zum Thema Zusammenführen noch einmal. Also Contiamo stellt sich auch dort auf, wo viele sehr, sehr unterschiedliche kleine Datenflüsschen zusammenkommen. So habe ich es hoffentlich richtig wiedergegeben. Korrigiere mich, wenn ich falsch stehe. Wie schafft es Contiamo eigentlich, diesen ja total heterogenen, sehr, sehr unterschiedlichen Umgebungen zusammenzuführen und eigentlich eine zentrale Stelle für alle Daten zu werden?

Michael Franzkowiak: Im Grunde genommen haben wir eine Art von Virtualisierungsschicht entwickelt, die auch über Datensätze hinweg funktioniert, die nicht notwendigerweise physisch an einem Ort zusammenliegen. Und wir haben also versucht, Daten verfügbar zu machen, ohne dass sie notwendigerweise in einem Data Warehouse zusammengeführt werden. Materialisieren dann bestimmte Abfragen bei uns und können so auf der Zugriffsschicht ein bisschen von dem Aufwand wegnehmen, der sonst zur ETL- und Datentransformationszeit anfallen würde, werden dadurch ein bisschen flexibler. Natürlich auch mit gewissen Einstrengungen dann, was man eben zur Abfragezeit machen kann. Das ist im Grunde genommen unser Ansatz und das ist definitiv auch ein Trend, den man jetzt gerade sehen kann, der sich in der gesamten Industrie vollzieht, wo man an einigen Stellen gemerkt hat, gerade wenn es um die nicht absoluten Kerndaten geht, die aus Software-as-a-Service-Tools kommen, die nur bestimmte Abteilungen nutzen, dass es da teilweise etwas schwer fällt, mit den sich verändernden Datenstrukturen zu arbeiten, die immer wirklich an einem Ort zusammenzuführen und dieses eine Data Warehouse sauber zu halten. Und insofern Auch mit der zur Verfügung stehenden schnelleren Verbindung zwischen unterschiedlichen Daten-Storages und mehr Computing-Power zur Abfragezeit ist es eben jetzt auch ein gangbarer Weg, an einigen Stellen zu sagen, ich frage Daten aus unterschiedlichen Quellen ab und zeige sie dann erst in den Resultaten zusammen an. Ich glaube aber für Kerndaten, für das, was mein Geschäft ausmacht, Und für die Bewegungsdaten muss das Ziel immer sein, die wirklich an einem Ort zusammenzuführen, weil nur dann kann ich darauf auch die richtigen Algorithmen laufen lassen und dann habe ich die meisten Möglichkeiten. Das ist definitiv auch das Ziel. Da helfen wir auch Unternehmen mit Sicherheit auch dabei, auch unseren Kunden. Und ich glaube, das wäre vermessen zu sagen, das könnte man komplett ersetzen.

Joel Kaczmarek: Was ist denn eigentlich so generell dein Ratschlag? Weil wenn ich jetzt Unternehmer wäre, was Johannes gerade gesagt hat, der hat gerade so ein bisschen seine Eigenbaulösung beschrieben. Wir haben davor ein bisschen geredet über Amazon, Google, Microsoft. Man ist ja immer bei diesem Thema Off-the-Shelf versus Eigenbau Open Source. Wie geht man daran? Also das ist wahrscheinlich eine epische Diskussion jetzt in sich genommen, aber jetzt mal so ein bisschen versuchen abschließend zu sagen, Diese Mischkalkulation mit mehreren Services versus alles aus einer Hand off the shelf. Was hast du da so das Gefühl, ist da so der Weg zu gehen? Und vielleicht ist das ja auch so eine Frage, ab irgendeiner Phase macht das eine Sinn und irgendwann das andere.

Michael Franzkowiak: Also mein Gefühl ist ganz stark, das finde ich auch ganz interessant. Bin natürlich jetzt auch so ein bisschen voreingenommen dadurch, was ich so aus der Startup verstehe. Dass sich im Grunde genommen in dem BI-Bereich jetzt so eine Entwicklung vollzieht, die man auch vorher so in dem Systemadministratoren-Bereich gesehen hat, nämlich dass das Ganze mehr und mehr von Entwicklern getrieben wird, als von Leuten, die Experten für einzelne Tools sind und in so einem Enterprise-Tool leben und da zusammenarbeiten. absolutes Expertenwissen aufgebaut haben und insbesondere gilt das für die Schritte Datentransformation, Datenspeicherung. Dann wenn es um die Visualisierung geht, da sind definitiv so off-the-shelf-Tools auch glaube ich weiterhin absolut relevant, weil sie sich eben ganz stark auch mit Oberflächenzugänglichkeit dann beschäftigen. Insofern würde ich das aus meiner Sicht gesehen auch häufig so ein bisschen als Best Practice so beschreiben, dass man in dem Bereich Datenextraktion gegebenenfalls auf Tools setzt, wie Tailend etc., die einfach auch grafische ETL-Prozesse zulassen. Wenn man etwas stärker auf der Entwicklungsseite ist, dann kann man das mit Sicherheit auch mit verschiedenen Frameworks machen, die eben auch solche Jobs ausführen und auch monitoren können. Dann ist es also eher eine Art von wirklich Programmierleistung, die da erbracht wird. Auf der Data-Storage-Seite, denke ich, ist das mittlerweile relativ klar, dass wenn ich das Inhouse aufsetze als Data Lake, dann werde ich so wie bei Ladenzeile auch, dann ist das Hadoop. In welchem Format ich es dann drauf speichere, ist dann wieder eine andere Frage, ob als Avro Parquet etc. Und in Sachen Datenbanken, glaube ich, gibt es für wenige Unternehmen, um ganz ehrlich zu sein, die Notwendigkeit zu sagen, dass sie in-house da die ganz teuren BI-Data-Warehouse-Datenbanken aufsetzen. Also wenn ich schon den Schritt gegangen bin, zu sagen, ich setze mir einen eigenen Hadoop-Cluster auf, dann kann ich darauf, so wie es Ladenseiler auch macht, Impala laufen lassen, Hive. Hive ist sehr, sehr fix geworden, gerade über große Datenmengen. Oder wenn meine Datenmengen einfach noch nicht so groß sind oder ich die Daten auch hinreichend aggregieren und kombinieren kann, bevor ich sie ins Data Warehouse dann schiebe, dann funktioniert es auch, sich da eine gute Postgres-Datenbank hinzusetzen, gegebenenfalls in einem der verteilten Flavors, Citus, TB etc. Und damit kann ich auch sehr schön arbeiten.

Johannes Schaback: Entscheidend ist natürlich auch, müssen die Daten on-premise also vorliegen? Muss ich 100% Kontrolle physisch über diese Daten haben? Es gibt durchaus Unternehmen, die können das aus Policy-Gründen nicht zu Amazon hochladen. Dann bist du darauf angewiesen, dass du physische Server bei dir im Keller stehen hast, auf denen deine Daten liegen. Grundsätzlich würde ich aber auch sagen, wenn du kannst, versuch erstmal gerade am Anfang eine offte Schärflösung zu nutzen. Auch am Anfang sind die Kosten ja eher gesagt gering, dass du da relativ wenig kaputt machst. Ein Thema, was immer wieder in dieser Bubble um Data Warehouse und auch Data Science auftaucht, sind OLAP-Cubes. Was ist das eigentlich? Also kannst du das beschreiben für nicht-technische Personen?

Michael Franzkowiak: Ja, und zwar ist es ja so, dass ich, wenn wir mal sagen, ein Unternehmen hat jetzt einen schönen Rohdatenspeicher, hat die Daten von da aus oder auch direkt ins Data Warehouse überführt, hat also sehr schönes physisches Schema, wie man so sagt, also von Tabellen, die miteinander verknüpft sind. dann bedeutet das ja noch lange nicht, dass ich jetzt einem Business-User ein Tool an die Hand geben kann, wo er dann irgendwo den Umsatz sieht. Den Umsatz vielleicht runtergebrochen nach Produkten, nach Marketingkanälen, woher die Leute kamen etc. Und insofern brauche ich also als zweites eine Art von logisches Schema, was beschreibt, wie kriege ich eigentlich aus den verschiedenen Tabellen, die ich habe mit den unterschiedlichen Spalten, wo zum Beispiel in einer Spalte Wenn es die Bestellungen sind, die einzelne Preise drinstehen können, der Warenkorb, also wie viel hat diese Bestellung gekostet, wie viel Umsatz hat diese einzelne Bestellung gebracht, dann bräuchte ich im logischen Schema eine Beschreibung davon, wie komme ich jetzt davon zum Umsatz. Das wäre in dem Fall die Summe dieser Spalte, die ich dann eben runterbrechen kann nach Datum, nach Produkt, nach Nutzer etc., Und im Grunde genommen beschreibe ich in diesem logischen Schema Würfel, mehrdimensionale Würfel meiner Daten, die ich dann unterschiedlich, man sagt, slicen und dicen kann. Wo ich also sagen kann, ich möchte meine KPIs, meine Metriken runterbrechen nach verschiedenen Attributen. Im Grunde genommen ist alles, was ich im Unternehmen als eine Entity sehe oder als eine Eigenschaft von einer Entity, etwas, was ich eben als Dimension dann dort auch beschreibe und wonach ich meine Zahlen runterbrechen kann.

Johannes Schaback: Lass uns doch langsam mal zum Nutzen kommen. Ich glaube, wir haben jetzt lange über das Zusammenführen von Daten gesprochen. Also das Nutzen setzt ja voraus, dass man sich die Daten anschauen kann. Visualisierung ist ein Riesengebiet oder eine Wissenschaft für sich. Was sind so deine aktuellen Beobachtungen im Visualisierungsbereich? Was gibt es da für Tools? Was ist wichtig? Was sind, wenn ich mich jetzt wieder entscheiden müsste für ein Visualisierungstool, welches würde ich da nehmen? Was sind so entscheidende Faktoren?

Michael Franzkowiak: Also wenn du jetzt fragst, welches würdest du da nehmen, bin ich ein bisschen voreingenommen. Da würde ich definitiv auch mal mit Contiamo sprechen. Ansonsten gibt es natürlich auch die üblichen Verdächtigen, teilweise eben auch vielleicht ein bisschen mehr von der Desktop-Welt stammen, Tableau, Clickview und MicroStrategy, Lumira etc., da gibt es definitiv einige am Markt. Das beinhaltet aber eben auch immer, dass ich diesen Tools dieses logische Schema in die Hand gebe und erkläre, wie ich eben von meinen physischen Tabellen dann zu meinen schönen Reports und Zahlen komme. Heißt

Johannes Schaback: das, dass im Grunde hinter jedem Graphen, also ein Visualisierungstool ist ja dafür da, dass man sich Plotter, Charts sich angucken kann oder Graphen, also Linien über Zeit und dass ich die dann idealerweise anklicken kann und rumspielen kann und dass ich mir diese Daten, dass ich mir diesen Daten, dass ich die irgendwie haptisch erfahrbar mache im Idealfall, dass ich irgendwie durch diesen Datenraum laufen kann und merke, okay, so entwickelt sich gerade mein Unternehmen oder dass ich diese Erkenntnisse, die ich bekomme, eigentlich durch exploratives Spielen mit diesen Daten bekomme und das ermöglicht mich eine Visualisierungsschicht. Wie funktioniert das ganz konkret eigentlich? Also du hast jetzt gerade beschrieben, das Datenmodell muss verstanden werden. Wie funktioniert das eigentlich? Ich kaufe mir jetzt irgendwie so eine Off-the-Shelf-Software und klemme die an mein Data Warehouse. Wie genau können die miteinander sprechen? Wie funktioniert das?

Michael Franzkowiak: Das ist, glaube ich, ein ganz wichtiger Punkt. Das war ja schon immer und ist aber jetzt die Schnittstelle zwischen allen Zugriffen auf die Daten für Auswertungen und der Datenbank. Interessanterweise auch das, wo alle auf Hadoop basierenden Lösungen jetzt seit mehreren Jahren daran arbeiten, dann auch performante SQL-Schnittstellen zur Verfügung stellen zu können. Also da hast du absolut recht, es ist die Schnittstelle und das, was am Ende aus so einem Visualisierungstool, aus so einer Schicht rausfällt und an die Datenbank gegeben wird.

Johannes Schaback: Jetzt haben wir ja im Grunde alle Ebenen des Data Warehouse Tools besprochen. Das Visualisierungstool ist das oberste. Vielleicht noch so ein Scripting-Interface, dann käme so eine OLAP-Schicht, also so eine, ich nenne das jetzt mal Homogenisierungsschicht oder vielleicht so ein bisschen so eine Virtualisierungsschicht, um die da drunter liegendes eigentliche Data Warehouse, nämlich die eigentlichen ersten Daten,

Michael Franzkowiak: die

Johannes Schaback: abgespeichert sind, in Tabellenform in der Regel, zugänglich zu machen. Dafür ist die OLAP-Schicht da. So und dann ist da drunter, unter dieser Tabellenschicht, also unter dem Data Warehouse, wenn man so will, also unter der Datenbank, ist der Data Lake.

Michael Franzkowiak: Genau. Und dieser Stream an Daten, die gegebenenfalls eben aus dem Event Hub oder Data River oder wie auch immer man es nennt, eben auch reinfließen.

Johannes Schaback: Warum sind dann Data Warehouses trotzdem immer noch so langsam, wenn eigentlich seit Jahren daran geforscht wird und gearbeitet wird?

Michael Franzkowiak: Das ist definitiv einfach auch an vielen Stellen kein einfaches Problem. Es kommt natürlich auch darauf an, welche Fragestellung ich mir da angucke. Und am Ende läuft es wirklich darauf hinaus, wie groß sind die Joins, also die Verknüpfungen zwischen Tabellen. Und das Teuflische sind immer die sogenannten High Cardinality Dimensions, also die Dimensionen, die Attribute, die sehr viele unterschiedliche Werte haben. Das bedeutet, wenn ich also etwas versuche mir anzuschauen wie Unique User, über einen bestimmten Zeitraum. Dann brauche ich ja die einzelnen Unique User IDs und muss sicherstellen, dass ich die innerhalb des Zeitraumes wirklich nur einmal zähle. Und wenn ich dann auch solche Daten, die ich eben in sehr granularer Form brauche für die Auswertungen, noch mit einem ganz anderen Datensatz, einer anderen Tabelle verknüpfen möchte, auf dieser granulären Ebene, dann werden die Abfragen einfach sehr, sehr aufwendig. Und das ist eben auch ein ganz großer Unterschied zu transaktionalen Datenbanken, wo ich eben einzelne Records verändere, wo ich sage, jetzt speichere ich einzelne Bestellungen an, jetzt zeige ich dem Kunden seine drei, vier, fünf letzten Bestellungen an. Das sind ganz andere Abfragen, die eben nicht immer die gesamte Datenbank dann berühren, wo ich also keinen Scan über Tausende oder Millionen oder Milliarden von Records machen muss. Und insofern ist das ein Thema, wo ich glaube, einfach immer weiter daran gearbeitet, geforscht werden wird, wo aber auch die Problemstellung an sich einfach vorgibt, dass gewisse Abfragen immer aufwendig sein werden, wo mit Sicherheit auch das, was an Zuwachs auf der Computing-Seite verfügbar ist, wie auch das, was gegebenenfalls noch an Optimierungen auf der Software-Seite vorgenommen wird, ein wenig ausgeglichen wird dadurch, dass einfach die Menge an Daten auch weiter zunimmt und die Komplexität im Data Warehouse

Joel Kaczmarek: wächst. Was würdet ihr beiden denn eigentlich sagen, das geht ja so ein bisschen in den Bereich Best Practice, warum meckern eigentlich immer so viele Leute über Data Warehouses und benutzen sie nicht? Weil wenn du so mal in Organisationen guckst, was ich mitbekommen habe, ist, da wird teilweise eher Excel benutzt als sowas, was ja irgendwie massive Nachteile hat, das heißt, woran liegt das und wie kann ich eigentlich so eine Firma dazu bringen, more data-driven zu werden?

Michael Franzkowiak: Also aus meiner Erfahrung ist ganz wichtig, dass die Value Proposition stimmt. Und die ist einfach an vielen Stellen nicht einfach. Ich glaube, da müssen sich teilweise eben BI-Abteilungen, da müssen sich die Leute, die in diesen entsprechenden Abteilungen arbeiten, ein bisschen an die eigene Nase fassen und sagen, wie können wir das noch besser verkaufen? Was fehlt noch? Weil am Endeffekt muss man da wirklich konkurrenzfähig sein. Und das geht von der Einfachheit her, die Reports anzupassen und eben auch ein bisschen mit den Daten spielen zu können, über die Qualität der Visualisierung und wie schön das Ganze ausschaut, über eben nicht nur Daten abzuliefern, sondern sie gegebenenfalls noch mit Beschreibungen und Informationen zu versehen. Das ist ganz, ganz wichtig. Ich glaube, es ist absolut notwendig, dass das, was am Ende dem Business-User verfügbar gemacht wird, konkurrenzfähig ist zu dem, was er selber machen kann, was er mit Excel hinbekommt, was er gegebenenfalls auch als tagtäglicher Nutzer in seinen Tools sieht, im Marketingbereich, in allen anderen Bereichen, wo viele Tools eben eigene Dashboards etc. mitbringen. Und da muss ganz, ganz viel Feinschliff vorgenommen werden. und das ist immer so eine kleine Gefahr zu sagen, ja, die Business-User, die wollen ja nicht. Und dann würde ich sagen, ist an vielen Stellen vielleicht auch das Angebot noch nicht ganz da, wo es sein muss.

Johannes Schaback: Absolut. Ich finde, was du beschreibst, das ist super. Das ist im Grunde ein Produkt, was du vermarkten musst intern. Und ich glaube, dass du auch nicht nur ein geiles Produkt ermieten musst mit einem guten Product-Market-Fit intern, sondern dass du auch zusätzlich deine Kollegen schulen muss, dass sie wissen, wie ist es zu verwenden. und wie kann ich dieses wahnsinnige Werkzeug, diesen riesen Hammer, der mir an der Hand gegeben ist, eigentlich benutzen? Wie kann ich diesen Porsche, wie kann ich da den Motor anlassen? Und das ist häufig gar nicht so einfach, wenn die Tools natürlich nicht gut sind, wenn das Produkt nicht gut ist, aber man muss auch ein bisschen verstehen und sozusagen lernen, wie mit solchen Datenbanken und Datenmengen umzugehen ist. Also was gibt es für Graphen, was gibt es für Visualisierungsmethoden, wenn ich eine bestimmte Fragestellung habe, wenn ich etwas untersuche, wie kann ich solche Drilldowns machen. Teilweise kennen das die Leute schon aus Excel, aber dass man eben noch viel mehr machen kann, dass man eben eine viel größere Flexibilität hat und auch einen viel größeren Datenraum erfassen kann, das ist etwas, was ein Education-Problem ist, was häufig auch gar nicht so sehr da ist, weil ich mit den Tools, die ich hatte, immer eine vorgefertigte View hatte. Und ich benutze zwar zig unterschiedlich tausend Tools, aber diesen Wert, der entsteht, indem ich diese Daten zusammenführe, was ein Data Warehouse kann, das erfordert sehr viel Bildung und Hintergrundwissen über die Verwendung von Data Warehouse.

Michael Franzkowiak: Und einen ganz, ganz starken Austausch auch mit den Business-Usern. die auf der einen Seite auch mit Sicherheit sehr wertvolles Feedback geben, auch gute Ideen haben, wo aber auch immer dann das Ganze abgeglichen werden muss mit dem Wissen eben in der BI-Abteilung, mit den Leuten, die sich mit den Daten beschäftigen und wo daraus dann entwickelt werden muss, was müssen wir und wie sollten wir Sachen wirklich als Reports darstellen. Also da kann es an beiden Stellen, glaube ich, auch einfach Misskommunikation geben, die zu Problemen führt. Sowohl, dass sich Data Science, BI-Bereich Leute Themen ausdenken oder Reports ausdenken, die ein bisschen an den Business-Fragestellungen vorbeigehen, als auch, dass Business-User durch eigene Ideen, aber auch gegebenenfalls durch Anregungen von Big Data kann jetzt dies, Big Data kann jetzt das Anforderungen stellen, die am Ende in keinen sinnvollen Reports und Zahlen münden. Also ich glaube, das ist ganz wichtig, dass man diesen Diskussionskanal sehr, sehr gut aufrecht erhält und da wirklich an einem Strang zieht.

Johannes Schaback: Top down glaube ich auch, dass man viel tun kann. Wir haben bei uns intern eine Deadline festgelegt, ab wann wir alle internen Reports über unser neues Data Warehouse laufen lassen wollen. Das hat natürlich auch den Druck erhöht, aber es hat natürlich auch den Zug zum Tor verstärkt, dass alle Leute angefangen, sich damit zu beschäftigen und diesen Push bekommen haben, okay, ich muss jetzt wechseln. Ganz viel Schulung gemacht und es ist auch angeboten und den Leuten immer geholfen und supportet. Aber da kann man auch als Manager auch wirken, dass du von der einen Seite bottom-up sagst, das ist ein geiles Produkt, es zieht mich an. Gleichzeitig zwinge ich euch aber auch, es zu nutzen. Das ist, glaube ich, beides wichtig. Grundsätzlich in dem Moment, wo man den Daten nicht mehr vertraut und wo man sie nicht mehr versteht, das ist manchmal eine Mischung aus beidem. Es ist aus, das ist auch immer wichtig. Also man muss die Daten verstehen können und es muss eigentlich relativ einfach sein und es muss nachvollziehbar sein und es muss Konsistenz sein, es muss Kohärenz sein. Und wenn der User sich nicht darauf verlassen kann, was er da sieht und das wirklich auch für businessentscheidende Vorgänge verwenden kann, dann leidet natürlich so ein Data Warehouse als Produkt massiv.

Joel Kaczmarek: Hast du noch einen Tipp, wie man so ein Data Warehouse generell einführen sollte? Weil man sagt ja immer so, no second chance for first impression. Und wenn die Leute einmal lieber sagen, ach nee, jetzt mache ich weiter mit meiner Analytics-Excel-Selbstbaumaschine, ist vielleicht irgendwie der Zug abgefahren. Also nochmal die ranzukriegen, ist schwierig. Wie würdest du das machen?

Michael Franzkowiak: Ich denke, ganz gut funktioniert da so ein sehr iterativer Ansatz, sich einzelne Fragestellungen, die auch einen sehr hohen Nutzen stiften, rauszugreifen. Vielleicht Sachen, die momentan noch nicht gut abgedeckt sind und zu sagen, da hat man ein Leuchtturmprojekt intern, was gut funktioniert, dann arbeitet man sich zum Nächsten vor. Und das also so zu spielen, dass man idealerweise eigentlich viele Sachen testen kann mit Zusammenarbeit, BI, Business-User, Infrastruktur und im Grunde genommen sich Schritt für Schritt auch nach Prioritäten durch die unterschiedlichen Aktivitäten arbeitet.

Joel Kaczmarek: Was ist denn eigentlich mit dem ganzen Thema Security? Ich meine, wir reden viel davon, dass wir ganz viele Daten, Daten, Daten alle in einem Lake zusammenschmeißen, dann irgendwie OLAP-Geschichten drüber liegen und es in ein Data Warehouse pumpen über River und man kann am Fluss stehen und alle Sachen sozusagen sehen. Das ist ja aus Unternehmersicht ein Traum. Jetzt sind wir hier irgendwie im Datenschutzstandort Nummer eins. Was sagt dir da so das Thema Security? Also was sollte man da beachten und wie relevant ist sowas?

Michael Franzkowiak: Das ist definitiv sehr relevant und je größer das Unternehmen ist und je mehr Leute dann am Ende auch mit den Daten arbeiten sollen, desto wichtiger ist es, eben da auch, glaube ich, sehr gute Prozesse und auch sehr gute Mechanismen zu haben. Da gibt es auch eine ganze Reihe von Tools und Möglichkeiten, das zu tun. Ich glaube, am Anfang ist es etwas, was man sehr stark über die Abfrageschicht regeln kann. wo man für die Leute, die sowieso Rohdatenzugriff brauchen, weil sie damit umgehen können, auch entsprechende Freigaben und Mechanismen, NDAs etc. auch einfach abgebildet haben muss, sowieso für alle Leute, die auf eher aggregierte Daten zugreifen, dann über die Abfrageschicht und die Art der Auswertungen, die sie benutzen können, wo eine Zugangskontrolle sicherstellt.

Joel Kaczmarek: Ja, klingt sehr plausibel. Ich meine, ich überlege gerade, wenn du im Prinzip internes Marketing für so ein Tool machst, wie du gerade gesagt hast, gar nicht mal, dass die jetzt Daten klauen oder die irgendwie nach draußen leaken oder so. Das kann ja manchmal einfach abschreckend sein, wenn du nicht weißt, was du mit Rohdaten anfangen sollst. Wenn du eigentlich sozusagen den relativ simplen Gedanken hast, bist du bei Johannes Gefühl, wenn die kein Vertrauen haben. Also es mag ja auf solche Sachen sich auch auswirken.

Johannes Schaback: In weiterer Security ist natürlich auch dieses Injektionsproblem, wenn wir jetzt in so einem Bild des Flusses bleiben. Und du verunreinigst diesen Fluss. Du kannst natürlich auch massiv Einfluss nehmen auf die Entscheidung von Unternehmen. Das ist dann gar nicht mal so sehr das Problem, dass die falschen Leute die richtigen Daten sehen, sondern dass eigentlich die richtigen Leute die falschen Daten sehen. Glaube ich jetzt kein signifikant großes Problem, aber in der ganzen Security-Welt ist eigentlich der Mensch immer der Schwachpunkt. Das ist auch nochmal ein Thema, was immer wieder kommt. Was gerade so in solchen Amazon-Bereichen mal die Sorge ist, wenn ich das jetzt auf S3 speichere, dann werden mir meine Daten geklaut oder manipuliert sogar, um Gottes Willen. Das ist in den allermeisten Fällen unnötig, diese Sorge, aber das kommt noch damit rein. Wenn ich ein DAX-Unternehmen bin, muss ich da schon zumindest darauf achten und dann habe ich da Themen.

Michael Franzkowiak: Ich glaube aber, was man definitiv sagen muss, ist, das ist etwas, was man managen kann. Und die Vorteile, das Ganze so aufzusetzen, überwiegen bei weitem auch die Risiken, die sich daraus ergeben. Insbesondere dann, wenn man sie eben sehr gut unter Kontrolle hat und darauf auch ein entsprechendes Augenmerk legt. Was man natürlich ganz klar sieht, ist, dass notwendigerweise sich größere Unternehmen, Konzerne eben auch mit einer gewissen Historie damit sehr, sehr viel mehr Zeit nehmen müssen, viel mehr auch intern mit Hierarchien dann arbeiten müssen und gegebenenfalls auch mit etwas weniger Vertrauen in das, was die Leute auch jeweils sehen sollten. Da spreche ich jetzt gar nicht über wirklich auf den einzelnen Kunden oder auf Personenmerkmale zugreifen zu dürfen, sondern welche Zahlen dürfen die denn, welche Transparenz dürfen die überhaupt haben über Vorfälle im Unternehmen und auch Gesamtperformance des Unternehmens. Das ist natürlich was, was in einem Startup, in einem jungen Unternehmen, in einem nativ digitalen Unternehmen ganz anders gehandhabt wird und wo mit Sicherheit auch ein gewisser Wettbewerbsvorteil dann liegt, zu sagen, Wir haben hier eine sehr offene Kultur. Wir geben das erst mal sehr demokratisch, man spricht ja auch von Demokratisierung des Zugriffs auf die Daten, vielen Leuten frei, weil wir glauben, dass es sie eben motiviert und die Lage versetzt, bessere Entscheidungen zu treffen.

Johannes Schaback: Was siehst du denn für Risiken für Unternehmen, die jetzt einen Data Warehouse einführen? Das ist ja grundsätzlich sehr, sehr positiv. Du kannst eben alle möglichen Daten zusammenführen. Hast du Erfahrungen gemacht, wo ein Data Warehouse eigentlich für das Geschäft gefährlich wurde möglicherweise. Siehst du da irgendwelche Risiken? Ich sehe persönlich keine, aber es ist halt immer so eine Frage.

Michael Franzkowiak: Ich glaube, es ist wie jedes große IT-Projekt, was sich über Monate und Jahre zieht, immer eine Gefahr eines Kostengrabs. Es gibt immer die Gefahr einer Diskrepanz dessen, was auf der IT- und Engineering-Seite gebaut wird und was auf der Business-Seite gebraucht wird. Das sind, glaube ich, Sachen, die hat man bei all diesen Projekten. Und da gelten dann auch die gleichen Mechanismen und das gleiche Vorgehen, um das möglichst unter Kontrolle zu halten. Nämlich iterativ vorgehen, immer wieder Bestandsaufnahme zu machen. Mit Sicherheit ist es ganz wichtig, glaube ich, heutzutage jemanden relativ hoch angesiedelt zu haben, gegebenenfalls sogar in der Geschäftsführung, der das nicht komplett abgibt und sagt, ihr macht mal. sondern sich auch das als Teil der Unternehmensstrategie und auch als möglichen kompetitiven Vorteil wirklich intensiv anschaut und sich daran beteiligt und versucht auch entweder selbst oder mit jemandem anderen zusammen Mittler zu sein zwischen was machen wir auf der Engineering-Seite und was brauchen wir auf der Business-Seite. Das ist definitiv, glaube ich, ein ganz, ganz wichtiger Erfolgsfaktor.

Johannes Schaback: Ich würde gerne noch mal über ein bisschen andere Interfaces sprechen. Also wir haben über die Visualisierung gesprochen, das heißt also Mensch-Data-Warehouse-Interaktion. Was ist mit Maschine-Data-Warehouse-Interaktion? Also zumindest bei Ladenzeile benutzen wir viel R, also die Sprache R, um unsere Abfragen, unsere Modelle zu trainieren auf Daten, die letztendlich aus dem Data-Warehouse kommen.

Michael Franzkowiak: Die kommen aus Impala bei euch.

Johannes Schaback: Exakt. Okay. Ist das gängig? Ist das etwas, was immer mehr passiert? Weil für uns ist einfach der Vorteil, es ist ein ganz klares Interface, es ist ganz einheitlich, es ist ganz homogen und es sind hundertprozentig sichere Daten, also korrekte Daten. Ist es aber natürlich eigentlich, ein Database ist nicht dafür gebaut worden, letztendlich. Wir missbrauchen es ein Stück weit dafür, aber ist das ein Trend? Oder ist das eher eine Insellösung jetzt von uns?

Michael Franzkowiak: Ich glaube, das ist definitiv was, was auch andere machen. Auf jeden Fall. Das kommt eben auch darauf an, welche Daten komme ich auch in welcher skalierbaren Art und Weise dann im Data Warehouse dran. Und schaffe ich es da, wenn ich eben mit ganz, ganz vielen Records arbeiten möchte, mit großen Datenmengen, die ich dann nochmal verarbeite und transformiere, dann werde ich die vielleicht nicht über meine SQL-Schnittstelle da rausziehen und sagen, ich ziehe mir jetzt mal ein paar hundert Millionen Records da raus, sondern dann gehe ich vielleicht, gerade wenn ich sowas wie Impala nutze, eher an die Storage darunter, kann ja direkt auch auf HDFS zugreifen oder habe meine Daten eben dann in meinem Data Lake, wo ich da eben mit arbeiten kann, ziehe das dann in meine Hadoop Jobs oder in Spark als Computing Engine. Also insofern glaube ich, das ist ein gangbarer Weg, wenn das Data Warehouse so wie bei euch das auch von der Skalierbarkeit hergibt. Ansonsten kann man solche Sachen eben auch sehr schön wirklich mit den Rohdaten aus dem Data Lake regeln. Was aber man definitiv sagen kann, ist, dass natürlich das Thema Visualisierung, Reporting, Self-Service, ich sage mal Exploration, nur so auch immer den ersten Schritt darstellt. Und wenn ich dann wirklich tiefer in die Daten reingehe, dann gibt es eben Sachen, die ich irgendwann nicht mehr mit Drag & Drop machen kann, die ich auch nicht mehr als einfach simple Visualisierung lösen kann. Oder wo irgendwann dann auch, wenn es, es gibt ja teilweise solche GUIs, die so ein bisschen durch solche Prozesse führen, es eben am Ende relativ kompliziert wird, solche Modelle dann zu bauen und wo irgendwo der Switch dann kommt, zu sagen, okay, jetzt brauche ich A so viel Hintergrundwissen und B auch so viel Flexibilität, dass es dann Sinn macht, in Code umzusteigen. Und da ist natürlich dann R, Python, Scala gegebenenfalls einfach das Tool der Wahl, um mit den Daten zu arbeiten. Das sind dann aber natürlich auch nicht mehr die Business-Anwender, die das machen.

Johannes Schaback: Wir haben noch nicht über die Zukunft von Data-Warehouses gesprochen, was mich sehr, sehr interessiert. Was glaubst du, wie sehen die Data-Warehouses in fünf, sechs Jahren aus? Wohin geht die Entwicklung?

Michael Franzkowiak: Ich glaube, in dem Stream-Bereich passiert ganz, ganz viel. Zu sagen, gerade dann, wenn ich auf Grundlage von Daten automatisierte Aktionen vornehmen möchte, wenn ich personalisierte Feedback-Aktionen durchführe, all solche Sachen, Fraud-Detection etc., das muss einfach und funktioniert viel besser, wenn ich mit Event-Streams arbeite. Insofern wird da auch einfach sehr, sehr viel passieren. Es werden immer mehr Event-Interfaces zur Verfügung gestellt werden, auch von gängigen Softwarelösungen, um genau solche Fragestellungen abbilden zu können. Im Data Warehouse selbst und auch in der Im Zugriff darauf, denke ich, ein Trend, den man jetzt gerade sieht, ganz stark so in Richtung da nochmal eine Art von Virtualisierung draufzupacken, also zur Abfragezeit oder im Abfrage- und Visualisierungstool Daten aus verschiedenen Quellen zusammenzuführen, um eben, da hatten wir eben schon mal drüber gesprochen, so ein bisschen auch Aufwand, der sonst zur Transformationszeit anfällt, zu sparen. Dann denke ich, ganz, ganz großes Thema, das ist natürlich auch schon seit vielen Jahren so im Gespräch, es muss eine Bewegung von, Pull hin zu Push geben. Dass ich also als Business-Nutzer nicht notwendigerweise mich immer davor setzen muss, sagen muss, jetzt habe ich die und die Fragestellungen, jetzt kaufe ich mir die mal genau an, suche so ein bisschen nach der Nadel im Heuhaufen, habe bestimmte Hypothesen, die ich teste, sondern so wie sich das jetzt eigentlich ja auch in vielen anderen Bereichen durchsetzt, wird eben nach Intelligenz gefragt. Kann nicht mein Tool, können nicht Softwarelösungen mir helfen, Sachen zu entdecken? Entwicklungen aufzuzeigen, die so nicht erwartbar waren und wo die Software vielleicht so viel verstanden hat über mein Business oder gewisse Business-Logik, die ich hinterlegt habe, dass sie mir da Hilfe an die Hand geben kann und Entwicklungen aufzeigen kann.

Johannes Schaback: Das heißt ja auch immer, dass der BIler, der klassische BIler, ist das erste Opfer von Artificial Intelligence, weil es schon so eine 100% digitalisierte und durchquantifizierte Welt ist und man mit vermeintlichen Artificial Intelligence Methoden oder Machine Learning sehr viel diese Prozesse automatisieren kann, die sozusagen dem BI zugerechnet werden. Würdest du das unterschreiben?

Michael Franzkowiak: Ich glaube, im Bereich Datenintegration ist es ganz, ganz, ganz schwierig, dass es einfach so individuell ist und so viel auch jetzt gerade von den einzelnen Fragestellungen und Gegebenheiten abhängt. Im Bereich Auswertung denke ich, gegebenenfalls wird da genau durch diesen von Pull zu Push Trend an einigen Stellen das ersetzt, was eben ein Data Scientist vorher gemacht hat oder ein Business Analyst, der eben gesagt hat, ich gucke mir die Zahlen an, ich teste und überprüfe regelmäßig Hypothesen, wo das gegebenenfalls von der Software dann irgendwann gemacht wird und auch an die entsprechenden Leute kommuniziert wird. Ich glaube aber, dass in dem Bereich ganz, ganz viel Platz ist noch dafür, als Data Scientist aktiv zu werden. Und dass sich natürlich der Trend auch dahingehend fortsetzt, dass es eben nicht mehr nur um die Aggregierung von Daten geht, sondern eben auch das Anwenden von immer ausgefeilteren Analysen, die eben auch mehr noch nach den Zusammenhängen in den Datenfragen.

Joel Kaczmarek: Hervorragend. Ich danke euch beiden ganz herzlich. Das war ein sehr spannendes und ein sehr vielschichtiges Gespräch. Alle Zuhörer übrigens, wenn euch das auch gefallen hat, schenkt uns gerne 5-Sterne-Bewertungen bei iTunes. Wir freuen uns und das hilft uns, höher zu ranken und mehr Leute zu erreichen mit solch wichtigen Sachen. Wenn ihr schon dabei seid, uns Feedback zu unseren Inhalten zu geben, geht gerne auch mal auf podstars.de und füllt unsere Umfrage aus. Wir verlosen drei spannende, signierte Samba-Bücher und das hilft uns, bessere Inhalte zu machen. Euch beiden kann ich nur danken. So viel Zeit, so viel Wissen, das muss man erstmal verarbeiten. Ich danke euch da ganz, ganz herzlich für. Und natürlich auch besonders dir, dass du die Zeit hergefunden hast, aber auch Johannes, dass der für mich mal den Übersetzer spielt. Technik, Non-Technik. Also ich danke euch.

Michael Franzkowiak: Vielen Dank.

Johannes Schaback: Sehr gern.