Data-Pipeline-Architektur: Komponenten, Typen und Aufbau

Wichtigste Erkenntnisse

• Eine Data Pipeline bewegt Daten von einer oder mehreren Quellen zu einem Ziel und wendet dabei Transformationen an.
• Die Hauptkomponenten sind Ingestion, Verarbeitung, Speicherung und Auslieferung.
• Batch-, Streaming- und Hybrid-Pipelines sind die drei Kerntypen, jeder mit unterschiedlichen Kompromissen.
• Die meisten Pipeline-Fehler gehen auf schlechte Datenqualität, starre Zuordnungen oder fehlende Fehlerbehandlung zurück.
• MDM und Pipeline-Design müssen zusammen geplant werden: Pipelines transportieren Daten, aber Master-Data-Management stellt sicher, dass sie in jedem System dasselbe bedeuten.
• AtroCore bietet eine konfigurierbare, Open-Source-Grundlage für den Aufbau automatisierter Data Pipelines zwischen ERP, E-Commerce, PIM und anderen Geschäftssystemen.

Was eine Data Pipeline wirklich ist

Eine Data Pipeline ist eine Reihe automatisierter Schritte, die Daten von einer Quelle zu einem Ziel bewegen. Zwischen diesen beiden Punkten werden die Daten extrahiert, transformiert, validiert und geladen. Die Pipeline verwaltet die technischen Abläufe, damit das Zielsystem saubere, strukturierte und nutzbare Daten ohne manuelle Eingriffe erhält.

In der Praxis führen die meisten Unternehmen mehrere Pipelines parallel aus. Eine zieht Bestellungen von einer E-Commerce-Plattform in ein ERP. Eine andere synchronisiert Produktdaten von einem PIM zu einem Webshop. Eine dritte übermittelt Bestandsaktualisierungen an einen Fulfillment-Partner. Jede davon ist eine Pipeline, und jede muss zuverlässig, planmäßig und im richtigen Format für das Zielsystem laufen.

Der Begriff „Data Pipeline" wird manchmal synonym mit ETL (Extract, Transform, Load) oder ELT (Extract, Load, Transform) verwendet. Dies sind spezifische Implementierungsmuster innerhalb des breiteren Konzepts. ETL transformiert Daten vor dem Laden in das Ziel, typischerweise ein Data Warehouse oder eine operative Datenbank. ELT lädt Rohdaten zuerst in einen Data Lake oder Cloud Warehouse, führt dann Transformationen innerhalb des Ziels mit eigener Rechenleistung aus. Beide Muster beschreiben Pipelines, aber nicht alle Pipelines folgen entweder Muster strikt. Ein Datenfluss, der Datensätze von einem ERP zu einem Webshop über geplanten Dateiexport bewegt, ist auch eine Data Pipeline, selbst wenn er nie ein Warehouse berührt oder SQL ausführt.

Kernkomponenten einer Data Pipeline

Jede Pipeline, unabhängig von Typ oder Komplexität, hat die gleiche grundlegende Struktur.

Ingestion

Der Einstiegspunkt. Daten kommen aus einer oder mehreren Quellen an: Datenbanken, APIs, Dateien, Message Queues oder Benutzereingaben. Source Connectors behandeln die Besonderheiten jedes Systems: Authentifizierung, Verbindungsverwaltung und initiale Datenerfassung. Für Systeme, die eine REST API verfügbar machen, sendet die Ingestion-Schicht HTTP-Anfragen und verwaltet Pagination und Rate Limits. Für dateibasierte Quellen überwacht sie Verzeichnisse oder FTP-Endpunkte auf neue Daten. Ihre Zuverlässigkeit bestimmt direkt alles, was nachgelagert passiert.

Verarbeitung

