Was ist eine Datenpipeline-Architektur?

Die Datenpipeline-Architektur ist das End-to-End-Design dafür, wie Daten erfasst, verarbeitet, gespeichert und von Quellsystemen an die Personen, Anwendungen und Modelle geliefert werden, die sie nutzen. Das Wort „Architektur“ bezieht sich auf den Entwurf (Blueprint), nicht auf die Pipeline selbst. Sie umfasst die Entscheidungen darüber, wie Daten fließen, wo sie transformiert werden und welche Tools die einzelnen Schritte auf dem Weg übernehmen.

Eine gute Architektur ist auf den jeweiligen Anwendungsfall abgestimmt und wird nicht einfach von der Stange genommen. Eine für die Betrugserkennung in Echtzeit entwickelte Datenpipeline sieht ganz anders aus als eine Pipeline, die einen nächtlichen Umsatzbericht erstellt, obwohl beide Daten von der Quelle zum Ziel bewegen. Diese Glossarseite beschreibt die Kernschichten, die jede Pipeline gemeinsam hat, die gängigen Phasenmodelle, die wichtigsten Architekturmuster und die Best Practices, die dafür sorgen, dass Pipelines auch bei Skalierung zuverlässig bleiben.

Wie funktioniert eine Datenpipeline-Architektur?

Eine Datenpipeline bewegt Daten durch eine Reihe von Phasen, und jede Phase hat eine bestimmte Aufgabe: Daten erfassen, bereinigen, speichern und nutzbar machen. Die Architektur ist der Plan, wie diese Phasen miteinander verbunden sind. Sie definiert, was mit den Daten bei jedem Schritt, in welcher Reihenfolge und unter welchen Regeln geschieht.

Architekturentscheidungen werden auf zwei Ebenen getroffen. Das logische Design definiert, welche Phasen existieren und was jede einzelne tut: Das ist das „Was“. Das physische Design definiert, welche spezifischen Tools und Infrastrukturen die einzelnen Phasen ausführen: Das ist das „Wie“. Die Orchestrierung (die automatische Planung und Koordinierung jedes Schritts) und das Monitoring gehören zu keiner einzelnen Phase. Sie laufen über die gesamte Pipeline hinweg. Moderne Plattformen haben zudem eine alte Trennung aufgehoben. Mit Lakeflow vereint Databricks Batch- und Streaming-Pipelines auf einer einzigen Basis, sodass Teams nicht zwei parallele Systeme aufbauen und warten müssen.

Die Kernschichten einer Datenpipeline

Unabhängig von dem Muster, für das sich ein Team entscheidet, basiert jede Datenpipeline auf denselben vier Schichten. Jede Schicht beantwortet eine andere Frage zu den Daten: Wie sie hineingelangen, wie sie nützlich werden, wo sie liegen und wer sie nutzt.

Ingestion

Die Ingestion zieht Daten aus Quellsystemen in die Pipeline: Datenbanken, Anwendungen, APIs, Dateien im Cloud-Speicher, Event-Streams und Sensoren. Die Daten-Ingestion gibt es in zwei Varianten. Die Batch-Ingestion ruft Daten nach einem Zeitplan ab, beispielsweise jede Stunde oder jede Nacht. Die Streaming-Ingestion erfasst Daten kontinuierlich, sobald Ereignisse eintreffen. Viele Pipelines nutzen auch Change Data Capture (CDC), eine Methode, die Änderungen auf Zeilenebene in einer Quelldatenbank verfolgt, sodass die Pipeline nur neue oder aktualisierte Daten überträgt, anstatt alles neu zu laden.

Verarbeitung und Transformation

In dieser Schicht werden Rohdaten bereinigt, umstrukturiert, angereichert und für die Nutzung vorbereitet. Zu den typischen Aufgaben gehören das Beheben fehlender Werte, das Standardisieren von Formaten, das Zusammenführen von Datensätzen und das Anwenden von Geschäftslogik – dieselben Aufgaben, die das Herzstück von ETL bilden. Die Verarbeitung folgt derselben Aufteilung wie die Ingestion. Die Batch-Verarbeitung verarbeitet große Datenmengen gemeinsam, während die Stream-Verarbeitung Datensätze einzeln oder in winzigen Micro-Batches verarbeitet, sobald sie eintreffen.

Speicherung

