Datenarchitekturen

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mit Rainer. Wir quatschen, wir haben irgendwie fast zu viel vor. Wir wollen in einer Stunde reinpacken, was ein Data Warehouse, Data Lake, Lakehouse, Data Mesh ist. Das ist nur kurz, da haben wir eine Folge. In Memory Analytics, wie DuckDB und Duck Lake, Data Fabric, Data Contracts auch nur ganz kurz, weil da haben wir eine Folge und Data Products auch nur ganz kurz, weil da haben wir eine explizite Folge. Und natürlich noch so ein paar einführende Dinge. Okay, wir versuchen es, Rainer, 60 Minuten.

Rainer Jaspert: Hallo Sven, vielen Dank für die Einladung hier zu dem Podcast.

Sven Johann: Genau, du bist mein Go-to Guy für Data Architecture bei INNOQ. Willst du noch mal so ein, zwei Minuten was über dich sagen, was du so treibst?

Rainer Jaspert: Ja, sehr gerne. Also, seit ungefähr 30 Jahren bin ich als Consultant im Geschäft. Ich habe mich in meiner Anfangszeit sehr intensiv mit Data Warehousing beschäftigt. Damals begannen Unternehmen, insbesondere Kreditkartenunternehmen, Data Warehousing für sich zu entdecken. Unter damals etwas fragwürdigen Bedingungen wurden die Daten der Kreditkarten auch für andere Zwecke verwendet. Ich glaube, da sind wir heute viel weiter und besser. Aber damals wurde natürlich viel aufgebaut und viel gelernt, wie man Daten für analytische Zwecke nutzt. Das ist, glaube ich, der wichtige Punkt: nicht für operatives Kreditkarten-Processing, das war klar, sondern für analytische Zwecke, wie zum Beispiel Fraud Detection, was immer noch hochaktuell ist.

Sven Johann: Mhm.

Rainer Jaspert: Diese analytischen Zwecke wurden damals bearbeitet, nicht nur bei Kreditkarten, sondern auch im Großhandel, die das gleiche Thema hatten. Ich war im Umfeld der HP NonStop Maschinen tätig, die früher Tandem hießen und dann von HP übernommen wurden. Diese waren gut geeignet für die Verarbeitung von Massendaten. Ich war auf diese Technik, auf diese HP NonStop Maschinen, spezialisiert, deswegen sind wir in diese Fachlichkeit reingerutscht. Das ist zum einen der Grund. Dann bin ich vor 20 Jahren zu INNOQ gekommen, und das Thema Datenanalyse, sich mit Daten beschäftigen, ist da etwas in den Hintergrund gerutscht. Wir haben damals, also generell kümmern wir uns eher um die operative Seite, haben wir damals gemacht und haben dann versucht, verteilte Systeme, unternehmenskritische verteilte Systeme, zu bauen und die Kunden dabei zu unterstützen. Das ist, glaube ich, immer noch unser Hauptthema: Wie macht man sowas? Dabei habe ich dann viel über verteilte Systeme gelernt. Und jetzt fließen die Dinge wieder zusammen. Wir waren damals bei INNOQ sehr skeptisch gegenüber analytischer Datenverarbeitung, weil sie so monolithisch ist, also immer ein großer Block von Daten, der in die Mitte gestellt wird und alle bedienen sich daraus. Da haben wir immer gedacht, verteilte Systeme gehen anders. Deswegen waren wir immer sehr skeptisch. Wir haben das zum Teil gemacht, ich habe da auch Projekte in der Zeit bei INNOQ gemacht, aber deutlich weniger als davor. Und jetzt kommen wir so langsam mit Data Mesh vor allem, das ist natürlich ein bisschen der Paradigmenwechsel in der Welt, dass wir sagen, ja, wir können da auch bei Daten richtig verteilte Systeme machen. Und da freue ich mich natürlich total drüber, jetzt wird das Thema wieder für INNOQ interessant.

Sven Johann: Ja, ja.

Rainer Jaspert: Und ich habe mit der Data Mesh Initiative und Entropy Data, ich glaube, wir können da drauf eingehen, schon einiges geleistet.

Sven Johann: Genau. Entropy Data, wie gesagt, Data Contracts mit Simon Harrer, dem CEO von Entropy Data, würde ich in die Shownotes packen. Beim Case Podcast haben wir auch mit Simon gesprochen, hat auch noch so ein bisschen über Data Marketplace und so weiter geredet, aber okay, da kommen wir vielleicht später noch dazu. Genau, fangen wir doch einfach mal an. Du hast analytische Daten gesagt und dann noch operationelle Daten. Kannst du noch mal dazu, was sind eigentlich die Unterschiede und was sind die jeweiligen Herausforderungen davon?

Rainer Jaspert: Ja, also diese Unterscheidung ist natürlich ein bisschen historisch, wurde immer sehr viel Wert draufgelegt. Man kann natürlich heute aus heutiger Sicht sagen, ja, das wächst natürlich alles irgendwie zusammen, sind nur noch Daten, aber ich glaube, es macht schon Sinn, wenn man sich die Lösungen, die es gibt, anschaut, dann ist vieles dadurch getrieben, dass wir halt eine klare Trennung zwischen operativen und analytischen Daten haben. Das steckt in vielen der Lösungen im Hintergrund drin. Mit operativen Daten kennen wir uns gut aus. Wir wollen eine Bestellung durchführen und müssen uns merken, was alles zur Bestellung gehört. Diese Daten bekommen wir über die UI oder über die Schnittstelle, verarbeiten sie, legen sie in der Datenbank ab und benutzen sie, verteilen sie vielleicht über Schnittstellen. Aber diese Daten sind sozusagen nur in unserem operativen Kontext existent. Wie wir die ablegen, welches Format wir ihnen geben, das ist völlig unter unserer Kontrolle, idealerweise. Idealerweise können wir das vollständig kontrollieren. Wir geben über Schnittstellen Daten nach draußen oder beziehen Daten von anderen, aber in unserem Bereich haben wir die volle Kontrolle darüber, wie wir mit diesen Daten hantieren. Auch andere Daten, die dabei entstehen, zum Beispiel Logdateien, da haben wir die Kontrolle darüber, was wir da in den Log reinschreiben und was nicht. Audits, wenn jemand auf unsere Anwendung zugreift, dann merken wir uns das. Das alles wollen wir gut kontrollieren. Und wir können dann auch hingehen und das Ding einfach ändern. Wenn wir sagen, unsere Anforderungen haben sich ein bisschen geändert, vielleicht Security oder Performance, kommen wir nicht mehr klar, müssen wir die Art, wie wir unsere Daten ablegen, wie wir sie organisieren, ändern, dann tun wir das einfach. Unsere Schnittstellen bleiben genauso ansprechbar und interoperabel mit der restlichen Welt wie vorher auch. Das ist so der Idealzustand der operativen Welt. Tatsächlich ist er dann auch wieder etwas anders. Und wir machen zum Beispiel Integration über Datenbank, das sieht man immer gerne. Würden wir natürlich vermeiden wollen. Genau. Wir haben es in diesen verteilten Umgebungen gelernt, darauf zu achten. INNOQ hat natürlich, ich glaube, mit den Self-Contained Systems einen wesentlichen Beitrag geleistet, wie man sowas macht. Ein guter Vorschlag, den man gerne beherzigen kann. Sobald wir uns in den analytischen Bereich begeben, haben wir diese Möglichkeit aber nicht mehr. Es muss einem sofort klar sein, wenn wir die Daten über den Zaun werfen und dann macht jemand anders analytische Dinge mit diesen Daten, die aber von meiner operativen Anwendung kommen. Auf einmal hängt jemand anders davon ab, was ich da zur Verfügung stelle und muss darauf reagieren, wenn ich mal irgendwas daran ändere. Wenn ich sage, hier, es kommt ein neues Feld dazu, oder wir strukturieren das um, wir wollen das Datenformat ein bisschen anders zur Verfügung stellen, das macht so keinen Sinn. Sofort sind andere von mir abhängig. Das ist der leichte Teil sozusagen. Der schwere Teil ist, ich muss erklären. Also, die Daten, die ich da über den Zaun schmeiße, die sind häufig erklärungsbedürftig. Und in dem Moment, wo ich es über den Zaun schmeiße, muss ich damit rechnen, dass Leute zu mir kommen und sich von mir erklären lassen. Und manchmal lassen sie sich nicht erklären, sondern interpretieren einfach, und dann muss ich damit leben, dass meine Daten falsch interpretiert werden. Also, diese Abhängigkeit auf einmal, die hat man. Und die wird besonders dann schwierig, wenn man jetzt an einer Stelle aus vielen Quellen, aus vielen operativen Systemen, Daten sammelt und versucht, die zusammenzubringen, also da so eine einheitliche, unternehmensweite Sicht auf die Daten zu erzeugen. Weil dann sitzt da in der Mitte auf diesem Topf mit einheitlichen Daten jemand, dem die Daten eigentlich nicht gehören, der die eigentlich nur mittelbar kennt, also nur über mich. So kennt er meine Daten. Ich habe sie ihm mal erklärt, und jetzt muss er damit klarkommen und muss interpretieren oder muss wissen, wie können jetzt die Daten von dem einen Topf mit den Daten aus dem anderen Topf kombiniert werden, um wiederum eine einheitlich stimmige Sicht zu erzeugen. Und das ist halt im Detail eine super schwierige Aufgabe, die dann, wenn ich dann sage, okay, ich habe fünf Quellen, vielleicht noch hin, und alle sind begeistert und es funktioniert hervorragend, und dann kommt die zehnte Quelle dazu, und derjenige in der Mitte ist völlig überfordert.

