---
title: "Data Engineering und Datenintegration | SKAFFON"
description: "Data-Engineering-Beratung: Datenpipelines mit Airflow, Kafka und dbt entwerfen, absichern und betreiben. Mit Auswahlmatrix Batch, CDC, Streaming."
url: https://skaffon.de/daten/data-engineering/
---
![Bildschirm vor einem dichten Geflecht aus Netzwerkkabeln an Server-Racks in blauem Licht](/_astro/datenzentrum-kabelgewirr-blau-hero.CAevLT1h_niGhU.jpg) 

1. [Startseite](/)
2. [Daten](/daten/)
3. Data Engineering und Datenintegration für Unternehmen

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.

[Projektanfrage stellen](/projekt-anfragen/) [Zur Auswahlmatrix](/daten/data-engineering/#ladeverfahren-je-quelle) 

- Batch, inkrementell, CDC, Streaming
- Tests und Alarme in jeder Pipeline
- Abnahme nach zehn Punkten

Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 

Ausgangslage

## 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.

[Datenplattformen und Lakehouse](/daten/datenplattformen/)

![Person bedient einen Rechner an einem Arbeitsplatz im Serverraum neben Netzwerkgeräten](/_astro/techniker-serverraum-arbeitsplatz.DfM3qZCe_Z21GI4s.jpg) 

Bausteine

## Sieben Bausteine, aus denen eine betriebsfähige Pipeline besteht

Der Bereich [Daten](/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](https://airflow.apache.org/docs/apache-airflow/stable/index.html). 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](https://docs.getdbt.com/docs/introduction): 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](https://kafka.apache.org/intro) 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.

Auswahlmatrix

## 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.

__Ladeverfahren im Vergleich: Aktualität, Last auf der Quelle, Erkennung von Löschungen, Aufwand__
| 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](https://www.postgresql.org/docs/current/runtime-config-wal.html) `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](https://www.postgresql.org/docs/current/logical-replication-restrictions.html)). 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.

Abnahme

## 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.

Sicherheit

## 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](/infrastruktur/souveraene-cloud/)
- Weitere Absicherung: [Cloud Security](/cybersecurity/cloud-security/)

![Zwei Entwickler besprechen Quellcode auf einem Monitor und einem Laptop am Arbeitsplatz im Büro](/_astro/entwickler-besprechen-quellcode-monitor.B8kLUd_l_13MQeb.jpg) 

Ablauf

## Von der Bestandsaufnahme zur laufenden Pipeline in fünf Schritten

1. 01  
### Bestandsaufnahme  
Quellen, Ziele, bestehende Abläufe, Abnehmer der Daten und ihre Aktualitätsanforderung.
2. 02  
### Zielbild und Pipeline-Entwurf  
Verfahren je Quelle nach der Matrix oben, Schema- und Qualitätsvereinbarungen, Betriebsmodell.
3. 03  
### Umsetzung in Iterationen  
Pro Datenquelle ein vollständiger Durchstich bis zum Abnehmer, nicht erst alle Quellen, dann alle Transformationen.
4. 04  
### Abnahme  
Nach der Checkliste oben, mit Ihrem Fachverantwortlichen.
5. 05  
### Übergabe oder Betrieb  
Runbooks und Schulung Ihres Teams oder Betrieb der Pipelines durch SKAFFON.

Lieferumfang

## 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](/leistungen/devops-automatisierung/))
- Transformationsmodelle mit Tests und Dokumentation
- Monitoring, Alarmregeln und Runbooks
- Abnahmeprotokoll nach der Checkliste

![Hände tippen auf einer Laptop-Tastatur, auf dem Bildschirm ist Quellcode in einer Entwicklungsumgebung geöffnet](/_astro/haende-tippen-laptop-tastatur.tEmHUGn8_mlvhH.jpg) 

Eingaben

## 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

Abgrenzung

## 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.

Angrenzende Themen

## Wohin die Daten weiterlaufen und woher sie kommen

- ### [Daten](/daten/)  
Übersicht über Ingest, Speicher, Verarbeitung und Bereitstellung.  
Weiter
- ### [Datenplattformen und Lakehouse](/daten/datenplattformen/)  
Die Zielarchitektur hinter den Pipelines.  
Weiter
- ### [PostgreSQL-Beratung](/daten/postgresql-datenbanken/)  
Datenbankbetrieb für Quellen und Ziele.  
Weiter
- ### [Managed PostgreSQL](/managed-services/managed-postgresql/)  
Betrieb der Datenbank durch SKAFFON.  
Weiter
- ### [Datenbankmigration](/daten/datenbank-migration/)  
Wenn die Daten aus einem Datenbankwechsel kommen, beginnt der Weg hier.  
Weiter

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.

[Projektanfrage stellen](/projekt-anfragen/)