Hier finden Transformationen statt. In einer ETL-Pipeline ist dies der aufwändigste Schritt: Rohdaten aus der Quelle entsprechen selten dem Schema, das das Ziel erwartet. Feldnamen unterscheiden sich. Datumsformate sind inkonsistent. Einige Werte müssen aus anderen berechnet werden. Die Verarbeitungsschicht wendet Zuordnungsregeln, Datentypkonvertierungen, Deduplizierungslogik und Validierungsprüfungen an. Hier tauchen auch Fehler auf, daher muss die Verarbeitungsschicht klare Regeln haben für den Fall, dass ein Datensatz die Validierung nicht besteht: ablehnen, kennzeichnen, unter Quarantäne stellen oder mit einer Warnung durchlassen.

Speicherung

Die Speicherung befindet sich zwischen Ingestion und Auslieferung für Pipelines, die es brauchen. Nicht jede Pipeline schreibt in zwischengelagerte Speicherung, aber Batch-Pipelines typischerweise schon. Daten landen in einem Staging-Bereich, werden verarbeitet und bewegen sich dann zum Ziel. Die Staging-Schicht ermöglicht auch Neuerarbeitung: Wenn sich eine Transformationsregel ändert, können Sie die Pipeline gegen gespeicherte Rohdaten erneut ausführen, ohne aus der Quelle neu zu ingestionieren.

Auslieferung

Die Ausgabeschicht. Daten gelangen zum Ziel im erwarteten Format: ein Datenbankinsert, ein API-Aufruf, ein Dateiexport oder eine an eine Queue gesendete Nachricht. Die Auslieferungsschicht verwaltet Bestätigungen und Wiederholungslogik. Wenn das Ziel einen Fehler zurückgibt, entscheidet die Pipeline, ob sofort wiederholt, mit Backoff wiederholt oder der Fehler protokolliert und ein Operator benachrichtigt wird.

Monitoring, Orchestrierung und Lineage

Eine Pipeline, die stillschweigend läuft und stillschweigend fehlschlägt, ist schlimmer als eine, die gar nicht läuft. Jede Produktions-Pipeline benötigt Event-Logs, Fehlerzählungen, Latenz-Metriken und Warnungen, wenn Schwellenwerte überschritten werden. Diese breitere Fähigkeit wird Pipeline-Observability genannt: nicht nur zu wissen, ob die Pipeline lief, sondern ob die Daten, die sie produzierte, korrekt und vollständig sind.

Pipeline-Orchestrierung sitzt über all dem. Sie verwaltet Task-Sequenzierung, Planung, Abhängigkeitsauflösung und Wiederholungsverhalten über den gesamten Datenfluss. Einfache Pipelines können sich auf Cron-basierte Planung verlassen. Komplexere mit verzweigter Logik oder systemübergreifenden Abhängigkeiten benötigen eine dedizierte Orchestrierungsschicht, die den Status jedes Durchlaufs verfolgt und Fehler ohne manuelle Intervention behebt.

Data Lineage ist der Datensatz darüber, woher jedes Datenelement kam, welche Transformationen es durchlaufen hat und wo es landete. Es ist eine Governance-Anforderung, aber auch ein operatives Werkzeug. Wenn ein nachgelagerter Bericht falsche Zahlen zeigt, ist Lineage, wie Sie das Problem bis zur Quelle zurückverfolgen. Wenn sich ein Quellschema ändert, sagt Ihnen Lineage, welche Pipelines und Ziele betroffen sind, bevor Sie die Änderung pushen.

Pipeline-Typen und wann jeder sinnvoll ist

Batch Pipelines

Batch Pipelines sammeln Daten über einen Zeitraum und verarbeiten sie in Massen in geplanten Intervallen: stündlich, nächtlich, wöchentlich. Sie sind einfacher zu bauen und leichter zu debuggen als echtzeitbasierte Alternativen. Die meisten Geschäftsdatenintegrationsszenarios passen gut zu Batch-Verarbeitung. Preisaktualisierungen, Produktdatensynchronisierung, Bestellexporte und Bestandsabstimmungen tolerieren alle eine Verzögerung von Minuten oder Stunden.