Sven Johann: Hm, hm.

Rainer Jaspert: Das ist das, was wir häufig in solchen Projekten erlebt haben, wo dieser monolithische Ansatz, wir integrieren alles und packen alles in die Mitte, dann irgendwann scheitert. Und natürlich die Datenwirtschaftsstrecken, also wie kommen die Daten vom operativen System in mein großes Paket, das ist dann natürlich auch fragil, das muss dann gegebenenfalls neu geändert werden, wenn sich was ändert, wenn da neue Felder hinzukommen, und dann brechen die zum Teil, und dann braucht man Strategien, wie man damit umgeht.

Sven Johann: Mhm.

Rainer Jaspert: Genau. Weil wie gesagt, das ist der große Unterschied: Sobald ich die Daten aus meiner Kontrolle nach draußen gebe und dann keinen direkten Einfluss mehr darauf habe, was damit gemacht wird, dann fangen Probleme an, die man im operativen Umfeld nicht hat.

Sven Johann: Okay, ja, war mir gar nicht so bewusst mit den 100 Quellen, die da zusammenkommen. Gut, also die erste Lösung, die ich so kenne, war halt Data Warehouse in dem Umfeld. Also, das gibt’s ja schon seit Jahrhunderten wahrscheinlich, ich übertreibe ein bisschen, aber was ist eigentlich so ein Data Warehouse? Das war ja wirklich so das erste, die erste analytische Datenbank, sage ich jetzt einfach mal, die auch ganz anders funktioniert als so eine relationale Datenbank.

Rainer Jaspert: Ja, die Technik war häufig dieselbe, es gab auch andere Ansätze, aber die Fachlichkeit war halt etwas anderes. Vielleicht noch vorher gab es natürlich auch Ansätze, aber häufig hat man dann in die Anwendung selbst Report-Generatoren eingebaut, also immer den analytischen Teil der Anwendung direkt in die operative Anwendung mit eingebaut. Der naheliegende Ansatz scheitert natürlich dann, wenn ich mehrere operative Anwendungen integrieren möchte oder wenn ich eine Auswertung habe, die über mehrere operative Anwendungen weggeht. Dann muss ich mir überlegen, in welche der operativen Anwendungen repliziere ich denn nun die Daten. Das geht dann irgendwann nicht mehr.

Sven Johann: Der erste Ansatz, den ich oft gemacht habe, ist, dass ich meine normale Datenbank mit operationalen Daten und ein paar Tabellen für historische Daten habe. Zum Beispiel sammle ich alle Orders. Es gibt Dinge, da mache ich keine Änderungen, sondern lege neue Einträge an, so eine Art Event Sourcing, obwohl es damals nicht so genannt wurde. Ich habe also Daten, auf denen ich Analysen durchführe und die Historie noch habe.

Rainer Jaspert: Das gibt es auch heute noch und ist oft sinnvoll, wenn ich eine Anwendung in der Cloud habe und Web-Analytics darauf anwenden möchte. Man kann argumentieren, dass man die Page Hits über externe Tools erfassen kann, aber man könnte solche Dinge auch direkt in der Anwendung machen.

Sven Johann: Mhm.

Rainer Jaspert: Dass man zählt, wie oft meine Anwendung genutzt wird. Man macht es typischerweise anders, aber warum nicht?

Sven Johann: Ja, genau, ich denke, es ist einfach. Man muss sich kein Teradata oder Ähnliches zulegen und kein Snowflake-Schema haben.

Rainer Jaspert: Wie gesagt, es gibt immer gute Gründe. Wir haben es auch letztes Mal bei der internen INNOQ-Anwendung diskutiert, inwiefern es Sinn macht, Dinge zentral auf einer einheitlichen Plattform zu machen oder ob die Anwendung das Reporting selbst übernimmt. Bei einer internen Anwendung wollten die Geschäftsführer ein paar Analysen und Reports haben, die man natürlich direkt einbauen kann.

Sven Johann: Ja.

Rainer Jaspert: Genau. Für mich ist der Punkt, an dem man über ein Data Warehouse nachdenken sollte, wenn ich versuche, Daten aus mehreren Quellen zu integrieren. Zwei Quellen gehen vielleicht noch, aber bei mehr als zwei würde ich sagen, dass wir an dem Punkt sind, wo wir über ein Data Warehouse nachdenken sollten, wenn wir eine Auswertung brauchen, die sich aus mehr als zwei Quellen bedient. Data Warehouse war der erste Ansatz. Damals gab es zwei Leute, Bill Inmon und Ralph Kimball, die sich darum kümmerten und im Wettstreit lagen, wer das richtige Data-Warehouse-Konzept anbietet. Sie unterschieden sich grundlegend, aber aus heutiger Perspektive vielleicht nicht so sehr.

Sven Johann: Ja.

Rainer Jaspert: Genau. Die Idee war, die Daten über ein sogenanntes ETL-Processing (Extract, Transform, Load) aus den operativen Systemen abzugreifen und in das Data Warehouse einzutragen. Dort sollte dann eine vereinheitlichte Sicht auf die Datenquelle hergestellt werden. Ein grundlegendes Merkmal bei beiden Ansätzen ist eine vordefinierte Zielstruktur. Das Data Warehouse gibt uns ein Schema vor. Wir denken uns das Schema aus, das gut geeignet ist, um unsere Auswertungen zu machen. Dann legen wir dieses Schema fest und bringen die Daten aus allen Quellen in dieses Schema. Natürlich erweitern wir das dann auch, wenn eine neue Quelle hinzukommt. Dann erweitern wir das Schema und die entsprechenden ETL-Strecken, also typische Batchverarbeitung, um die zusätzliche Quelle zu integrieren. Das ‘T’ steht für Transformation. Wir gehen immer davon aus, dass wir, wenn wir Dinge vereinheitlichen, transformieren müssen, weil die Datenformate natürlich auch vereinheitlicht werden müssen. Regionale Besonderheiten, zum Beispiel unterschiedliche Warengruppen in Italien und Deutschland, müssen wir transformieren, um eine vereinheitlichte Sicht auf die Daten zu erhalten. Das kann im Detail recht hässlich werden.

