Daten­pipe­lines & Integration

Ein Bericht über Umsatz je Kanal braucht Daten aus mehreren Systemen: Tracking-Ereignisse, Aufträge im ERP, Kontakte im CRM, Bestellungen im Shop, dazu Dateien und Schnittstellen externer Anbieter. Zusammengeführt wird das oft über manuelle Exporte oder einzelne Skripte, die nur eine Person kennt. Fällt eines aus, bemerkt man es erst, wenn im Bericht Zahlen fehlen.

Spätestens dann lohnt sich der Umbau, wenn nach einem Fehler jemand mühsam herausfinden muss, welche Daten fehlen oder doppelt sind, wenn sich eine Schnittstelle ändert und mehrere Berichte gleichzeitig brechen oder wenn die Ladezeiten nicht mehr ins Zeitfenster passen. Wie das Ziel der Daten aufgebaut ist, mit Schichten und Historisierung, beschreiben wir unter Data Warehouse. Hier geht es um den Weg dorthin.

Was auf dem Weg von der Quelle zum Ziel passiert

Eine Pipeline holt Daten aus den Quellen, legt sie im Ziel ab, bereinigt und vereinheitlicht sie und bereitet sie für die Auswertung auf. Das Ziel ist meist ein Data Warehouse oder Lakehouse, manchmal auch eine Anwendung, die die Daten direkt nutzt. Ein Orchestrator steuert Reihenfolge, Zeitpläne und Wiederholungen, und automatische Prüfungen sichern bei jedem Lauf ab, dass die Daten stimmen und rechtzeitig da sind. Tracking-Daten sind dabei eine Quelle unter mehreren. Dieselben Pipelines können aufbereitete Daten auch zurück in operative Systeme wie das CRM spielen (Reverse ETL).

ETL oder ELT, Batch oder Streaming

ETL und ELT

Bei ETL werden Daten vor dem Laden umgewandelt, bei ELT zuerst roh geladen und im Ziel transformiert. In Cloud-Plattformen ist ELT üblich, weil die Rechenleistung dort vorhanden ist und die Rohdaten für spätere Fragen erhalten bleiben. ETL bleibt sinnvoll, wenn Daten schon vor dem Laden bereinigt oder maskiert werden müssen.

Batch und Streaming

Beim Batch werden Daten in Intervallen geladen, etwa täglich oder stündlich. Das ist einfach zu betreiben und für die meisten Berichte ausreichend. Streaming verarbeitet Ereignisse laufend, sodass sie nach Sekunden bis Minuten bereitstehen. Das lohnt sich, wenn Aktualität entscheidend ist, etwa bei Überwachung oder operativen Dashboards, und es kostet im Betrieb spürbar mehr. Wir fragen deshalb zuerst, wie oft der Bericht gelesen wird. Wird er einmal am Tag angesehen, ist Echtzeit verschwendet.

Für Streaming braucht es eine Plattform für Ereignisströme. Apache Kafka ist hier weit verbreitet, auch als verwalteter Dienst, und die großen Cloud-Anbieter haben eigene Dienste dafür.

Änderungen statt Komplettabzug

Statt eine ganze Tabelle immer wieder zu lesen, überträgt Change Data Capture nur die Änderungen aus dem Protokoll der Datenbank. Das entlastet das Quellsystem und macht auch Löschungen sichtbar. Debezium ist ein verbreitetes Open-Source-Werkzeug dafür. Ein Komplettabzug bei jedem Lauf belastet Quelle und Kosten oft unnötig, wo ein inkrementelles Verfahren reichen würde.

APIs und Dateien

Bei Schnittstellen und Dateien sind Seitenlimits, Abfragegrenzen, Authentifizierung und Strukturänderungen die typischen Hürden. Eine Pipeline muss damit umgehen können, ohne dass ein Lauf stillschweigend unvollständig bleibt.

Orchestrierung und Werkzeuge