Im Storage (Speicher) landen die verarbeiteten Daten, damit sie abgefragt, analysiert oder in Modelle eingespeist werden können. Das Ziel ist in der Regel ein Data Lake, ein Data Warehouse oder ein Lakehouse – ein einziges System, das die Stärken von beiden vereint. Das Format ist ebenso wichtig wie der Speicherort. Offene Formate wie Lakehouse Storage und Apache Iceberg ermöglichen es mehreren Tools, dieselben Daten zu lesen, ohne sie von System zu System kopieren zu müssen. Delta Lake bietet zudem Zuverlässigkeitsfunktionen wie ACID-Transaktionen (eine Garantie, dass Schreibvorgänge entweder vollständig erfolgreich sind oder vollständig fehlschlagen, was Datenkorruption verhindert) und Time Travel (die Möglichkeit, ältere Versionen einer Tabelle abzufragen).

Bereitstellung und Nutzung

Die letzte Schicht liefert die vorbereiteten Daten an die Personen und Systeme, die sie benötigen: Analysten, die SQL-Abfragen ausführen, geschäftliche Anwender, die mit Dashboards arbeiten, Data Scientists, die Modelle trainieren, und Anwendungen, die APIs aufrufen. Die Ziele reichen von BI-Tools über ML-Plattformen bis hin zu operativen Systemen, wobei ein Data Warehouse oft im Mittelpunkt von Analytics-Workloads steht. Über alle vier Schichten hinweg übernehmen Orchestrierung und Observability die verbindende Arbeit: Sie planen Jobs, verfolgen die Datenqualität und schlagen Alarm, wenn etwas fehlschlägt.

Aus wie vielen Phasen besteht eine Datenpipeline? (3 vs. 4 vs. 5)

Verschiedene Quellen beschreiben Datenpipelines mit drei, vier oder fünf Phasen, was oft zu Verwirrung führt. Die Realität ist einfacher. Alle drei Modelle beschreiben dieselbe zugrunde liegende Arbeit auf unterschiedlichen Detailebenen.

Die Anzahl der Phasen ist lediglich eine Frage der Benennung. Die Arbeit, die die Pipeline verrichtet, bleibt dieselbe.

Gängige Architekturmuster für Datenpipelines

Architekturmuster sind die etablierten Designs, aus denen Teams beim Erstellen von Pipelines wählen können. Das richtige Muster hängt von den Latenzanforderungen, dem Datenvolumen und der nachgelagerten Nutzung der Daten ab.

Batch-Architektur

Die Batch-Architektur verarbeitet Daten in geplanten Blöcken: jede Stunde, jede Nacht oder jede Woche. Sie eignet sich für das Reporting, historische Analysen, ML-Trainingsdaten und alle Anwendungsfälle, bei denen Verzögerungen von Minuten oder Stunden akzeptabel sind. Batch-Pipelines sind einfacher zu erstellen, kostengünstiger im Betrieb und leichter zu debuggen als ihre Streaming-Pendants. Der Kompromiss liegt in der Aktualität. Wenn Entscheidungen von Ereignissen abhängen, die vor wenigen Sekunden stattgefunden haben, kann Batch nicht mithalten.

Streaming-Architektur

Die Streaming-Architektur verarbeitet Daten kontinuierlich, Datensatz für Datensatz, sobald sie generiert werden. Sie eignet sich für Anwendungsfälle, bei denen es auf Reaktionen im Sekundenbereich ankommt: Betrugserkennung, Echtzeit-Personalisierung und IoT-Überwachung. Der Kompromiss sind die Kosten. Streaming-Pipelines sind im Betrieb in der Regel teurer als Batch-Pipelines, da sie eine Always-on-Infrastruktur erfordern.

Lambda-Architektur

Die Lambda-Architektur nutzt zwei parallele Pfade. Ein Batch-Pfad liefert präzise historische Daten, ein Streaming-Pfad liefert schnelle, aktuelle Daten, und ein Serving-Layer führt die Ergebnisse zusammen. Das Design funktioniert, bringt jedoch einen bekannten Nachteil mit sich: Die Wartung von zwei Pipelines bedeutet doppelten Code, doppelte Logik und den doppelten Betriebsaufwand.

Kappa-Architektur

Die Kappa-Architektur vereinfacht Lambda, indem sie eine einzige Streaming-Pipeline für alles nutzt. Wenn eine historische Analyse erforderlich ist, wird der Stream von Anfang an erneut abgespielt. Kappa eignet sich für Teams, die Aktualität auf Streaming-Niveau wünschen, ohne die Kosten für die Wartung zweier paralleler Systeme tragen zu müssen.

Medallion-Architektur (Lakehouse-Muster)

