Data Warehousing im Wandel

Voiceover: Hallo und herzlich willkommen bei Digital Future, dem Podcast zu Technologie

Voiceover: und Unternehmenskultur.

Voiceover: Mein Name ist Wolfgang Schoch und ich bin Agile Coach bei Inovex.

Voiceover: Ich habe aber auch schon ein paar andere Sachen gemacht und so die IT-Branche

Voiceover: aus verschiedenen Blickwinkeln kennengelernt.

Voiceover: Zum Beispiel als Softwareentwickler, als Experte für Suchtechnologie oder im Vertrieb.

Voiceover: Ich freue mich, euch in jeder Folge des Podcasts eine Kollegin oder einen Kollegen

Voiceover: vorzustellen und mich mit ihr oder ihm über das jeweilige Fachgebiet zu unterhalten.

Voiceover: So bekommt ihr einen Einblick in unseren technologischen und unternehmenskulturellen Alltag.

Voiceover: In der heutigen Folge spreche ich mit meinem Kollegen Marvin Klosek.

Voiceover: Marvin arbeitet als Data Engineer bei uns und er beschäftigt sich sehr viel mit Data Warehouses.

Voiceover: Und genau darüber haben wir uns unterhalten. Wir sprachen über die Historie

Voiceover: und vor allem aber auch über die heutige Bedeutung von Data Warehouse Plattform.

Voiceover: Und natürlich haben wir auch einen Blick in die Zukunft gewagt.

Voiceover: Und jetzt wünsche ich euch viel Spaß beim Zuhören.

Wolfgang: Hallo Marvin, schön, dass du heute da bist und ich freue mich auf unser Thema,

Wolfgang: denn ich glaube, ich kann heute eine ganze Menge dazulernen und ich glaube,

Wolfgang: ich kann auch einiges von meinem, naja, vielleicht ein bisschen veralteten Wissen

Wolfgang: heute einfach mal so auf einen neuen Stand bringen.

Wolfgang: Aber Marvin, bevor wir anfangen, über ein cooles, spannendes,

Wolfgang: technisches Thema zu sprechen, würde ich dich bitten, dich einfach mal kurz

Wolfgang: vorzustellen. Wer bist du?

Wolfgang: Was machst du bei uns so den ganzen lieben langen Tag? Und ja,

Wolfgang: wie lange bist du denn schon bei InnoVax?

Gast: Ja, da war er. Und vielen Dank nochmal für die Einladung. Freut mich mega, hier zu sein heute.

Gast: Genau. Hallo, liebe Zuhörer. Ich bin der Marvin. Bin jetzt seit fünf Jahren

Gast: bei InnoVax. Arbeite hier als Data Engineer.

Gast: Und beschäftige mich hauptsächlich mit ETL-Prozessen und, sagen wir mal,

Gast: Infrastruktur und, ja, Data Management, Schrägstrich, Data Integration.

Gast: In diesem Themenkomplex beschäftige ich mich halt auch gerade häufig mit Data

Gast: Warehousing, Data Warehouse Prozessen und dem Bereitstellen und Entwerfen von

Gast: Data Warehouses und da würde ich dann heute gerne mal mit dir quatschen.

Wolfgang: Ja, auf jeden Fall. Wir sollten das mal in aller Tiefe machen.

Wolfgang: Data Warehouses, das ist so ein Begriff, ich glaube, den kennt man wahrscheinlich,

Wolfgang: wenn man sich so in dem Datenthema so ein bisschen bewegt.

Wolfgang: Das ist auch ein Begriff, den es schon relativ lange gibt und ich fände es ganz

Wolfgang: gut, wenn wir mal eine kleine Zeitreise machen und uns vielleicht mal so ein

Wolfgang: bisschen die Historie anschauen, einfach um zu verstehen,

Wolfgang: woher kommt das eigentlich, was steckt dahinter und warum ist das heute immer

Wolfgang: noch ein wichtiges Thema.

Wolfgang: Achtung, kleiner Spoiler, es ist immer noch ein wichtiges Thema.

Gast: Genau. Da kann ich zurückgehen, naja, erstmal bis in die frühen 50er und die

Gast: Entwicklung bis in die 70er.

Gast: Erstmal generell zum Entstehen von Datenbanken, so wie wir sie heute kennen,

Gast: insbesondere relationellen Datenbanken.

Gast: Ich hatte früher angefangen mit den Fallsystem-basierten Datenbanken.

Gast: Daraus hat sich dann irgendwann bei IBM die DB2 entwickelt, so wie wir sie kennen,

Gast: mit eben relationalem SQL, mit Beziehungen zwischen Tabellen und eben auch der

Gast: ganzen Mathematik, die sich darum herum entwickelt hat in Richtung Normalform etc.

Gast: Und so hat man dann quasi seine ersten Online-Systeme hochgezogen.

Gast: Wir hatten unsere Business-Prozesse abgebildet und wir hatten jetzt Datenbanken,

Gast: die konnten Crowd-Operationen gut ausführen, konnten wir Daten ablegen,

Gast: sicherspeichern in unseren Anwendungen.

Gast: Was man aber schnell gemerkt hat natürlich auch ist, wenn man jetzt die Daten

Gast: aber da drin hat, hat man einen riesigen Schatz von Sachen, die man da abgelegt hat.

Gast: Und wenn man da eine ganze Menge Daten hat, kann man daraus bestimmt noch gewisse

Gast: Erkenntnisse ableiten.

Gast: Und insbesondere eine Art von Reporting, auch vielleicht ein höheres Management

Gast: machen und einfach mal, soll ich mal, Zusammenfassung von den Daten oder auch

Gast: gewisse Erkenntnisse daraus extrahieren.

Gast: Hat sich jetzt jedenfalls schnell herausgestellt, dass die Arten von Queries,

Gast: die man schreibt, um analytische Sachen herauszufinden, unterscheidet sich extrem

Gast: stark von den Arten von Queries, die man in so einem Online-System schreibt.

Gast: In so einem Online-System hast du halt häufig eben Crud-Queries,

Gast: Wares auf irgendwelche IDs, Zugriff auf einzelne Rows.

Gast: Während so eine analytische Query, die funktioniert häufig mit größeren Work-Clause

Gast: über verschiedene Spalten, gefolgt von einem Group-Bio, um irgendwelche Aerationen

Gast: auf irgendwelchen Metriken zu bilden.

Gast: Man hat dann gemerkt, dass das auf den...

Gast: SQL-Datenbanken, wie sie für die Online-Systeme existieren, insbesondere wenn

Gast: sie in dritter, vierter, fünfter Normalform sind,

Gast: dass das schwierig ist, dass man da viel zu viele Joins braucht,

Gast: dass die Queries alle ewig dauern, dass man auf den Entwicklern irgendwie so

Gast: ein bisschen dazwischen funkt, weil du hast jetzt plötzlich Queries,

Gast: die teilweise extrem lang laufen.

Gast: Gleichzeitig will aber dein Online-System schnelle Zugriffszeiten garantieren.

Gast: Du willst ja so ein Objekt und so eine Anlegen, du willst deine Transaktion

Gast: durchführen, das soll schnell gehen, damit die Datenbank wieder im konsistenten Zustand ist.

Gast: Kannst du nicht brauchen, dass dir da irgendeine Query, die einen halben CPU

Gast: blockiert für dein gesamtes Online-Warenkatalog-System oder was auch immer.

Gast: Also haben sie dann schlaue Köpfe gemerkt, dass es vielleicht eine gute Idee

Gast: ist, wenn wir die zwei Sachen einfach trennen.

Wolfgang: Vielleicht kann man an der Stelle mal ein kleines Beispiel einführen für alle,

Wolfgang: die nicht so super tief in der Materie stecken.

Wolfgang: Ich mag immer, wenn wir so Online-Business oder generell über das Business sprechen,

Wolfgang: ich mag immer das Beispiel vom Online-Shop.

Wolfgang: Also stell dir mal vor, also ich fahre gerne Fahrrad, ich habe einen großen

Wolfgang: Online-Shop, wo du Fahrräder kaufen kannst, Zubehör kaufen kannst.

Wolfgang: Dann wäre ja so das Online-Business so mein ganz normales Tagesgeschäft,

Wolfgang: oder? Das heißt, als Kunde gehe ich auf die Website wolfgangsfahrradparadies.de

Wolfgang: und muss mal schauen, ob es das noch gibt. Dann kann ich mir das mal für die

Wolfgang: Zukunft vielleicht auch sichern.

Wolfgang: Und ich kann mir irgendwelche Produktlisten anschauen. Ich kann Bestellungen durchführen.

Wolfgang: Ich kann vielleicht auch mich einloggen in meinen User-Bereich.

Wolfgang: Ich kann meine Bestellhistorie anschauen etc. pp.

Wolfgang: Und da habe ich schon so eine gewisse Art von Anfragen, die immer und immer wieder kommen.

Wolfgang: Also ich mache eine SQL-Anfrage, um mir von einer Kategorie alle Produkte anzuzeigen.

Wolfgang: Ich muss mir vielleicht aus einer anderen Datenbank aktuelle Preise ziehen.

Wolfgang: Ich muss mir vielleicht Bestellungen anschauen.

Wolfgang: Aber man kann sich, glaube ich, schon gut vorstellen, das sind alles schon so

Wolfgang: Anfragen, die irgendwie ähnlich sind.

Wolfgang: Also auch von der Menge, die ich zurückbekomme. und ich habe dann vielleicht

Wolfgang: auch keine Anfragen, die jetzt so superkomplex sind und über zwölf Tabellen

Wolfgang: gehen mit ganz komplexen Joints oder so.

Wolfgang: Das könnte man sich, glaube ich, so vorstellen, oder?

Gast: Stell dir vielleicht auch mal vor, der Online-Shop will jetzt eine neue Marketing-Kampagne

Gast: fahren und du wirst deshalb vielleicht wissen, welches Produkt hat sich nicht

Gast: so gut verkauft in letzter Zeit, welches hat sich gut verkauft und gerade bei welchen Leuten.

Gast: Das heißt, du hast jetzt plötzlich Abfragen, die sich über die Kategorie der

Gast: Bestellungen ziehen in Relation zu den Usern, in Relation zur Zeit,

Gast: aggregiert für verschiedene Produkte, um zu versuchen, daraus Erkenntnisse abzuleiten.

Gast: Das wird wahrscheinlich in deiner dritten Normalforms Datenbank für deinen Online-Shop

Gast: schwierig, möglich, aber irgendwie schwierig werden, weil du wahrscheinlich

Gast: irgendwie 32 Joints am Ende da hast.

Gast: Genau, deswegen wäre es ja vielleicht sinnvoller angenommen,

Gast: wenn wir vielleicht irgendwie die einzelne Transaktion in einer Art Fakten-Tabelle,

Gast: könnte man fast sagen, hätte und rundherum gewisse, sage ich mal,

Gast: kategorische Sachen, die diese als Dimension quasi beschreiben.