Sven Johann: Mhm.

Rainer Jaspert: Was wir auch haben, ganz wichtig dabei, ist die Historisierung. Operative Anwendungen brauchen typischerweise keine historische Sicht, sondern nur den aktuellen Zustand. Im Data-Warehouse-Umfeld wollen wir typischerweise die Veränderungen der Daten sehen und mitbekommen. Das heißt, wenn du umziehst, möchte deine Kreditkartenfirma wissen, wo du mal gewohnt hast, um zum Beispiel zu sagen: ‘Diese Transaktion hat Sven noch in Düsseldorf gemacht, als er in Düsseldorf wohnte, und diese Transaktion gestern hat er in Köln gemacht.’

Sven Johann: Ja.

Rainer Jaspert: Und wohnt er in Köln. Genau, diesen historischen Blick wollen wir mit Data Warehousing gerne haben. Es gibt eine ganze Theorie dazu, wie man historische Daten sinnvollerweise in so einem Schema abbildet.

Sven Johann: Okay, wie heißt die Theorie?

Rainer Jaspert: Wir nennen das Slowly Changing Dimensions. Im Data-Warehouse-Umfeld, das, was du vorhin mit Snowflake gesagt hast, unterscheiden wir gerne zwischen Dimensionen und Fakten. Ganz einfach gesprochen, sind die Fakten das, was ich in eine Zelle in Excel packe, und die Dimension ist das, was ich in die Spaltenköpfe oder in die erste Zeile packe. Das sind Dimensionswerte. Meine Fakten sind so etwas wie Transaktionsdaten. Wie viel wurde nun von einem Konto auf ein anderes übertragen? Dieser Wert würde in der Zelle stehen, das wäre der Fakt. Oder Lagerbestand, auch ein Fakt.

Sven Johann: Ah, ja, ja, ja, ja. Mhm, mhm. Mhm. Ja, ich habe noch so dunkel in der Erinnerung irgendwas mit Cube.

Rainer Jaspert: Genau, genau, wir haben das dann als Cubes bezeichnet, weil die Dinge mehrdimensional sind. Wenn ich natürlich jetzt noch drei Dimensionen habe, dann wird es ein Würfel. Diese Analogie wurde dann häufig gerne verwendet, um die Daten abzulegen. Es gibt auch Datenbanken, die multidimensional waren, also die genau das abgebildet haben, multidimensionale Datenbanken, die auch heute noch genutzt werden, um solche dimensionalen Daten abzulegen.

Sven Johann: Mhm.

Rainer Jaspert: Aber wie gesagt, Excel ist eine gute Möglichkeit, es sich vorzustellen. Und Slowly Changing Dimensions ist der Ansatz für das, was sich ändert, nicht die Fakten. Die Fakten habe ich unter einem bestimmten Kontext erfasst, zum Beispiel eine Transaktion, die gemacht wurde, als du in Köln oder Düsseldorf warst. Der Kontext ergibt sich aus der Dimension. Also Dimension Ort oder Wohnort, das ist die Dimension. Die Änderung des Wohnortes muss ich jetzt in der Dimension darstellen. Das heißt, ich muss einen einfachen Wohnort in der Dimension haben, zusätzlich einen, der auf Köln verweist, und einen auf Düsseldorf. Und dann ändern sich diese Dimensionen. Man geht davon aus, dass sie sich langsam ändern, deswegen Slowly Changing Dimensions. Wenn sie sich schnell ändern würden, würde man das vielleicht nicht so modellieren. Und man geht bei Dimensionen davon aus, dass sie sich langsam ändern, und damit fängt man diese Art der Historisierung ein.

Sven Johann: Ja. Gut. Ja, Data Warehouse, wie habe ich das vorhin gesagt, war so eine Weile das Ding, aber…

Rainer Jaspert: Ist auch heute, glaube ich, immer noch das Ding, okay.

Sven Johann: Ist immer noch, ist immer noch das Ding, okay.

Rainer Jaspert: Es ist immer noch sinnvoll, wenn man dieses Schema First hinbekommt. Also, wenn man sagen kann, ich habe hier genau das Schema, ich kenne das Schema, meine analytischen Anwendungen sind sehr ähnlich, die kommen alle mit diesem Schema klar.

Sven Johann: Okay.

Rainer Jaspert: Dann ist das immer noch sehr gut. Und wenn ich halt nicht so viele Änderungen im Schema habe. Wenn ich täglich eine Änderung in meinem Schema habe und zusätzlich auch noch häufig neue Auswerteanforderungen zukommen, wo ein altes Schema vielleicht nicht mehr so gut passt, dann ist Data Warehousing fragwürdig. Und das wurde genau erkannt, dass dieses Data Warehouse etwas zu unflexibel war für viele Anforderungen. Oft wollte man direkt KI-Modelle trainieren, und dafür möchte man dieses Schema First nicht haben, weil die Transformation passiert. Wenn ich die Daten für ein Modelltraining brauche, möchte ich die Rohdaten haben, so wie sie von meinem operativen System kommen. Ich möchte die Transformation vielleicht gar nicht. Dann werden solche Ansätze fragwürdig, oder eben wenn sehr, sehr viele Änderungen im Schema kommen, dann sind die ETL-Strecken in der Mitte überfordert, sie am Laufen zu halten, und dann geht das nicht mehr.

Sven Johann: Mhm. Mhm. Ja. Ja, ich kann mich noch erinnern, früher, wir waren noch jung, es war, glaube ich, so 2012, da war ich sogar mal Host vom Big Data Track bei der QCon London. Oh Gott, ja. Auf jeden Fall, da kann ich mich noch an einen Kunden von mir erinnern, der da war. Der hat halt gemeint, ja, hier, ich will den Data Lake und ich will Daten, wir sammeln jetzt Daten bis zum Abwinken, ob wir die brauchen oder nicht, da wird alles reingeworfen und genau. Ich dreh den Geldhahn auf und so weiter. Also, was ist jetzt, was ist ein Data Lake und wie unterscheidet er sich von so einem Data Warehouse? Und warum gab es den überhaupt? Der kam ja irgendwoher.