Medallion-Architektur ist ein beliebtes Muster auf Lakehouse-Plattformen, das Daten in drei Qualitätsstufen organisiert: Bronze (roh, wie eingelesen), Silber (bereinigt und angepasst) und Gold (aufbereitet, bereit für geschäftliche Analysen). Wie es in der Databricks-Dokumentation heißt: „Die Medallion-Architektur verwendet drei Schichten: Bronze, Silber und Gold, die jeweils einen bestimmten Zweck in der Pipeline erfüllen.“ Jede Stufe kann als eigene Pipeline ausgeführt werden, was die Planung, Überwachung und Fehlerbehebung erleichtert, da Probleme auf eine einzelne Schicht beschränkt bleiben.

ETL vs. ELT: Wie die Reihenfolge der Transformation die Architektur prägt

ETL und ELT unterscheiden sich darin, wann Daten transformiert werden. ETL (Extract, Transform, Load) transformiert Daten, bevor sie in den Speicher geladen werden. ELT (Extract, Load, Transform) lädt zuerst Rohdaten und transformiert sie im Zielsystem. Moderne Cloud-Plattformen wie Databricks, Snowflake und BigQuery haben ELT zum dominierenden Muster gemacht, da Cloud-Speicher und -Compute mittlerweile kostengünstig und elastisch genug sind, um Daten direkt vor Ort zu transformieren. Einen detaillierteren Vergleich finden Sie unter ETL vs. ELT.

Ist ETL dasselbe wie eine Datenpipeline?

Nein. ETL ist eine Art von Datenpipeline, aber nicht jede Datenpipeline ist ETL. Eine Datenpipeline ist die übergeordnete Kategorie: jedes System, das Daten von einem Ort an einen anderen verschiebt. ETL ist ein spezifischer Ansatz innerhalb dieser Kategorie, der sich dadurch definiert, dass Daten transformiert werden, bevor sie im Speicher abgelegt werden. Pipelines können auch ELT, Streaming, reine Replikation (Verschieben von Daten ohne jegliche Transformation) oder Reverse ETL (Senden von Warehouse-Daten zurück in operative Systeme) sein.

Best Practices für die Datenpipeline-Architektur

Diese 10 Designprinzipien unterscheiden Pipelines, die skalieren, von Pipelines, die fehlschlagen.

1. Ingestion von Transformation trennen. Halten Sie die Rohdatenerfassung und die Datenbereinigung in verschiedenen Phasen, damit Probleme in einer Phase nicht auf die andere übergreifen.
2. Auf Idempotenz auslegen. Eine Pipeline sollte sicher erneut ausgeführt werden können, ohne doppelte Datensätze zu erstellen oder Ergebnisse zu verfälschen. Dies ist entscheidend für den Umgang mit Fehlern und Backfills.
3. Datenqualitätsprüfungen integrieren. Strikte Datenqualitätsprüfungen validieren Schema, Wertebereiche, Null-Werte-Anzahl und Aktualität in jeder Phase. Sie schlagen sofort Alarm, wenn etwas nicht stimmt, anstatt fehlerhafte Daten weiterzugeben.
4. Schema-Drift einplanen. Quellsysteme ändern sich. Pipelines sollten erkennen, wenn Spalten hinzugefügt, entfernt oder umbenannt werden, und diese Änderung reibungslos verarbeiten, anstatt abzustürzen.
5. Offene Speicherformate verwenden. Formate wie Delta Lake und Apache Iceberg verhindern einen Vendor Lock-in und ermöglichen es mehreren Tools, dieselben Daten ohne Kopien zu lesen.
6. Pipeline-Ebenen entkoppeln. Die Aufteilung der Medallion-Ebenen (Bronze, Silber und Gold) in separate Pipelines erleichtert die unabhängige Planung, Überwachung und Fehlerbehebung für jede einzelne Ebene.
7. Alles versionieren. Speichern Sie Pipeline-Code und -Konfiguration in Git, damit Änderungen überprüft, nachverfolgt und rückgängig gemacht werden können.
8. Governance als oberste Priorität behandeln. Wenden Sie mit einem Tool wie Unity Catalog in jeder Phase konsistente Berechtigungen, Lineage-Tracking und Audit-Kontrollen an, anstatt diese erst am Ende hinzuzufügen.
9. Streaming vs. Batch richtig dimensionieren. Nutzen Sie Streaming nur dort, wo Aktualität wirklich eine Rolle spielt, und verwenden Sie standardmäßig Batch-Verarbeitung, um die Kosten zu kontrollieren.
10. End-to-End-Überwachung implementieren. Verfolgen Sie Datenaktualität, -volumen, -qualität und Pipeline-Laufzeiten, damit Probleme erkannt werden, bevor nachgelagerte Benutzer sie bemerken.

Warum die Datenpipeline-Architektur wichtig ist