Ein Orchestrator startet Läufe nach Zeitplan oder durch ein Ereignis, hält Abhängigkeiten ein, wiederholt fehlgeschlagene Schritte, erlaubt das Nachladen vergangener Zeiträume und meldet Fehler. Plattformunabhängige Open-Source-Orchestratoren beschreiben Abläufe als Python-Code. Apache Airflow ist hier der Standard.

Die großen Datenplattformen bringen ihren eigenen Orchestrator mit, Microsoft Fabric etwa Data Factory. Wer ohnehin auf einer solchen Plattform arbeitet, braucht oft kein zusätzliches Werkzeug.

Für gängige Quellen gibt es fertige Connectors, verwaltet oder als Open Source. Für Quellen ohne Connector lassen sich Pipelines mit einer Python-Bibliothek wie dlt als Code schreiben. Die Transformation im Ziel läuft bei vielen Teams über dbt. Weil Anbieter Datenübernahme, Transformation und Orchestrierung zunehmend in einem Produkt bündeln, bauen wir so, dass sich einzelne Werkzeuge austauschen lassen.

Qualität sichern: Prüfungen und Data Contracts

Eine Pipeline, die schnell läuft, aber falsche Zahlen liefert, schadet mehr als eine langsame. Bei jedem Lauf prüfen wir deshalb automatisch, ob Spalten und Datentypen stimmen und Pflichtfelder gefüllt sind, ob Schlüssel doppelt vorkommen und jede Bestellung einen passenden Kunden hat, ob Mengen und Summen im erwarteten Bereich liegen und die Daten rechtzeitig eingetroffen sind. Dazu kommt der Abgleich mit dem Quellsystem: Stimmen die Summen im Ziel mit denen der Quelle überein?

Zusätzlich helfen Data Contracts, also eine schriftliche Vereinbarung zwischen der Stelle, die Daten liefert, und denen, die sie nutzen: Struktur, Bedeutung, Qualitätsregeln, Aktualität, Zuständigkeit und der Umgang mit Änderungen. Für die Beschreibung gibt es offene Formate, etwa den Open Data Contract Standard des Projekts Bitol unter dem Dach der Linux Foundation. Wird der Vertrag automatisch geprüft, fällt eine geänderte Schnittstelle auf, bevor Berichte brechen. Bei einem Verstoß stoppt die Pipeline, oder die betroffenen Daten werden getrennt abgelegt und gemeldet.

Was im Betrieb den Unterschied macht

Ob eine Pipeline verlässlich ist, zeigt sich nach dem ersten Fehler. Ein Lauf muss bei Wiederholung dasselbe Ergebnis liefern (Idempotenz). Das gelingt, indem Daten per Abgleich über Schlüssel oder durch Ersetzen ganzer Zeiträume geschrieben werden und nicht einfach angehängt. Vergangene Zeiträume müssen sich gezielt nachladen lassen, zum Beispiel nach einem Fehler oder einer geänderten Logik. Ohne das sind nach einem Ausfall Daten doppelt oder fehlen, und die Korrektur geschieht von Hand.

Kurzzeitige Störungen werden mit Wartezeit automatisch wiederholt. Daten, die nicht verarbeitet werden konnten, landen in einer Ablage zur Prüfung, statt den ganzen Lauf zu stoppen oder unbemerkt zu verschwinden. Laufzeiten, Datenmengen, Aktualität und Fehler werden erfasst, und Alarme gehen an die zuständige Person und nicht an ein Postfach, das niemand liest. Alarme ohne Zuständigkeit sind einer der häufigsten Gründe, warum Fehler tagelang liegen bleiben.

Eine Quelle, die eine Spalte umbenennt, ist der klassische Fall für einen Fehler, der erst im Bericht auffällt. Strukturprüfungen am Eingang fangen das ab. Bei den Kosten, die oft nach Datenmenge, Rechenzeit oder Anzahl der Läufe abgerechnet werden, helfen inkrementelles Laden, sinnvolle Intervalle und ein Blick auf den Verbrauch.