Rainer Jaspert: Ja, ich war in einem Projekt, in dem wir klassisch Data Warehousing vorgeschlagen hatten. Dann haben wir eine Evaluierung für Anbieter gemacht, und auf einmal kam einer um die Ecke und sagte: „Hey, dieses ganze in Data Warehouse schreiben ist doch blöd. Wir packen die ganzen Daten, die jetzt aus den Quellsystemen kommen, in XML-Dateien, stellen sie zur Verfügung, und unsere Reports machen wir direkt auf diesen XML-Dateien." Ja, ist doch eine Tatsache. Aber diese Idee hatte für den Kunden ein paar Vorteile, denn die hatten auf einmal diesen ganzen Schmerz, den das Aufbauen eines Data Warehouse mit der ETL-Bewirtschaftung hat. Das war ein großer Kunde, ein großes Projekt, weltweit Daten sammeln, und für die war das natürlich ein super Versprechen: „Ihr kriegt hier so ein XML hingeworfen, und ihr könnt direkt am ersten Tag auf Basis dieser XML den Report bekommen." Dann haben wir den gesehen und gesagt: „Wow!" Kein halbjähriges Projekt, kein Millionen versenken, bevor wir den ersten Report bekommen. Direkt der erste Report nach einem Tag. Nur in Cash. Man muss dann irgendwie sagen, ja, spricht was dafür. Und genau aus diesem Gedanken, oder eben die XML wollen wir vielleicht nicht mehr machen heutzutage, wollen wir was anderes, Apache oder so, aber die Idee, dass man einfach die Daten so wie sie sind, über den Zaun wirft, sie erst einmal zur Verfügung stellt und direkt den ersten Report auf diesen Daten machen kann, die ist halt total überzeugend. Hinzu kamen dann noch mal so ein bisschen technische Dinge. Wir waren vor allem auch häufig mit Datenbanken unterwegs. Also, wir haben die Daten halt in Datenbanken, die sind häufig transaktionale Datenbanken, die sind für Online Transaction Processing optimiert. Und die berechtigte Frage ist natürlich, brauchen wir das überhaupt für unsere analytischen Anwendungen? Wir brauchen doch, wir haben doch gar nicht das Thema, dass wir viele Updates haben und konkurrierende Reads auf sich ständig ändernde Daten, das haben wir doch gar nicht. In so einem Data Warehouse schreiben wir einmal rein und dann lesen wir häufig, aber wir haben wir nicht, wenn wir was ändern, dann machen wir eine neue einfach, das heißt, wir inserieren eine neue historische Version. Und kein Update auf die alten Daten, wir wollen ja gerade die Historie bewahren. Deswegen war die Frage, brauchen wir überhaupt diese Transaktionsmaschinen da, die halt für dieses operative Geschäft optimiert sind? Und da kam dann die Idee, lass uns doch die Daten nicht mehr in Datenbanken verwalten, sondern in Dateisystemen. Hadoop war damals so ein Dateisystem, mit dem so etwas ging. Hadoop war da deutlich weiter. Inzwischen stellen diese Dateisysteme die Möglichkeit zur Verfügung, auch über SQL-Schnittstellen auf diese Daten zuzugreifen. Wir verlieren also grundsätzlich von unseren Datenprozessierungsfähigkeiten nichts. Wir haben die Daten aber in Dateien, und das passt auch deutlich besser zu dieser Batchverarbeitung. Der Batch verarbeitet irgendwie eine ganze Reihe von Daten, liest sie aus den 100 Dateien, schreibt sie in 50 andere. Batchverarbeitung, keine Einzeldatensatzverarbeitung mit den Datenbanken, die wir sonst immer gemacht haben. Und dass man das eben auf Dateiebene über Batch macht, ist auch total überzeugend. So, diese beiden Dinge kamen dann zusammen, plus noch so Sachen wie Query Engines wie Spark, dass man dann MapReduce-Methoden im Gegensatz zu den üblichen Methoden zur Parallelisierung nutzen kann – wir haben Partitionierung, wir haben eine Tabelle partitioniert, das war auch wieder sehr statisch. Man muss sich auf eine Partitionierung typischerweise festlegen. Und wenn dann andere Anforderungen kamen, hat die Partitionierung nicht so ganz zu der Frage gepasst. Man muss anders partitionieren, und das war unsere Möglichkeit zu parallelisieren. Und jetzt mit MapReduce kam dann noch eine andere Möglichkeit der Parallelisierung hinzu, die vielleicht auch zu der Rechnerarchitektur besser passt, also dieses

Sven Johann: Ja, genau.

Rainer Jaspert: MPP, SMP-Frage, ich weiß nicht, ob wir da hier auch eingehen wollen.

Sven Johann: Ich würde gerne, aber ich glaube, wir müssen auf die Zeit achten.

Rainer Jaspert: Ja, aber das war.

Sven Johann: Du könntest zumindest ganz kurz sagen, was MPP und SMP bedeutet.

Rainer Jaspert: Also Massively Parallel Processing, das sind die Maschinen damals, die waren da gut. Ich füge einfach einen weiteren Rechenkern mit dazugehörigem Speicher hinzu. Konnte ich halt linear, idealerweise linear skalieren, einfach indem ich einen neuen CPU dazu genommen habe. Das hat weitgehend das Versprechen eingehalten, denn die Daten wurden massiv parallel verarbeitet. Und Symmetric Multiprocessing: Ich habe halt ein Cluster und da bin ich jetzt nicht mehr für die Verteilung zuständig, sondern der Cluster selbst entscheidet,

Sven Johann: Mhm.

Rainer Jaspert: wie er was sinnvollerweise verteilt, und das passt halt mit diesem MapReduce-Ansatz ganz gut.

Sven Johann: Ja. Das sagst du so, also ich muss ich erwähne einfach nur mal, also ich will gar nichts erwähnen, ich will nur sagen, ich früher, als MapReduce so rauskam, MapReduce total geil, macht Google, ich will MapReduce machen. Und irgendwann gedacht, MapReduce ist voll scheiße, aber also SQL ist doch viel besser, ja. Und na ja, okay.

Rainer Jaspert: Ja, das war.

Sven Johann: Gut, lassen wir das, lassen wir das.

Rainer Jaspert: Die Einflüsse, die in Richtung Data Lake gegangen sind und ihn so ein bisschen motiviert haben aus meiner Sicht, würde ich sagen, waren das so die treibenden Faktoren, um so etwas wie einen Data Lake zu entwickeln. Natürlich eine Schwachstelle, ganz klar, wenn ich das Schema nicht vorher habe, sondern wenn ich das Schema erst im Nachhinein erarbeiten möchte, dann mache ich das für jeden Report. Also jeder Report muss jetzt wieder hingehen und sagen, hey, wie muss ich dann jetzt die Daten von Quelle A mit Quelle B vereinheitlichen?

Sven Johann: Mhm.

Rainer Jaspert: Ich muss natürlich das Verständnis jeder einzelnen Quellanwendung haben, um die Daten richtig interpretieren zu können und so weiter. Der Reportersteller kann nicht hingehen und sagen, ich habe hier die eine Wahrheit aus dem Data Warehouse und dagegen programmiere ich jetzt, sondern der muss dann gegen jede Wahrheit jeder Quelle arbeiten. Nur hat er jetzt all die Schmerzen, die vorher die ETL-Programmierer ihm abgenommen haben durch die Vereinheitlichung in ein Schema, selbst.

Sven Johann: Mhm. Also Data Warehouse hat den Vorteil, ich kann Queries auf Daten ausführen, die bereinigt sind, das ist irgendwie alles klar, ich kenne die Tabellenstruktur und fertig ist die Laube, das ist der Vorteil. Der Nachteil ist natürlich, du musst die irgendwie, irgendwer muss die integrieren und muss die transformieren und wie auch immer. Data Lake nimmt praktisch diesen Nachteil weg, indem er sagt, du kannst einfach reinwerfen, was du willst, aber jetzt ist natürlich der bequeme Teil des Readers, also des Reporterstellers, der ist weg, weil der Reportersteller muss dann. Der muss wühlen.

Rainer Jaspert: Der muss die Arbeit machen. Einen Punkt habe ich noch vergessen, das ist halt Streaming. Batch Processing war halt so die Welt, und jetzt gab es aber auch die Möglichkeit, oder man möchte immer mehr in Richtung Streaming kommen. Und da vielleicht auch Anforderungen sind, dass die Daten nicht immer nur tagesgenau sind, sondern halt minütlich aktuell werden und das nicht, dass ich nicht immer halt die Daten in solchen Paketen da reinlege, also dieser Load-Vorgang ist immer ein ganzes Paket von Daten, was da übernommen wird, sondern ich möchte vielleicht – Stichwort Eventual Consistency – auch schon Daten reinfließen lassen und die Konsistenz vielleicht erst später herstellen. Und dieser Ansatz, das war noch ein weiterer Treiber für Data Lake, weil das mit Data Warehouse schwer ist. Streaming in ein Data Warehouse ist blöd, weil keine Konsistenz gewährleistet ist.

Sven Johann: Mhm.

Rainer Jaspert: Nur diese Eventual Consistency, da muss man sich überlegen, wie man das mit Data Warehouse macht.

Sven Johann: Ja.

Rainer Jaspert: Was man dann versucht hat natürlich: Man hat versucht, dass darüber hinaus diese Schwächen vom Data Lake, die offensichtlich sind, dann irgendwie in Richtung Data Warehouse wieder ein bisschen zu verbessern, das ist so der nächste Schritt.

