Analytics, Streaming, Data Warehouses, Data Lakes und Data Mesh

Zwei verschiedene Workloads: OLTP und OLAP

Alles in diesem Kapitel drehte sich bisher um Online-Transaktionsverarbeitung (OLTP): viele kleine, schnelle Lese- und Schreibvorgänge einzelner Datensätze, etwa eine Bestellung aufgeben, eine Zahlung buchen oder die Position eines Kuriers aktualisieren. Analytics stellt eine andere Art von Frage. Wie hoch war der Umsatz nach Küche und Region, Woche für Woche, in den letzten zwei Jahren? berührt Millionen Zeilen, liest von jeder nur wenige Spalten und ändert nichts. Das ist Online Analytical Processing (OLAP), und es unterscheidet sich so stark von OLTP, dass beides auf derselben Datenbank meist keinem von beiden gut dient: Eine große analytische Abfrage kann die Festplatten und den Puffer-Cache auslasten, von denen der Checkout abhängt, und das normalisierte Schema, das Transaktionen korrekt hält, zwingt Analysten, ein Dutzend Tabellen zu joinen.

Die übliche architektonische Antwort besteht darin, die Workloads zu trennen. Operative Systeme behalten ihre eigenen Datenbanken, die ihren Services gehören, wie in Abschnitt 7.1 beschrieben. Daten werden laufend oder periodisch in eine Analyseplattform kopiert, die für Scans ausgelegt ist: spaltenorientierte Speicherung, die nur die benötigten Spalten liest, starke Kompression, massiv parallele Abfrage-Engines und Schemas, die für Analysen geformt sind. Der Rest dieses Abschnitts behandelt, wie diese Plattform entworfen wird, wie Daten zu ihr gelangen, wie Streaming das Bild verändert und wem das Ergebnis gehört.

Data Warehouses und dimensionale Modellierung

Ein Data Warehouse ist eine für Analysen gebaute Datenbank, die bereinigte Daten aus vielen operativen Systemen integriert und deren Historie aufbewahrt. Zwei Schulen haben geprägt, wie Data Warehouses entworfen werden, und Fachleute streiten bis heute darüber. Bill Inmon, oft der Vater des Data Warehouse genannt (Building the Data Warehouse, 1992), vertritt einen Top-down-Entwurf: Zuerst wird ein unternehmensweites, normalisiertes, integriertes Data Warehouse als Single Source of Truth gebaut, und daraus werden dann abteilungsbezogene Data Marts abgeleitet. Ralph Kimball (The Data Warehouse Toolkit, erstmals 1996 erschienen, dritte Auflage mit Margy Ross 2013) vertritt einen Bottom-up-Entwurf: dimensionale Modelle Geschäftsprozess für Geschäftsprozess bauen und sie über gemeinsame, konforme Dimensionen integrieren (eine vereinbarte Definition von Kunde, Datum oder Restaurant, die jedes Modell nutzt). Inmons Ansatz bietet stärkere Integration bei höheren Anfangskosten; Kimballs liefert früher nutzbare Ergebnisse, braucht aber Disziplin, um die Dimensionen konform zu halten. Viele moderne Plattformen verbinden beides: eine bereinigte, integrierte Schicht, die dimensionale Modelle für die Nutzung speist.

Kimballs Sternschema ist nach wie vor das am häufigsten gelehrte Analysemodell. Eine zentrale Faktentabelle erfasst Geschäftsereignisse in einer deklarierten Granularität (eine Zeile pro Bestellposition, pro Zahlung, pro Kurier-Ping), mit numerischen Kennzahlen wie Menge, Betrag und Minuten sowie Fremdschlüsseln auf Dimensionstabellen. Jede Dimension enthält beschreibende Attribute zum Filtern und Gruppieren: Datumsangaben (mit vorberechneten Kennzeichen für Wochentag, Monat und Feiertag), Restaurants (Name, Küche, Stadt), Kunden und Gerichte. Abfragen bestehen dann aus einer Faktentabelle, gejoint mit wenigen kleinen Dimensionen, was spaltenorientierte Engines sehr effizient ausführen. Attribute, die sich im Lauf der Zeit ändern, etwa wenn ein Restaurant in eine andere Stadt zieht, werden mit Techniken für Slowly Changing Dimensions behandelt; die gängigste, Typ 2, fügt eine neue Dimensionszeile mit Gültigkeitsdaten hinzu, sodass historische Fakten weiterhin auf die Attribute zeigen, die damals galten.

-- Revenue and average delivery time by cuisine and weekday for last quarter.
-- One join per dimension; the fact table is scanned, never updated.
SELECT r.cuisine,
       d.weekday,
       SUM(f.line_total_pence) / 100.0 AS revenue_gbp,
       AVG(f.delivery_minutes)          AS avg_delivery_min
FROM   fact_order_line f
JOIN   dim_date       d ON d.date_key       = f.date_key
JOIN   dim_restaurant r ON r.restaurant_key = f.restaurant_key
WHERE  d.quarter = '2026-Q2'
  AND  r.region  = 'North West'
GROUP  BY r.cuisine, d.weekday
ORDER  BY revenue_gbp DESC;
-- Caveat: delivery_minutes is per order, so averaging it over order LINES
-- weights big orders more. Grain decisions matter (see the worked example).

Daten hineinbringen: ETL, ELT und Change Data Capture

Daten gelangen über Pipelines ins Data Warehouse. Beim klassischen ETL (Extract, Transform, Load) extrahiert ein separates Werkzeug Daten aus den Quellsystemen, bereinigt und formt sie auf eigenen Servern um und lädt nur das Ergebnis. Seit Cloud-Data-Warehouses Speicher billig und Rechenleistung elastisch gemacht haben, ist ELT verbreitet: Rohdaten zuerst extrahieren und laden, dann im Data Warehouse mit SQL transformieren, oft verwaltet als versionierte, getestete Modelle mit einem Werkzeug wie dbt. ELT bewahrt die Rohdaten auf, sodass Transformationen korrigiert und erneut ausgeführt werden können; sein Risiko ist, dass sich personenbezogene Rohdaten weiter verbreiten als nötig.

Wie Daten extrahiert werden, ist ebenso wichtig. Nächtliche Vollkopien sind einfach, aber langsam und veraltet. Change Data Capture (CDC) liest mit einem Werkzeug wie Debezium das eigene Replikations-Log der Datenbank (das Write-Ahead-Log von PostgreSQL, das Binlog von MySQL) und streamt jedes Insert, Update und Delete als Event, mit niedriger Latenz und wenig Last auf der Quelle. Unabhängig vom Mechanismus koppelt das direkte Lesen der Tabellen eines anderen Service die Analyseplattform an dessen privates Schema, genau das Problem, das Abschnitt 7.1 beschrieben hat. Das robustere Muster ist, dass jeder Service Daten gezielt veröffentlicht, über Events oder einen vereinbarten Export, im Rahmen eines Datenvertrags.

Data Lakes, Lakehouses und Open Table Formats

Ein Data Lake (der Begriff wird James Dixon zugeschrieben, 2010) speichert Rohdaten aus vielen Quellen in ihrer ursprünglichen Form, meist als Dateien in günstigem Objektspeicher wie Amazon S3, oft in spaltenorientierten Formaten wie Apache Parquet. Er schiebt das Schema auf, bis die Daten gelesen werden; das passt zu Data Scientists, die rohe Details wollen, und zu Daten, deren Verwendung noch nicht bekannt ist. Data Lakes haben sich den Ruf erworben, zu Datensümpfen zu werden: Ohne Verantwortliche, Dokumentation und Qualitätsprüfungen vertraut niemand ihrem Inhalt. Dateien im Objektspeicher fehlt zudem, was ein Data Warehouse bietet: Transaktionen, Updates und Löschungen, Schemadurchsetzung und konsistente Lesevorgänge, während Daten geschrieben werden.

Das Lakehouse (Armbrust, Ghodsi, Xin und Zaharia, CIDR 2021) ergänzt diese Data-Warehouse-Funktionen auf offenen Dateien im Data Lake. Die tragende Technologie ist das Open Table Format: Delta Lake (entstanden bei Databricks), Apache Iceberg (entstanden bei Netflix) und Apache Hudi (entstanden bei Uber). Jedes führt eine Metadatenschicht (ein Transaktions-Log oder einen Baum aus Manifest-Dateien), die festhält, welche Datendateien jede Version einer Tabelle bilden. Das ermöglicht atomare Commits, nebenläufige Schreiber mit optimistischer Nebenläufigkeitskontrolle, Schemaevolution, Updates und Löschungen auf Zeilenebene (nötig für Löschanträge) und Time Travel: eine Tabelle so abzufragen, wie sie in einer früheren Version war. Weil das Format offen ist, können mehrere Engines (Spark, Trino, Flink und zunehmend die Cloud-Data-Warehouses selbst) dieselben Tabellen lesen und schreiben, was Lock-in verringert. Viele Lakehouses organisieren Daten in Schichten, von Databricks als Medallion-Architektur bekannt gemacht: Bronze für roh aufgenommene Daten, Silber für bereinigte und konforme Daten, Gold für Modelle auf Geschäftsebene wie Sternschemas.

Stream Processing: Ereigniszeit, Fenster und Watermarks

Batch-Pipelines beantworten Fragen über gestern. Manche Fragen können nicht warten: Wird diese Karte gerade betrügerisch verwendet, sind die Kuriere in Manchester heute Abend verspätet, welche Restaurants sollten pausiert werden, weil ihre Küchen überlastet sind? Stream-Prozessoren wie Apache Flink, Kafka Streams und Spark Structured Streaming rechnen fortlaufend über unbegrenzte Event-Streams. Die grundlegenden Konzepte stammen aus Googles Dataflow-Modell (Akidau und Kollegen, VLDB 2015).

Das erste ist der Unterschied zwischen Ereigniszeit, wann etwas tatsächlich geschah, und Verarbeitungszeit, wann das System es beobachtet. Sie weichen voneinander ab wegen Netzwerkverzögerungen, Wiederholungen, Batching und Geräten, die offline gehen: Das Smartphone eines Kuriers im Aufzug erfasst eine Übergabe um 19:03, liefert das Event aber um 19:13 aus. Jedes Ergebnis, das die Wirklichkeit abbilden soll (Bestellungen pro fünf Minuten, durchschnittliche Lieferzeit pro Stunde), muss nach Ereigniszeit berechnet werden, sonst verschiebt es sich, sobald die Pipeline langsam ist, und ist beim erneuten Abspielen falsch.

Das zweite sind Fenster, die einen unbegrenzten Stream zum Aggregieren in endliche Stücke schneiden: Tumbling-Fenster sind fest und überlappen nicht (alle fünf Minuten), Sliding-Fenster überlappen (die letzten zehn Minuten, jede Minute aktualisiert), und Session-Fenster gruppieren Aktivitätsschübe pro Schlüssel, getrennt durch eine Lücke der Inaktivität (die Browsing-Sitzung eines Kunden).

Das dritte ist die Watermark: die mitlaufende Schätzung des Prozessors, dass alle Events bis zu einer bestimmten Ereigniszeit wahrscheinlich eingetroffen sind. Wenn die Watermark das Ende eines Fensters überschreitet, kann das Ergebnis des Fensters ausgegeben werden. Watermarks sind Heuristiken, daher treffen manche Events trotzdem ein, nachdem ihr Fenster geschlossen wurde. Die Pipeline braucht eine ausdrückliche Regel für solche verspäteten Daten: verwerfen, an eine Nebenausgabe zur späteren Korrektur senden oder Fenster für eine erlaubte Verspätung offen halten und aktualisierte Ergebnisse ausgeben. Längeres Warten liefert vollständigere Antworten, früheres Ausgeben aktuellere. Diese Abwägung zwischen Latenz und Vollständigkeit ist die Stream-Processing-Variante einer Abwägung zwischen Qualitätsmerkmalen und sollte mit dem Fachbereich entschieden werden.

Lambda- und Kappa-Architektur

Wie sollten Batch- und Streaming-Ergebnisse kombiniert werden? Nathan Marz’ Essay How to beat the CAP theorem von 2011 beschrieb, was als Lambda-Architektur bekannt wurde: Ein unveränderlicher Master-Datenbestand speist einen Batch-Layer, der periodisch aus allen Daten genaue Sichten neu berechnet, und einen Speed-Layer, der in Echtzeit näherungsweise Sichten auf aktuelle Daten berechnet; Abfragen führen beide zusammen, und jeder Batch-Lauf ersetzt die Näherungen des Speed-Layers. Lambda bietet Genauigkeit und niedrige Latenz, und der Batch-Layer dient als Sicherheitsnetz für Streaming-Fehler. Der Preis ist, dass dieselbe Logik in zwei verschiedenen Frameworks geschrieben und identisch gehalten werden muss.

2014 stellte Jay Kreps, einer der Schöpfer von Apache Kafka, diesen Entwurf infrage und schlug die Kappa-Architektur vor, ein Name, den er halb im Scherz anbot. Nutzen Sie nur einen Stream-Prozessor und bewahren Sie die Eingabe lange genug in einem Log auf, um sie erneut abzuspielen. Um die Logik zu ändern, starten Sie eine zweite Instanz des neuen Jobs, die vom Anfang des Logs in eine neue Ausgabetabelle liest, und stellen die Leser darauf um, sobald sie aufgeholt hat. Eine Codebasis, und Neuverarbeitung ist einfach erneutes Abspielen. Kappa setzt eine lange Log-Aufbewahrung voraus und Stream-Prozessoren, die Ereigniszeit und Zustand zuverlässig korrekt behandeln, was moderne Engines leisten. Heute neigen die meisten neuen Entwürfe zu Streaming im Kappa-Stil mit einem Lakehouse für die Historie, während Entwürfe im Lambda-Stil dort fortbestehen, wo die Batch-Neuberechnung über sehr lange Historien günstiger ist oder wo bestehenden Batch-Pipelines vertraut wird.

