# Modern Data Architecture: From Warehouses to Mesh

**Podcast:** INNOQ Podcast
**Published:** 2026-06-29

## Transcript

Hallo und herzlich willkommen zu einer neuen Folge vom InnoCube Podcast.
Heute mit Rainer und wir quatschen, wir haben irgendwie fast zu viel vor.
Wir wollen in eine Stunde wollen wir irgendwie reinpacken, weil es ein Data Warehouse, Data Lake, Lakehouse, Data Mesh ist nur...
kurz, da haben wir eine Folge in Memory Analytics, wie DuckDB und DuckLake, 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.
Hallo Sven, vielen Dank für die Einladung hier zu den Top-Gasten.
Genau.
Im ersten Mal.
Ich hoffe, wir kommen da unbeschadet durch.
Wir kommen durch, wir kommen durch.
Du bist mein Go-To-Guy Data Architecture bei InnoQ.
Willst du noch mal so ein, zwei Minuten was über dich sagen, was du so treibst?
Ja, sehr gerne.
Also seit ungefähr 30 Jahren im Geschäft hier als Consultant und ich habe halt sehr intensiv meine ersten Zeit mit Data Warehousing mich beschäftigt.
Damals sind die Unternehmen, gerade die Kreditkartenunternehmen, die haben damals angefangen, Data Warehousing für sich zu entdecken.
Und unter etwas fragwürdigen Bedingungen damals wurden die Daten der Kreditkarten verwendet.
Auch für andere Dinge, ich glaube, da sind wir heute viel weiter und viel besser.
Aber damals wurde natürlich viel aufgebaut, viel gelernt darüber, wie man Daten...
Für analytische Zwecke, das ist ja glaube ich der wichtige Punkt, also nicht für das Operative von der Kreditkartenprocessing, das war klar, aber für die analytischen Zwecke, wie man das da benutzt.
Gerade so Sachen wie Fraud Detection ist natürlich immer noch hochaktuell.
Diese analytischen Zwecke, da wurde es damals mit beschäftigt, nicht nur Kreditkarten, auch hier natürlich Großhandel, die haben das gleiche Thema gehabt.
Im Umfeld der HP Non-Stop-Maschinen, früher hießen die Tandem, ist dann irgendwann von HP übernommen worden.
Und die waren etwas geeignet sozusagen für diese Verarbeitung von Massendaten.
Ich war spezialisiert auf diese Technik, auf diese HP Non-Stop-Maschinen.
Und deswegen sind wir da in diese Fachlichkeit rein gerutscht.
Das so zu meinem Hintergrund.
Dann bin ich vor 20 Jahren zur Innobe gekommen.
Und das Thema...
Datenanalyse, sich mit Daten beschäftigen, ist da etwas im Hintergrund gerutscht.
Wir haben damals, generell kümmern wir uns eher um die operative Seite, haben wir damals gemacht und haben dann versucht, verteilte Systeme, unternehmenskritische verteilte Systeme, die Kunden dabei zu unterstützen, die zu bauen.
Das ist ja, glaube ich, immer noch unser Hauptthema, wie macht man sowas.
Und 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 das immer so monolithisch ist.
Immer ein großer Block von Daten in die Mitte gestellt und alle bedienen sich daraus.
Wir haben immer gedacht, Teilsysteme gehen anders.
Und deswegen war das immer sehr skeptisch.
Wir haben das zum Teil gemacht.
Ich habe da auch Projekte gemacht in der Zeit bei InnoQ, 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 jetzt, dass wir sagen, ja, wir können da auch bei Daten richtige verteilte Systeme machen.
Und da freue ich mich natürlich total drüber.
Jetzt wird das Thema wieder für InnoQ interessant.
Und natürlich auch mit der Data Mesh-Initiative und Entropy Data.
Ich glaube, wie wir darauf eingehen können, haben wir natürlich da auch jetzt schon einiges geleistet.
Genau, Entropy Data, wie gesagt, Data Contracts mit Simon Harrer, Gründer, 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 nochmal dazu, was sind eigentlich die Unterschiede und was sind die jeweiligen Herausforderungen davon?
Ja, also diese Unterscheidung ist natürlich ein bisschen historisch, da wurde noch sehr viel Wert drauf gelegt.
Man kann natürlich aus heutiger Sicht sagen, das wächst natürlich alles irgendwie zusammen.
Es sind nur noch Daten, aber ich glaube, es macht schon Sinn, gerade wenn man sich die Lösung, die es gibt, anschaut.
Und 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.
Operative Daten, damit kennen wir uns halt gut aus.
Wir wollen eine...
Bestellung durchführen und wir müssen uns merken, oder wir müssen irgendwie erfassen, was für die Bestellung alles dazugehört.
Und diese Daten, die bekommen wir über eine UI vielleicht oder über eine Schriftstelle und dann verarbeiten wir die, legen die ab in eine Datenbank und benutzen die, verteilen sie vielleicht nur über Schriftstellen.
Aber diese Daten sind sozusagen nur existent in unserem operativen Kontext.
Wie wir die ablegen, welches Format wir denen geben, das ist völlig unter unserer Kontrolle.
Also idealerweise können wir das vollständig kontrollieren.
Wir sind über Schlittstellen, geben wir dann 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.
Und auch andere Daten, die dabei entstehen, vielleicht, zum Beispiel Log.
Die Kontrolle darüber, was wir da in den Log reinschreiben und was nicht.
Audits und wie jemand auf unsere Anwendung zugreift und wir merken uns das.
Alles war gut in der Kontrolle.
Und wir können dann auch hingehen und Dinge einfach ändern.
Wenn wir sagen, unsere Anforderungen haben sich ein bisschen geändert, vielleicht Security oder...
Performance kommen wir nicht mehr mit klar.
Wir müssen die Art, wie wir unsere Daten ablegen, wie wir sie organisieren, zu ändern.
Tun wir das einfach.
Bei unseren Schnittstellen bleiben wir genauso ansprechbar und interoperabel mit der restlichen Welt wie vorher auch.
Das ist so der Idealzustand der operativen Welt.
Tatsächlich ist es ja dann auch wieder etwas anders.
Und wir machen zum Beispiel eine Integration über Datenbanken.
Das sieht man immer gerne.
Ich sage es jetzt.
Sagt es Ihnen.
sofort klar sein, wenn wir die Daten über den Zaun werfen und dann macht jemand anders analytische Dinge mit diesen Daten, die aber von mir aus meiner operativen Anwendung kommen.
Und auf einmal hat halt jemand anders, hängt davon ab, was ich da zur Verfügung stelle und muss darauf reagieren, wenn ich vielleicht irgendwas dran ändere.
Wenn ich sage, hier, ich komme 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.
So sofort sind andere von mir abhängig.
Der leichte Teil sozusagen, der schwere Teil ist, ich muss erklären.
Die Daten, die ich da über den Zaun schmeiße, die sind häufig erklärungsbedürftig.
Und in dem Moment, wo ich sie ü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 sich Daten sammelt und versucht, die zusammenzubringen.
Also da so eine einheitliche Sicht.
um ein unternehmensweit einheitliche Sicht auf die Daten zu erzeugen.
Weil dann sitzt da in der Mitte auf diesem Topf mit einheitlichen Daten sitzt jemand, der eigentlich die Daten nicht, dem wir nicht gehören, der die eigentlich nur unmittelbar kennt, sondern nur über mich.
Er kennt da meine Daten.
Ich habe sie ihm erklärt mal.
Und jetzt muss er damit klarkommen.
interpretieren oder muss wissen, wie können jetzt die Daten aus dem einen Topf mit den Daten aus dem anderen Topf kombiniert werden, eine einheitlich stimmige Sicht wiederum zu erzeugen.
Und das ist halt im Detail eine superschwierige Aufgabe, die dann, wenn ich dann sage, okay, ich habe fünf Quellen, kriegen wir es vielleicht noch hin.
Und alle sind begeistert und es funktioniert hervorragend.
Und dann kommt die zehnte Quelle dazu und diejenigen in der Mitte oder diejenigen in der Mitte sind völlig überfordert.
Das ist das, was wir häufig erlebt haben in solchen Projekten, wo dieser monolithische Ansatz, wir packen alles in die Mitte, wo das dann irgendwann scheitert.
Und natürlich die Datenwirtschaft zu strecken.
Also wie kommen die Daten vom operativen System in mein großes Paket?
Das ist dann natürlich auch fragil.
Das muss dann gegebenenfalls mal geändert werden, wenn da neue Felder hinzukommen.
Und dann brechen die zum Teil und dann brauchen wir Strategien, wie man dann umgeht.
Aber wie gesagt, das ist der große Unterschied, sobald ich die Daten aus meiner Kontrolle, nach draußen gebe und dann, wenn ich nicht mehr direkten Einfluss drauf habe, was damit gemacht wird, dann fangen halt Probleme an, die man im operativen Umfeld halt nicht hat.
Okay, 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 es ja schon seit Jahrhunderten wahrscheinlich.
Also ich übertreibe ein bisschen.
Aber was ist eigentlich so ein Data Warehouse?
Das war ja wirklich so das erste, also die erste analytische Datenbank, sage ich jetzt einfach mal.
Die auch ganz anders funktioniert als so eine relationale Datenbank.
Ja, die Technik wurde häufig die gleiche Technik verwendet.
Es gab auch andere Ansätze, aber die Technik war häufig dieselbe.
Aber die Fachlichkeit da drauf war etwas andere.
Vielleicht noch vorher waren es auch andere Sätze, aber häufig hat man dann in die Anwendung selbst zum Beispiel Report-Generatoren eingebaut.
Das sind immer die analytischen Teile der Anwendung.
direkt in die operative Anwendung mit eingebaut hat.
Das ist natürlich der naheliegende Ansatz.
Der scheitert natürlich dann, wenn ich mehrere operative Anwendungen integrieren möchte.
Oder wenn ich eine Auswertung habe, die über mehrere operative Anwendungen weggeht, muss ich mich überlegen, in welche der operativen Anwendungen repliziere ich denn nun die Daten.
Irgendwann geht das halt nicht mehr.
Also der erste Ansatz, Ich bilde mir ein, das ich ja ziemlich oft gemacht habe, aber ich weiß es nicht.
Ich habe meine normale Datenbank, da habe ich meine operationalen Daten und ich habe so ein paar Tabellen, wo ich historische Daten sammle.
Also alle Orders, okay, die hat man vielleicht sowieso.
Aber es gibt Dinge, ich kenne das noch so, ich mache keine Änderungen.
Sondern ich lege eben so eine Art Event-Sourcing, könnte man schon fast so sagen.
Also obwohl das damals jetzt nicht so war.
Also ich habe so ein paar Daten, wo ich einfach Analytics drauf mache, wo ich die Historie noch habe.
Gibt es auch heute noch, das ist auch häufig total sinnvoll, wenn ich mir überlege, ich habe eine Anwendung, irgendwie der Cloud deployed und ich möchte die Web-Analytics drauf haben.
kann man argumentieren, okay, wie viele Page-Hits sind, kann man irgendwie sich rausziehen, aber man kann auch direkt, man könnte solche Dinge auch direkt in Anwendung machen.
Dass man da zählt, wie oft ist auch mal in Anwendung.
Man macht es anders, typischerweise, aber warum nicht?
Ja, genau, also ich denke, ist halt einfach.
Also da muss man kein...
Teradata oder so sich zulegen und ein, also nicht, dass ich Ahnung hätte, aber und dann irgendwie ein Snow Snowflake Snowflake Schema haben oder so, genau.
Wie gesagt, es gibt immer gute Gründe.
Wir haben es auch letztes Mal bei einer internen Induktionanwendung diskutiert, inwieweit es Sinn macht hier Dinge.
zentral zu machen, also im Sinne vereinheitlichte Plattformen zu überführen oder halt die Anwendung macht das Reporting selbst.
Interne Anwendung, da wollten die Geschäftsführer, wollten ein paar Analysen dazu haben, ein paar Webports daraus ziehen.
Kann man natürlich direkt reinbauen.
Für mich ist immer der Punkt, wo man Richtung der Warehouse denken sollte, wenn ich versuche, Daten aus mehreren Quellen zu integrieren.
Also zwei geht vielleicht noch, aber Mehr als zwei würde ich sagen.
Jetzt sind wir an dem Punkt, wo ich, wenn ich eine Auswertung brauche, die aus mehr als zwei Quellen sich bedient, dann würde ich sagen, lasst uns über sowas wie ein Deta-Warehaus nachdenken.
Und ein Deta-Warehaus war also der erste Ansatz.
Damals gab es irgendwie zwei Leute, die haben sich darum gekümmert.
Die waren da so ein bisschen im Wettstreit, ein Bill Inman und ein Ralf Kimber.
Die haben dann so gewetteifert, darum wäre dann nur die richtige.
das richtige Data Warehouse-Konzept anbietet.
Die haben sich schon grundlegend unterschieden, aber aus der heutigen Perspektive vielleicht nicht so sehr.
Sie rufen hierbei halt die Daten über so ein sogenanntes ETL-Prozesse, Extract, Transform, Load, aus den operativen Systemen abzugreifen und mit dem Load-Shirt in das Data Warehouse einzutragen.
Und dort dann sozusagen eine vereinheitlichte Sicht auf die Daten mehrerer Quelle herzustellen.
Und ein grundlegendes bei beiden gleiches Merkmal ist, wir haben eine vordefinierte Zielstruktur.
Das Data Warehouse gibt uns, wir sagen auch Schema first, wir denken uns erst das Schema aus, wir kommen mal sozusagen von unseren Auswertungs...
Anforderungen, denken wir unser Schema aus, was gut geeignet ist, um unsere Auswertung zu machen.
Dann legen wir dieses Schema fest und dann bringen wir aus den ganzen Quellen die Daten in dieses Schema rein.
Natürlich erweitern wir das dann auch.
Also wenn wir sagen, jetzt hier kommt eine neue Quelle dazu, erweitern wir das Schema und erweitern dann die entsprechenden LGL-Strecken, also eine typische Batch-Verarbeitung, um auch die zusätzliche Quelle mit rein zu bekommen.
T steht für Transformation.
Wir gehen immer davon aus, dass wir, wenn wir Dinge vereinheitlichen, müssen wir transformieren.
Das fängt bei so Sachen wie Datumsformaten an, dass die natürlich vereinheitlicht werden müssen.
Regionale Besonderheiten.
Ich habe irgendwie meine Großmärkte in Italien und die in Deutschland.
Die haben ihre Warengruppen etwas anders.
Das machen wir nicht.
Wir müssen da irgendwie die Daten transformieren, dass man dann auch irgendwie so eine vereinheitlichte Sicht auf die Daten hinbekommt.
Im Detail kann das recht schnischig werden.
Was wir auch haben, ganz wichtig dabei, ist die Historisierung.
Also operative Anwendungen typischerweise brauchen keine historische Sicht.
Es gibt nur den aktuellen Zustand.
In der Taversen-Feld wollen wir typischerweise die Veränderung auf Daten sehen und mitbekommen.
Wenn du umziehst, dann möchte deine Kreditkartenfirma wissen, wo du mal gewohnt hast.
Um dann zu sagen, okay, diese Transaktion, die hat er erst mal noch in Düsseldorf gemacht.
Und da er in Düsseldorf gewohnt hat und diese Transaktion gestern hat er in Köln gemacht.
Er wohnt auf den Köln gemacht.
Also diesen historischen Blick, den wollen wir mit Data Warehouse gerne haben.
Da gibt es auch eine ganze Theorie dazu, wie man so historische Daten sinnvollerweise in so einem Schema ablegt.
Okay, wie heißt die Theorie?
Wir nennen das Slowly Changing Dimensions.
Vielleicht noch ein bisschen ausholen.
Im Data Warehouse Umfeld, das was du vorher mit Snowflake gesagt hast, Star-Schema, Snowflake-Schema, unterscheiden wir gerne zwischen Dimensionen und Fakten.
Ganz einfach gesprochen.
sind das die Fakten, das, was ich in der Zelle vom Excel packe und die Dimension ist das, was ich in die Zeilen geschleift habe.
Die Dimensionswerte landen dann sozusagen in den Spaltenköpfen oder in den Zeilen in der ersten Zeitende.
Das sind mehr so meine Dimensionswerte und meine Fakten.
Das sind sowas wie Transaktionsdaten.
Wie viel wurde denn nun übertragen von einem Grund aufs andere?
Dieser Wert, der würde dann in der Zelle stehen, das wäre der Fakt.
Lagerbestand, aber auch ein Fakt.
Ich habe noch so dunkel in Erinnerung irgendwas mit Cube.
Genau.
Wir haben das dann als Cubes bezeichnet, weil die Dinge mehrdimensional sind.
Und wenn ich natürlich jetzt auch noch drei Dimensionen habe, dann hätte ich so einen Würfel.
Diese Analogie, die wurde dann heute gerne verwendet, um die Daten abzulegen.
Es gibt auch Datenbalken, die multidimensional waren, die genau das abgebildet haben.
Multidimensionale Datenbalken, die heute noch genutzt werden, um solche dimensionalen Daten abzulegen.
Aber wie gesagt, Excel ist eine gute Möglichkeit, das vorzustellen.
Und Slowly Changing Dimensions ist halt jetzt der Ansatz.
Was sich ändert, sind ja nicht die Fakten.
Die habe ich unter einem bestimmten Kontext erfasst.
Also meine Transaktion wurde gemacht, eben als du in Köln warst oder Düsseldorf.
Das ist sozusagen der Kontext.
Der Kontext ergibt sich aus der Dimension, also Dimension Ort oder Wohnort, das ist die Dimension.
Und die Änderung des Wohnortes muss ich jetzt in der Dimension darstellen.
Das heißt, ich muss einen Eintrag Wohnort in der Dimension haben, für dich.
die auf Köln verweist und ein L auf das Überrasch.
Und dann ändern sich diese halt, diese Dimensionen.
Man geht davon aus, dass sie sich langsam ändert.
Deswegen slowly changing dimensions.
Wenn die sich schnell ändern würden, dann würde man vielleicht noch anders.
Würde man das nicht so modellieren.
Und das wirkt bei Dimensionen davon aus, dass sie sich langsam ändern und damit kriegt man das sozusagen eingefangen, diese Art der Historisierung.
Gut.
Ja, Data Warehouse.
wie habe ich ja schon gesagt, war so eine Weile, war das das Ding, aber...
Ist immer noch das Ding?
Immer noch sinnvoll, wenn man davon ausgeht, dass man dieses Schema first hinkriegt.
Also wenn man das Schema first nur sagen kann, ich habe hier genau das Schema, ich kenne das Schema, meine Anwendungen, meine analytischen Anwendungen sind sehr ähnlich, die kommen alle mit diesem Schema klar.
Dann ist das immer noch sehr gut.
Und wenn ich halt nicht so viele Änderungen im Schema habe, täglich eine Änderung in meinem Schema habe und zusätzlich auch noch häufig neue Anforderungen, Auswerteanforderungen zukommen, wo mein altes Schema vielleicht nicht mehr so gut passt, dann ist Data Warehouse halt fragwürdig.
Und das wurde genau erkannt, dass man halt etwas zu, dieses Data Warehouse etwas zu unflexibel war für viele Anforderungen.
Häufig wollte man direkt zum Beispiel KI-Modelle trainieren.
Möchte man dieses Schema first eigentlich gar nicht haben, weil eine Transformation passiert.
Wenn ich die Daten nicht habe, für Modelltraining möchte ich vielleicht die Rohdaten haben, so wie sie von meinem operativen System kommen.
Ich möchte die Transformation vielleicht gar nicht.
Und dann wären auch einmal solche Ansätze fragwürdig.
Oder eben, wenn sehr, sehr viele Änderungen ins Schema kommen, dann sind die in der Mitte halt überfordert, die EDL-Strecken umlaufen zu halten und dann geht das nicht mehr.
Ja, ich kann mich noch erinnern, früher, wir waren noch jung, das war glaube ich so 2012, da war ich sogar mal Host vom Big Data Track bei der QCon London.
Auf jeden Fall, da kann ich mich noch so an einen Kunden von mir erinnern, der da war.
Der hat halt gemeint, ja hier, ich will...
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 ich drehe den Geldhahn auf und so weiter.
Also was ist ein Data Lake und wie unterscheidet der sich von so einem Data Warehouse?
Und warum gab es den überhaupt?
Der kam ja irgendwo her.
Und da hatten wir halt klassisch eben Data Warehouse vorgeschlagen.
Und dann haben wir so eine Eberle-Übung für einen Anbieter gemacht und auf einmal kam einer um die Ecke und der hat gesagt, hey, dieses Ganze in Data Warehouse schreib ist doch blöd.
Wir packen die ganzen Daten, die jetzt auf die Quellsysteme kommen, in XML-Dateien, stellen wir die zur Verfügung und unsere Reports machen wir direkt auf diesen XML-Dateien.
Vielleicht ist das doch eine Tagen-Schweiz-Idee.
Aber diese Idee hatte für den Kunden noch ein paar Vorteile, weil die hatten auf einmal diesen ganzen Schmerz, den das Aufbauen eines Detail-Werhows mit der ETL-Bewirtschaftung hat.
Und das war ein großer Kunde, ein großes Projekt, weltweit irgendwie Daten sammeln.
Und für die war das natürlich ein super Versprechen.
Ihr kriegt hier so ein XML-Wand zusammengeworfen und ihr könnt direkt am ersten Tag auf Basis dieses XML kriegt ihr den Report.
Und dann haben die den gesehen und gesagt, wow.
Kein halbjähriges Projekt, keine Millionen versenken, bevor wir den ersten Report bekommen.
Direkt der erste Report.
Nach einem Tag irgendwie ein Cache, muss man dann irgendwie sagen, ja, spricht was dafür.
Und genau aus diesem Gedanken, also in dem XNL würden wir vielleicht nicht mehr machen heutzutage, nur was anderes, Paket oder so, aber die Idee, dass man einfach die Daten so wie sie sind, über den Zaun wirft, sich so da rein erstmal zur Verfügung stellt und direkt den ersten Report auf diesen Daten machen kann, die ist halt total überzeugend.
Hinzu kamen dann nochmal so ein bisschen technische Dinge.
Wir waren vorher immer häufig mit Datenbanken unterwegs.
Wir haben die Daten halt in Datenbanken gehabt, 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 gar nicht, dass das Thema, dass wir viele Updates haben und konkurrierende Reads auf sich stellen, dann finde ich ändernde Daten, das haben wir doch gar nicht.
In so einem Data Warehouse schreiben wir einmal rein und dann lesen wir häufig.
Das haben wir ehrlich.
Wenn wir was ändern, dann machen wir eine neue einfach.
Das wäre ein Insert mit einer neuen historischen Version.
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 verweisen, sondern in Datalsystemen.
Hablup war damals so ein Datalsystem, mit dem so etwas ging.
Hablup war dann deutlich weiter.
Inzwischen diese Dateisysteme, die es ergibt, stellen halt super die Möglichkeit zur Verfügung, auch über SQL-Schnittstellen, also SQL-Mittel darauf zuzugreifen.
Wir verlieren also grundsätzlich von unseren Datenprozessierungstähigkeiten nichts.
Wir haben die Daten aber in Dateien und das passt auch deutlich besser zu dieser Batch-Verarbeitung.
Der Batch verarbeitet irgendwie eine ganze Reihe von Daten, liest sie aus den 100 Dateien, schreibt sie in 50 Anwar.
Batch-Verarbeitung, keine Einzeldatensatzverarbeitung mit den Datenbanken, wie wir es sonst immer gemacht haben.
Dass man das eben auf Dateiebene im Batch macht, ist auch total überzeugend.
Diese beiden Dinge kamen dann im Grunde zusammen.
Plus noch so Sachen wie dann Query-Engines wie Spark.
Genau.
Mit MapReduce-Methoden im Gegensatz zu den...
zu den üblichen Methoden des Datenzugriffs, die wir sonst hatten zur Parallelisierung.
Wir haben eine Partitionierung, wir haben eine Tabelle partitioniert.
Das war auch wieder sehr statisch.
Wir mussten uns auf eine Partitionierung typischerweise festlegen.
Und wenn dann andere Anforderungen kamen, hat die Partitionierung nicht so ganz zu der Frage gepasst.
Mussten wir anders partitionieren.
Das war unsere Möglichkeit zu parallelisieren.
Jetzt mit MapReduce kam dann noch eine andere Möglichkeit der Parallelisierung hinzu, die vielleicht auch zu der Rechnerarchitektur vielleicht besser passt.
Also diese MPP, SMP-Frage.
Ich weiß nicht, ob wir da hierauf eingehen wollen.
Ich würde gerne, aber ich glaube, wir müssen auf die Zeit achten.
Du könntest zumindest ganz kurz sagen, was MPP und SPP bedeutet.
Also die Massiv-Parallel-Processing, das sind die in der Tandem damals, die waren da gut.
Ich habe einfach einen weiteren Kern, Rechenkern mit dazugerunden.
Auch einmal konnte ich halt linear, idealerweise linear skalieren.
Einfach indem ich einen neuen.
neuen CPU dazu genommen hat.
Das hat standen weitgehend eingehalten dieses Versprechen, in dem halt massiv parallel verarbeitet wurde.
Und Symmetrisch-Multiprocessing, ich habe halt ein Cluster und da bin ich jetzt nicht mehr für die Verteilung zuständig, sondern der Cluster selbst sagt sich auch, wofür da was aussehen vollerweise.
Und das passt halt mit diesem MapReduce-Ansatz, passt das ganz gut.
Das sagst du so.
Ich will gar nichts erwähnen.
Früher, als MapReduce rausgekommen, ich dachte, MapReduce ist total geil, macht Kugel.
Ich will MapReduce machen.
Irgendwann habe ich gedacht, MapReduce ist voll scheiße.
SQL ist doch viel besser.
Okay.
Gut, lassen wir das.
Die Einflüsse, wenn wir so in Richtung Data Lake gegangen, so ein bisschen motiviert haben, aus meiner Sicht heute, würde ich sagen, waren das so die treibenden Faktoren, um so etwas wie ein Data Lake zu entwickeln.
Natürlich mit der 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?
Ich muss natürlich das Verständnis jeder einzelnen Quellanwendung haben, um die Daten richtig interpretieren zu können.
Der Reportersteller kann nicht hingehen und sagen, ich habe die eine Wahrheit aus dem Data Warehouse.
Und dagegen programmiere ich jetzt, sondern er muss dann gegen jede Wahrheit, jeder Quelle arbeiten.
Er hat die ganzen Schmerzen, die vorher die ETL-Programmierer ihm abgenommen haben durch die Vereinheitlichung in ein Schema, die hat er jetzt selbst.
Also Data Warehouse hat den Vorteil, ich kann Queries auf Daten...
ausführen, die sind bereinigt.
Ich kenne die Tabellenstruktur und fertig ist die Laube.
Das ist der Vorteil.
Der Nachteil ist natürlich, irgendwer muss die integrieren und muss die transformieren und wie auch immer.
Und 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.
Also weil der Reportersteller muss dann, der muss wühlen.
Der muss die Arbeit machen.
Einen Punkt habe ich noch vergessen, das ist halt Streaming.
Also Dedge Processing war halt so die WL-Welt.
Und jetzt gab es aber auch die Möglichkeit, man möchte immer mehr in Richtung Streaming kommen.
Da vielleicht auch Anforderungen sind, dass die Daten nicht immer nur tagesgenau sind, sondern halt minütlich aktuell werden.
Und dass ich nicht immer halt die Daten in solchen Paketen da reinlage.
Also dieser Load-Vorgang ist ja immer ein ganzes Paket von Daten, was da genommen wird, sondern ich möchte.
Stichwort Eventual Consistency, auch schon Daten reinfließen lassen und die Konsistenz vielleicht erst später herstellen.
Und dieser Ansatz, das war dann noch ein weiterer Treiber für Data Lake, weil das mit Data Warehouse ist das schwer.
Data Warehouse ist ein Streaming in Data Warehouse.
Das ist ja blöd, weil es keine Konsistenz gewährleistet.
Nur diese Eventual Consistency und da muss man sich überlegen, wie man das mit Data Warehouse macht.
Was man dann versucht hat natürlich, Data Lake, man hat dann 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.
Also der nächste Schritt vom Data Lake zum Lake House.
Ja.
Also Lakehouse ist ja im Grunde genommen so eine Art Kunstwort, weil es offensichtlich aus Data Lake und Warehouse kommt.
Genau, was ist da anders?
Ja, so muss man versuchen, dass im Grunde die Stärken von Data Warehouse wieder, auch im 2D, 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 noch was passieren.
Und die Lakehouse-Architektur bietet mir jetzt gute Möglichkeiten, diese Rohdaten so 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.
Genau, aber ich kann auf alle Teile des Lakehouse schon zugreifen, wenn ich den Schmerz mir antun möchte, auf die Rohdaten zu zugreifen, wenn ich sie brauche, wenn ich sie schnell brauche, kann ich das tun.
Ich kann aber auch warten, bis diese schrittweise Transformation innerhalb des Lakehouse passiert ist und dann auf die vereinigten Daten, vereinheitlichten Daten zugreifen.
Im Grunde ist das, man hat das ETL-Prozessing im Grunde ins Lakehouse verlagert.
im Lakehouse selbst.
Was man da manchmal hört, ist die Medallion-Architektur, der von Databricks geprägt wurde, wo man sagt, man hat so unterschiedliche Zonen innerhalb des Databricks, Bronze, Silber, Gold typischerweise, Bronze ist auch so, wo die Rohdaten reinfließen, Silber, da wird man schon mal so zum Beispiel Vereinheitlichung auf einheitliche Datumsformate.
Werbungsformate, sowas kriegt man da schon mal hin.
Und macht vielleicht auch schon eine Qualitätsbereinigung, füllt für einige Quellen, zum Beispiel sind bestimmte Felder nicht gefüllt.
Überlegt man sich, wie ergänzt man das sinnvollerweise.
Macht man solche Dinge und dann hat man so eine Silberschicht.
Und dann für die Goldschicht würde man dann wirklich die harte Arbeit der Integration richtig machen.
Also dass die auch inhaltlich zusammenpassen, die Daten aus den unterschiedlichen Quellen.
Dass dann stimmige Reports rauskommen.
Dass da nicht heute mal drauf guckt mit Sachverstand und sagt, die Zahl, die da rausschmuss, die kann ja gar nicht stimmen.
Ja, aber es ist immer noch sozusagen ein zentrales Team, das...
domainenspezifische Daten von x anderen Teams beackern muss, wo sie eigentlich kein Domain-Know-how haben.
Das ist so eine Frage, genau.
Typischerweise, wenn man das macht, würde ich nur sagen, man hat so ein zentrales Team, was 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 diese Ownership-Thema besser in den Griff kriegen.
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?
Genau.
Da wären wir beim Data Mesh, oder?
Data Mesh ist sozusagen ein, ich muss mal sagen, konzeptioneller Ansatz.
Und der Fabrik vielleicht, der technische Ansatz, wo man sagt, ich habe hier ein Produkt oder ich habe hier ein Produkt.
Gruppe, die halt mir so eine Datenfabrik zur Verfügung stellen.
Der Mesh eher, sondern das Denken.
Ich denke nicht mehr in monolithischen Anwendungen, sondern ich denke in Datenprodukten.
Genau, also wie gesagt, wir haben eine ganze Folge Data Mesh mit Stefan Tilkow und Jochen Christ.
Wir haben eine ganze Folge Data Products mit Stefan Nägele und mir.
Aber vielleicht trotzdem nochmal für die, die es so einen 5 Minuten Abriss, was ist überhaupt, was macht so ein Data Mesh aus?
Auch in Abgrenzung zum Data Warehouse, Data Lake und Lake House.
Also die, die Erkenntnis, die habe ich ja vorhin schon skizziert.
Die große Erkenntnis ist dieses Team in der Mitte, was halt am Anfang eine tolle Lösung mit so einem Data Warehouse oder Data Lake zur Verfügung stellt.
Alle sind glücklich.
Die Daten werden geliebt von den Fachbereichen, dass sie endlich nicht mehr auf die Einzelanwendungen zugreifen müssen und sich in Excel das dann mühsam zusammenbasteln müssen, was an Auswertungen...
werden brauchen, 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, das sind wir ja im Operativen, Umfeld gemacht.
Da haben wir ja auch versucht, Anwendungen so zu zerlegen, dass sie gut miteinander interoperieren können.
Und sind dann zu sowas wie Microservice gekommen.
Und wir können dann 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 diesen Microservices.
Und genau dieser Gedanke jetzt zu übertragen und zu sagen, wie machen wir das mit Daten?
Und da war die Idee eben, Daten als Produkt zu greifen.
Und das ändert dann so ein bisschen was in der Art, wie wir auf diese Daten schauen.
Weil wir auf einmal sich mehr so sehr darum kümmern, wie kriegen wir die Daten in unseren Unternehmen vereinernden Sicht.
Also wie kriege ich jetzt die Bestellung mit den Pageviews zusammen?
Ja, ja.
Damit ich da das Gegenüber stellen kann und sagen kann, okay, wie weit geht es, wenn meine Pageviews hochgehen, Pageheads hochgehen, wie hat es denn auch Auswirkungen auf meine Bestellung?
Das sind zwei völlig unterschiedliche Quellen, aber ich möchte vielleicht eine Auswertung.
Möchte ich vielleicht da Rückschlüsse haben oder Zusammenhänge erkennen, ob es meine Ausgaben für die Webseite vielleicht lohnen oder nicht.
Also solche Dinge haben wir gemacht, indem wir die Dinge zusammengeschmissen haben.
Und dabei ist was irgendwie nicht gut gelaufen, weil auf einmal Dinge zusammen waren und beherrscht werden mussten, die die Leute überforderten.
Und in dem Moment, wo wir in Richtung Datenprodukten denken, überlegen wir uns, wie können wir diese Daten jetzt strukturieren, teilen, aufteilen, sinnvoll aufteilen, sodass wir sie Teams zuordnen können und sagen können, 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 dir auch verpflichten, ich kann dir sagen, hey, mit neuen Daten darfst du nur das und das tun.
Ich kann darüber informieren, wenn sich irgendwas ändert.
Ich bin derjenige, der, wenn sich was ändert, eine neue Version meiner Daten meines Produkts zur Verfügung stellt.
Ich kann bestimmte Zusicherungen machen über die Daten, über die Qualität, über die aktuell sie sind.
Und das sind alles Dinge, die wir im Data Ware Haushalt konnten.
eben immer auf dem großen Maßstab, immer für alle.
Alle waren da irgendwie über einen Kamm quasi geschoren.
Ja, also ich muss sagen, das fand ich bei Stefan Negele war so eine Art Augenöffner für mich.
Also immer wenn ich mit Data Lake oder Lakehouse Teams zusammengearbeitet habe, da ist halt einfach so, ich stelle Daten zur Verfügung.
Und dann passiert irgendwas mit den Daten.
Ich habe gar keine Ahnung, wer die interessant findet.
Das ist irgendwie raus aus meinem Blickfeld.
Aber die Idee zu sagen, ich biete ein Data-Product an und ein Produkt hat immer Kunden.
Also ich muss wissen, wer interessiert sich denn überhaupt in der Firma für meine Daten?
Woher wissen die Leute überhaupt, dass es diese Daten gibt und was erwarten die?
Ist halt so ein, da denke ich ganz anders natürlich darüber nach.
Das fand ich auf jeden Fall ziemlich, also ist eigentlich ein erfreulicher Mindshift aus meiner Sicht.
Genau, aber das ist sehr, sehr schwierig.
Sehr, sehr schwierig, weil wir lernen gerade im Grunde, die lernen das auch und sind da glaube ich noch nicht so richtig.
angekommen, wie man diese Zerlegung macht.
Wie zählt man diesen großen Datenblock denn jetzt sinnvollerweise in diese Produkte?
Also für Main-Dovement Design, da haben wir, glaube ich, schon ganz gutes Werkzeug, um zu sagen, wie zerlegt man denn jetzt operative Anwendungen sinnvollerweise.
Da sind wir schon weiter bei den Daten, die wir auch, glaube ich, noch am rausfinden und lernen, wie das am besten geht.
Ja, also für mich gilt das so.
Ich kann das noch nicht sagen, dass ich da jetzt genau weiß, wenn ich eine neue Aufgabe, eine neue Domäne habe und wie würde ich denn jetzt die Daten zerlegen.
Das ist sehr, sehr schwierig.
Ja, wir hatten gestern, hatten wir, hatten wir so eine, im Kölner Büro hatten wir so ein Meetup und Stefan Nägele war da und da Da hat er ü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 haben immer so ein bisschen gelacht.
So, ja, genau, das haben wir falsch gemacht und so weiter.
Das war sehr amüsant.
Das war wirklich eine sehr amüsante Diskussion.
Jetzt nicht, dass ich irgendwas davon verstanden habe, weil ich mache ja nichts mit Data Products.
Genau, das habe ich da auch gemerkt, dass das offensichtlich nicht das Einfachste der Welt ist.
Aber ich finde den Ansatz, den der Stefan da verfolgt hat, er hat einen Artikel dazu geschrieben und einen Post dazu verfasst, finde ich genau richtig.
Wir sammeln gerade so Best Practices, wie man solche Datenprodukte sinnvollerweise schneidet.
Ja, schreibe ich direkt mal auf, damit es in die Shownotes kommt.
Gut, wir waren nochmal beim Data Mesh.
Wir haben Datenprodukte, die werden von einzelnen Teams, die auf ihren Daten, auf ihren operationellen, operativen Daten sitzen, bieten halt auch zu Analysezwecken Datenprodukte an.
Ja, vielleicht doch der Punkt, sie schmeißen immer noch Daten über den Sound 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.
Auch mit der Möglichkeit, sie zurückzuziehen, auch so 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.
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 bin ich so, also muss ich sagen, war ich so einigermaßen im Bilde, was so die Landschaft angeht.
Aber so in unserem Vorgespräch, da kam dann plötzlich, da kam Data Fabric auf, da habe ich gesagt, hoch.
Noch nie davon gehört.
Und DuckDB, also da gehen wir jetzt wirklich drauf ein, so tief, wir erwähnen es nur, aber so DuckDB und DuckLake war mir, also DuckDB kenne ich, aber DuckLake 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.
Was ist denn jetzt die Data Fabric?
Ja, also wir haben ja die, mit Data Mesh ist ja weniger ein Produkt, das ist kein Produkt, das ist eine Art über das Bereitstellen analytischer Daten nachzudenken.
Also wie strukturiere ich meine Daten?
Wie kläre ich dieses Problem der Ownership?
Der ist verantwortlich für die Daten, das ist so Data Mesh.
Aber im Data Mesh gibt es halt einen Teil, von den vier Säulen, die wir da noch im Data Mesh typischerweise haben, ist halt Ownership eine und eine weitere ist halt das Denken von Daten als Produkt, das ist ein zweiter.
Und ein dritter Punkt, der sehr wichtig ist, ist halt eine einheitliche Plattform, Data Engineering Plattform.
Also da versuchen wir zu sagen, okay, man muss jetzt die Technik doch möglichst einheitlich haben.
wenn ich jetzt so meine Massendaten habe, meine Bestellung, meine Page-Ships, wo dann die vielleicht in mehrere Millionen gehen, oder vielleicht sogar Milliarden, und ich möchte die miteinander kombinieren, dann kann ich nicht mir erstmal die Millionen von der einen Seite lesen, nur die andere Millionen von der anderen Seite lesen, und dann feststellen, welche von denen halt jetzt, welche 50 davon ich jetzt...
mir rausgeben lassen möchte in meinem Rekord.
Das geht nicht.
Und deswegen muss, das ist halt so ein bisschen auch der Unterschied aus meiner Sicht zu Microservices, wo wir das können.
Microservices können wir halt sagen, gibt mir erstmal oben über die Schnittstelle das, was ich brauche und dann kombiniere ich oben.
Bei diesem Data Mesh muss ich irgendwo unten auf unterer Ebene die Möglichkeit haben, indem ich gemeinsame Technologie verwende, schon sowas wie Joints hinzubekommen.
Das ist, glaube ich, so eine Herausforderung, wie man das macht.
Deswegen haben wir im Data Mesh-Ansatz eben so eine gemeinsame Plattform.
den Dank einer gemeinsamen Datenplattform formuliert.
Und die Teams benutzen eben die Plattform gemeinsam.
Also jeder macht sein Ding, aber sie benutzen halt die Möglichkeiten, die diese Plattform bietet.
eine Tabelle mir anlenden, eine Service nutze, der mir so eine Tabelle anlegt, die ich dann verwenden kann in so einem Snowflake.
Snowflake ist aber noch so eine Firma, die genau für sowas eben Lösungen bietet.
Genau für diese Plattform.
Databricks wäre eine andere.
Aber im Grunde jeder Datenbank, relational Datenbankhersteller könnte auch ans Plattform gehen.
Oder ein Dateisystem, was einfach nur ein Paket-Dateien hat.
Mit Natrino, SQL Engine drauf und sowas.
Viele verschiedene Möglichkeiten.
Wir haben auch hier, es gibt ja diese Seite datamasharchitecture.com, da sind auch mal so verschiedene Beispiele dafür auch nochmal aufgeführt, wie man diese Plattform gestalten kann.
Also das ist sehr, sehr breit gefächert.
Genau.
Und Data Framework, um sich davon abzugrenzen, könnte man benutzen, um so eine Plattform zu alles, was sie als Data Fabric zeichnet, würde ich sagen.
Es ist ein guter Kandidat, um diese einheitliche Datenplattform zu bauen.
Aber es ist dann dieses, die im Grunde bietet die Technik zu diesem Data Mesh-Ansatz.
Was man dabei vielleicht noch sehen muss, ist, Mit Data Warehouse haben wir immer Folgendes gemacht.
Wir haben die Daten geholt und geschrieben.
Und dann erst auf dem Geschriebenen haben wir sie genutzt.
Mit Data Fabric bieten wir jetzt die Möglichkeit, die Daten zu holen, zu verarbeiten und direkt, ohne so zu schreiben, zu nutzen.
Also dieses zusätzliche Schreiben oder Bezielen in ein Data Lake, in ein Data Warehouse, können wir mit Data Fabrics halt vermeiden.
Mit Printing-Kell könnten die Daten mit Data Fabrics in der Quelle verbleiben und wir bieten nur einen geschickten Zugriff darauf.
Also zumindest in Teilen ist das sinnvoll.
Manche Dinge muss ich schreiben und da komme ich nicht drum rum, aber es gibt Anwendungsfälle, wo ich...
das Schreiben darauf verzichten kann und dann bieten Data Fabrics eben die Möglichkeit, dass man dann direkt darauf arbeitet.
Ah, ja, ja, ja.
Jetzt wird mir einiges klarer, weil wenn ich so, als ich diesen Artikel gelesen habe oder allgemein die, also alles, was da auf Data Mesh minus Architecture steht, ist ja eine ziemlich gute Aufbereitung, also wer zu faul ist, um das ganze Buch zu lesen.
Und auf der einen Seite kam ich mir sehr zu Hause vor bei DataMesh, weil ich sage mal aus der normalen Softwareentwicklung, wir haben Plattformen, da gibt es halt die Data-Plattform.
Aber war mir nicht so ganz klar, wie die Data-Plattform aussieht im Vergleich zu so einer normalen Software-Plattform, also Software-Architektur-Plattform.
Und dann gab es ja noch die Enabling Teams und das sind alles so Sachen, die waren mir sehr bekannt, aber ich konnte mir dann nie so vorstellen, wie so eine Data Platform aussieht.
Aber jetzt ist irgendwie klar, die Data Platform ist eigentlich so weit wie Snowflake oder Google bietet Sachen, AWS Redmine, nee, es sind nicht Redmine, sondern Redshift oder so.
Und dann ist 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 sag jetzt einfach mal, in einer eigenen Tabelle an.
Ja, das ist eine Tabelle.
Könnte man so machen, ja.
Und jetzt bin ich Nutzer und ich kann dann einfach sagen, naja, die haben zwei Tabellen, dann mach ich einen Join.
Wenn ich mich für die, okay, ja.
It's nice.
Am Ende wird alles gut.
Okay, hervorragend.
Gibt es sonst noch was zu Data Fabric?
Ja, ich meine, dieses ganze Datenuniversum hat natürlich dann viele Aspekte, die wir gerne sehen.
Da gehört zum Beispiel das Thema Data Lineage dazu.
möchte wissen, ich habe jetzt irgendwie mein Data-Produkt und es vielleicht liefert mir meine Quelldaten aus dem Bestell zum Order-Management und ich habe ein anderes Datenprodukt und das liefert mir Daten aus den Pages und dann bringe ich die irgendwie zusammen und dann mache ich so ein kombiniertes Datenprodukt und dieses Datenprodukt nutzt die Daten aus dem Order-Management und ihr aus den Pages.
kombiniert die irgendwie sinnvollerweise und stellt die dann zur Verfügung.
Und die Daten rauschen ja dann sozusagen von dem Quellsystem durch das eine Datenprodukt, das andere Datenprodukt sozusagen dann zu mir.
Und jetzt zu wissen, okay, aus was setze ich denn nun meine Daten zusammen?
Und wann wurden die denn jetzt überhaupt zur Verfügung gestellt, wenn man jetzt im Batch-Processing ist?
Welcher Batch hat welche Daten, die jetzt gerade bei mir angekommen sind, zur Verfügung gestellt?
Was möchte man gerne irgendwie nachvollziehen können?
Also im Sinne von einem Vertrauen schaffen.
Ich möchte ja Vertrauen haben in die Daten, die ich da sehe.
Und wenn ich denen jetzt so misstraue, dann werde ich meine Lösung nicht benutzen, werde ich das Datenprodukt nicht benutzen.
Und Data-Linage kann mir halt helfen, das Vertrauen in diese Daten aufzubauen.
Wenn ich dem Anwender zeige, hey, das Datum, was du da gerade einzweifelst, dieser Wert, der da steht, der setzt sich so zusammen.
Der Ursprungswert kommt daher und dann auf einmal ist das Vertrauen da, weil das dann nachvollziehbar wird.
Ich glaube, das ist ein wichtiger Punkt und solche Dinge gibt es mehrere, die von...
zu einer Plattform zur Verfügung stellen werden können, damit es leicht ist, solche Lösungen umzusetzen.
Wo man ein paar Dinge halt irgendwie geschenkt bekommt sozusagen.
Also ich muss mich da nicht mit, nicht dass ich Ahnung hätte, aber da muss ich mich nicht extra noch mit Open Lineage oder so beschäftigen.
Genau, das wäre dann halt so Idealfall, wenn ich dann so ein Tooling verwende, dass das dann die Schnittstelle zu meinem Data Lineage System halt schon teilautomatisiert oder komplett befüllt wird.
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 und zwar der Hannes Mühleisen.
Das ist so ein Deutscher, der ist Professor in den Niederlanden und er hat DuckDB gegründet und er macht großartige Vorträge.
Also muss man sich auf jeden Fall, also ich würde mir jeden Vortrag von ihm angucken.
Ist nicht nur über DuckDB, sondern ganz allgemein zu, also er ist ja so ein Professor und er hat wirklich sehr lustige Vorträge, All Things Data.
Was ist eigentlich Was ist denn eigentlich dieses In-Memory-Analytics?
Was ist der Unterschied zu dem, was wir bisher diskutiert haben?
Ja, also die, bisher, also der, der, als wir mit Dataverse angefangen haben, war undenkbar, dass man diese Datenmengen, um die wir uns da kümmern, in-Memory bearbeiten kann.
Also vieles von dem, was wir damals gemacht haben, setzt.
Zwingend vorausgesetzt, dass wir die Daten auf Sekundärspeichern haben.
Und im Hauptspeichern wurde dann halt geschickt, gecashed.
Also man muss dafür, was ein wichtiger Punkt ist zum Beispiel, wenn wir so eine Dimensionstabelle haben mit den ganzen, welche Tage gibt es oder welche Orte gibt es oder welche Artikel gibt es.
Und die haben wir natürlich gerne dann im Cache gehalten, weil darauf wurde permanent zugegriffen.
Und wenn die im Datenbank-Cache waren, war natürlich super.
Da musste man die nur einmal lesen und dann waren sie für immer da.
Und was halt nicht immer komplett neu gelesen wurde, waren die Transaktionsdaten.
Die musste man nicht immer wieder komplett neu lesen.
Jetzt hätte der Cache gesprengt.
Also so ganz vertraut bin ich mit dem Thema nicht, aber im Grunde ist das Versprechen, was ich da herauslese, ist jetzt, dass man mit Technologie wie Dac-DB jetzt dieses Hindernis eliminieren kann.
Dass man also nicht nur sozusagen die kleineren Dimensionsdaten im Cache zu angehalten kann, sondern dass man sich die komplette...
alles, was ich für meine Analyse brauche, im Hauptspeicher halten kann.
Im Zug auf meine Daten im externen Speicher, dass ich mir das sparen kann.
Und das ist natürlich eine Beschlägenung und Vereinfachung.
Das bietet dann natürlich auch etwas mehr Möglichkeiten, wenn man da direkt Dinge adressieren kann.
Ich glaube, das Wesentliche ist, dass so ein paar Optimierungen, die wir immer gemacht haben, dass die dann auf einmal wegfallen.
Wir haben halt immer optimiert um den Sachverhalt, dass wir auf die Fakten-Tabelle immer nur mit einem Full-Table-Scan im Grunde zugreifen können.
Das war so der Bottleneck, wenn ich so eine Quere habe und dann habe ich meine ganzen Dimensionsdaten im Hauptspeicher, aber ich muss halt einmal muss ich halt durch die komplette Fakten-Tabelle, zumindest Teile der Fakten durch.
Man muss mal den heutigen Tag lesen, vielleicht nicht den Tag von gestern, aber die Fakten für 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 halt um diese Dinge herum optimiert.
Das fällt dann weg.
Diese Anforderung jetzt darum zu optimieren, fällt weg.
Wenn wir einfach sagen können, ist ja eh alles im Hauptspeichern, dann greift doch zu wie du willst.
Genau, also ich hatte auch einmal einen Vortrag gesehen von jemand von DuckDB, die waren ziemlich auch auf dem Trip.
so Mechanical Sympathy, also im Sinne von, die wissen wirklich, was unter der Haube abgeht, also wie Prozessoren funktionieren und die, da wird halt wirklich so, also die wissen ganz genau, was, wann, in welchem Prozessor-Cache liegt, so ungefähr, wie man das optimiert und deswegen sind die ultra schnell, ja.
Genau.
Also wer sich dafür interessiert, ich packe auf jeden Fall nochmal so einen Talk rein, wie das unter der Haube läuft.
Also 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.
Alles, was ich so im Blick habe, ist das größere.
Alles ist zu viel, aber wir haben einen schönen Überblick über die typischen Entwicklungen bekommen.
Vielen Dank, Rainer.
Ich hoffe auf weitere Besuche hier beim InnoCube Podcast.
Danke auch an alle Zuhörer und bis dann.
Vielen Dank.