Im Zusammenhang mit analytischen Daten gibt es jede Menge Begriffe, welche die jeweils optimale Architektur definieren. In diesem Beitrag ordne ich ein paar von diesen Begriffen etwas ein.
Erzählen wir die Geschichte von vorne, als Bill Inmon, der Vater vom Datawarehouse (DWH), den Begriff und das Konzept Anfang der Neunzigerjahre des letzten Jahrhunderts einführte. Bill Inmon definierte und charakterisiert(e) das Datawarehouse wie folgt: "A subject oriented, nonvolatile, integrated, time variant collection of data in support of management's decisions." Daraus lässt sich bereits einiges ableiten. Die Daten sind wohlstrukturiert, es bezieht sich auf ein Subjekt, also um eine definierte Struktur. Die Daten sind unveränderlich und haben eine zeitliche Dimension. Dazu gibt es eine klare Zielsetzung, Entscheidungen vom Management zu unterstützen. Daten werden mittels ETL: Extract Transform Load in ein DWH geladen. Das T vor dem L ist hier wichtig, weil die Daten zuerst transformiert werden, bevor sie geladen werden. Im DWH selber sind die Daten dann entsprechend zielgerichtet strukturiert vorhanden. Bill Inmon hat dutzende von Bücher zum Thema geschrieben. Es wäre vermessen zu behaupten, diese paar Sätze würden dem Thema gerecht. Zum Vergleich mit den anderen Begriffen und zur Einordnung sollte es aber vorerst ausreichen.
Das DWH entstand in einer Zeit, wo Speicherplatz noch rar und teurer war. Jüngere Leser können sich dies vielleicht nicht ganz vorstellen. Man sammelte nur die Daten die wirklich für das Business relevant waren und in einer Form, wie man sie für den Zweck effizient nutzen konnte. Der Speicher wurde aber immer grösser und immer günstiger und es kam die Zeit, als man Daten einfach auf Vorrate speichern konnte. Niemand weiss für was, aber vielleicht kann man sie einmal brauchen.
Das war die Geburtsstunde vom Data Lake. Während ein Warenhaus (Warehouse) ordentlich strukturiert Produkte anbietet die nachgefragt werden, sind stille Wasser tief und die Tiefen der Meere grösstenteils unbekannt. Die Erfindung des Begriffs lässt sich nach meinen bescheidenen Recherchen fundiert keiner einzelnen Person zuordnen. Die Grundlagen schufen aber sicher zu einem wichtigen Teil Google mit dem MapReduce-Projekt (etwas mehr dazu in diesem Artikel zum Thema Streaming-Applikationen), dem Google Dateisystem und nicht zuletzt Doug Cutting, dem Erfinden von Apache Lucene und Hadoop, welches auf MapReduce aufsetzt und Ideen vom Google Dateisystem aufgriff. Hadoop wurde 2006 das erste Mal veröffentlicht. Damit war erstmals die Grundlage geschaffen, dass man auch mit günstiger Hardware riesige Datenmengen (zentral) verwalten konnte. Eine wichtige Grundlage eines Data Lakes. Damit kommen wir zu den Charaktereigenschaften. Ein Data Lake ist eine Sammlung von strukturierten aber vor allem auch unstrukturierten Daten. Daten in einem Data Lake können unterschiedliche Formate haben (Texte, Bilder, Audio, Video etc.) und sich auch semantisch von einander unterscheiden. Was ein Data Lake ausmacht ist, dass über definierte API zentral auf die Daten zugegriffen werden kann. Ein Data Lake ist also eine Art Integrations-Layer. Die technische Integration ist gelöst und wird bereitgesellt. Was man inhaltlich wie mit den Daten macht oder machen kann, ist nicht festgelegt oder zumindest nicht für alle Daten. Um Daten aus einem Data Lake nutzbar zu machen, müssen sie inhaltlich semantisch erschlossen und nicht selten technisch transferiert werden. Dies führte dazu, dass der Data Lake oftmals in Co-Existenz mit einem Data Warehouse war und dies in einer bidirektionalen Form: 1) Aus dem Data Lake werden einzelne Daten gezielt mittels ETL in ein Data Warehouse geladen. 2) Grosse Daten wie Videos werden im Datawarehouse nur mittels Metadaten referenziert. Die Daten selber bleiben im Data Lake und werden bei Bedarf direkt aus dem Data Lake geladen. Nebenbemerkung: Werden (zu) wenige Daten über die Zeit strukturiert nutzbar gemacht, spricht man abwertend auch von einem Data Swamp.
Damit sind wir bei der Verschmelzung und dem Begriff Data Lakehouse oder Data Lakewarehouse angekommen. Die Nutzung von Daten in einem Datawarehouse und einem Data Lake über eine zentrale API wäre wunderbar. Und noch besser, wenn man sie direkt kombiniert verwenden könnte. Diese Verschmelzung bieten Produkte wie bspw. Googles BigQuery in Kombination mit Cloud Storage. Sie können klassisch strukturierte Daten in BigQuery speichern und daneben bspw. Daten in Form von CSV oder JSON/JSONL im Cloud Storage speichern. Auf beide Ressourcen können sie via BigQuery-Interface zugreifen und dabei sogar Daten aus BigQuery mit einer CSV-Quelle in einem SQL-Statement kombinieren, ohne dass das CSV zuerst mittels ETL in BigQuery geladen werden muss. Und voilà, da haben Sie ein Data Lakehouse. Selbstverständlich können Sie das nicht mit allen Daten gleichermassen direkt ohne E und T machen. Aber die Adapter werden mehr und mehr und beinhalten bspw. auch Standard SQL-Datenbank und NoSQL-Datenbanken. Ein Data Lakehouse bietet wo notwendig und hilfreich die Vorteile eines Data Warehouses bei gleichzeitiger Möglichkeit, unstrukturierte oder noch unbekannt strukturierte Daten auf Vorrat zu speichern und bei Bedarf einfach zu analysieren und nutzbar zu machen.
Schön, dieses Data Lakehouse. Aber wie organisiert man es am besten? Sie ahnen es, es gibt mehrere Möglichkeiten. Schauen wir uns zwei bekannte Möglichkeiten an, um ein weiteres Buzzword zu erschlagen.
Medaillen-Architektur:
In dieser Architektur-Form organisiert man die Daten anhand des Reifengrades der inhaltlichen Erschliessung. Klassisch Bronze, Silber und Gold. Daten im Bronze-Bereich sind roh, so wie sie von einem Drittsystem gespeichert werden. Silber-Daten haben bereits eine erste Transformation hinter sich, besitzen bspw. eine eindeutige Id über den ganzen Data Lake oder sind hinsichtlich einzelner Attribute normiert auf ISO-Code (Länder, Währungen etc.). Die Gold-Daten schliesslich können vom Business verwendet werden. Sie besitzen dem Business bekannte Attributsnamen und verkörpern sinnvollerweise Business-Objekte. Wir kommen wenig später beim Data Vault nochmals auf diese Aufteilung zurück.
Data Vault
Damit sind wir beim nächsten Buzzword, Data Vault, angekommen (wir sprechen hier von Data Vault 2.0, welches 2013 veröffentlicht wurde).
Wichtig ist das Verständnis, dass Data Vault 2.0 zwei grundlegende Architektur- oder besser Design-Prinzipien für die Daten definiert:
- Hub, Link, Satellite (HLS):
Dieses grundlegende Konzept der Datendefinition gab es bereits in der Version 1.0. Die Hub-Tabellen stellen Business-Objekte wie Kunden, Produkte und Bestellungen dar. In ihnen werden die eindeutigen Schlüsseln gespeichert. Die Link-Tabellen enthalten die Verbindungen zwischen verschiedenen Entitäten. Die Satelliten-Tabellen schliesslich, enthalten die Attribute zu den Hub- oder Link-Objekten. In einer Hub-Tabelle kommt ein Kunde nur einmal vor, mit einer eindeutigen Id. In der Satelliten-Tabelle kann dieser Kunde aber mehrmals vorkommen. So können bspw. Historisierungen abgebildet werden. - Landing Zone, Raw Data Vault, Business Data Vault, Information Mart:
Dies beschreibt den Datenlade-Prozess von links nach rechts: In der Landing Zone werden die Daten gespeichert, wie sie sind. Also im Original. Im Raw Data Vault kommt die HLS-Modellierung der Daten zum Zuge. Die Daten aus der Landing Zone werden mittels HLS abgebildet. Im Business Data Vault werden spezifische Business-Views abgebildet, die einen spezifischen Use Case abdecken. Im Information Mart werden die Daten schliesslich effektiv zugänglich gemacht. Das kann eine Visualisierung sein oder auch spezifische API mit Metadaten etc.
Sie haben vielleicht bereits die Ähnlichkeit zwischen der Medaillen-Architektur und dem Lade- oder Aufbereitungsprozess von Data Vault festgestellt. Und tatsächlich lässt sich dies gut in Einklang bringen:
- Bronze:
- Landing Zone - Silber:
- Raw Data Vault
- Business Data Vault - Gold:
- Information Mart
Damit lässt sich Data Vault grundsätzlich gut mit einem Data Lakehouse umsetzen. Oder ein Data Lakehouse mit Data Vault strukturieren. Aber es gilt festzuhalten: Nur weil man das Data Lakehouse in vier anstelle von drei Töpfen organisiert, hat man noch kein Data Vault umgesetzt. Data Vault hat man umgesetzt, wenn man im Topf 2, Silber/Raw Data Vault, die Daten mit HLS strukturiert.
Ein Buzzword für eine echte Kombination kenne ich bislang noch nicht. Wenn Data Vault mit einem Data Lakehouse umgesetzt haben, haben Sie aktuell einfach Data Vault mit einem Data Lakehouse umgesetzt. Haben Sie einfach ein Data Lakehouse mit den vier Töpfen, haben Sie, je nach Benennung und Verwendung der Töpfe, ein Data Lakehouse mit Data Vault 2.0 Ladeprozess umgesetzt.
Wenn Sie Zweifel haben, dass eine zentrale Einheit es schafft, die Daten in den Gold-Standard oder nur schon in Use Case spezifische Business Views zu bringen, dann sind Sie nicht alleine. Data Mesh wurde 2019 von Zhamak Dehghani propagiert. Data Mesh orientiert sich u.a. am Domain Driven-Konzept von Eric Evans aus dem Jahre 2003 und besagt, dass auch die analytischen Daten von den Entwickler-Teams der transaktionalen Daten in Eigenverantwortung allen bereitgestellt werden müssen. Es ist ein soziotechnischer Ansatz für eine dezentrale Datenarchitektur. Data Mesh impliziert "Data as a Product" mit entsprechender Domänenverantwortung. Data Warehouse, Data Lake, Data Vault sind zentralistische Ansätze, welche sich in der Regel auch auf die Organisation auswirken. Dedizierte Teams sind verantwortlich für den Auf-, Ausbau und den Betrieb der Lösungen. Dabei beziehen sie (meist) transaktionale Daten aus den operativen Systemen um sie wiederum für verschiedene Stakeholder nutzbar zu machen. Data Mesh ist mehr ein kulturellen Wandel in der Art und Weise, wie Unternehmen über ihre Daten denken, denn eine technische Lösung. Anstatt dass Daten als Nebenprodukt eines Prozesses gesehen werden, werden sie zu dem eigentlichen Produkt (Stichwort "Data as Product"), bei dem die Datenproduzenten (resp. die Owner dieser System) als Datenprodukteigentümer fungieren. Technisch gesehen können einzelne Teams ihre Datenprodukte intern natürlich auch bspw. mit einen Datawarehouse oder strikt nach Data Vault umsetzen und ihre Datenprodukte bspw. über entsprechende Dashboards oder Rest API zur Verfügung stellen. Dass jedes Team innerhalb derselben Unternehmen einen eigenen richtigen Data Lake aufbaut und unterhält, ist wohl eher weniger empfehlenswert und auch nicht der Sinn von Data Mesh. Wenn Sie mehr über Data Mesh wissen möchten, finden Sie hier einen guten Überblick.
Das Gegenteil von einem soziotechnischer Ansatz ist eine Fabrik, könnte man sagen. Damit wären wir mit Data Fabric beim letzten Buzzword von diesem Artikel angekommen. Data Fabric kann als eine Art virtuelle (Architektur-) Schicht angesehen werden, welche Daten von verschiedenen Quellen u.a. mit Hilfe von KI in real-time aggregiert und kontrolliert zugänglich macht. Obwohl man heute so einiges einfach in einen Data Lake speichern kann gibt es Datenspeicher, welche nicht zentral erschlossen werden können. Dies kann verschiedene Gründe haben. Der technische Prozess lohnt sich (noch) nicht oder die Daten sollen nicht redundant gehalten werden. Dennoch möchte man bestimmte Daten aus einem Data Lake, Data Lakehouse, aus verschiedenen Data Warehouses und weiteren Quellen vielleicht in einer zentralen Sicht haben. Data Fabric hat aber nicht nur eine aggregierende Funktion. Data Fabric kann, je nach Tool, auch als Discovery genutzt werden. Also um noch nicht erschlossene Daten zu entdecken. Data Fabric speichert dabei selber keine Inhaltsdaten. In einer Data Fabric werden nur jeweils Metadaten zu Quellen gespeichert. Data Fabric ermöglicht in der Regel eine feingranulare Zugriffsregelung um spezifische Data Governance-Konzept einer Unternehmung um zu setzen. Data Fabric ersetzt kein vorstehend genanntes Buzzword, kann aber hilfreich um diese zentral zu erschliessen und eine konsolidierte Sicht darauf zu geben. Data Fabric ist nicht das Gegenteil von Data Mesh wie eingangs als Überleitung vielleicht suggeriert wurde. Als zentralistischer Ansatz ist es aber dennoch mindestens ein Stück weit ein mentaler/methodischer Widerspruch. Technisch gesehen ist Data Fabric in der Regel ein Software-Tool, welches wiederum auf verschiedene Tools zurück greift. Eine bekannte Data Fabric-Lösung ist Dataplex von Google.
Keine Kommentare:
Kommentar veröffentlichen