Der Nachteil ist, dass die Aktualität an das Batch-Intervall gebunden ist. Wenn sich ein Produktpreis ändert und die nächste Batch in sechs Stunden läuft, zeigt der Webshop für sechs Stunden den alten Preis. Für viele Anwendungsfälle ist das akzeptabel. Für andere nicht.

Streaming Pipelines

Streaming Pipelines verarbeiten Daten kontinuierlich, wenn sie ankommen, Ereignis für Ereignis. Die Latenz fällt auf Sekunden oder Millisekunden. Anwendungsfälle, die dies wirklich erfordern, sind Betrugserkennung, echtzeitliche Bestandsverfolgung über mehrere Lager hinweg und Live-Pricing-Engines.

Streaming Pipelines sind deutlich schwieriger aufzubauen und zu betreiben als Batch Pipelines. Sie erfordern Infrastruktur, die außer Reihenfolge gelandete Ereignisse verwaltet, Zustandsverwaltung über einen Stream und Fehlertoleranz unter hohem Durchsatz. Sofern der geschäftliche Fall nicht wirklich eine Datenfresh-Rate unter einer Minute verlangt, ist die zusätzliche Komplexität schwer zu rechtfertigen.

Hybrid Pipelines

Hybrid-Architekturen führen Streaming-Ingestion aber Batch-Verarbeitung durch. Daten kommen kontinuierlich an und werden in einem Buffer oder einer Queue gespeichert. Die Verarbeitung läuft auf diesem Buffer in Intervallen oder in Micro-Batches alle paar Sekunden. Micro-Batch-Verarbeitung ist ein praktischer Mittelweg: Sie erhalten deutlich frischere Daten als eine nächtliche Batch ohne die volle operative Komplexität von echtem Streaming. Die meisten Plattformen, die „nahezu echtzeitlich" werben, führen tatsächlich Micro-Batches durch.

Lambda-Architektur ist ein bekanntes Hybrid-Muster, das separate Batch- und Streaming-Schichten mit einer Serving-Schicht aufrechterhält, die Outputs zusammenführt. Es ist leistungsstark, aber komplex zu warten, da die gleiche Transformationslogik zweimal implementiert werden muss. Kappa-Architektur vereinfacht dies, indem sie alles als Stream behandelt, einschließlich historischer Neuerarbeitung.

Ein verwandtes Muster, das es wert ist, bekannt zu sein, ist Change Data Capture (CDC). Anstatt einen vollständigen Datensatz auf jedem Durchlauf zu extrahieren, überwacht CDC das Transaktionsprotokoll des Quellsystems und erfasst nur die Zeilen, die sich seit dem letzten Durchlauf geändert haben. Dies reduziert die Belastung von Quellsystemen dramatisch und ermöglicht kontinuierliche, latenzarme Datenintegration ohne vollständige Streaming-Infrastruktur. Für Hersteller mit ERP-Systemen mit hohem Transaktionsvolumen ist CDC oft der praktischste Weg zu nahezu echtzeitlichen Daten, ohne die gesamte Integrationschicht neu aufzubauen.

Für die meisten mittelständischen Fertigungs- oder Distributionsunternehmen deckt eine gut gebaute Batch-Pipeline mit kurzen Intervallen 90 % der Integrationsbedürfnisse ab.

Wo Data Pipelines fehlschlagen

Schema Drift ist die häufigste Ursache. Ein Quellsystem aktualisiert seine API-Antwort und fügt Felder hinzu, benennt sie um oder entfernt sie. Die Zuordnungslogik der Pipeline, gegen das alte Schema geschrieben, bricht entweder zusammen oder leitet stillschweigend falsche Daten durch. Pipelines benötigen Schema-Validierung bei der Ingestion, damit Änderungen erfasst werden, bevor sie das Ziel beschädigen. Data Lineage hilft hier auch: Zu wissen, welche Pipelines von einem bestimmten Quellfeld abhängen, bedeutet, dass Sie den Auswirkungsbereich einer Schemaänderung beurteilen können, bevor sie die Produktion erreicht.