Gast: Und da kommen auch schon in die richtige Richtung. Denn die schlauen Menschen,

Gast: die sich dann überlegt haben, wie man das ändern kann, haben zwei Feststörungen

Gast: gemacht dann in den 90ern.

Gast: Ah, wir trennen das quasi in der zweiten Datenbank auf, wo wir erst mal sagen,

Gast: okay, wir batch kopieren die Daten von dem Online-System in ein anderes System.

Gast: Dann tun wir schon erst mal nicht mal den Betriebsfluss stören,

Gast: sondern wir könnten unsere langläufigen Queries auf der zweiten Datenbank machen.

Gast: Damit stören wir schon mal keinen mehr. Und dann wäre die zweite Idee,

Gast: kriegen wir die Laufzeiten dieser Queries irgendwie besser.

Gast: Und dann sind sie da richtig schnell drauf gekommen, ja, wenn wir das Datenschema

Gast: einfach anpassen und die Daten einmal transformieren, bevor wir sie quasi abfragen.

Gast: Also quasi die ersten Extract Transform Load Prozesse, die damals geschrieben wurden.

Gast: Und da ist dann der Rolf Kimber gekommen und der hat dann das Sternschema definiert.

Gast: Und das ist jetzt ein Schema, wo eben gewisse Sachen innerhalb unseres Unternehmens,

Gast: irgendwelche Arten von Business Strukturen, also solche Prozesse für Bestellungen,

Gast: Prozesse für irgendwie im HR Bereich oder so,

Gast: jede einzelne dieser Prozesskategorien kann man da in einem eigenen Schema abbilden. Das ist ein Stern.

Gast: In diesem befindet sich dann eine zentrale Fakten-Tabelle, die irgendwelche

Gast: Ereignisse in unserem Business beschreibt. Zum Beispiel, sagen wir mal, Bestellungen.

Gast: Irgendwelche Transaktionen sind da durchgeführt worden. Und um diese Bestellungen

Gast: rundherum hätten wir dann unsere Dimensionstabellen. Jetzt in unserem Beispiel eine Komponente.

Gast: Die Kategorie der Fahrräder, die Uhrzeit bzw.

Gast: Das Datum, welcher Kunde beteiligt war, die sind dann alle rundherum um diese

Gast: Faktentabellen in sogenannten Dimensionstabellen.

Gast: Wenn wir jetzt verschiedene Faktentabellen haben, zum Beispiel verschiedene

Gast: Prozesse, zum Beispiel Bestellungen beim Zulieferer versus Bestellungen beim

Gast: Kunden, könnten wir die quasi auch über gewisse Dimensionstabellen,

Gast: die sich teilen, zum Beispiel die Kategorie des Fahrrades, auch ineinander in Relation setzen.

Gast: Und so haben wir plötzlich anstatt vier, fünf Joints in eine stark denormalisierte

Gast: Tabelle Da haben wir plötzlich nur noch pro Fakten-Tabelle ein,

Gast: zwei Joints an die Dimensionen, die uns gerade interessieren.

Gast: Haben uns einen Haufen komplexer relationaler Abfragen gespart und können dadurch

Gast: viel bessere Queries schreiben und auch viel schneller Antworten geben.

Wolfgang: Ich optimiere also meine Datenbasis so, dass die von mir gewünschten Abfragen

Wolfgang: später einfach schneller durchführbar sind.

Gast: Genau, nicht nur die aktuell bekannten Abfragen, sondern es hat sich auch gestellt,

Gast: dass dieses Sternschema relativ robust ist und auch ad hoc Anfragen auch für

Gast: komplexere Analysen relativ gut sich durchführen lassen dann später.

Wolfgang: Das heißt, ich muss mir dann für mein Business überlegen, wie ich die Daten

Wolfgang: transformiere, was die relevanten Fakten für mich sind.

Wolfgang: Das sind in dem Beispiel diese Transaktionen zum Beispiel und die Bestellung,

Wolfgang: und ich überlege mir das,

Wolfgang: überlege mir dann auch, okay, was sind dann die relevanten Dimensionen,

Wolfgang: setze das alles in Relation zueinander und wenn ich später vielleicht noch andere

Wolfgang: Fakten dazu bekomme, was sich mein Business verändert oder ich vielleicht eine

Wolfgang: neue Idee habe für irgendwas,

Wolfgang: dann kann ich diese vorhandenen Dimensionstabellen ja einfach weiter nutzen.

Wolfgang: Die ändern sich ja nicht. Die Fahrräder bleiben die gleichen,

Wolfgang: die Kunden bleiben die gleichen.

Wolfgang: Aber ich habe jetzt halt vielleicht nicht Bestellungen, sondern ich habe zusätzlich

Wolfgang: noch irgendwie eine Wunschliste.

Wolfgang: Kann ja sein, da füge ich als neues Feature ein, wo ich mir Sachen auf eine

Wolfgang: Wunschliste packen kann oder eine Merkliste und das möchte ich vielleicht später

Wolfgang: auch analysieren für eine Marketingkampagne, dass ich weiß, okay,

Wolfgang: welches Fahrrad wird am häufigsten gewünscht?

Wolfgang: Dann mache ich da vielleicht eine Sonderaktion irgendwie.

Gast: Genau so, das ist eben ein iterativer Prozess, das hat Kimball damals auch schon

Gast: so beschrieben, du fängst an mit, du suchst dir deinen Prozess aus,

Gast: den du beschreiben willst,

Gast: überlegst dir, okay, was ist jetzt der Fakt, was ist mein Granule,

Gast: was ist die eine Aktion, die da häufig wieder und wieder passiert,

Gast: in dem Fall zum Beispiel irgendwie eben die Verkaufstransaktion,

Gast: dann überlegst du dir, was sind deine Dimensionen, was sind solche Dimensionen,

Gast: die ich schon habe, auf die ich mitzugreifen kann und so entwürfst du dann quasi pro,

Gast: sagen wir mal Business Kategorie oder Business,

Gast: Vorgang jeweils einen einzelnen Stern und diese Sterne zusammenbilden ein sogenanntes

Gast: Galaxy Schema mit geteiltem Dimensionen.

Gast: Und so baust du nach und nach, sag ich mal, in einem Bottom-up-Prozess dein Data Warehouse.

Gast: Auch von dieser Prozess hat sich jetzt relativ ziemlich gut etabliert über die

Gast: letzten, ja mittlerweile schon 40 Jahre fast.

Wolfgang: Spannend, oder? Dass man vor 40 Jahren so eine Idee hatte und die heute immer noch Bestand hat.

Gast: Na gut, also es geht ja dasselbe für Relationale SQL, das ist jetzt auch schon

Gast: 50, fast 60 Jahre alt und bis heute das Zentrum von allen unseren Datenbankprozessen.

Gast: Letzten Endes, abgesehen von den Noah's Gold Datenbanken, die sich hier und

Gast: da noch ein Nischendasein fristen.

Wolfgang: Es gab Zeiten, da dachte man, dass die MongoDB das nächste große Ding ist.

Gast: Ja, und dann hat die böse, böse Postgres plötzlich den JSON-Type eingeführt und alles war erledigt.

Wolfgang: Ja, zum Glück, ja.

Gast: Genau, und das ist der Prozess, so wie ihn Kimball beschreibt.

Gast: Ein paar Jahre später kam dann noch der Herr Immen dazu und hat,

Gast: sage ich mal, eine Art Top-Down-Perspektive auf das Ganze formuliert.

Gast: Weniger als Prozess, um einzelne Projekte durchzuführen, sondern mehr darauf

Gast: bedacht, okay, wie kriege ich das jetzt sauber in meinen Gesamtunternehmenskontext abgebildet?

Gast: Und er hat die Idee formuliert vom allgemeinen Data Warehouse für den gesamten

Gast: Betrieb, wo wirklich alle Daten aus allen meinen operativen Systemen reinlaufen,

Gast: wo ich dann quasi eine vorbereitete Schicht habe, auch über eine zeitliche Dimension

Gast: vor allem abgebildet, aus der ich dann quasi die einzelnen,

Gast: Sternschemas für die einzelnen Berichte oder Berichtskomplexe,

Gast: die ich haben will, häufig genannt Data Mart, relativ einfach konstruieren kann

Gast: und der Helmand hat auch so ein paar,

Gast: Eigenschaften von so einem Data Warehouse,

Gast: beschrieben dass es eben über eine zeitliche Dimension immer abbildbar sein muss,

Gast: Dass es eben die einzelnen Businesskomplexe beschreiben kann,

Gast: aber diese auch eben in Relation setzen muss und vor allem, dass es jede Form

Gast: von Fakt, die da drin ist,

Gast: immer irgendwie allgemein eindeutig identifizierbar ist über einen eindeutigen Surrogate Key.

Wolfgang: Und wenn wir jetzt über Data Warehouses sprechen, umfasst ein Data Warehouse

Wolfgang: dann so die Gesamtmenge aus erstmal natürlich der Technologie für die Datenbank,

Wolfgang: die ich habe, in der mein Sternschema und meine ganzen Daten drin liegen,

Wolfgang: plus die entsprechenden Transformations- und Ladeprozesse, wo ich quasi nutzen

Wolfgang: kann, um meine operativen Daten dann erstmal initial und dann wahrscheinlich

Wolfgang: batchmäßig so iterativ, vielleicht einmal pro Tag,

Wolfgang: darüber zu packen, dann ins Data Warehouse plus natürlich Möglichkeiten dann

Wolfgang: für Abfragen und Reporting.

Gast: Genau, du beschreibst, also Reporting vielleicht nicht, aber das Data Warehouse

Gast: ist immer der Gesamtprozess aus, wo liegen die Daten und wie kommen sie da rein.

Gast: Also sowohl den Ladeprozess als auch die eigentliche Datenbank,

Gast: die die Daten hält, das ist das Data

Gast: Warehouse und das wird durch den Data Warehouse-Prozess am Leben erhalten.

Gast: Und letztendlich, wie es jetzt effektiv beschrieben ist, wir haben am Ende eine

Gast: Datenbank, die ist subjektorientiert, Das heißt,

Gast: wir schauen uns nicht die Business-Prozesse an, so wie sie wirklich als Prozess

Gast: leben, so wie wir sie quasi in unserem Online-System haben, sondern wir gucken

Gast: uns an, okay, was sind jetzt unsere Bestellungen, was sind unsere Autos,

Gast: etc. bei PPM, die Subjekte, die wir haben wollen.

Gast: Es ist vollständig integriert, das heißt, alle Prozesse laufen irgendwie zusammen

Gast: und wir haben die Daten in einem einzigen Ding drin am Ende.

Gast: Es ist Zeitvariant, das heißt, zeitliche Veränderungen werden analysiert und

Gast: idealerweise haben wir eine sogenannte Append-Only-Datenbank.

Gast: Das heißt, irgendwelche Veränderungen, die wir machen, ersetzen nicht irgendwelche

Gast: Zeilen, so wie es quasi im Online-System sein würde, sondern wir behalten uns