Sven Johann: Also der nächste Schritt vom Data Lake zum Lakehouse.

Rainer Jaspert: Ja.

Sven Johann: Also Lakehouse ist ja im Grunde genommen so eine Art Kunstwort, weil es offensichtlich aus Data Lake und Warehouse kommt, ne? Genau, was ist da anders?

Rainer Jaspert: Ja, also man hat versucht, die Stärken von beiden Welten zusammenzukriegen. Ich kann meine Daten sehr schnell passend zum Originalschema aufnehmen, das bietet mir der Lake-Anteil, aber ich biete auch bestimmten Konsumenten schon ein klares Schema für ihre Auswertung. Das ist so der Data-Warehouse-Gedanke. Und dazwischen muss was passieren, und die Lakehouse-Architektur bietet mir halt jetzt gute Möglichkeiten, diese Rohdaten schrittweise zu verfeinern oder zu verbessern, sodass sie am Ende quasi wie in einem Data Warehouse nach außen zur Verfügung gestellt werden können. Aber ich kann auf alle Teile des Lakehouse schon zugreifen, wenn ich den Schmerz mir antun möchte, auf die Rohdaten zuzugreifen – das ist aber auch, wenn ich es schnell brauche, möglich. Ich kann aber auch warten, bis diese schrittweise Transformation innerhalb des Lakehouse passiert ist, und dann auf die bereinigten, vereinheitlichten Daten zugreifen. Im Grunde ist das – man hat das ETL-Processing ins Lakehouse verlagert, das passiert im Lakehouse selbst. Und was man da manchmal hört, ist die Medallion Architecture, ich glaube, das ist ein Begriff, der von Databricks geprägt wurde, wo man sagt, okay, man hat so unterschiedliche Zonen innerhalb des Data Lakes, Bronze, Silber, Gold typischerweise. In Bronze fließen zunächst die Rohdaten ein. In der Silberschicht macht man schon Vereinheitlichungen, zum Beispiel auf einheitliche Datumsformate, Währungsformate – sowas kriegt man da schon mal hin. Und man macht vielleicht auch schon eine Qualitätsbereinigung: Wenn für einige Quellen bestimmte Felder nicht befüllt sind, überlegt man sich, wie man das sinnvollerweise ergänzt. Man macht solche Dinge und hat dann so eine Silberschicht. Und dann für die Goldschicht wollte man die harte Arbeit der Integration richtig machen, also dass die Daten aus den verschiedenen Quellschichten auch inhaltlich zusammenpassen. Dass dann stimmige Reports rauskommen, dass ich nicht draufguckt mit Sachverstand und sage: „Hier, die Zahl, die da rauskommt, die kann ja gar nicht stimmen."

Sven Johann: Mhm. Ja, aber es ist immer noch sozusagen ein zentrales Team, das domänenspezifische Daten von X anderen Teams beackern muss, wo sie eigentlich kein Domänen-Know-how haben, ne? Das ist so.

Rainer Jaspert: Das ist ja die Frage, genau. Typischerweise, wenn man das macht, würde man sagen, man hat so ein zentrales Team, das sich darum kümmert. Aber ich glaube, da kommen wir dann mit den nächsten Lösungsansätzen auch hin, dass wir sagen, okay, wie kommen wir denn jetzt dahin, dass wir dieses Ownership-Thema besser in den Griff kriegen? Also, wer ist verantwortlich für diese Daten, wer darf das Schema ändern und wie gehen die, die von diesen Daten abhängig sind, mit diesen Schemaänderungen um?

Sven Johann: Genau, ja. Genau, da wären wir beim Data Mesh, oder?

Rainer Jaspert: Data Mesh ist so ein, muss man sagen, konzeptioneller Ansatz und Data Fabric vielleicht der technische Ansatz, wo man sagt, ich habe hier Produkte oder ich habe eine Produktgruppe, die mir so eine Datenfabrik zur Verfügung stellen. Data Mesh ist eher so das Denken, ich denke nicht mehr in monolithischen Anwendungen, sondern ich denke in Datenprodukten.

Sven Johann: Genau, also wir haben eine ganze Folge Data Mesh mit Stefan Tilkov und Jochen Christ, wir haben eine ganze Folge Data Products mit Stefan Negele und mir. Aber vielleicht trotzdem noch mal für die, die es so ein 5-Minuten-Abriss brauchen: Was ist überhaupt, was macht so ein Data Mesh aus? Auch in Abgrenzung zum Data Warehouse, Data Lake und Lakehouse.

Rainer Jaspert: Die große Erkenntnis ist dieses Team in der Mitte, das am Anfang eine tolle Lösung mit einem Data Warehouse oder Data Lake zur Verfügung stellt. Alle sind glücklich, die Daten werden von den Fachbereichen geliebt, dass sie endlich nicht mehr auf die Einzelanwendung zugreifen müssen und sich in Excel das dann mühsam zusammenbasteln müssen, was an Auswertungen gebraucht wird, sondern sie können an eine Stelle gehen, da kriegen sie alles qualitätsgesichert, täglich frisch. Das ist natürlich eine tolle Sache und irgendwann waren die in der Mitte, die das zur Verfügung gestellt haben, völlig überfordert. Der Ansatz von Data Mesh, der dann propagiert wurde, hat sich genau mit diesem Thema beschäftigt: Wie können wir denn jetzt mit unserem Wissen aus Domain Driven Design, was wir im operativen Umfeld gemacht haben, wo wir auch versucht haben, Anwendungen so zu zerlegen, dass sie gut miteinander interoperieren können und so etwas wie Microservices entstanden sind, sagen: Okay, dieses Team kümmert sich um diesen Microservice und ist dafür spezialisiert und kennt sich damit fachlich super aus und kann deswegen auch super Lösungen schaffen in diesem Microservice. Und genau dieser Gedanke ist jetzt zu übertragen und zu sagen, wie machen wir das mit Daten? Und da war die Idee, Daten als Produkt zu begreifen, und das ändert dann so ein bisschen die Art, wie wir auf diese Daten schauen, weil wir uns auf einmal nicht mehr so sehr darum kümmern, wie wir die Daten in unserem Unternehmen vereinen. Also, wie kriege ich jetzt die Bestellung mit den Page Views zusammen, damit ich das gegenüberstellen kann und sagen kann: Wenn meine Page Views hochgehen, welche Auswirkungen hat das dann auch auf meine Bestellungen? Für zwei völlig unterschiedliche Quellen, aber ich möchte vielleicht in der Auswertung Rückschlüsse haben oder Zusammenhänge erkennen, ob sich meine Ausgaben für die Webseite lohnen oder nicht.

Sven Johann: Ja, ja.

Rainer Jaspert: Genau, solche Dinge haben wir gemacht, indem wir die Dinge zusammengeschmissen haben, und dabei ist etwas nicht gut gelaufen, weil auf einmal Dinge zusammen waren und beherrscht werden mussten, die die Leute überfordert haben. In dem Moment, wo wir in Richtung Datenprodukten denken, überlegen wir uns, wie wir diese Daten jetzt strukturell teilen, aufteilen, sinnvoll aufteilen, so dass wir sie Teams zuordnen können und sagen: Okay, ihr kümmert euch jetzt nicht mehr um alles, sondern ihr kümmert euch nur noch um dieses Produkt. Und dieses Produkt liefert dann jetzt Daten, und zwar in einer bestimmten Qualität, und ich kenne auch meine Konsumenten, ich weiß, wer die sind. Ich kann sie auch verpflichten, ich kann ihnen sagen: Hey, mit meinen Daten machst du nur das und das. Ich kann sie darüber informieren, wenn sich irgendwas ändert. Ich bin derjenige, der, wenn sich etwas ändert, eine neue Version meines Datenprodukts zur Verfügung stellt. Ich kann bestimmte Zusicherungen machen über die Datenqualität, über die Aktualität. Und das sind alles Dinge, die wir im Data Warehouse konnten, aber eben auf diesem großen Maßstab, immer für alle. Alle waren da irgendwie über einen Kamm geschert.