Datenqualitätsprobleme sammeln sich nachgelagert an. Null-Werte, wo das Ziel ein erforderliches Feld erwartet. Text in einer numerischen Spalte. Doppelte Datensätze, weil das Quellsystem sie erlaubt. Die Verarbeitungsschicht muss diese explizit handhaben, nicht durchlassen und das Ziel damit umgehen lassen.

Enge Kopplung ist das dritte Problem. Wenn Pipeline-Logik gegen die spezifischen Feldnamen, Datentypen oder API-Struktur eines Systems geschrieben wird, bricht die Pipeline bei jeder Änderung dieses Systems. Konfigurierbare Zuordnungsschichten beheben dies. Transformationsregeln, die als Konfiguration und nicht als Code gespeichert werden, können aktualisiert werden, ohne die Pipeline selbst zu berühren.

Damit verbunden sind fehlende Fehlerbehandlung und Wiederholungslogik, die vorübergehende Fehler in Datenverlust verwandeln. Netzwerke fallen aus. APIs zeitlich ab. Zielsysteme gehen zur Wartung herunter. Eine Pipeline ohne Wiederholungslogik verliert Datensätze dauerhaft, wenn diese Dinge geschehen.

Damit verbunden ist Idempotenz. Wenn ein Pipeline-Schritt zweimal auf den gleichen Daten aufgrund eines Wiederholung ausgeführt wird, sollte das Ergebnis dasselbe sein wie wenn es einmal läuft. Pipelines, die nicht idempotent sind, erstellen doppelte Datensätze oder falsche Aggregate, wenn Wiederholungen ausfeuern.

Data Pipelines und Master-Data-Management

Pipeline-Architektur und Master-Data-Management (MDM) sind eng verwandt, und die Beziehung wird oft zu Beginn von Integrationsprojekten unterschätzt.

MDM ist die Disziplin der Erstellung und Pflege eines einzelnen, autoritativen Datensatzes für Kerngeschäftsentitäten: Kunden, Lieferanten, Produkte, Materialien und Standorte. Ein Master-Data-Datensatz ist die vertraute Referenz, auf die sich alle Systeme einigen.

Pipelines transportieren Daten zwischen Systemen, aber ohne verwalteten Master-Datensatz in der Mitte kann jede Pipeline ihre eigene Version derselben Entität einführen. Ein System nennt ein Produkt „Stahlhalter M6". Ein anderes nennt es „Halter, M6, Stahl". Ein drittes verwendet einen internen Code ohne Label überhaupt. Die Pipeline bewegt die Daten; MDM stellt sicher, dass sie überall, wo sie landen, dasselbe bedeuten.

In der Praxis bedeutet dies, dass MDM und Pipeline-Design zusammen geplant werden müssen. Die Transformationslogik innerhalb einer Pipeline hängt oft von einer Master-Data-Schicht ab: Zuordnung von Quellcodes zu kanonischen Identifizierern, Auflösung von Duplikaten gegen einen Golden Record und Anreicherung eingehender Datensätze mit Attributen aus einem zentralen Repository. Ohne diese Schicht wird Transformationslogik zu einem Flickenteppich von hardcodierten Lookups, der mit jedem neuen Quellsystem schwerer zu warten wird.

Für Hersteller sind die häufigsten Master-Data-Domänen, die durch Pipelines fließen, Produktdaten, Lieferantendatensätze und Stücklisten-Strukturen. Wenn Produktmaster-Daten zentral verwaltet werden und Pipelines aus dieser einzelnen Quelle ziehen, erhalten nachgelagerte Systeme (Webshops, ERPs, Beschaffungsplattformen) auf jedem Durchlauf konsistente, validierte Daten. Wenn Master-Daten über Systeme verteilt sind und Pipelines unabhängig voneinander aus jedem ziehen, nehmen Inkonsistenzen mit jedem Synchronisierungszyklus zu.