Die Pipeline-Architektur entscheidet darüber, ob Teams ihren Daten vertrauen können, ob Entscheidungen auf aktuellen Informationen basieren und ob KI- und ML-Projekte den Sprung vom Prototyp in die Produktion schaffen. Sie macht den Unterschied zwischen einer Datenplattform, deren Wert kontinuierlich steigt, und einer, die ständig Support-Tickets generiert.

Eine instabile Architektur verursacht reale Kosten: veraltete Dashboards, widersprüchliche Metriken, fehlgeschlagene ML-Bereitstellungen und Data Engineers, die mehr Zeit mit der Brandbekämpfung als mit der Entwicklung verbringen. Der moderne Lakehouse-Ansatz packt das Problem an der Wurzel. Durch die Zusammenführung von Batch und Streaming, Analytics und KI sowie Governance auf einer einzigen Plattform wie der Databricks-Plattform eliminieren Teams die fehleranfälligen Übergaben zwischen Systemen, an denen traditionelle Architekturen scheitern.

Datenpipeline-Architektur auf Databricks

Databricks bietet jede Ebene der Pipeline-Architektur auf einer einzigen Plattform. Lakeflow Connect übernimmt die Ingestion aus Datenbanken, SaaS-Anwendungen, Dateiquellen und Event-Streams. Lakeflow Spark Declarative Pipelines erstellt Batch- und Streaming-ETL-Pipelines mit integrierten Datenqualitätsprüfungen, und Lakeflow Jobs orchestriert und plant Pipeline-Ausführungen auf der gesamten Plattform. Darunter bietet Delta Lake das offene Speicherformat zusammen mit Zuverlässigkeitsfunktionen wie ACID-Transaktionen und Time Travel, während Unity Catalog Governance, Lineage und Zugriffskontrolle über alle Phasen hinweg anwendet.

Da Batch- und Streaming-Pipelines auf derselben Engine ausgeführt werden und in denselben Speicher schreiben, müssen Teams keine parallelen Systeme im Lambda-Stil warten. Eine einzige Pipeline-Definition kann sowohl den nächtlichen Bericht als auch das Echtzeit-Dashboard bedienen.

Häufig gestellte Fragen

Was ist eine Datenpipeline-Architektur in einfachen Worten?

Es ist der Plan, wie Daten von ihrem Entstehungsort dorthin gelangen, wo sie nützlich sind. Der Plan umfasst, wie Daten erfasst, bereinigt und vorbereitet werden, wo sie gespeichert werden und wie sie an die Personen und Anwendungen geliefert werden, die sie benötigen.

Was ist der Unterschied zwischen Lambda- und Kappa-Architektur?

Lambda führt zwei parallele Pipelines aus – eine für Batch und eine für Streaming – und führt deren Ergebnisse in einem Serving Layer zusammen. Kappa verwendet eine einzige Streaming-Pipeline für alles und spielt den Stream erneut ab, wenn eine historische Analyse erforderlich ist. Kappa ist einfacher zu betreiben, während Lambda in Umgebungen fortbesteht, in denen sich Batch- und Streaming-Pfade separat entwickelt haben.

Wann sollte man Batch- und wann Streaming-Pipelines verwenden?

Nutzen Sie Streaming, wenn der Wert von Daten innerhalb von Sekunden oder Minuten sinkt, wie z. B. bei der Betrugserkennung, der Live-Personalisierung oder der Geräteüberwachung. Verwenden Sie Batch-Verarbeitung für alles andere, einschließlich Berichterstattung, historischer Analysen und ML-Trainingsdaten. Batch ist einfacher und kostengünstiger, weshalb es der sinnvolle Standard ist, bis ein Anwendungsfall zeigt, dass Echtzeitdaten erforderlich sind.

Was ist der Unterschied zwischen logischer und physischer Pipeline-Architektur?

Die logische Architektur definiert die Phasen einer Pipeline und deren jeweilige Funktion, unabhängig von bestimmten Tools. Die physische Architektur ordnet diese Phasen bestimmten Technologien und Infrastrukturen zu. Teams legen in der Regel zuerst das logische Design fest und wählen dann die Plattformen aus, die es implementieren.

Passen Sie Ihre Architektur an die jeweilige Aufgabe an

Die Datenpipeline-Architektur ist das Design dahinter, wie sich Daten bewegen und nützlich werden. Die richtige Architektur ist diejenige, die Aktualität, Kosten und Zuverlässigkeit für die jeweilige Aufgabe in Einklang bringt – sei es ein nächtlicher Verkaufsbericht oder eine Betrugsprüfung, die in Millisekunden abläuft.

Erfahren Sie, wie Databricks Batch- und Streaming-Pipelines, Speicher und Governance auf einer Plattform vereint.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag