Datenpipeline-Architekturdiagramm: CDC, Streaming und ein Data Warehouse

Datenpipelines brechen leise. Ein Dashboard zeigt die Zahlen von gestern, eine Spalte ändert im Quellsystem ihren Typ und ein Job verwirft Zeilen ohne Fehlermeldung, oder ein Replication Slot, an den sich niemand erinnert, hält Write-Ahead-Log auf der Produktionsdatenbank fest, bis die Platte voll ist. Jeder dieser Fälle ist ein Hop oder ein Vertrag, den niemand gezeichnet hat.

Ein Datenpipeline-Architekturdiagramm zeigt, woher Daten kommen, wie sie sich bewegen, wo sie in jeder Stufe liegen, wer sie wann transformiert und woran alle erkennen, dass sie aktuell und korrekt sind. Dieser Beitrag baut eines für ein verbreitetes Setup auf, Change Data Capture aus PostgreSQL über Kafka in einen Lake und ein Warehouse, und zeigt, was auf jeden Hop gehört.

Batch-Extrakte, CDC oder Events

Es gibt drei verbreitete Wege, Daten aus einer operativen Datenbank zu holen:

Log-basiertes Change Data Capture (CDC) ist für Analysen beliebt, weil es keine Änderungen an der Anwendung braucht, Löschungen sieht und wenig Abfragelast erzeugt. Seine Kosten sind operativ, und sie gehören ins Diagramm.

So funktioniert log-basiertes CDC mit PostgreSQL

PostgreSQL stellt Änderungen über Logical Decoding bereit, das das Write-Ahead-Log (WAL) in einen Strom von Zeilenänderungen verwandelt. Dafür braucht es wal_level = logical, ein Output-Plugin und einen Replication Slot. Der Debezium PostgreSQL Connector nutzt das Standard-Plugin pgoutput, das ab PostgreSQL 10 mitgeliefert wird. Beim ersten Start erstellt er einen konsistenten Snapshot der Tabellen und streamt dann jedes bestätigte Insert, Update und Delete, standardmäßig in ein Kafka-Topic pro Tabelle mit dem Namen topicPrefix.schemaName.tableName.

Der Replication Slot ist der Teil, der beißt. Die PostgreSQL-Dokumentation erklärt, dass ein Slot verhindert, dass WAL entfernt wird, das sein Konsument noch braucht, selbst wenn nichts verbunden ist. Steht der Connector ein Wochenende lang still, wächst das WAL auf dem Primary weiter. Die Einstellung max_slot_wal_keep_size begrenzt, wie viel WAL Slots vorhalten dürfen; ihr Standardwert -1 bedeutet keine Grenze. Eine Grenze schützt die Datenbank, kostet aber die Invalidierung des Slots, also einen neuen Snapshot. So oder so: Überwache die Verzögerung des Slots und zeichne den Slot ins Diagramm.

Lake-Schichten und das Warehouse

Sind die Änderungen in Kafka, schreibt ein Sink sie in einen Speicher, und Transformationen machen sie nutzbar. Databricks hat die Medallion-Architektur zur Benennung der Stufen bekannt gemacht:

• Bronze hält die Rohdaten, wie sie ankamen, mit Lade-Metadaten, sodass du ohne erneutes Lesen der Quelle neu verarbeiten kannst.
• Silver hält bereinigte, deduplizierte und vereinheitlichte Datensätze: eine aktuelle Zeile pro Bestellung, einheitliche Typen und Schlüssel.
• Gold hält fachliche Tabellen und Aggregate, die Dashboards und Modelle lesen.

Wo jede Schicht liegt, ist eine Designentscheidung: in Object Storage mit einem offenen Tabellenformat wie Apache Iceberg oder im Warehouse selbst. Zeichne, wo sie tatsächlich liegt, denn das entscheidet über Kosten, Zugriffskontrolle und darüber, wer sie abfragen kann.

Orchestrierung und Verträge

Transformationen von Bronze nach Gold laufen nach Zeitplan oder wenn neue Daten eintreffen, gesteuert von einem Orchestrator wie Airflow oder Dagster, oft mit SQL-Modellen in dbt. Zwei Dinge machen den Unterschied zwischen einer Pipeline und einer Belastung:

• Verträge. Die Schemas der Änderungsereignisse sind mit Kompatibilitätsregeln in einer Schema Registry registriert, sodass eine inkompatible Änderung an der Quelltabelle laut beim Produzenten scheitert statt leise in einem Report.
• Prüfungen. Aktualitäts-, Zeilenanzahl-, Eindeutigkeits- und Null-Prüfungen laufen nach jedem Schritt, und ein Fehlschlag alarmiert die verantwortliche Person, bevor das Dashboard falsch ist.

Das Beispiel: ein Onlineshop

Die PostgreSQL-Datenbank des Shops hält Bestellungen, Zahlungen und Kunden. Debezium läuft in Kafka Connect, liest das WAL über einen Replication Slot und veröffentlicht shop.public.orders, shop.public.payments und shop.public.customers. Ein Sink Connector hängt die Änderungsereignisse an Bronze-Tabellen an. Alle 15 Minuten führt der Orchestrator dbt-Modelle aus, die Silver und Gold bauen, und anschließend die Datenprüfungen. Dashboards lesen Gold.