Die MDM-Schicht gehört von Anfang an in die Architektur, mit der gleichen Priorität wie die Ingestions- oder Transformationsschicht.

Aufbau einer Data Pipeline: praktische Schritte

Beginnen Sie mit einer klaren Definition von Quelle und Ziel. Definieren Sie das Quellsystem, sein Datenformat und ob es auf Zeitplan oder Trigger liefert. Definieren Sie, was das Ziel erwartet, welches Schema es benötigt und wie es falsch formatierte oder fehlende Datensätze verarbeitet.

Ordnen Sie die Transformationslogik zu, bevor Sie Code schreiben oder ein Tool konfigurieren. Jedes Feld im Zielschema benötigt eine Quelle. Jeder Mismatch in Format, Einheit oder Struktur benötigt eine Transformationsregel. Dies zuerst auf Papier zu machen bringt Probleme früh zutage und macht die tatsächliche Implementierung schneller.

Bauen Sie Fehlerbehandlung von Anfang an ein, nicht als Nachgedanke. Definieren Sie explizit, was mit Datensätzen geschieht, die Validierung nicht bestehen: Ablehnung mit Protokollierung, Quarantäne zur manuellen Überprüfung oder Durchlass mit einem Warnflag. Bauen Sie die Warnungen vor der Pipeline-Bereitstellung ein.

Testen Sie mit echten Daten, nicht mit synthetischen Daten. Synthetische Daten verpassen die Grenzfälle, die echte Daten mit sich bringt: Encoding-Probleme, leere Strings statt Null, locale-spezifische Datumsformate, Werte außerhalb erwarteter Bereiche. Führen Sie die Pipeline gegen ein Beispiel echter Quelldaten in einer Staging-Umgebung durch.

Überwachen Sie kontinuierlich nach der Bereitstellung. Verfolgen Sie Datensatzanzahl rein versus Datensätze raus. Warnen Sie bei Fehlerzahl-Schwellenwertüberschreitungen. Protokollieren Sie jeden Durchlauf mit Zeitstempeln und Zeilenzählungen. Eine Pipeline mit vollständiger Observability von Tag eins kostet fast nichts extra zu warten; eine ohne sie sammelt unsichtbare technische Schulden an, bis etwas in Produktion bricht.

Wie AtroCore Data-Pipeline-Workflows unterstützt

In unserer Erfahrung ist das wiederkehrende Problem das Tooling: benutzerdefinierte Skripte, die bei jedem Quellsystem-Update brechen, oder teure Middleware, die Vendor-Beteiligung zur Neukonfiguration benötigt. In mehreren Fällen führten Teams fünf oder mehr separate Skripte durch, um Produktdaten zwischen einem ERP, einem PIM und zwei Sales Channels zu synchronisieren, ohne Error-Logging und ohne Warnungen.

AtroCore ist eine kostenlose, Open-Source-Datenplattform mit einer eingebauten Integrationschicht. Seine Import- und Export-Module verwalten Ingestion und Auslieferung über REST APIs, FTP, DateiQuellen und Datenbanken. Zuordnungsregeln werden über die Benutzeroberfläche konfiguriert, statt hardcodiert, sodass sie wartbar bleiben, wenn vorgelagerte Systeme sich ändern. Durchläufe werden protokolliert mit Datensatzzählungen und Fehlerdetails, abdecken Pipeline-Observability ohne einen separaten Monitoring-Stack. Die Plattform verbindet sich nativ mit ERP-Systemen, einschließlich SAP, Oracle, NetSuite und Business Central, sowie mit E-Commerce-Plattformen, einschließlich Shopify und Adobe Commerce, und fungiert als zentrale Orchestrierungsschicht über alle.

Für Unternehmen, die auch MDM benötigen, verwaltet das breitere AtroCore-Datenplatform Master-Daten neben Pipeline-Ausführung in einer einzelnen Instanz. Vollständige Details zur Integrationsplattform sind unter atrocore.com/en/integration-platform.