Gast: die einzelnen Zwischenzustände, um, sage ich mal, auch rückwärtig Analysen,

Gast: ermöglichen zu haben über gewisse Änderungsprozesse. Und natürlich als allerwichtigstes,

Gast: die Daten müssen nicht volatil irgendwie gesichert sein, weil wenn wir so ein

Gast: Data Warehouse haben, dann wollen wir nicht, dass sich das irgendwann in der

Gast: Luft auflöst, sondern das muss besser ausfallsicher und gebackupt sein.

Wolfgang: Also dann habe ich direkt so zwei Gedanken, Marvin. Zum einen,

Wolfgang: wahrscheinlich verwundert es dann nicht, dass die großen Datenbankhersteller

Wolfgang: auch diejenigen waren, die dann sicherlich sehr schnell mit Data Warehouse Lösungen kamen.

Wolfgang: Ich selbst kenne die entsprechende Lösung von Microsoft, die ja mit dem Microsoft

Wolfgang: SQL Server damals groß waren, heute denke ich immer noch stark im Geschäft sind.

Wolfgang: Dann was hast du noch, Oracle natürlich, IBM hast du schon angesprochen.

Wolfgang: Also das ist ja das eine. Das zweite, was ich aber so im Kopf habe,

Wolfgang: ist, mit so einer Skalierung war es zumindest ja früher nicht so super einfach mit SQL-Datenbanken.

Wolfgang: Also wenn es jetzt um Performance ging, solche Master-Slave-Konstrukte,

Wolfgang: die gab es schon immer, da konnte man die Daten verteilen und dann entsprechend

Wolfgang: auch schnell lesen oder schreiben auch parallel.

Wolfgang: Aber das große Problem war doch oftmals, wenn die Datenmenge so groß ist,

Wolfgang: dass sie jetzt halt nicht mehr so gut auf den Server draufpasst.

Wolfgang: Das war ja immer schon ein bisschen schwierig. Ist es bei einer Data Warehouse

Wolfgang: Lösung einfacher, weil man es vielleicht irgendwie nach einer Zeit partitionieren

Wolfgang: kann, dass man sagen kann, okay, ich habe vielleicht pro, weiß nicht,

Wolfgang: Zeiteinheit pro Jahr oder so dann vielleicht früher einen Server genommen und

Wolfgang: habe dann entsprechend was gemergt, wenn ich was gesucht habe?

Gast: Ja, das war so eine der Varianten, die man früher gemacht hat.

Gast: Der war die ähnliche Variante, die man früher hauptsächlich getan hat.

Gast: Wir hatten halt einfach eine horizontale, eine vertikale Skalierung.

Gast: Unsere Server sind immer größer und größer geworden.

Gast: Unsere Euckel-Datenbank musste jedes Jahr aufs nächst höhere Lizenzschema geupdatet

Gast: werden, damit sie da nochmal das dritte Terabyte speichern kann.

Gast: SAP kam dann um die Ecke mit dem HANA-Ansatz, wo sie sich gedacht haben,

Gast: okay, wir nehmen einfach die gesamte Rational-Datenbank. Schieben sie einmal

Gast: den Hauptspeicher, das wird schnell genug sein.

Gast: Brauchst du als Server mit einem Terabyte Hauptspeicher. Ist jetzt auch nicht

Gast: die billigste Variante.

Wolfgang: Ja.

Gast: Genau, und so sind dann letzten Endes teilweise auch einige Sachen in ihre Grenzen gekommen.

Gast: Dann kamen in den frühen 2000ern bis in die 10er Jahre dann gleichzeitig die Big Data,

Gast: No-Schemer-Data, Sache nebenan auch, wo man gesagt hat, ja okay,

Gast: die Data Warehouses, die reichen nicht mehr,

Gast: wir haben jetzt ganz, ganz viele auch nicht strukturierte Daten oder einfach

Gast: zu viele Daten, da haben wir dann gesagt, okay, ziehen wir uns einfach nur einen

Gast: Cold-Storage-Layer hoch, packen dann einen Hadoop-Cluster, später einen Spark-Cluster

Gast: oben drüber und führen unsere Analysen darauf auf.

Gast: Das hat für einige, sag ich mal, Use Cases sehr gut funktioniert,

Gast: insbesondere eben für diejenigen, die halt nicht so in den klassischen Datenbank

Gast: passen, gerade Richtung irgendwie Textverarbeitung oder verarbeitet von massiven

Gast: JSON-Dokumenten, Logverarbeitung.

Wolfgang: Ja, gerade für Logverarbeitung. Gerade für Logverarbeitung, genau.

Gast: Hat sich hier doch schnell herausgestellt, dass man für tabellarische Daten

Gast: kann man das machen, hat man aber mit hohen Latenzen und irgendwie auch eigentlich

Gast: hohen Laufzeitkosten, gerade am Anfang gleich zu einer Datenbank zu kämpfen.

Gast: Also das ist deinerseits das Problem, deine Datenbanken sind nicht mehr groß

Gast: genug, andererseits das Problem, die anderen Systeme, die groß genug sind,

Gast: passen von der Kostenstruktur her nicht. Also stand man da so ein bisschen in so einer Brutfolie.

Gast: Und dann sind aber über die letzten,

Gast: Sagen wir mal zehn Jahre, sehr spannende Dinge passiert. Also insgesamt sind

Gast: sehr viele neue Hersteller und auch sehr viele neue Konzepte auf den Markt der

Gast: Data Warehouses gesprungen.

Gast: Also früher hat es ja eben die klassischen Hersteller gehabt mit Oracle,

Gast: Microsoft eben mit dem Analysis Services auf dem MS SQL.

Gast: Weil Oracle hat ja auch ganz viel die OLTP und OLAP-Paradigmen gepusht,

Gast: insbesondere der berühmte OLAP-Cube, damit man da seine Datenbank irgendwie

Gast: in einem speziellen, dimensionalen, proprietären Schema anlegen kann.

Wolfgang: Kannst du mal kurz erklären, was OLAP ist, für alle, die es nicht kennen?

Gast: Genau, also OLAP und OLTP sind erstmal, sag ich mal, nette Begriffe, um was einzuordnen.

Gast: OLTP steht für Online Transactional Processing. Das ist jetzt in unserem Fahrradhändler-Beispiel,

Gast: ist das unsere Postgres, die jetzt den Webshop am Laufen hält und unser OLTP,

Gast: OLAP ist unser Online Analytical Processing.

Gast: Das ist quasi unser Data Warehouse, wo wir unsere analytischen Queries darauf

Gast: abfragen und letzten Endes auch gucken können, okay, hier ist wie erwähnt unsere

Gast: getrennte Datenbank mit der Spezialsoftware, wo wir dann unsere Abfragen machen können.

Gast: Und so ein Urlaub-Cube, das hat man sich früher ausgedacht, eben um die großen

Gast: Datenmengen in den Griff zu kriegen, die mir nicht mehr so gut auf eine Datenbank

Gast: gepasst haben, hat man sich da verschiedene Strukturen, die nicht mehr wirklich

Gast: in so ein tabellares SQL-Modell passen,

Gast: ausgedacht, einfach um andere Arten von Datenbanken intern zu haben,

Gast: die besser auf die Datenmengen klarkommen.

Gast: Was aber in den letzten zehn Jahren passiert ist, wir haben eine in zwei Arten

Gast: große Entwicklung gesehen.

Gast: Einerseits horizontale Skalierung.

Gast: Das fing ja an hauptsächlich im Kubernetes-Kontext oder auch eben im Hadoop-Kontext,

Gast: wo wir gesagt haben, okay, anstatt, dass wir jetzt einen dicken Server nehmen,

Gast: in dem wir jedes Jahr einmal aufziehen.

Gast: Packen wir uns einen Haufen Commodity-Artware, schalten die zusammen und lösen

Gast: das Problem mit darüber, dass wir irgendwie die Prozesse darauf synchronisieren

Gast: müssen, irgendwie in Software. wäre.

Gast: Und dann können wir plötzlich, sage ich mal, ganz, ganz viele Rechner in die

Gast: Reihe schalten. Das hat sich relativ gut bewährt in dem ganzen Hadoop,

Gast: Spark, Kontext, auch auf Kubernetes hat es sich relativ gut bewährt.

Gast: Also kamen relativ schnell Leute

Gast: auf die Idee, okay, können wir so nicht vielleicht eine Datenbank bauen?

Gast: Müssen wir halt einmal Storage und Compute komplett trennen,

Gast: sagen, okay, wir haben unsere Storage-Lehrer und wir haben oben noch irgendwelche

Gast: Worker-Prozesse, die dann Abfragen machen.

Gast: Aber so kann man ja theoretisch plötzlich ad hoc mehr Leistung für Queries hinzubringen,

Gast: die halt höhere Leistung erfordern.

Wolfgang: Ja, das war ja das riesengroße Ding, als diese Big Data Bewegung, sag ich mal, aufkam.

Wolfgang: Das war ja auch jahrelang so ein krasses Buzzword. Ich weiß auch bei uns,

Wolfgang: wir haben damals auch viele Stellenanzeigen gehabt für Big Data Engineers und,

Wolfgang: ich glaube, das ist heute so ein Begriff, den man nicht mehr so findet irgendwo.

Wolfgang: Also heute ist dann, glaube ich, eher so Data Engineering oder Business Data Engineering.

Wolfgang: Aber so dieses klassische Big Data, das gibt es irgendwie als Begriff nicht

Wolfgang: mehr so, finde ich heute.

Gast: Hat sich halt rausgestellt, so big ist das Data dann doch nicht bei dem meisten Betrieb.

Gast: Deswegen haben wir dann alle mal die Jobtitel einmal auf LinkedIn geändert auf

Gast: Data Engineer. Ist aber dann keinem aufgefallen im Management, glücklicherweise.

Gast: Genau. Und die zweite Entwicklung, eigentlich eher die spannendere sogar,

Gast: ist eine neue Art von der Art und Weise, wie wir unsere Tabellen,

Gast: unsere Datenbanken intern orchestrieren.

Gast: Weil so eine klassische SQL-Datenbank, wie wir sie kennen, die ist ja RAW-oriented,

Gast: also wirklich zeilenbasiert.

Gast: Wenn sie irgendwie einen Seek macht auf eine einzelne Zeile,

Gast: dann löst sie mit der ID, dann schlappt sie sich immer die komplette Zeile.

Gast: Nur die Zeilen stehen nacheinander und im Speicher drin, um adressierbar zu

Gast: sein, was für CRUD-Prozesse super sind, weil meistens haben wir eine ID, die wir ranwollen.

Gast: Die finden wir in Log N, schnappen die uns, machen da unsere Updates etc. pp.

Wolfgang: Die gute binäre Suche halt.

Gast: Ja, genau. Problem ist aber, wenn wir jetzt analytische Abfragen haben,

Gast: haben wir meistens keine ID, an die wir ranwollen, sondern wir haben auf verschiedenen

Gast: Columns, haben wir verschiedene Bedingungen.