So liest du es:

• Obere Reihe, Erfassung. Änderungen verlassen PostgreSQL über den Replication Slot, werden in Debezium, das ihre Schemas registriert, zu Änderungsereignissen und laufen über ein Kafka-Topic pro Tabelle zum Sink Connector.
• Untere Reihe, Speicher, von rechts nach links. Der Sink hängt Rohänderungen an Bronze an. Transformationen führen sie in Silver zusammen und aggregieren Silver zu Gold, das die Dashboards abfragen.
• Darunter, Steuerung. Der Orchestrator führt die Transformationen und die Prüfungen aus; eine fehlgeschlagene Prüfung löst einen Alert aus.
• Der Markdown-Block listet die Betriebsregeln für den Slot und für Schemaänderungen.

Was du beschriften solltest

• Den Slot und sein Limit an der ersten Kante, und wer alarmiert wird, wenn er hinterherhinkt.
• Topic-Namen oder eine Namensregel, damit Konsumenten wissen, was sie abonnieren.
• Zeitpläne und Aktualitätsziele an Transformationskanten, etwa „alle 15 Min., höchstens 30 Min. alt“.
• Aufbewahrung pro Schicht. Bronze hält Historie oft am längsten; es ist dein Replay-Puffer.
• Verantwortliche für jede Schicht und jede Prüfung.
• Personenbezogene Daten. Markiere, wo sie gespeichert und wo sie maskiert oder verworfen werden; siehe das DSGVO-Datenmapping-Diagramm.

Häufige Fehler

• Ein einziger Pfeil von der Datenbank zum Warehouse. Er verbirgt den Slot, die Schemas und jede Stelle, an der Daten verloren gehen oder sich verspäten können.
• Analyseabfragen auf dem Primary. Batch-Extrakte gegen den produktiven Primary konkurrieren mit dem Kundentraffic; nutze CDC oder ein Replikat und zeichne, welches.
• Kein Replay-Pfad. Wird Bronze nicht aufbewahrt, bedeutet ein Fehler in einer Transformation, die Quelle erneut zu lesen.
• Rohtabellen als öffentliche Schnittstelle. Konsumenten, die Änderungsereignisse interner Tabellen lesen, brechen, wenn sich das Schema ändert. Veröffentliche für Events, die für andere Teams gedacht sind, entworfene Events; das Event-driven-Architekturdiagramm behandelt diese Seite.
• Prüfungen, die nur loggen. Ein Test, der fehlschlägt, ohne jemanden zu alarmieren, ist ein Kommentar.

Für die Datenbankseite desselben Systems siehe das Datenbank-Replikationsdiagramm und das ER-Diagramm-Beispiel.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Daten-Pack einen Postgres-Node für die Quelldatenbank und einen Kafka-Node für die Topics hinzu.
3. Füge aus dem C4-Modell-Pack Container-Nodes für Debezium, die Schema Registry, den Sink Connector und die Dashboards hinzu.
4. Füge aus dem Basis-Pack einen Rahmen namens Lake and warehouse hinzu, darin aus dem Daten-Pack zwei Objektablage-Nodes für Bronze und Silver und ein Datenlager für Gold.
5. Füge aus dem DevOps-Pack eine CI/CD-Pipeline für den Orchestrator und einen Alarm für die Datenprüfungen hinzu. Zeichne Steuerungskanten gestrichelt.
6. Füge aus dem Basis-Pack einen Markdown-Block mit den Regeln für Slot und Schemas hinzu.

Das Beispiel nutzt 13 Diagramm-Nodes und bleibt damit im Free-Plan. Wenn du das Quellschema als SQL vorliegen hast, zeichnet das Tool PostgreSQL zu ER-Diagramm die Tabellen hinter den Topics.

FAQ

Ist CDC besser als Batch-Extrakte? Bei Aktualität, Löschungen und Last auf der Quelle meistens ja. Batch ist einfacher zu betreiben und reicht, wenn Stunden Verzögerung akzeptabel sind und Zeilen nie hart gelöscht werden.

Brauche ich Kafka für CDC? Debezium läuft meist auf Kafka Connect, und Kafka bietet dir Replay und viele Konsumenten. Es gibt andere Setups; zeichne den Transport, den du tatsächlich betreibst, und seine Aufbewahrung.

Wie gehe ich mit Schemaänderungen um? Registriere Schemas mit Kompatibilitätsregeln, füge Spalten hinzu, statt sie zu ändern, und mach die nachgelagerten Modelle tolerant gegenüber neuen Spalten. Zeichne die Registry, denn dort lebt der Vertrag.

Wo sollten Datenqualitätsprüfungen laufen? Nach jeder Schicht, als Teil des orchestrierten Laufs, mit Alerts an die Verantwortlichen. Aktualitätsprüfungen auf Gold fangen die meisten stillen Fehler.

Wie halte ich das Pipeline-Diagramm aktuell? Ändere es im selben Pull Request wie die Konfiguration von Connector und Orchestrator; siehe Architekturdiagramme, die nicht veralten.

Kostenlos starten — ein Seat, keine Kreditkarte.