Sven Johann: Ich muss sagen, das fand ich bei Stefan Negele ein Augenöffner für mich. Immer wenn ich mit Data Lake oder Lakehouse Teams zusammengearbeitet habe, ist es so, dass ich Daten zur Verfügung stelle und dann passiert irgendwas mit den Daten. Ich habe keine Ahnung, wofür die interessant sind, es ist raus aus meinem Blickfeld. Aber die Idee zu sagen, ich biete ein Data Product an, und ein Data Product hat immer Kunden, also ich muss wissen, wer sich überhaupt in der Firma für meine Daten interessiert und woher die Leute überhaupt wissen, dass es diese Daten gibt und was sie erwarten können, das ist ein ganz anderer Denkansatz. Das fand ich auf jeden Fall ziemlich erfreulich, also ist eigentlich ein erfreulicher Mindshift aus meiner Sicht.

Rainer Jaspert: Genau, aber das ist sehr, sehr schwierig, weil wir gerade lernen, wie man diese Zerlegung macht. Wie wir diese großen Daten dann jetzt sinnvollerweise in diese Produkte aufteilen. Bei Domain Driven Design haben wir, glaube ich, schon ganz gute Werkzeuge, um zu sagen, wie man operative Anwendungen sinnvollerweise zerlegt. Da sind wir schon weiter. Bei den Daten sind wir, glaube ich, noch am Herausfinden und Lernen, wie das am besten geht. Also für mich gilt das so, ich kann noch nicht sagen, dass ich da jetzt genau weiß, wie man, wenn ich eine neue Aufgabendomäne habe, die Daten zerlegen würde. Das ist noch sehr, sehr schwierig.

Sven Johann: Ja, also. Gestern hatten wir im Kölner Büro ein Meetup, und Stefan Negele war da. Er hat über Heuristiken für den Produktschnitt gesprochen, und ich meine, ich kümmere mich ja kaum darum, aber es war sehr lustig, weil ganz viele Leute im Publikum immer so ein bisschen gelacht haben, so ja, genau, das haben wir falsch gemacht und so weiter. Das war sehr amüsant, ja, war wirklich eine sehr, sehr amüsante Diskussion, ohne dass ich irgendwas davon verstanden habe, weil ich ja nichts mit Data Products mache, aber genau, das habe ich da auch gemerkt, dass das offensichtlich nicht das Einfachste der Welt ist.

Rainer Jaspert: Ich finde den Ansatz, den Stefan da verfolgt hat, er hat auch einen Artikel und einen Post dazu verfasst, genau richtig. Wir sammeln gerade Best Practices, wie man solche Datenprodukte sinnvollerweise schneidet.

Sven Johann: Ja, schreibe ich direkt mal auf, damit es in die Shownotes kommt. Gut, wir waren noch mal beim Data Mesh. Wir haben Datenprodukte, die von einzelnen Teams, die auf ihren operativen Daten sitzen, auch zu Analysezwecken Datenprodukte anbieten.

Rainer Jaspert: Vielleicht auch der Punkt: Sie schmeißen immer noch Daten über den Zaun für analytische Zwecke, aber mit viel mehr Kontrolle. Viel, viel mehr Kontrolle darüber, wo die Daten landen, was für Bedingungen für die Nutzung dieser Daten gelten, und auch mit der Möglichkeit, sie zurückzuziehen. Ein wichtiger Punkt. Ich möchte die Daten. Ja, stimmt, genau. Ich möchte dafür nicht mehr verantwortlich sein, auch diese Möglichkeit zu schaffen.

Sven Johann: Ja, stimmt, genau. Genau, wie du sagst, dass man die Hoheit über die Datenqualität hat. Also, wie gesagt, haben wir auch eine Folge Data Contracts mit Simon Harrer. Genau, also bis dahin war ich so einigermaßen im Bilde, was so die Landschaft angeht, aber so in unserem Vorgespräch, da kam dann plötzlich Data Fabric auf, da habe ich gesagt, noch nie davon gehört. Und DuckDB, das kennen, also wir gehen wir jetzt nicht wirklich drauf ein so tief, wir erwähnen es nur, aber so DuckDB und Duck Lake war mir, also DuckDB kenne ich, aber Duck Lake war mir dann auch unbekannt. Genau, was ist ja auch, also hätte ich jetzt behauptet, ist jetzt nicht mehr ganz, also ist schon ein bisschen neuer, ne? Was ist denn jetzt die Data Fabric?

Rainer Jaspert: Ja, also mit Data Mesh ist es weniger ein Produkt, sondern eher eine Art, über das Bereitstellen analytischer Daten nachzudenken. Also wie strukturiere ich meine Daten? Wie kläre ich das Problem der Ownership? Wer ist verantwortlich für die Daten? Das ist Data Mesh. Im Data Mesh gibt es einen Teil, für den wir vier Säulen haben. Ownership ist eine davon, eine weitere ist das Denken von Daten als Produkt, das ist die zweite. Ein dritter sehr wichtiger Punkt ist eine einheitliche Data Engineering Plattform. Da versuchen wir zu sagen, dass die Technik möglichst einheitlich sein muss, denn wenn ich meine Massendaten habe, meine Bestellungen, meine Page Hits, die vielleicht in Millionen oder sogar Milliarden gehen, und ich möchte sie miteinander kombinieren, kann ich nicht erst Millionen von allen Seiten lesen und dann feststellen, welche 50 davon ich in meinem Report haben möchte. Das geht nicht. Deswegen ist das auch ein bisschen der Unterschied zu Microservices, wo wir das können. Bei Microservices können wir sagen: Gib mir erstmal über die Schnittstelle das, was ich brauche, und dann kombiniere ich es. Beim Data Mesh muss ich irgendwo auf unterer Ebene die Möglichkeit haben, indem ich gemeinsame Technologie verwende, schon so etwas wie Joins hinzubekommen. Das ist, glaube ich, eine Herausforderung, wie man das macht. Deswegen haben wir im Data-Mesh-Ansatz den Gedanken einer gemeinsamen Datenplattform formuliert. Die Teams benutzen die Plattform gemeinsam. Jeder macht sein Ding, aber sie nutzen die Möglichkeiten, die diese Plattform bietet, zum Beispiel, indem ich eine Tabelle anlege, einen Service nutze, der mir so eine Tabelle anlegt, die ich dann in Snowflake verwenden kann. Snowflake ist eine Firma, die genau für so etwas Lösungen bietet, genau für diese Plattform. Databricks wäre eine andere. Aber im Grunde könnte jeder relationale Datenbankhersteller als Plattform dienen oder ein Dateisystem, das einfach nur Paketdateien mit einer SQL Engine hat. Es gibt viele verschiedene Möglichkeiten.

Sven Johann: Mhm.

Rainer Jaspert: Wir haben auch auf der Seite Data Mesh Architecture [?] verschiedene Beispiele dafür aufgeführt, wie man so eine Plattform gestalten kann. Das ist sehr breit gefächert. Data Fabric muss man davon abgrenzen. Alles, was sich als Data Fabric bezeichnet, wäre ein guter Kandidat, um diese einheitliche Datenplattform zu bauen.

Sven Johann: Okay, ja, ja.