Gast: Das heißt, es wäre eigentlich viel nützlicher, wenn wir die Spalten adressieren

Gast: können, anstatt der einzelnen Zeilen.

Gast: Und eben genau das ist, was Staukipfen dann getan haben. Wir haben jetzt spaltenorientierte

Gast: Datenmodelle mit spaltenorientierten Datenmarken, wo nicht die einzelnen Werte

Gast: der einzelnen Zeilen aneinander der Hauptspeicher sind, sondern alle Spalten

Gast: nacheinander im Speicher abgelegt werden und adressierbar sind.

Gast: Und dadurch kann man verschiedene Dinge tun. Insbesondere man hat eben schnelleren

Gast: Zugriff auf Projektion, weil du kannst jetzt einzelne Spalten einzeln lesen.

Gast: Das heißt, wenn du ein Select machst, musst du jetzt nur noch die Spalten lesen,

Gast: die dich wirklich interessieren und nicht mehr alles von der Hauptplatte abholen.

Gast: Und du kannst Vektorisierung moderner CPUs besser verwenden.

Gast: Moderne CPUs können ja Single Instruction Multiple Data, das heißt,

Gast: wenn du eine Operation auf vielen Datenpunkten ausführen willst,

Gast: was du ja bei so, wenn du eine ganze Spalte auf einmal lesen kannst, genau tun kannst,

Gast: kannst du eben viel mehr Durchsatz aus modernen Prozessoren rausholen oder sogar

Gast: teilweise analytische Operationen auf Grafikkarten durchführen,

Gast: um noch viel mehr Durchsatz zu erzeugen.

Gast: Und es hat sich dann letztendlich herausgestellt, dass du über so eine Column-Oriented

Gast: Datenbank, du viel mehr analytische Leistung herausholen kannst,

Gast: vielleicht so eine Raw-Oriented Datenbank.

Gast: Und wenn du das dann noch kombinierst mit so einer Trennung von Storage und

Gast: Compute und eben auf spaltenorientierte Datenmodelle gleichzeitig mehrere Worker,

Gast: laufen das Ganze relativ komplexe analytische Queries mit dann doch recht einfacher

Gast: Commodity-Hardware in extrem hoher Geschwindigkeit abfragen.

Wolfgang: Dann lass mich das mal zusammenfassen. Das war jetzt eine ganze Menge.

Wolfgang: Also eine klassische Datenbank-Tabelle, nehmen wir mal an, die hat vielleicht zehn Spalten.

Wolfgang: Da habe ich einfach Reihe für Reihe oder Zeile für Zeile einfach nacheinander

Wolfgang: im Speicher und ich habe vielleicht einen Index drauf und kann dann halt auch

Wolfgang: relativ einfach ganz gezielt auf Zeile 3.150 zugreifen.

Wolfgang: Das ist easy und für viele Business-Anwendungen genau das, was ich möchte.

Wolfgang: Wenn ich jetzt aber nicht zeilen, sondern spaltenorientiert vorgehe,

Wolfgang: habe ich letztendlich ja genau das, was ich früher auch machen konnte,

Wolfgang: wenn ich einen Index auf eine Spalte angelegt habe, oder?

Wolfgang: Also einfach eine indizierte Spalte letztendlich oder wie man es auch vielleicht

Wolfgang: bei sowas wie Elasticsearch hat.

Wolfgang: Da habe ich ja auch quasi jeweils einen Index auf ein Attribut oder in dem Fall

Wolfgang: halt auf eine Spalte und kann jetzt, wenn ich irgendwelche Abfragen durchführe,

Wolfgang: in welchen Analysen durchführe, gezielt auf Werte dieser Spalte zugreifen.

Wolfgang: Ist diese Spalte durch die Indizierung dann, wenn man es vielleicht vereinfacht

Wolfgang: ausdrückt, auch sortiert?

Gast: Ja, sortiert kannst du sie vorher, wenn du sie indizierst, was du halt tust

Gast: bei einem Index. Auf der klassischen Datenbank ist, du führst eine zweite Speicherstruktur ein.

Gast: Die Funktionen, die ich indizierst nämlich so, dass du quasi die Werte innerhalb

Gast: dieser Spalte nochmal ablegst, meistens in einem binären Suchbaum,

Gast: damit die Datenbank dann relativ schnell darauf zugreifen kann.

Wolfgang: Okay, das heißt, wenn ich jetzt nach einem Wert Ausschau halte und der Wert

Wolfgang: ist jetzt, keine Ahnung, Wolfgang, dann habe ich eben halt diese zweite Datenstruktur,

Wolfgang: kann hier gezielt auf Wolfgang zugreifen und weiß dann, okay,

Wolfgang: referenziert es auf Eintrag XY zum Beispiel.

Gast: Genau.

Wolfgang: Und dadurch, dass ich jetzt, wenn ich jetzt von dieser Ursprungstabelle ausgehe,

Wolfgang: dann jetzt nicht eine Tabelle habe, wo ich zeilenorientiert darauf zugreifen

Wolfgang: kann, sondern vielleicht jetzt zehn Spalten habe, auf die ich auch einzeln zugreifen kann,

Wolfgang: kann ich diese zehn Spalten auch verteilen auf verschiedene physikalische Maschinen.

Gast: Genau, und wenn du die Spalten, sag ich mal, schlau ablegst und dir auch vielleicht

Gast: auf Metadaten gerade merkst, welcher Wert gerade vorne steht,

Gast: welcher Wert gerade hinten steht und das vielleicht auch noch irgendwo in der

Gast: Metadatentabelle ablegst, kannst du auch relativ schnell auch binäre Suchen auf sowas aufbauen, ne?

Wolfgang: Und dadurch habe ich jetzt eine Möglichkeit, A, das Ganze erstmal zu verteilen

Wolfgang: und so einfach eine Skalierung durchzuführen.

Wolfgang: Und ich kann gleichzeitig durch die Nutzung von mehreren CPUs bzw.

Wolfgang: Durch die Nutzung von mehreren gleichzeitigen Worker-Prozessen halt auch gleichzeitig

Wolfgang: darauf arbeiten und gleichzeitig irgendwelche Dinge analysieren.

Gast: Und jeder einzelne dieser Worker kann wiederum gleichzeitig auf mehreren Daten

Gast: arbeiten, weil es ja jetzt vektorisiert ausgeführt werden kann.

Gast: Das heißt, du gewinnst, sag ich mal, Orders of Magnitude und Performance auf dem ganzen Denken.

Wolfgang: Und das bedeutet, ich brauche nicht mehr den einen Supercomputer mit einem Terabyte

Wolfgang: RAM, der irgendwo im Keller steht und wahrscheinlich einen siebenstelligen Betrag

Wolfgang: kostet und vielleicht den ganzen Tag auch nicht ausgelastet ist, sondern nur ab und an,

Wolfgang: sondern ich habe ganz normale Hardware oder ich habe vielleicht gar keine Hardware.

Gast: Oder du bist vielleicht in der Cloud, genau.

Wolfgang: Oder ich bin vielleicht in der Cloud. Ja, sag mal Marvin, gibt es auch Warehouses

Wolfgang: in der Cloud? Gibt es sowas auch?

Gast: Ja, aber durchaus. Also jeder Cloud-Vendor hat so seine eigene.

Gast: Es gibt aber auch, sag ich mal, so generelle Platzwürfe, die sich da durchgesetzt

Gast: haben. Snowflake ist somit das größte Beispiel.

Gast: Ist ja auch seit 10, 15 Jahren, sind ja jetzt schon mittlerweile im Geschäft,

Gast: haben sich durchgesetzt.

Gast: Letzten Endes ist alles das, sag ich mal, Data Warehouse heutzutage.

Gast: Wenn du frisch anfängst, sagen wir mal kein Oracle mehr, sondern wenn ich sagen

Gast: will, du willst aus der Box was haben.

Gast: Du hast jetzt kein großes Team, um irgendwie Hosting von interessanteren Technologien

Gast: zu machen, auf die wir später kommen, dann spricht nichts dagegen.

Gast: Du holst dir in der Cloud deine Oracle, deinen Snowflake Compute und sorgst

Gast: letzten Endes dafür, dass die sich um alles kümmern, effektiv. Und genau.

Gast: Unter der Haube gehen die auch relativ schnell vor. Die haben eben auch Columnar Storage.

Gast: Die haben auch unten drunter, auch wenn sie nicht genau sagen,

Gast: wie sie es machen, das war das Geschäftsgeheimnis, weil es ja proprietäre Technologie

Gast: ist, aber die arbeiten auch mit verteilten Workern. Das ist alles sehr weit weg abstrahiert.

Wolfgang: Das heißt Snowflake beispielsweise ist so eine komplette Software-as-a-Service-Lösung.

Wolfgang: Die klicke ich mir im Internet, dann stöpsele ich da meine eigene Datenbank

Wolfgang: an, sodass die Daten dorthin exportiert werden können und dann kann ich mir

Wolfgang: auch über das Web wahrscheinlich Auswertung irgendwie zusammen konfigurieren

Wolfgang: und kann die dann nutzen.

Gast: Genau, für das Datentransportieren haben sie dann mittlerweile auch eigene Software-Suites,

Gast: Snowpipes nennen die das, und wirklich optimiert Daten aus zig verschiedenen

Gast: Quellen, von SAP bis Oracle bis Salesforce sind alles dran, Daten in deine Snowflake

Gast: reinzustreamen, auch in Echtzeit.

Gast: Das ist nämlich auch einer der großen Use-Cales heutzutage.

Gast: Wir wollen heutzutage nicht mehr irgendwie batchmäßig einen Tag warten,

Gast: sondern Sales will jetzt die Auswertung von gestern haben.

Gast: Und deswegen ist es heutzutage eher so, dass wir hauptsächlich über Change Data

Gast: Capture unsere Daten von unseren Online-Systemen direkt in unser Data Warehouse streamen können.

Gast: Und da ist es umso besser, wenn wir da spaltenbasiert reinstreamen können,

Gast: können wir halt Streams pro Spalte aufmachen, gleichzeitig noch den Schreibdurchsatz verbessern.

Wolfgang: Ja, sehr, sehr spannend. Du hast gesagt, die großen Anbieter haben alle eigene Sachen.

Wolfgang: Bedeutet das, dass die großen Hyperscaler eigene Sachen haben?

Gast: Genau, auf Amazon hast du zum Beispiel Redshift auf AWS.

Gast: Auf Google hast du BigQuery jetzt nicht so als klassische reine Data Warehouse-Lösung,

Gast: sondern eher als Query-Engine.

Gast: Du hast haufenweise Zeug auf TCP rumliegen und willst darauf analytische Queries durchführen.

Gast: Dann haben sie ein BigQuery-entspannendes System, obwohl sie auch mit dem Cloud-Spanner

Gast: so eine Art Data Warehouse hochgezogen haben. auf Azure hast du mehrere Angebote

Gast: du kannst Cosmos DB als analytisches Urlaubssystem verwenden,

Gast: Aber Snowflake läuft doch auf allen drei Cloud-Vendos.

Wolfgang: Aber diese ganzen verschiedenen Systeme, die kochen schon alle ein bisschen

Wolfgang: der eigene Süppchen, oder?

Wolfgang: Also das heißt, ich bin da jetzt nicht irgendwie so agnostisch,

Wolfgang: sondern sage, ich nutze das eine System und wenn man es nicht mehr passt,

Wolfgang: dann switche ich rüber auf ein anderes.

Wolfgang: Ich muss dann mehr oder weniger schon immer bei Null anfangen, oder?

Gast: Genau, also klar, die sprechen natürlich alle irgendeinen Ansias-SQL-Dialekt,

Gast: aber wenn du dich einmal so, wenn du loginst, dann bist du halt drin.

Gast: So eine Migration aus Snowflake raus ist auch nicht so eine Sache,

Gast: die man einfach so mal macht. Also wenn man sich dafür ein System entscheidet,

Gast: soll man sich schon gut überlegen, welches man da nimmt.

Gast: Oder man nimmt halt ein Open-Source-System.

Wolfgang: Was gibt es denn da im Open-Source-Bereich?

Gast: Da gibt es einige Platze. Also wie man sagt, der Hauptvertreter von modernem

Gast: Data Warehouse als Open-Source ist ganz klar Clickhouse.

Gast: Clickhouse, die gibt es auch. Also die operieren einem ähnlichen Business-Modell wie bei MongoDB.

Gast: Du kannst das Ganze auch quasi gehostet bei denen online bestellen.

Gast: Die deployen dir das auch, welche Cloud auch immer du willst.

Gast: Aber die ganze Clickhouse-Codebase ist halt Open-Source. und sie haben auch

Gast: wunderbare Anleitungen, wie du selber hosten kannst, wenn du willst.

Gast: Und die hier Vorgehensweise ist eben genauso. Die haben halt eine Datenbank

Gast: entwickelt, die ist vollständig column-orientiert.

Gast: Sie tun auch gerade unter der Haube das, was ich erklärt habe,

Gast: dass sie die Daten speichern in einzelne Dateien pro Column,

Gast: auch unterteilt in verschiedene, sag ich mal,

Gast: Badges und mit ganz viel Metainformationen außenrum, damit du quasi für jeden

Gast: Key weißt, okay, dieser Badge fängt jetzt für diesen Key an hier und endet da,

Gast: sodass du quasi jede Form von Suchaktionen immer erst in der binären Suche runterbrechen

Gast: kannst, welche einzelnen Wedges du dann auswählen kannst, damit du diese wiederum

Gast: direkt in den Hauptspeicher laden kannst und da relativ schnell vorgehen kannst.

Gast: Die haben eine ganze Menge Optimierung unter der Haube gemacht,

Gast: eben um so ein modernes Datensystem hochzuziehen.

Gast: Und die finde ich relativ spannend, weil du fängst da jetzt nicht mit einem

Gast: Riesensystem an, sondern du kannst die ganz klassisch auf einer Node anfangen,

Gast: und, sag ich mal, wachsen lassen und dann später einfach mehrere von denen in

Gast: Reihe schalten mit ein bisschen Overheads, gebe ich zu, wenn du dann dich ein

Gast: bisschen darum selber kümmern musst, dass die Abfragen korrekt geroutet werden,

Gast: aber du kannst halt so ein Growing machen.

Gast: Du bist nicht direkt auf angewiesen, einen kompletten Kubernetes-Taster hinzustellen,

Gast: sondern du kannst irgendwie auf einer VM anfangen, mal einen so einen Klick-Aus-Prozess

Gast: hochzuziehen und den mal zu befüllen.

Wolfgang: Das ist dann aber auch spannend für vielleicht so mittelständische Unternehmen, oder?

Gast: Definitiv.

Wolfgang: Wo man jetzt nicht so eine riesen Admin-Truppe irgendwie hat,

Wolfgang: die vielleicht super geschult ist und das alles auch stemmen kann,

Wolfgang: sondern man kann sowas vielleicht auch einfach mal als Prototyp dann relativ

Wolfgang: einfach mal einfach anfangen.

Gast: Genau, es gibt einen Docker-Container, den kannst du hochziehen,

Gast: dann hast du das Ding lokal laufen.

Gast: Effektiv. Und was ich jetzt sagen muss bei ClickHouse,

Gast: Ja, wenn ich mir so bei so einer Technologie, ich störe ja gerne in der Doku

Gast: als Ingenieur und immer wenn ich auf eine Technologie stoße,

Gast: wo mir nichts sagt, okay,

Gast: wir übernehmen alles für dich und hier ist alles super und wir optimieren alles

Gast: weg und es sind schöne Management Slides und dann bin ich da reingucke und ich

Gast: sehe 500 Seiten mit Best Practices und wenn das passiert, musst du das machen,

Gast: dann merke ich schon, okay,

Gast: die werden sich da was dabei gedacht haben, ich muss das konfigurieren,

Gast: aber ich kann es auch konfigurieren.

Gast: Wenn ich konfigurieren kann, dann kann ich auch Performance ausholen.

Wolfgang: Ist das stark verbreitet, Clickhouse? Du hast gesagt, das ist so das größte Open Source Projekt.

Gast: Es ist relativ stark vorbei mittlerweile. Ich kann manchmal die Use Cases,

Gast: mit denen sie häufig wir haben, ist zum Beispiel Microsoft tut intern seine

Gast: Analyse-Tools für ihre eigenen Websites.

Gast: Also quasi für das Microsoft-Portal etc. pp.

Gast: Da haben sie sich eine Analyse-Chain auf einer Clickhouse aufgebaut.

Gast: Und es gibt auch, auf denen ihre Website haufen, weil sie Showcases von größeren

Gast: Unternehmen, die auf Clickhouse eben ihre Analysen durchführen.

Wolfgang: Okay, das ist echt super interessant. Was gibt es sonst aus dem Open-Source-Bereich?

Wolfgang: Gibt es da nicht auch was von Apache vielleicht?

Gast: Wenn du mich so fragst. Es gibt direkt zwei Apache-Systeme, über die wir reden

Gast: könnten. Druid und Doris.

Gast: Genau, mit dem Druid anfangen. Druid ist ein interessantes Ding,

Gast: weil es ist jetzt als Data Warehouse gedacht, aber es hat ein bisschen so einen Spezialfall.

Gast: Druid ist insofern anders als Kligos, als bei Druid bindest du direkt den ganzen

Gast: Cluster auf, wenn du den hochziehen willst.

Gast: Du musst, weil das Cluster des Systems gebaut ist, mehrere Nodes zur Verfügung stellen.

Gast: Du hast immer eine Aufsichtsnode, also quasi irgendwann ein Master und du hast mehrere Worker Nodes.

Gast: Auf den Worker Nodes liegt dann immer ein Subset der Daten und die können die

Gast: Daten untereinander hin und her replizieren und dadurch auch,

Gast: sag ich mal, Abfragen könnten auf verschiedene Buchzeiten der Daten gehen.

Gast: Das heißt, die Masternacht kümmert sich dann darum, dass die korrekten Worker

Gast: die korrekte Teilabfragen bekommen und dann sammelt der quasi die einzelnen

Gast: Ergebnisse ein. Also du hast da so ein Shuffle-Curray-System.

Gast: Genau, und was das halt relativ gut kann und worauf es ausgelegt ist,

Gast: sind Echtzeit-Event-Daten.

Gast: Also der Druid ist dafür gebaut, dass wenn du deine Daten ingestestest,

Gast: dass sie innerhalb von wirklich Minisekunden deinen neuesten Events bereits

Gast: in deinem System drin sind, weil Druid auch ganz klar sagt, wir machen das gesamte

Gast: Indexing und die Optimierung selber.

Gast: Das heißt, du hast beim Ingest, sage ich mal, wesentlich weniger Kontrolle als

Gast: bei manchen anderen Datenbanken, wo du dein Index jetzt selber festlegst,

Gast: sondern die sagen, wir machen das.

Gast: Wir haben auch hauptsächlich Wissenschaftliche Paper, wo sie sagen,

Gast: wie sie genau das machen.

Gast: Weil wir dann alles wirklich auf diesen Echtzeit-Use-Case zuschneiden,

Gast: um dir dann wirklich garantieren zu können, also wo das ganz groß ist,

Gast: so ein Börsen-Use-Case ist,

Gast: wo du dann gesamte Orderbooks drin hast und einfach sagen kannst,

Gast: okay, auf den allerneuesten Transaktionsdaten kann ich hier meine Analysen in Echtzeit durchführen.

Gast: Gleichzeitig hast du dann natürlich ein hochkomplexes, verteiltes System,

Gast: das schon einiges an Hopplan-Operations erfordert, um es am Laufen zu halten.

Wolfgang: Also das ist nichts, was man sich einfach mal so installiert.

Wolfgang: Da brauchst du auch echt die Leute dafür, die es betreiben können.

Wolfgang: Und du musst dir vorher auch gute Gedanken drüber machen, wie das Setup aussieht,

Wolfgang: was du an Infrastruktur brauchst, etc.

Gast: Genau, so Druid ist wirklich so ein Use Case, wo ich sagen würde,

Gast: macht man sich Vorgedanken, ob man den braucht.

Gast: Aber wenn das was ist, was man lösen kann, dann kann man es damit meistens deutlich

Gast: besser lösen als mit anderen Systemen, was dann wirklich drauf abgestimmt ist.

Wolfgang: Und dann hast du gemeint, es gibt noch Doris von Apache.

Gast: Genau, Apache Doris ist ein relativ junges Projekt. Das ist aus dem chinesischen

Gast: Bereich entstanden bei Tencent hauptsächlich.

Gast: Die haben sich ein eigenes Data Warehouse. Es steht auch, wenn man sich zwischen

Gast: den Zeilen der Doku liest, kommt es mir manchmal vor wie so ein Frontal-Angehörer

Gast: aus Snowflake, nur halt als Open-Source-System.

Gast: Effektiv ist es auch Data Warehouse, komplett verteilt.

Gast: Du hast auch eine Aufteilung in einzelne Worker-Nodes und Node-Sie-Queries entgegennehmen,

Gast: ähnlich wie beim Druid, nur dass es halt nicht wie beim Druid alles auf 100%

Gast: Realtime getrimmt ist, sondern dir die DORIS auch erlaubt,

Gast: deine Indizes und deine Datenmodelle mehr oder weniger selber festzulegen,

Gast: so wie es halt für dich am besten passt und dir letzten Endes auch ähnlich wie

Gast: auf einem Klick aus deiner,

Gast: Query-Engines auszuwählen und sauberer hinzuzufügen.

Wolfgang: Ja, echt spannend, dass es da so viele Sachen gibt. Ich finde es immer interessant,

Wolfgang: wenn wir auf der einen Seite gute Open-Source-Systeme haben,

Wolfgang: die auch verwendet werden bei großen Kunden, man aber auf der anderen Seite

