Datenpipelines · Airflow, Kafka, dbt
Data Engineering und Datenintegration für Unternehmen
Aus gewachsenen Skripten und Einzel-Importen werden nachvollziehbare, überwachte Pipelines: von der Quelle bis zum Abnehmer, mit Abnahme nach Checkliste.
- Batch, inkrementell, CDC, Streaming
- Tests und Alarme in jeder Pipeline
- Abnahme nach zehn Punkten
01Ausgangslage
Der Lauf war grün, der Bericht stimmt trotzdem nicht
SKAFFON berät und liefert im Data Engineering: Wir entwerfen, bauen und betreiben Datenpipelines, die Daten aus Anwendungsdatenbanken, Dateien und Ereignisströmen zuverlässig in Ihre Zielsysteme bringen und dort für Analyse und Anwendungen aufbereiten.
Pipelines scheitern selten am ersten Lauf, sondern im Betrieb. Typische Auslöser für ein Projekt sind:
- Eine Quelle ändert still ihr Schema.
- Ein Lauf bricht nachts ab und wird nicht bemerkt.
- Ein Wiederholungslauf erzeugt Dubletten.
- Niemand weiß, welche Zahl im Bericht woher stammt.
- Gewachsene Cron-Skripte ohne Überwachung, eine neue Datenbank zum Anbinden oder der Wunsch nach aktuelleren Daten.
02Bausteine
Sieben Bausteine, aus denen eine betriebsfähige Pipeline besteht
Der Bereich Daten zeigt die gesamte Plattform aus Ingest, Speicher, Verarbeitung und Bereitstellung. Hier geht es um die Pipeline-Schicht.
-
Pipelines in Python
Orchestrierung über Apache Airflow. Airflow definiert Workflows laut Dokumentation vollständig in Python; damit sind Pipelines versionierbar, testbar und per Code-Review änderbar.
-
ETL und ELT
Bei ELT landen Rohdaten zuerst im Ziel, Transformationen laufen dort als versionierter SQL-Code, etwa mit dbt: Modelle sind SELECT-Anweisungen, dbt übernimmt Materialisierung und Ausführungsreihenfolge. Bei ETL wird vor dem Laden transformiert, sinnvoll etwa bei Pseudonymisierung vor dem Zielsystem.
-
Schema-Governance
Vereinbarungen, was sich in Quellen ändern darf und wie Änderungen erkannt werden, bevor sie Berichte brechen: Schema-Vergleich im Lauf, Versionierung der Zielmodelle, definierter Umgang mit neuen, entfernten und umbenannten Spalten.
-
Datenqualität im Lauf
Automatische Prüfungen als Teil der Pipeline: Eindeutigkeit, Pflichtfelder, Wertebereiche, Beziehungen zwischen Tabellen, Aktualität. dbt unterstützt laut Dokumentation Datenqualitätstests und erzeugt Dokumentation aus dem Code.
-
Monitoring
Laufstatus, Laufzeiten, Alarmierung bei Fehlschlag oder ausbleibenden Daten, Dashboards für die Verantwortlichen der Pipelines.
-
Ereignisströme
Wo Aktualität im Sekunden- bis Minutenbereich gefordert ist, setzen wir Apache Kafka ein: Ereignisse liegen in Topics, die in Partitionen auf mehrere Broker verteilt und repliziert werden; Kafka Connect bindet Datenbanken und andere Systeme an.
-
Ziele für Daten
PostgreSQL für strukturierte Daten, S3-kompatibler Objektspeicher für Rohdaten, Dateien und Archive.
03Auswahlmatrix
Wie kommen die Daten an? Das Ladeverfahren je Quelle
Die Wahl des Ladeverfahrens bestimmt Aktualität, Last auf der Quelle und Betriebsaufwand. Sie wird je Quelle getroffen, nicht einmal für die ganze Plattform.
| Verfahren | Aktualität | Last auf der Quelle | Löschungen erkennbar | Aufwand und Fallstricke |
|---|---|---|---|---|
| Vollladung (Batch) | nach Laufintervall | hoch bei großen Tabellen | ja, durch Vergleich der Gesamtmenge | einfach; wird bei Wachstum langsam und teuer |
| Inkrementell (Watermark-Spalte, z. B. Änderungszeitpunkt) | nach Laufintervall | gering | nein, harte Löschungen bleiben unsichtbar | Spalte muss zuverlässig gepflegt werden; nachträgliche Korrekturen mit altem Zeitstempel gehen verloren |
| CDC (Änderungen aus dem Log der Quelldatenbank) | Sekunden bis Minuten | gering bis mittel | ja | zusätzliche Komponenten, Überwachung der Verzögerung, Umgang mit Schemaänderungen |
| Streaming über Kafka (Anwendung publiziert Ereignisse) | Sekunden | bei der Quelle gering | als eigenes Ereignis, wenn modelliert | Ereignismodell, Reihenfolge je Schlüssel, Wiederholung und Doppelzustellung müssen im Konsumenten behandelt werden |
Bei PostgreSQL als Quelle setzt logische Dekodierung laut Dokumentation wal_level = logical voraus; die Einstellung erfordert einen Neustart des Servers und erhöht das WAL-Volumen. Tabellen ohne Primärschlüssel brauchen eine passende Replica Identity (Einschränkungen der logischen Replikation). Das planen wir vor dem Projekt ein, nicht danach.
Faustregel
Das einfachste Verfahren, das die geforderte Aktualität liefert
Ein Stundenbericht braucht kein Streaming; ein Bestandsabgleich im Sekundentakt kommt mit Batch nicht aus. Wir wählen nach der Anforderung, nicht nach der Technik.
04Abnahme
Zehn Punkte, bevor eine Pipeline als fertig gilt
Die Liste dient zugleich als Prüfliste für bestehende Pipelines. Jeder Punkt wird belegt, nicht behauptet.
- Idempotenz. Ein wiederholter Lauf desselben Zeitraums erzeugt denselben Endzustand, keine Dubletten. Belegt durch Test mit doppeltem Lauf.
- Backfill. Historische Zeiträume lassen sich gezielt nachladen, ohne laufende Läufe zu stören.
- Fehlerbehandlung. Ein fehlerhafter Datensatz stoppt nicht stillschweigend den Lauf und verschwindet nicht lautlos: Er landet in einer prüfbaren Ablage mit Fehlergrund, oder der Lauf bricht definiert ab.
- Schemaänderung. Verhalten bei neuer, fehlender und typveränderter Spalte ist festgelegt und getestet.
- Datenqualität. Tests laufen im Lauf und blockieren die Übernahme in produktive Modelle, wenn Pflichtkriterien verletzt sind.
- Aktualitätsalarm. Ausbleibende Daten lösen einen Alarm aus, auch wenn der Lauf technisch erfolgreich war.
- Abstimmung mit der Quelle. Zeilenzahlen und Summen zwischen Quelle und Ziel werden regelmäßig verglichen.
- Zugriff und Geheimnisse. Technische Konten mit minimalen Rechten, Zugangsdaten außerhalb des Codes, Rotation möglich.
- Dokumentation und Eigentümer. Jede Pipeline hat einen benannten Verantwortlichen auf Ihrer Seite, eine Beschreibung und eine Lauf-Anleitung für Störungen.
- Wiederanlauf. Nach Ausfall von Orchestrierung oder Zielsystem ist der Wiederanlauf beschrieben und einmal geübt.
05Sicherheit
Pipelines lesen Produktivdaten: Rechte, Geheimnisse, Datenschutz
Pipelines lesen Produktivdaten und sind deshalb sicherheitsrelevant. Wo personenbezogene Daten fließen, klären Sie mit Ihrer Datenschutzverantwortung Zweck, Rechtsgrundlage und Löschfristen; wir setzen technisch um, etwa Pseudonymisierung vor dem Zielsystem oder Löschläufe.
- Personalisierte oder technische Konten mit minimalen Rechten
- Verschlüsselte Übertragung
- Secrets außerhalb von Images und Repositories
- Betrieb auf Ihrer Infrastruktur oder in einer von Ihnen gewählten Umgebung, auch in der souveränen Cloud
- Weitere Absicherung: Cloud Security
06Ablauf
Von der Bestandsaufnahme zur laufenden Pipeline in fünf Schritten
- 01
Bestandsaufnahme
Quellen, Ziele, bestehende Abläufe, Abnehmer der Daten und ihre Aktualitätsanforderung.
- 02
Zielbild und Pipeline-Entwurf
Verfahren je Quelle nach der Matrix oben, Schema- und Qualitätsvereinbarungen, Betriebsmodell.
- 03
Umsetzung in Iterationen
Pro Datenquelle ein vollständiger Durchstich bis zum Abnehmer, nicht erst alle Quellen, dann alle Transformationen.
- 04
Abnahme
Nach der Checkliste oben, mit Ihrem Fachverantwortlichen.
- 05
Übergabe oder Betrieb
Runbooks und Schulung Ihres Teams oder Betrieb der Pipelines durch SKAFFON.
07Lieferumfang
Was nach dem Projekt in Ihrem Repository und Ihrem Betrieb liegt
Das Ergebnis ist prüfbarer Code und dokumentierter Betrieb, keine Blackbox.
- Bestandsaufnahme und Zielbild mit begründeter Verfahrenswahl je Quelle
- Pipeline-Code im Repository, mit Tests und CI/CD (DevOps-Beratung)
- Transformationsmodelle mit Tests und Dokumentation
- Monitoring, Alarmregeln und Runbooks
- Abnahmeprotokoll nach der Checkliste
08Eingaben
Was wir für den Entwurf von Ihnen brauchen
Unbekannte Eingaben werden im Assessment als Annahmen dokumentiert und nicht stillschweigend gefüllt.
- Quellen und Ziele mit Art, Größe und Änderungsrate; wer die jeweilige Quelle verantwortet
- Gewünschte Aktualität pro Datensatz: Tage, Stunden, Minuten, Sekunden
- Zulässige Last auf den Quellsystemen und vorhandene Zugriffswege (Lesereplika, Exporte, Schnittstellen)
- Datenklassen, Standortvorgaben, Aufbewahrungs- und Löschfristen
- Vorhandene Orchestrierung, Kubernetes-Plattform, Identity-Lösung und Monitoring
09Abgrenzung
Pipelines und Datenintegration ja, Berichtsdesign und Kennzahlenlogik nein
Das liefern wir
- Überwachte, getestete Pipelines von der Quelle bis zum Zielsystem
- Verfahrenswahl je Quelle, begründet und mit Abnahme nach Checkliste
Das gehört nicht zu dieser Leistung
- Ein fertiges Business-Intelligence-Produkt oder die Gestaltung von Berichten und Dashboards
- Die Fachlogik Ihrer Kennzahlen ohne Fachbereich als Ansprechpartner: Die Bedeutung der Daten bleibt bei Ihnen.
- Ein einzelner, seltener Export: Dafür ist ein Projekt unverhältnismäßig.
10Angrenzende Themen
Wohin die Daten weiterlaufen und woher sie kommen
-
Daten
Übersicht über Ingest, Speicher, Verarbeitung und Bereitstellung.
-
Datenplattformen und Lakehouse
Die Zielarchitektur hinter den Pipelines.
-
PostgreSQL-Beratung
Datenbankbetrieb für Quellen und Ziele.
-
Managed PostgreSQL
Betrieb der Datenbank durch SKAFFON.
-
Datenbankmigration
Wenn die Daten aus einem Datenbankwechsel kommen, beginnt der Weg hier.
Projektanfrage
Quellen, Ziele und gewünschte Aktualität nennen
Beschreiben Sie Quellen, Ziele und gewünschte Aktualität; auf dieser Grundlage folgt die Bestandsaufnahme. Das Angebot richtet sich nach Zahl und Art der Quellen, dem Ladeverfahren (CDC und Streaming sind aufwendiger als Batch), den Qualitätsanforderungen, der Zahl der Umgebungen und dem Betriebsumfang.