Rainer Jaspert: Das Tech Team bietet die Technik für diesen Data-Mesh-Ansatz. Was man dabei vielleicht noch sehen muss, ist, dass wir mit Data Warehousing und Data Lake die Daten immer geholt und geschrieben haben. Erst auf den geschriebenen Daten haben wir sie genutzt. Data Fabric bietet jetzt die Möglichkeit, die Daten zu holen, zu verarbeiten und direkt zu nutzen, ohne sie zu schreiben. Dieses zusätzliche Schreiben, das Replizieren in einen Data Lake oder ein Data Warehouse, können wir mit Data Fabric vermeiden. Wir könnten die Daten mit Data Fabric in der Quelle verbleiben lassen und bieten nur einen geschickten Zugriff darauf. Das ist zumindest teilweise sinnvoll. Manche Dinge muss ich schreiben, da komme ich nicht drum herum, aber es gibt Anwendungsfälle, wo ich auf das Schreiben verzichten kann, und dann bietet Data Fabric die Möglichkeit, direkt darauf zu arbeiten.

Sven Johann: Ah, ja, ja, ja. Jetzt wird mir einiges klarer, denn als ich diesen Artikel gelesen habe oder allgemein alles, was auf Data Mesh Architecture steht, ist ja eine ziemlich gute Aufbereitung, also für diejenigen, die zu faul sind, das ganze Buch zu lesen. Ich kam mir auf der einen Seite sehr zu Hause vor bei Data Mesh, weil ich sage mal aus der normalen Softwareentwicklung haben wir auch eine Plattform. Da gibt es halt die Data Plattform, aber mir war jetzt nicht ganz klar, wie die Data Plattform aussieht im Vergleich zu einer normalen Software-Architektur-Plattform. Und dann gab es ja noch die Enabling Teams, und das sind alles Sachen, die waren mir sehr bekannt, aber ich konnte mir nie so vorstellen, wie so eine Data Plattform aussieht. Aber jetzt ist irgendwie klar, die Data Plattform ist eigentlich so wie Snowflake oder Google bietet Sachen, AWS Redshift oder so. Ah, und dann ist es so: Ich habe Produkt A, also ich bin Team A Order, und dann bin ich Team B Rückläufer oder so. Und die haben jeweils, die bieten ihr Produkt in einer eigenen, ich sage es einfach mal, in einer eigenen Tabelle an.

Rainer Jaspert: Datenprodukt, eine Tabelle, könnte man so machen, ja.

Sven Johann: Ja. Und jetzt bin ich Nutzer und ich kann dann einfach sagen, na ja, die haben zwei Tabellen, da mache ich einen Join. Wenn ich mich für die, okay, ja. Ah.

Rainer Jaspert: Das ist gut.

Sven Johann: Ja, am Ende wird alles gut. Okay. Hervorragend. Gibt es sonst noch etwas zu Data Fabric?

Rainer Jaspert: Ja, ich meine, dieses ganze Datenuniversum hat natürlich viele Aspekte, die wir gerne sehen. Dazu gehört zum Beispiel das Thema Data Lineage. Ich möchte wissen, wenn ich mein Datenprodukt habe, das mir Quelldaten aus dem Bestell- beziehungsweise Order Management liefert, und ich habe mein anderes Datenprodukt, das mir Daten aus den Page Hits liefert. Dann bringe ich die irgendwie zusammen und mache ein kombiniertes Datenprodukt. Dieses Datenprodukt nutzt die Daten aus dem Order Management und die aus den Page Hits, kombiniert sie sinnvollerweise und stellt sie dann zur Verfügung. Diese Daten brauche ich ja dann sozusagen vom Quellsystem durch das eine Datenprodukt, hier das andere Datenprodukt, bis zu mir und dann zu mir. Und jetzt möchte ich wissen, wie sich meine Daten zusammensetzen und wann sie überhaupt zur Verfügung gestellt wurden. Wenn es ein Batch Processing ist, welcher Batch hat welche Daten, die jetzt gerade bei mir angekommen sind, zur Verfügung gestellt? So etwas möchte man gerne nachvollziehen können, im Sinne von Vertrauen schaffen. Ich möchte Vertrauen in die Daten haben, die ich da sehe, und wenn ich ihnen misstraue, werde ich meine Lösung nicht benutzen, werde ich das Datenprodukt nicht benutzen. Data Lineage kann mir helfen, das Vertrauen in diese Daten aufzubauen, wenn ich dem Anwender zeige: Hey, das Datum, das du da gerade anzweifelst, dieser Wert, der da steht, der setzt sich so zusammen, der kommt daher, und der Ursprungswert kommt daher. Dann ist auf einmal das Vertrauen da, weil es nachvollziehbar wird. Das ist ein wichtiger Punkt, und solche Dinge gibt es mehrere, die von so einer Plattform zur Verfügung gestellt werden können, damit es leicht ist, solche Lösungen umzusetzen.

Sven Johann: Mhm. Mhm. Ja. Okay, ja. Ah, also ich muss mich dann nicht mit Open Lineage oder so beschäftigen, nicht, dass ich Ahnung hätte.

Rainer Jaspert: Genau, das wäre dann der Idealfall, wenn ich dann irgendein Tooling verwende, das die Schnittstelle zu meinem Data Lineage System teilautomatisiert oder sogar komplett automatisiert.

Sven Johann: Alright. Ja, wunderbar. Ich gucke gerade auf die Uhr. Wir schaffen es unter einer Stunde oder fast. Ich hätte noch so einen ganz kleinen Abstecher, und zwar in Memory Analytics. Hannes Mühleisen, das ist ein Deutscher, der ist Professor in den Niederlanden und der hat DuckDB gegründet. Er macht großartige Vorträge, die man sich auf jeden Fall ansehen muss. Ich schaue mir jeden Vortrag von ihm an. Es geht nicht nur um DuckDB, sondern ganz allgemein um All Things Data. Er ist ja Professor und hat wirklich sehr lustige Vorträge. Was ist eigentlich In Memory Analytics? Was ist der Unterschied zu dem, was wir bisher diskutiert haben?

Rainer Jaspert: Ja, als wir mit Data Warehousing angefangen haben, war es undenkbar, dass man die Daten, um die wir uns kümmern, im Speicher bearbeiten kann. Vieles von dem, was wir damals gemacht haben, setzte zwingend voraus, dass wir die Daten auf externem Speicher haben.

Sven Johann: Mhm.

Rainer Jaspert: Ja, und im Hauptspeicher wurde dann geschickt gecacht. Ein wichtiger Punkt ist zum Beispiel, wenn wir eine Dimensionstabelle haben mit allen Tagen, Orten oder Artikeln, die wir natürlich gerne im Cache gehalten haben, weil darauf permanent zugegriffen wurde. Wenn die im Datenbank-Cache waren, war das natürlich super. Man musste sie nur einmal lesen und dann waren sie für immer da.

Sven Johann: Mhm.

Rainer Jaspert: Und was halt nicht im Cache war und immer komplett neu gelesen wurde, waren die Transaktionen. Die musste man sich immer wieder komplett neu lesen, da sprengt das den Cache. Genau, und so ganz vertraut bin ich mit dem Thema nicht, aber im Grunde ist das Versprechen, das ich da herauslese, dass man mit Technologie wie DuckDB dieses Hindernis eliminieren kann, dass man also nicht nur die kleineren Dimensionstabellen, Dimensionsdaten im Cache halten kann, sondern dass man alles, was ich für meine Analyse brauche, im Hauptspeicher halten kann. Den Zugriff auf meine Daten im externen Speicher kann ich mir sparen. Das ist natürlich eine irre Beschleunigung und Vereinfachung. Es bietet dann natürlich etwas mehr Möglichkeiten, wenn man da direkt Dinge adressieren kann. Ich glaube, das Wesentliche ist, dass ein paar Optimierungen, die wir immer gemacht haben, auf einmal wegfallen. Wir haben immer optimiert, um den Sachverhalt zu umgehen, dass wir auf die Faktentabelle immer nur mit einem Full Table Scan zugreifen können. Das war der Bottleneck, wenn ich eine Query habe und dann habe ich meine ganzen Dimensionsdaten im Hauptspeicher, aber ich muss einmal durch die komplette Faktentabelle oder zumindest Teile der Faktentabelle durch und muss nur den heutigen Tag lesen, vielleicht nicht den Tag von gestern, aber die Fakten von heute muss ich lesen. Wenn meine Tabelle gut partitioniert war, dann war mir das möglich, also der Schlüssel für den Tag ziemlich weit oben. Dann habe ich die Möglichkeit, alle Daten, die zu einem Tag kommen, in einem Rutsch zu lesen. Und wir haben um diese Dinge herum optimiert. Ja, und das fällt dann weg, diese Anforderung, jetzt darum zu optimieren, fällt weg, wenn wir einfach sagen können: Ist ja alles im Hauptspeicher, greif doch zu, wenn du willst.