Data Mesh: Hoheit über analytische Daten

Als Organisationen wuchsen, wurden zentrale Datenteams zu Engpässen: Jede neue Quelle und jede neue Frage stand in der Warteschlange hinter einem Team, das weder die Quellsysteme noch die fachlichen Fragen besonders gut verstand. 2019 schlug Zhamak Dehghani, damals bei Thoughtworks, das Data Mesh vor (später ausgebaut in ihrem Buch Data Mesh von 2022). Es überträgt auf analytische Daten dieselbe Dezentralisierung, die Microservices auf operative Systeme übertragen haben, und beruht auf vier Prinzipien.

Fachliche Datenhoheit: Die Teams, die den Daten am nächsten sind, etwa Bestellungen, Zahlungen oder Kuriere, besitzen und bereitstellen ihre analytischen Daten, so wie sie ihre Services besitzen. Daten als Produkt: Jedes Team veröffentlicht Datenprodukte, die auffindbar, dokumentiert, vertrauenswürdig, adressierbar und sicher sind, mit einem Verantwortlichen und Qualitätszielen, und behandelt andere Teams als Kunden. Self-Service-Datenplattform: Ein Plattformteam stellt Speicher, Pipelines, Katalog und Zugriffskontrolle bereit, die das Veröffentlichen eines Datenprodukts günstig machen, sodass nicht jede Domäne sie neu erfindet. Föderierte, automatisierte Governance (Federated Computational Governance): Globale Regeln (Kennungen, Datenschutzklassifizierungen, Interoperabilitätsstandards) werden gemeinsam vereinbart und von der Plattform automatisch durchgesetzt statt von einem zentralen Prüfgremium.

Data Mesh ist ebenso sehr ein Organisationsdesign wie eine Architektur, und die Meinungen darüber, wann es sich lohnt, gehen auseinander. Seine Befürworter verweisen auf die Skalierung: Es beseitigt den zentralen Engpass und verankert Datenqualität dort, wo das Wissen ist. Seine Kritiker weisen darauf hin, dass es reife Fachteams, eine starke Plattform und echte Investitionen braucht und dass kleinere Organisationen meist mit einer gut geführten zentralen Plattform und klarer Verantwortung für jeden Datenbestand besser bedient sind. Das Gesetz von Conway (Abschnitt 3.7) gilt unmittelbar: Die Datenarchitektur wird die Struktur widerspiegeln, die die Organisation tatsächlich annimmt.

Qualität, Lineage, Kataloge und Datenschutz

Analytische Daten sind nur nützlich, wenn man ihnen vertraut. Prüfungen der Datenqualität laufen innerhalb der Pipelines und testen Aktualität (ist die heutige Ladung angekommen?), Volumen (hat sich die Zeilenzahl halbiert?), Schema (hat eine Spalte ihren Typ geändert?), Gültigkeit (sind Beträge positiv und Postleitzahlen wohlgeformt?) und Eindeutigkeit. Fehlgeschlagene Prüfungen sollten eine Pipeline anhalten oder Daten in Quarantäne stellen, statt sie unbemerkt zu veröffentlichen. Data Lineage hält fest, woher jeder Datenbestand stammt und welche Transformationen ihn erzeugt haben, sodass Sie, wenn eine Zahl falsch aussieht oder sich ein Quellschema ändert, die Auswirkungen vor- und nachgelagert verfolgen können; die Spezifikation OpenLineage standardisiert, wie Pipelines sie melden. Ein Datenkatalog macht Datenbestände auffindbar, mit Beschreibungen, Verantwortlichen, Klassifizierungen und Lineage an einem Ort.

Analyseplattformen bündeln Daten, was sie für Angreifer attraktiv und datenschutzrechtlich riskant macht. Wenden Sie Datenminimierung an (kopieren Sie keine personenbezogenen Felder, die keine Analyse braucht), pseudonymisieren Sie Kennungen, wo möglich, klassifizieren Sie Spalten, damit Zugriffsrichtlinien den Daten folgen, setzen Sie Aufbewahrungsfristen mit automatischer Löschung durch und stellen Sie sicher, dass Löschanträge den Data Lake und das Data Warehouse ebenso erreichen wie die operativen Systeme; Open Table Formats helfen dabei, weil sie Löschungen auf Zeilenebene unterstützen. Abschnitt 8.7 behandelt die Pflichten im Detail.