Wolfgang: natürlich die großen fetten Platzhirsche hat.

Wolfgang: Also gerade sowas wie Oracle, SAP, Microsoft, die ja schon seit Jahrzehnten hier sind.

Wolfgang: Und gerade Snowflake kenne ich auch. Du hast gemeint, die gibt es seit so 10, 15 Jahren.

Wolfgang: Das heißt, die haben natürlich auch schon eine riesengroße Basis einfach an

Wolfgang: Installationen oder an Usern.

Wolfgang: Und was sich für mich da immer so ein bisschen als Frage herauskristallisiert,

Wolfgang: wir haben ein spannendes Thema, das für viele Unternehmen relevant ist.

Wolfgang: Wir haben viele Anbieter, die etabliert sind, also von Oracle über Snowflake bis hin zu Clickhouse.

Wolfgang: Und da frage ich mich immer, wo sind so die großen Unterschiede,

Wolfgang: Vielleicht ist es abgesehen vom Lizenzmodell, aber wo ist vielleicht aber auch

Wolfgang: noch so ein bisschen dieses Potenzial für Verbesserung und Optimierung?

Wolfgang: Also wenn es immer nur einen Anbieter gibt oder nur zwei Anbieter,

Wolfgang: dann ist meistens der Markt ziemlich ausdefiniert schon einfach.

Wolfgang: Wenn es aber so eine ganze Handvoll oder mehr Anbieter gibt,

Wolfgang: das wirkt für mich immer so ein bisschen wie, da ist noch Bewegung drin.

Wolfgang: Und gerade hier, wir haben darüber gesprochen, das Thema gibt es seit, I don't know, 40 Jahren.

Wolfgang: Und wenn nach 40 Jahren da aber immer noch Bewegung drin ist,

Wolfgang: da bin ich halt neugierig. Ich meine, ich habe ein Experten vor mir.

Wolfgang: Wo geht die Reise hin? Jetzt nicht in den nächsten 40 Jahren,

Wolfgang: sondern vielleicht in den nächsten zwei, drei, vier Jahren.

Wolfgang: Gibt es da aktuell am Horizont spannende Themen, wo du sagen würdest,

Wolfgang: ja, da wird wahrscheinlich was kommen oder da könnte irgendwie was Spannendes kommen?

Gast: Ja, definitiv. Es ist ein hochbewegter Bereich und man sieht es auch gerade

Gast: daran, dass sich die einzelnen Anbieter ja hauptsächlich schlachten über die Benchmarks.

Gast: Also gerade die Art und Weise, wie die Open-Source-Hersteller gerne die Closed-Source-Hersteller

Gast: angreifen, indem sie sagen, okay, wir haben hier schon wieder zig Benchmarks abgeräumt.

Gast: Wir sind einfach besser, unser System funktioniert besser, weil wir es eben

Gast: Open-Source entwickeln und weil wir ja effektiv viel mehr Entwickler haben,

Gast: als so ein Unternehmen eigentlich immer stemmen könnte.

Gast: Weil die ganzen Leute können es ja niemals bezahlen, die an so einem großen

Gast: Open-Source-Projekt arbeiten. Ich meine, schau dir mal nur eine Postgres an.

Gast: Warum gewinnt die jedes SQL-Datenbank-Batchmark?

Gast: Einfach weil viel mehr Leute daran arbeiten mit viel mehr Expektive.

Gast: Die sich ja über die Jahrhunderte an Arbeit, die da reingeflossen sind, ansammeln.

Gast: Wenn ich darüber nachdenke, wo sind gerade die interessanten Sachen,

Gast: die sich passieren, ist einerseits noch, wie gehe ich wahrscheinlich mit weniger

Gast: strukturierten und auch teilweise unstrukturierten Daten um.

Gast: Da gibt es interessante Ansätze.

Gast: Gerade ist ja schon viel in Richtung JSON-Parsing und Document-Parsing passiert.

Gast: Und was zum Beispiel so eine Apache Doris kann, ist, die kann Federated Queries

Gast: nicht nur auf ihrem eigenen Data Layer, sondern die kann auch auf deinen Data

Gast: Lake gehen. Also wenn du da Daten irgendwie hast, die zum Beispiel im Iceberg-Format

Gast: schon rumliegen, kann die die auch ansteuern.

Gast: Und das Interessante ist dann für mich, ja letzten Endes, wenn ich diese Ausführungs-Engine-Hubs

Gast: in den Datenmarkten, die ja jetzt letzten Endes getrennt sind vom Storage,

Gast: ich habe da Computereinheiten, wie kriege ich das jetzt zusammen mit,

Gast: sage ich mal, meinen KI-Algorithmen, die ich aktuell trainiere?

Gast: Also schaffe ich es vielleicht auch, meine Inferenz irgendwie direkt auf meinem

Gast: Datenbanksystem durchzuführen, das quasi im Analyseprozess direkt aufrufen zu

Gast: können, wie in der Startprocedure, dass ich jetzt sage,

Gast: okay, die ruf folgendes KI-Modell auf, um darauf zu trainieren.

Gast: Und da gibt es auch schon erste Ansätze.

Gast: Einerseits bei Snowflake, andererseits aber eben auch bei Doris,

Gast: bei Clickhouse, um die Dinge zu verknüpfen oder auch um vielleicht auch Trainingsdaten

Gast: besser zur Verfügung zu stellen oder auch die zweite Sache ist natürlich Abfrageoptimierung.

Gast: Kommt da auch irgendwann mal das Thema KI rein, weil die meisten Abfrageoptimierer,

Gast: laufen ja aktuell noch auf entweder Ressourcen oder regelbasierten Systemen.

Gast: Also entweder ich versuche mehrere Pläne aufzustellen und gucke mal,

Gast: welcher ist der billigste oder ich habe Auf Apache Spark zum Beispiel im Katalys

Gast: tausende Optimierungsregeln, die da untereinander greifen.

Gast: Da laufen gerade auf vielen ecken und netten Experimente mit,

Gast: kriege ich vielleicht irgendwie ein KI-basiertes System da rein,

Gast: das mir meine Queries noch krasser optimieren kann, das vielleicht auch lernt,

Gast: wie meine Daten aussehen.

Wolfgang: Gibt es da schon eine fehlversprechende Ansätze für Query-Optimierung mit KI?

Gast: Ich habe noch keinen gesehen, der funktioniert hätte. Aber ich glaube,

Gast: es liegt nicht am Mangel an Versuchen.

Gast: Ich bin auch ziemlich überzeugt, dass da in den nächsten vier,

Gast: fünf Jahren vielleicht spannende Durchbrüche auf uns zukommen.

Wolfgang: Das ist interessant. Ja, aber du hast gerade schon KI angesprochen.

Wolfgang: Ich meine, KI steckt heute überall drin.

Wolfgang: KI wird von vielen als die große universelle Verheißung irgendwo gesehen für

Wolfgang: ganz utopische, tolle Sachen.

Wolfgang: Abgesehen von so Sachen wie so Query-Optimierung, siehst du noch andere Ansätze,

Wolfgang: wo man vielleicht mit KI das klassische Data-Warehousing weiterbringen kann?

Gast: Einerseits ist es wahrscheinlich User-Facing. Heutzutage brauchst du immer noch,

Gast: wenn du so ein Data Warehouse hast, ist ja cool und hast deine Daten da,

Gast: du brauchst trotzdem noch eine BI-Schicht.

Gast: Also irgendjemand, der da vorsitzt, deine BI-Reports baut.

Gast: Und es gibt ja in den, sag ich mal, neueren, cooleren BI-Tools,

Gast: wie zum Beispiel Metabase, ja jetzt schon die Möglichkeit Chat-Befue Data zu machen.

Gast: Also du formulierst deine Abfrage oder deine Anfrage nicht mehr in SQL,

Gast: sondern in natürlicher Sprache und das System kümmert sich darum,

Gast: eine SQL-Query zu bauen, die dann gegen das Data Warehouse geht und zu sagen,

Gast: okay, ich hole dir jetzt hier für deinen Bericht die nötigen Daten raus.

Gast: Das sind natürlich spannende Sachen.

Gast: A, wie Interface haben wir direkt gegen so ein System?

Gast: Wäre es zum Beispiel vielleicht auch nützlich für so ein Data Warehouse neben

Gast: der klassischen Dokumentation jetzt natürlich als SQL-Datenbank-Schema, wie man es kennt,

Gast: vielleicht auch irgendeine Form von Dokumentation, keine Ahnung,

Gast: sei es ein YAML oder irgendein Maschinen-Liesbaren-Format zu haben,

Gast: dass du quasi in den Kontext von so einem MLM pipen kannst, damit es,

Gast: sag ich mal, die Queries korrekt schreiben kann, auch weil es welche Datenbanken

Gast: und welche Datentypen-Entities du hast.

Gast: Aber sowas ist auf jeden Fall eine interessante Sache, gerade so Chat mit your

Gast: Data und Use Cases optimal zu unterstützen.

Gast: Und dann ist vielleicht auch irgendwann mal die Frage, wenn man sich vielleicht

Gast: anguckt, wie funktionieren die Query Patterns von so einem LLM vielleicht zu

Gast: dem, was ein Mensch schreibt, ob man irgendwann auf die Idee kommen würde,

Gast: einzelne Datamarts, also Datenmodelle, speziell für, sage ich mal,

Gast: KI-Konsumenten zu entwerfen.

Gast: Ob das auch eine Herausforderung ist, die in den nächsten fünf Jahren vielleicht auf uns zukommt.

Wolfgang: Ja, das wird auf jeden Fall spannend. Ich glaube, um,

Wolfgang: Potenzial steckt da auf jeden Fall drin, denn so die Dinge, in denen KI halt

Wolfgang: gut ist, also so Mustererkennung, Optimierung, das sind ja schon auch Dinge,

Wolfgang: die im Rahmen oder im Kontext vom Data Warehouse relevant sind einfach.

Wolfgang: Und da vielleicht irgendwie neue Ansätze zu finden, gerade eine Query zu optimieren

Wolfgang: oder andere Sachen zu optimieren oder gerade auch so dieser natürlichsprachige

Wolfgang: Ansatz, dass ich vielleicht so eine Art Self-Service-Portal habe für mein Data Warehouse,

Wolfgang: wo dann ich als Manager rangehen kann und ich habe vielleicht gar nicht so viel

Wolfgang: Ahnung von der Technik, brauche ich auch nicht, aber ich weiß,

Wolfgang: was ich eigentlich sehen möchte oder was mich interessiert.

Wolfgang: Und ich habe dann vielleicht so eine Art Dialogsystem und bekomme dann jetzt

Wolfgang: nicht nur Zahlen, sondern vielleicht auch noch irgendwie einen schönen Graphen

Wolfgang: oder vielleicht sogar einen fertigen Report, den ich dann auch ein bisschen nachjustieren kann.

Wolfgang: Das wäre natürlich schon super praktisch, wenn ich dann einfach so eine Art

Wolfgang: Mensch-Maschine-Interface habe,

Wolfgang: dass das besser funktioniert, denn wo ich dann nicht immer den in Anführungszeichen

Wolfgang: Umweg gehen muss über den Data Analyst, der sich dann in der Zeit vielleicht

Wolfgang: lieber um spannendere Sachen kümmert, also meine wöchentliche Auswertung zum

Wolfgang: Thema, was sind die beliebtesten Fahrradfarben jetzt?

Gast: Ja, und dann vielleicht natürlich noch quasi von der anderen Seite aus Seiten

Gast: des eben Data Engineers.

Gast: Inwiefern kann uns KI bei eben unseren ETL-Prozessen oder ELT-Prozessen unterstützen?

Gast: Aber wir haben ja häufig auch Aufgaben, die eher repetitiv sind.

Gast: Du hast ja x Datenschemas, die irgendwie in Normalformen sind.

Gast: Du willst da auch ein Sternschema bauen.

Gast: Klar, auf der einen Seite brauchst du dafür tiefe Business Insights,

Gast: um das Schema korrekt entwerfen zu können, aber auf der anderen Seite ist es

Gast: auch wieder so eine Operation, die häufig ähnlich verläuft und da ist vielleicht auch die Frage.

Gast: Wie lässt sich dafür ein guter Code Assistant bauen? Gerade für diese Use Cases

Gast: oder wie weit runter automatisieren kann man das noch?

Gast: Und dann eine andere Entwicklung, die da parallel läuft, ganz weggezogen von

Gast: den ganzen KI-Sachen, die jetzt schon auch seit ein paar Jahren läuft,

Gast: aber die ich finde, die sich gerade aktuell bestärkt ist.

Gast: Das weitere Zusammenwachsen von eben ETL schrägstlich ELT und Data Warehouse

Gast: selbst. Weil früher hattest du ja noch immer ein getrenntes Suite von Tools.

Gast: Du machst zum Beispiel deinen Load ganz klassisch von deinen Datenbanken auf

Gast: erstmal den Data Lake rein über einen Batch Copy und dann machst du deine Vorverarbeitung

Gast: von den Daten in dein Sternschema irgendwie mit Apache Spark und dann tust du

Gast: das finale Sternschema erst in das Warehouse reinladen.

Gast: Das ändert sich so ein bisschen teilweise, dass du jetzt erstmal direkt die

Gast: Rohdaten schon auf das Data Warehouse ablegst und dann innerhalb des Data Warehouses

Gast: mit SQL-Abfragen über so Systeme wie zum Beispiel,

Gast: DBT oder so, nach und nach deine einzelnen Medaillenschichten von Bronze,

Gast: Silber, dann aufs Gold-Sternschema in der SQL selbst machst und in der Datenbank selbst machst.

Gast: Und zum Beispiel gerade am Clickhaus ist darauf sogar ausgelegt,

Gast: weil die arbeiten da ganz viel mit Materialized Views und die sagen selber,

Gast: hole deine Rohdaten hier rein,

Gast: baue dann Schritt für Schritt die einzelnen Views, die sich aus den Rohdaten

Gast: ableiten, bis hin auf dein finales Galaxy-Schema und diese Views werden dann

Gast: quasi vom System selbst in so einer Art CDC-Prozess automatisiert im Hintergrund

Gast: geupdatet, wenn neue Daten da sind.

Wolfgang: Und Materialized Views bedeutet, dass die eben persistent sind und dass sie

Wolfgang: nicht in Echtzeit berechnet werden und dadurch halt eine bessere Performance hast.

Gast: Genau, dadurch sorgen die dafür, dass quasi, sag ich mal so,

Gast: 99% der Daten immer irgendwie relativ schnell vorhanden sind und,

Gast: sag ich mal, so die 1% der neuesten Updates vielleicht mit etwas Latenz reinlaufen.

Gast: Aber zum Beispiel Clickhouse sagt, für seine Zwecke, das sind die Use Cases, die sie abziehen.

Gast: Wenn du irgendwelche Zeitanalysen willst, hol dir Android.

Wolfgang: Und da kümmert sich dann quasi auch die Datenbank drum. Das heißt,

Wolfgang: du definierst einfach eine View ganz normal und die Datenbank sorgt dafür,

Wolfgang: dass das immer aktuell ist.

Gast: Genau, und wenn du es quasi Datenmarker genostisch haben willst,

Gast: kannst du es dann ganz mit DBT, also mit Data Build Tool machen,

Gast: wo du dann diese einzelnen Views entwirfst und dich dann quasi auch in dem Tool

Gast: über die Orchestration kümmerst, dass diese Workflows laufen.

Wolfgang: Okay, super spannend. Wir haben festgestellt, Data Warehouses sind auf jeden

Wolfgang: Fall für alle oder fast alle Unternehmen

Wolfgang: relevant, natürlich in einer ganz unterschiedlichen Ausprägung.

Wolfgang: Wenn ich jetzt einen Weltkonzern habe mit gigantischen Datenmengen,

Wolfgang: werde ich wahrscheinlich eine andere Lösung brauchen, als wenn ich jetzt den

Wolfgang: kleinen Fahrrad-Online-Shop habe.

Wolfgang: Und da frage ich mich natürlich, Marvin, was ist denn der beste Ansatz,

Wolfgang: um für sich selbst die beste oder die passendste Lösung zu finden,

Wolfgang: also im Sinne von, was für ein System, was selbst gehostet ist,

Wolfgang: irgendwas beim Hyperscaler, was es da von der Stange gibt oder vielleicht auch

Wolfgang: ein Clickhouse irgendwie oder ein Apache Druid.

Wolfgang: Ich meine, das hängt wahrscheinlich von vielen Faktoren ab, aber wenn du jetzt

Wolfgang: in deiner Rolle als Data Engineer mit einem Kunden sprechen würdest,

Wolfgang: dass der so in dem Punkt ist,

Wolfgang: wo der Kunde noch nicht sicher ist, was er genau braucht, aber er möchte in

Wolfgang: der Richtung was machen, weil er eben halt seine ganzen Daten hat und da Interessen

Wolfgang: einfach hat, was auszuwerten und Erkenntnisse rauszuziehen.

Wolfgang: Wie könnte denn so ein Findungsprozess aussehen?

Gast: Frage 1 ist für mich, und das überrascht jetzt vielleicht welche Leute im Publikum,

Gast: gar nicht so sehr die Frage nach Datenmenge, sondern erstmal die Frage nach Personal beim Kunden.

Gast: Habe ich eine Softwareabteilung oder auch ein IT-Team, das irgendwie Erinnerung

Gast: von Operations hat und auch irgendwie ein System darauf betreiben kann?

Gast: Oder ist das wirklich ein Unternehmen, das sich eigentlich auf andere Dinge

Gast: konzentrieren will, wo IT eher als Service betrachtet ist, dass man vielleicht

Gast: ein, zwei Atmen ins Zimmerhaus hat?

Gast: Weil dann beantworte ich erstmal die Frage, brauche ich eine Software-as-a-Service-Lösung

Gast: oder kann ich irgendwie Open-Source-Technologie selber hosten?

Gast: Und wenn die Antwort ganz klar ist, nee, wir wollen hier kein Hosting betreiben,

Gast: dann ist ja immer ganz klar, ich brauche Software-as-a-Service.

Gast: Und dann kann man jetzt erstmal gucken, welches man nimmt, dann ist das abhängig

Gast: ein bisschen von der Datengröße und davon, wie viel man auch Integration will,

Gast: wenn man dann wirklich eine einheitliche Plattform will und auch sagen will, okay, mir ist,

Gast: bewusst, dass ich ein bisschen Vendor-Login und ich will das aber vielleicht

Gast: auch und ich will auch vielleicht, dass die Daten irgendwie mit dem Rest zu

Gast: meiner Cloud gut funktionieren,

Gast: kann man schon sagen, mit Snowflake macht man ab einer gewissen Datenmenge schon

Gast: irgendwie nichts falsch.

Gast: Andere Alternative ist, wenn man vielleicht bereit ist, okay,

Gast: doch so ein bisschen drumherum zu bauen und vielleicht auch zu gucken,

Gast: dass man das Autodentifizierung und so doch selber machen kann,

Gast: der eine Atme, die man dann hat, dann würde ich vielleicht sagen,

Gast: selbst bei kleinen Datenmengen kann man die gehostete Variante von einem Blickhaus

Gast: ziemlich preiswert betreiben und es.

Gast: Braucht man halt ein bisschen Expertise, um die Schemata etc.

Gast: Korrekt darzustellen, aber da kommst du nie unter. Auf meinem Snowflake müssen deine Schemas stimmen.

Gast: Das heißt, einen Data Engineer wirst du immer brauchen, der zumindest mal,

Gast: sei es auch Data Engineer und BI Dude in Personalunion, sich darum kümmert,

Gast: dass die Daten da richtig reinlaufen. Aber dadurch spaßt dir zumindest das ganze Operations.

Gast: Oder einen großen Teil von Operations. Alles spaßt dir nie, um das mal so deutlich zu sagen.

Gast: Genau, das wäre so die erste Entscheidung. Also buy or make.

Gast: Wenn ich aber gleichzeitig sage, okay, ich habe jetzt kein Problem damit,

Gast: habe ich schon Teams in-house, die das können, dann kann ich mir natürlich auch

Gast: die Lizenzgebühren für so eine Software-to-Service-Lösung sparen und wenn ich

Gast: eh schon ein Kubernetes-Cluster habe, um mir Zeug zu hosten,

Gast: dann kannst du auch jetzt tiefer ins Detail gucken und sagen,

Gast: okay, welcher Use-Gest will ich wirklich abbilden, wie viele Daten habe ich,

Gast: wenn ich jetzt eine kleinere Datenmenge habe, würde ich immer noch sagen,

Gast: top, nehmt ein Klick aus.

Gast: Oder vielleicht sogar, wenn ihr da eine Postgres rumstehen habt,

Gast: zieht eine zweite Postgres-Datenbank hoch, installiert Hydra,

Gast: damit lernt sie Columnar Storage und macht einfach auf der Hüte oder dann.

Gast: Wenn ich sage, ich habe relativ große Datenmenge und ich weiß auch schon,

Gast: dass eine Note mir von vornherein nicht ausreichen wird, würde ich sagen,

Gast: okay, greift vielleicht nicht zum Klick aus, sondern schaut euch an, ist Doris was für uns?

Gast: Haben wir auch politisch kein Problem damit, uns so ein bisschen Tencent ans Bein zu minden?

Gast: Wenn man da mutig genug ist, würde ich sagen, ja, greift zu Doris,

Gast: die ist frisch, die erinnert sich noch stark, aber die ist halt mega performant

Gast: und gerade bei einem jungen Open-Source-Projekt hast du auch immer noch so ein

Gast: bisschen die Chance, eine größere Stimme zu werden.

Gast: Auch wenn du Contribute ist und auch größerer Vendor oder größerer Kunde bist,

Gast: dass man vielleicht auch mal hier und da ein Feature für dich entwickelt.

Gast: Wenn ich jetzt JV Morgan Stanley bin und mein Orderbook,

Gast: automatisieren will und da Echtzeitinformationen brauche, dann sage ich ganz

Gast: klar, jo, um den Druid kommt der nicht herum.

Gast: Aber dann wird man auch die Teams dafür haben.

Wolfgang: Also es ist dann trotzdem aber eine sehr individuelle Entscheidung.

Wolfgang: Also man kann nicht einfach sagen, okay, X oder Y passt immer oder X ist für

Wolfgang: einen Einstieg immer super, sondern man wird nicht drumherum kommen,

Wolfgang: sich an den Tisch zu setzen, wahrscheinlich nicht nur einen Tag und mal die

Wolfgang: ganzen Punkte mal durchzuarbeiten.

Wolfgang: Und ich finde gerade, was du am Anfang gesagt hast mit den Leuten,

Wolfgang: die Operations machen oder überhaupt mit dem Personal, das man braucht,

Wolfgang: das finde ich ist eine super, super wichtige Frage.

Wolfgang: Ich habe das ab und an auch schon mal erlebt, dass das eine Frage ist,

Wolfgang: die gar nicht so intensiv diskutiert wurde, weil man sehr lösungsorientiert

Wolfgang: war und dass man dann aber irgendwann an einen Punkt kam,

Wolfgang: wo man gemerkt hat, oh, jetzt bräuchten wir ja noch Leute, die die Expertise haben.

Wolfgang: Und ich weiß nicht, wie es bei den ganzen Lösungen ist, aber ich vermute,

Wolfgang: da wird so die Zwei-Tage-Schulung wahrscheinlich auch nicht ausreichen,

Wolfgang: um dann wirklich ein Profi drin zu sein, sowas zu betreiben.

Gast: Genau. Das Ganze ist eine Software-Architektur-Entscheidung und deswegen muss

Gast: man es so behandeln wie jede andere Software-Architektur-Entscheidung.

Gast: Du musst deinen Kontext analysieren, du musst vor allem deine qualitativen Anforderungen

Gast: an das System erheben, also formulieren, wie viele Daten erwarte ich,

Gast: wie viele Daten müssen in welcher Geschwindigkeit abfragbar sein.

Gast: Und erst wenn du all diese Fragen beantworten kannst, dann kannst du die oberste

Gast: Regel der Softwarearchitektur anwenden, die lautet, it depends.

Wolfgang: Aber apropos it depends, war noch so eine ganz andere Frage.

Wolfgang: Jetzt kommt vielleicht ein Kunde um die Ecke mit dem großen Bedürfnis,

Wolfgang: ein Data Warehouse zu haben.

Wolfgang: Braucht jeder ein Data Warehouse? Ich meine, ich habe vorhin gesagt,

Wolfgang: ja, es ist relevant für jeden, aber stimmt das überhaupt?

Wolfgang: Braucht man unbedingt ein Data Warehouse oder gibt es vielleicht auch Situationen,

Wolfgang: wo man jetzt ein bisschen Analytics möchte, ein bisschen Insights möchte in seine Daten,

Wolfgang: wo aber vielleicht eine normale Datenbanklösung, die man sowieso hat,

Wolfgang: schon ausreicht oder völlig, völlig okay ist, dass man da vielleicht Daten rauszieht

Wolfgang: und ein bisschen, weiß nicht, Microsoft Power BI dran stöpselt,

Wolfgang: um da schöne Auswertungen zu haben.

Gast: Also mal gucken, dass du mit deinen analytischen Queries eben dein Business

Gast: System nicht interruptest, dass wenn du quasi auf einem Scale bist,

Gast: der so klein ist, dass du sagst, okay,

Gast: die analytischen Queries können nebenläufig zu den Online-Qeries laufen,

Gast: ohne dass du die Datenbank dabei,

Gast: Latenzprobleme kriegst, dann klar, dann brauchst du da kein zweites System,

Gast: sondern kannst auf deinem Online-System genauso gut auch die analytischen Queries

Gast: mit ein bisschen Schmerzen vielleicht bei den Queries, weil du FME und Jordan

Gast: brauchst in deiner dritten Normalform.

Gast: Aber klar, es gibt Punkte, da kommst du damit durch.

Gast: Vielleicht brauchst du auch kein komplettes Data Warehouse-System.

Gast: Vielleicht reicht es dir auch einfach, die Daten in deiner Datenbank,

Gast: wenn sie nicht so groß sind, dass dir dann einer anlöst, sich das einmal mit,

Gast: DuckDB abzieht, dann hat er sie lokal bei sich im Hauptspeicher und kann auch mit DuckDB arbeiten.

Gast: Das ist auch so ein zweiter Begriff, ne? Build your own Data Warehouse.

Gast: Vielleicht wirst du auch gar kein Data Warehouse an sich, sondern du sagst,

Gast: du wirst ein Data Lake haben, weil du vielleicht eh schon irgendwelche AI-Analysten

Gast: hast, dann hast du die Daten da eh schon rumliegen.

Gast: Dann kannst du an den ganzen Kopien von den tabellarischen Daten,

Gast: die du da drin hast, quasi auch so eine Art Data Ware aufbauen,

Gast: in dem du eine Query Engine drauf loslässt, wie zum Beispiel Trainer oder so,

Gast: die dann quasi auf dem Data Lake auch erstmal quasi noch die einzelnen tabellarischen

Gast: Dateien, jetzt Paketdateien oder Iceberg-Dateien oder whatever,

Gast: eben ein Sternschema erst bringt und dann dieses Sternschema ganz von alleine

Gast: eben in seinen eigenen Prozessen abfragt.

Wolfgang: Ja, super, super interessant. Ich merke schon wieder, das ist halt auch so ein

Wolfgang: roter Faden, der sich irgendwie durch alle IT-Projekte durchzieht.

Wolfgang: Es ist so super wichtig, sich am Anfang die Zeit zu nehmen, um so eine Fragestellung,

Wolfgang: so ein Problem ausführlich zu analysieren und dann die passende Lösung zu finden einfach.

Wolfgang: Weil ich glaube, man kann halt viel Geld investieren in eine Data Warehouse-Lösung

Wolfgang: und traurig ist es halt, wenn man das gemacht hat und es läuft alles und man

Wolfgang: merkt, oh, da ist gar keine Last drauf, wir hätten es vielleicht gar nicht gebraucht.

Wolfgang: Es hätte vielleicht auch anders funktioniert und wir hätten uns das Geld sparen

Wolfgang: können für eine andere Weiterentwicklung, wo wir was Wertvolleres für uns oder

Wolfgang: was Wertstiftenderes irgendwie hätten entwickeln können.

Gast: Ja, klar, drauflos, Ingenieren führt selten zu guten Lösungen.

Gast: Und deswegen ist, genau, am Anfang jedes Projekts sollte natürlich an der Bedarfsanalyse

Gast: stehen und eben, wie man es in der Softwarearchitektur lernt,

Gast: das Erheben von A, unseren fachlichen Anforderungen,

Gast: aber auch von unseren Qualitätsanforderungen beantworten zu können,

Gast: auf welche Art und Weise müssen wir unser System skalieren, wo wollen wir hin,

Gast: wo stehen wir vielleicht heute, wo stehen wir in zehn Jahren,

Gast: wie müssen wir wachsen können und all diese Fragen müssen halt am Anfang beantwortet

Gast: werden, bevor du halt irgendeine Form von Technologieentscheidungen treffen kannst, natürlich.

Gast: Zumindest, sage ich mal, sinnvoll treffen kannst. Kannst du dir auch aus dem

Gast: Bauch heraus sagen, okay, wir nehmen jetzt Snowflake, die Slides sehen gut aus.

Wolfgang: Was auch stimmt, die sehen sicherlich sehr, sehr gut aus.

Wolfgang: Da sind viele glücklich und zufriedene Menschen drauf und wahrscheinlich sind

Wolfgang: die vor allem wegen der Lösung so zufrieden und so glücklich.

Wolfgang: Aber Spaß beiseite, ich glaube, das darf man halt nicht vergessen.

Wolfgang: Sobald eine Lösung nicht mehr so super trivial und einfach ist,

Wolfgang: dass man die in zwei Tagen fertig hat, lohnt es sich, glaube ich,

Wolfgang: ausführlich darüber nachzudenken, weil sonst legst du am Ende halt irgendwie

Wolfgang: drauf oder hast am Ende vielleicht irgendwie eine tolle Lösung gebaut,

Wolfgang: die aber die falsche ist.

Gast: Und insbesondere hast du bei Data Warehouse ja häufig so das Pech,

Gast: dass du meistens businesskritische Lösungen baust, weil du ja das Decision Support

Gast: System für dein Management zum Beispiel irgendwie hochziehen willst.

Gast: Und da sind Überlegungen hier besonders angebracht.

Wolfgang: Und wenn es bei mir soweit ist, Marvin, dass ich für meinen Online-Fahrradladen

Wolfgang: mal ein vernünftiges Data Warehouse benötige,

Wolfgang: dann würde ich mich natürlich freuen, wenn du Zeit hast, um mich da mal ausführlich

Wolfgang: zu beraten und mir das vielleicht auch auszureden, weil aufgrund des geringen

Wolfgang: Bestellvolumens vielleicht eine Excel-Tabelle ausreicht. Aber Spaß beiseite.

Wolfgang: Ich fand es super interessant. Also du hast viele Lücken in meinem Kopf gefüllt

Wolfgang: mit Fachwissen, was ich natürlich in Zukunft hoffentlich mal einsetzen kann irgendwo.

Wolfgang: Aber ich fand es sehr spannend, weil gerade das Thema Data Warehouse ist halt

Wolfgang: echt ein altes Thema, weil es halt 40 Jahre alt ist, aber immer noch Bestand

Wolfgang: hat. und ich fand es spannend, diese ganzen Aspekte mal zu beleuchten.

Wolfgang: Also vielen, vielen Dank für deine Zeit und vielen Dank für deine spannenden

Wolfgang: Erfahrungen, die du mitgebracht hast.

Gast: War mir eine große Freude und vor allem eine große Ehre, hier in diese ehrwürdigste

Gast: Aller-InnowX-Einrichtung mal eingeladen zu werden und freut mich natürlich,

Gast: dass ich dir auch mal wieder helfen konnte.

Wolfgang: Sehr, sehr gerne. Und wer weiß, was das nächste spannende Datenthema ist,

Wolfgang: wo du genau der richtige Gesprächspartner für bist.

Wolfgang: Vielen Dank.

Voiceover: Das war das Gespräch mit Marvin. Ich hoffe, es hat euch Spaß gemacht.

Voiceover: Wenn ihr Feedback habt, dann erreicht ihr mich per E-Mail unter podcast.innervex.de.

Voiceover: Wir hören uns in der nächsten Folge wieder. Bis dahin wünsche ich euch viel Spaß und eine gute Zeit.