Sven Johann: Genau, ich hatte auch einmal einen Vortrag von jemandem von DuckDB gesehen. Die waren ziemlich auf dem Trip der Mechanical Sympathy, also im Sinne von, die wissen wirklich, was unter der Haube abgeht, wie Prozessoren funktionieren. Die wissen ganz genau, was wann in welchem Prozessor-Cache liegt und wie man es optimiert. Deswegen sind die ultraschnell. Genau, wer sich dafür interessiert, ich packe auf jeden Fall noch mal einen Talk rein, wie das unter der Haube läuft. Es ist wirklich faszinierend, finde ich. Ich kann jetzt zur Nützlichkeit nichts sagen, aber technisch faszinierend. Alright. Dann würde ich sagen, haben wir einen schönen Überblick über alles bekommen, was es so gibt.

Rainer Jaspert: Ja, alles, was ich so im Blick habe, wahrscheinlich.

Sven Johann: Ja, ja, ja.

Rainer Jaspert: Ja, alles ist zu viel, aber wir haben einen schönen Überblick über die typischen Entwicklungen bekommen, genau.

Sven Johann: Ja, vielen Dank, Rainer. Ich hoffe auf weitere Besuche hier beim INNOQ Podcast und danke auch an alle Zuhörer und bis dann.

Rainer Jaspert: Vielen Dank, mach’s gut, ciao.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Wie speichern, strukturieren und nutzen Unternehmen ihre Daten und welche Architektur passt wann?

Operative vs. analytische Daten: eine unterschätzte Trennlinie

Rainer erläutert, warum die Unterscheidung zwischen operativen und analytischen Daten nach wie vor grundlegend ist. Operative Systeme haben die volle Kontrolle über ihre Daten – sie können Strukturen ändern, ohne dass andere davon betroffen werden. Sobald Daten aber für analytische Zwecke nach außen gegeben werden, entstehen Abhängigkeiten: Andere Systeme und Teams bauen darauf auf, interpretieren sie – oft falsch – und müssen bei Änderungen reagieren. Besonders schwierig wird es, wenn viele operative Quellen in einem zentralen System zusammengeführt werden sollen, weil dann niemand in der Mitte die Daten wirklich kennt.

„Sobald ich die Daten aus meiner Kontrolle nach draußen gebe und keinen direkten Einfluss mehr darauf habe, was damit gemacht wird, fangen Probleme an, die man im operativen Umfeld nicht hat."

Data Warehouse: Stärken, Grenzen und Slowly Changing Dimensions

Das Data Warehouse war der erste strukturierte Ansatz zur Integration analytischer Daten aus mehreren Quellen. Über ETL-Strecken werden Daten extrahiert, transformiert und in ein einheitliches Schema überführt. Rainer erklärt, dass ein zentrales Merkmal die Historisierung ist: Anders als operative Systeme, die nur den aktuellen Zustand kennen, sollen Data Warehouses Veränderungen über die Zeit abbilden – das Konzept der Slowly Changing Dimensions. Das klassische Data Warehouse lohnt sich noch immer, wenn das Schema stabil ist und die analytischen Anforderungen klar sind. Es gerät an seine Grenzen, wenn sich Schemata häufig ändern oder Rohdaten für KI-Modelltraining benötigt werden.

„Es ist immer noch sinnvoll, wenn man Schema First hinbekommt und alle analytischen Anwendungen damit klarkommen."

Data Lake: maximale Flexibilität, neue Komplexität

Der Data Lake entstand aus dem Wunsch, Daten ohne vorherige Transformation bereitzustellen – Schema wird nicht beim Schreiben, sondern erst beim Lesen definiert. Hinzu kam die Idee, statt transaktionaler Datenbanken einfache Dateisysteme wie Hadoop zu nutzen, die besser zur Batchverarbeitung passen. Mit Query Engines wie Spark und dem MapReduce-Ansatz kam eine neue Art der Parallelisierung. Der Nachteil: Die Arbeit der Vereinheitlichung, die zuvor ETL-Entwickler übernommen haben, liegt nun bei jedem einzelnen Reportersteller.

„Die Idee, dass man die Daten einfach so wie sie sind über den Zaun wirft, sie zur Verfügung stellt und direkt den ersten Report darauf machen kann, ist total überzeugend."

Lakehouse und Medallion Architecture: das Beste aus beiden Welten

Das Lakehouse versucht, die Stärken von Data Warehouse und Data Lake zu verbinden. Die ETL-Verarbeitung findet nicht mehr vor dem System statt, sondern innerhalb – schrittweise, in mehreren Zonen. Die von Databricks geprägte Medallion Architecture unterteilt diese in Bronze (Rohdaten), Silber (vereinheitlichte Formate, Qualitätsbereinigung) und Gold (inhaltlich konsistente, auswertbare Daten). Nutzer können je nach Bedarf auf jede Schicht zugreifen – direkt auf die Rohdaten oder auf die aufbereitete Goldschicht.

„Ich kann direkt auf die Rohdaten zugreifen, wenn ich es schnell brauche oder warten, bis die schrittweise Transformation abgeschlossen ist, und dann auf die bereinigten, vereinheitlichten Daten zugreifen."

Data Mesh: Daten als Produkt mit klarem Ownership

Data Mesh überträgt die Prinzipien von Domain Driven Design und Microservices auf die Datenwelt. Statt eines zentralen Teams, das alle Daten verwaltet, übernehmen die Fachbereiche selbst Verantwortung für ihre Daten – als Produkt mit definierten Konsumenten, Qualitätszusicherungen und klaren Nutzungsbedingungen. Rainer betont, dass der Produktschnitt dabei eine der schwierigsten Aufgaben ist: Wie Daten sinnvoll in Produkte aufgeteilt werden, ist noch Gegenstand aktiver Forschung und Praxis. Eine gemeinsame technische Plattform – etwa Snowflake oder Databricks – ist dabei unverzichtbar, um teamübergreifende Joins überhaupt zu ermöglichen.

„Ein Data Product hat immer Kunden. Ich muss wissen, wer sich in der Firma für meine Daten interessiert, woher die Leute wissen, dass es diese Daten gibt und was sie erwarten können. Das ist ein ganz anderer Denkansatz."

Data Fabric und In-Memory Analytics mit DuckDB

Data Fabric bezeichnet Technologien, die als technische Grundlage für einen Data-Mesh-Ansatz dienen können. Ihr besonderes Merkmal: Daten müssen nicht zwingend repliziert werden, sondern können direkt in der Quelle verbleiben und über intelligente Zugriffsmechanismen genutzt werden. Mit DuckDB und dem Ansatz der In-Memory Analytics entfällt zudem ein klassischer Flaschenhals: Statt Optimierungen rund um den begrenzten Hauptspeicher werden alle für eine Analyse relevanten Daten direkt im Arbeitsspeicher gehalten – mit enormen Geschwindigkeitsgewinnen und deutlich weniger Komplexität bei der Abfrageoptimierung.

„Den Zugriff auf meine Daten im externen Speicher kann ich mir sparen. Das ist eine irre Beschleunigung und Vereinfachung."