Was ist Data Engineering?

Data Engineering ist die Disziplin, die Systeme zu entwerfen, zu bauen und zu betreiben, die Daten in großem Maßstab verlässlich erfassen, speichern, umformen und ausliefern. Menschen im Data Engineering bauen die Pipelines, Plattformen und die Infrastruktur, die aus Rohdaten operativer Systeme vertrauenswürdige Bestände machen, die Analyse, Data Science, Anwendungen und KI-Agenten nutzen können. Sind Daten der Blutkreislauf einer Organisation, dann ist Data Engineering das Herz-Kreislauf-System, das ihn in Bewegung hält: unsichtbar, wenn es arbeitet, und verheerend, wenn es versagt.

Die Rolle ist aus dem Zusammenlaufen dreier älterer Disziplinen entstanden: ETL und Data Warehousing, Softwareentwicklung und verteilte Systeme. Als Datenmengen im Maßstab der Cloud die klassische Werkzeugkette überforderten (Informatica, Talend, On-Premises-Warehouses), borgte sich eine Generation von Entwicklerinnen und Entwicklern die Praktiken der Softwareentwicklung, also Versionskontrolle, Code-Review, CI/CD und Tests, und wandte sie auf Datenpipelines an. Herausgekommen ist eine Disziplin, die heute große technische Breite (SQL, Python, verteilte Systeme, Cloud-Plattformen, Streaming) mit dem fachlichen Verständnis dafür verbindet, wie Daten tatsächlich verwendet werden.

Data Engineering im Überblick

Die Aufgabe im Data Engineering ist es, Daten nutzbar zu machen: am richtigen Ort, in der richtigen Form, zur richtigen Zeit, mit der richtigen Aktualität, Genauigkeit und Zugriffskontrolle für die Verbraucher, die sie brauchen. Die Arbeit erstreckt sich über mehrere Schichten des Datenstacks.

• Quellen: die Anbindung an operative Datenbanken, SaaS-APIs, Ereignisströme, Datei-Feeds, Daten Dritter und unstrukturierte Quellen.
• Speicher: der Entwurf des Data Warehouse, des Lakehouse oder des operativen Datenspeichers, der die Daten hält, also Schemata, Partitionierung, Tabellenformate und Zugriffsmuster.
• Umformung: die Rohdaten säubern, verbinden, verdichten und in Formen modellieren, die Verbraucher nutzen können, meist über SQL-Umformungen in Werkzeugen wie dbt und mit verwalteter Orchestrierung.
• Auslieferung: die umgeformten Daten über Tabellen, Sichten, APIs, Ströme, BI-Werkzeuge, Feature Stores oder MCP-Server bereitstellen.
• Betrieb: das alles mit Überwachung, Alarmierung und Reaktion auf Störungen verlässlich am Laufen halten.

Das prägende Wort ist verlässlich. Die schweren Probleme im Data Engineering sind nicht, ob jemand das SQL schreiben kann. Sie sind, ob jemand das SQL so schreiben kann, dass es jeden Tag läuft, richtige Ergebnisse liefert, sich von vorgelagerten Ausfällen erholt, mit wachsendem Volumen skaliert und von denen verstanden wird, die es erben. Data Engineering ist genau in dem Maß zur Disziplin gereift, in dem Organisationen begriffen haben, dass aus dem Stegreif gebaute Pipelines über eine kleine Zahl von Verbrauchern hinaus nicht tragen.

Kernaufgaben

Die tägliche Arbeit im Data Engineering umfasst meist sechs wiederkehrende Tätigkeiten.

1. Erfassung

Daten aus den Quellsystemen in die Datenplattform bringen. Die Werkzeuge reichen von verwalteten Konnektoren (Fivetran, Airbyte, Stitch) für SaaS-Quellen über Change Data Capture (Debezium, Striim) für operative Datenbanken bis zu Streaming-Plattformen (Kafka, Kinesis) für Ereignisdaten. Die schweren Teile: Schema-Drift, Gegendruck aus dem Quellsystem, Idempotenz und der Umgang mit Quellen, die gelegentlich über ihre Vollständigkeit die Unwahrheit sagen.

2. Speicher und Modellierung

Den Entwurf, wie Daten in der Plattform liegen. Lakehouse-Architekturen auf Delta Lake oder Apache Iceberg, Warehouses im Stil von Snowflake, Dokumentspeicher für halbstrukturierte Daten und zunehmend Vektordatenbanken für Embeddings. Die Datenmodellierung, also Sternschemata, Data Vault, dimensional oder normalisiert, findet hier statt, wobei die heutige gute Praxis die Medallion-Architektur (Bronze, Silber, Gold) als Schichtungskonvention bevorzugt.

3. Umformung

Aus Rohdaten verbrauchbare Formen machen. Das vorherrschende Muster im Jahr 2026 ist die SQL-basierte, versionierte Umformung in dbt oder gleichwertigen Werkzeugen, die auf dem Warehouse oder Lakehouse selbst läuft. Python und Spark bleiben unverzichtbar für schwerere Umformungen, für das Merkmals-Engineering im maschinellen Lernen und für die Arbeit mit unstrukturierten Daten. Die Umformungsschicht ist die Stelle, an der die meisten Probleme der Datenqualität auffallen und die meiste Lineage entsteht.

4. Orchestrierung

Die Pipeline planen und aufeinander abstimmen. Apache Airflow, Dagster, Prefect und verwaltete Alternativen orchestrieren täglich Hunderte oder Tausende Jobs, behandeln Wiederholungen und Abhängigkeiten und erzeugen die Betriebsmetadaten, die andere Systeme verbrauchen. Moderne Orchestrierer kennen zunehmend die Metadaten: Sie wissen, welche Datenbestände jede Aufgabe erzeugt, und senden Lineage-Ereignisse für nachgelagerte Verbraucher aus.

5. Observability und Qualität

Werkzeuge für die Data Observability (Monte Carlo, Acceldata, Soda) überwachen die Gesundheit der Pipeline und erkennen Auffälligkeiten bei Volumen, Aktualität, Verteilung und Schema. dbt-Tests prüfen Umformungen gegen Geschäftsregeln. Das Data Engineering verantwortet die Alarmierung und die Handlungsanweisungen, die aus „da sieht etwas komisch aus“ eine geordnete Reaktion machen.

6. Auslieferung

Daten für Verbraucher bereitstellen. Unmittelbarer SQL-Zugriff für die Analyse, Semantic Layer für BI-Werkzeuge, Feature Stores für ML, REST- und GraphQL-APIs für Anwendungen, MCP-Server für KI-Agenten, gesteuerte Selbstbedienungsoberflächen für nicht technische Nutzer. In der Auslieferungsschicht trifft das Data Engineering unmittelbar auf den Verbraucher.

Data Engineering, Data Science und Analytics Engineering

Drei eng verwandte Rollen werden oft in einen Topf geworfen. Die Unterschiede zählen, wenn Datenteams besetzt und aufgebaut werden.

• Data Engineer: baut und betreibt die Pipelines, die Plattform und die Infrastruktur. Schwerpunkt: Verlässlichkeit, Maßstab, Richtigkeit der Datenbewegung. Typische Fähigkeiten: SQL, Python, verteilte Systeme, Cloud-Plattformen, Streaming.
• Analytics Engineer: eine Rolle, die um 2019 mit dbt entstanden ist. Sitzt zwischen Data Engineering und Analyse. Baut auf der Plattform, die das Data Engineering pflegt, die kuratierten, fachlich fertigen Datenmodelle. Schwerpunkt: Datenmodellierung, Geschäftslogik, Richtigkeit der Umformung. Typische Fähigkeiten: sicheres SQL, dbt, Versionskontrolle, Kenntnis des Fachgebiets.
• Data Scientist: baut Modelle und statistische Analysen auf den Daten auf. Schwerpunkt: Vorhersage, Schlussfolgerung, Experiment. Typische Fähigkeiten: Python, Statistik, ML-Rahmenwerke, Merkmals-Engineering, Methodik des Experimentierens.

Die drei Rollen überschneiden sich, und die Bezeichnungen meinen in verschiedenen Organisationen Verschiedenes. Die funktionale Trennung hält länger als der Titel: Jemand bewegt Daten, jemand formt sie, jemand modelliert Ergebnisse aus ihnen. In kleinen Organisationen spielt eine Person alle drei Rollen. In großen sind es eigene Teams mit eigenen Schnittstellen zueinander.

Der moderne Stack im Data Engineering

Der Stack der 2020er Jahre hat sich um einige wiederkehrende Muster verdichtet:

• Cloud-nativ, Rechenleistung und Speicher getrennt. Snowflake, Databricks, BigQuery und Redshift Serverless teilen diese Architektur. Speicher in Objektspeichern (S3, ADLS, GCS), Rechenleistung unabhängig skaliert. Delta Lake, Iceberg und Hudi als offene Tabellenformate, die Lakehouse- und Warehouse-Muster vereinen.
• SQL als erste Sprache der Umformung. Die Verbreitung von dbt hat den Satz normalisiert, dass Umformungen SQL sind, unter Versionskontrolle stehen, getestet werden und auf dem Warehouse laufen. Python bleibt für schwerere Arbeit, die Modellierungsschicht ist aber überwiegend SQL.
• Orchestrierung mit Code an erster Stelle und Blick für Metadaten. Airflow bleibt das Arbeitspferd; Dagster und Prefect betonen die Sicht auf Bestände und eine von Metadaten getriebene Orchestrierung. Beide speisen die Metadatenschicht.
• Observability als erstrangiges Thema. Pipelines bekommen Überwachung, Alarmierung und Zusagen zur Dienstgüte, wie Dienste sie haben.
• Der Semantic Layer als veröffentlichte Schnittstelle. Cube, MetricFlow, Looker, AtScale und ähnliche Werkzeuge legen fachliche Definitionen über das Warehouse, damit Verbraucher nicht jedes Quartal die Kennzahlen neu erfinden.
• Governance als Teil der Plattform. Unity Catalog, Snowflake Horizon, Polaris und externe Kataloge wie Dawiso behandeln Klassifizierung, Lineage und Zugriffsrichtlinien zunehmend als Grundbausteine der Plattform statt als gesonderte Auflage für die Compliance.

Wo Engineering auf Governance trifft

Data Engineering und Data Governance sind im Betrieb ineinander verschränkt. In den Pipelines, die das Data Engineering baut, entstehen die meisten Metadaten der Governance, und dort müssen die Richtlinien der Governance durchgesetzt werden, wenn sie überhaupt greifen sollen.

• Lineage entsteht aus Umformungen. Moderne Werkzeuge, also dbt, Orchestrierer mit OpenLineage-Unterstützung und Scanner für Abfrageprotokolle, senden Lineage automatisch aus, wenn Umformungen laufen. Die Lineage, die im Katalog landet, ist nur so gut wie die Praxis im Engineering, die sie erzeugt hat.
• Qualität wird in die Pipeline hineingebaut. dbt-Tests, Great Expectations, Soda und gleichwertige Werkzeuge laufen als Teil der Pipeline. Fehlerhafte Daten bringen die Pipeline zum Scheitern und nicht am nächsten Morgen das Dashboard des Verbrauchers.
• Klassifizierung pflanzt sich durch Umformungen fort. Tags, die an der Quelle gesetzt werden (diese Spalte ist PII), müssen den Daten durch Joins, Verdichtungen und Sichten folgen. Moderne Plattformen (Unity Catalog, Snowflake, Databricks) reichen Tags automatisch weiter; ältere Stacks verlangen ausdrückliche Arbeit im Engineering.
• Zugriffsrichtlinien werden bei der Auslieferung durchgesetzt. Sicherheit auf Zeilenebene, Maskierung von Spalten und dynamische Maskierung von Daten werden im Engineering eingerichtet, aber von der fachlichen Richtlinie getrieben. An der Schnittstelle zwischen Governance (wer darf was sehen) und Engineering (wie wird das im Warehouse durchgesetzt) entscheidet sich, ob ein Zugriffsprogramm gelingt.

Die wirksamsten Teams im Data Engineering behandeln die Metadaten der Governance als Produktergebnis und nicht als Nebeneffekt: Sie verbrauchen dieselben Metadaten, die sie erzeugen. Der Katalog ist eine ihrer wichtigsten Schnittstellen und kein gesondertes Compliance-Werkzeug, das jemand anderes pflegt.

Fähigkeiten und Laufbahn

Das Fähigkeitsprofil im modernen Data Engineering ist breit und wird weiter breiter.

• Sicheres SQL: Fensterfunktionen, CTEs, Optimierung, Unterschiede zwischen Dialekten. Die nicht verhandelbare Grundlage.
• Python: für schwerere Umformungen, Orchestrierung, Arbeit an APIs und die Unterstützung von ML-Pipelines. Zunehmend mit Typhinweisen, Tests und Paketdisziplin, geborgt aus der Softwareentwicklung.
• Datenplattformen in der Cloud: tiefe Vertrautheit mit mindestens einem großen Warehouse oder Lakehouse (Snowflake, Databricks, BigQuery, Redshift) und Sicherheit im Umgang mit Cloud-Infrastruktur (S3, ADLS, GCS, IAM, Netzwerke).
• Verteilte Systeme und Streaming: Kafka, Spark, Flink. Weniger allgemein als SQL und Python, aber zunehmend verbreitet, je weiter ereignisgetriebene Architekturen vordringen.
• Praktiken der Softwareentwicklung: Versionskontrolle, Code-Review, CI/CD, Tests, Observability. Die Grenze zwischen Data Engineering und Softwareentwicklung ist so gut wie verschwunden.
• Verständnis des Fachgebiets: zu wissen, was die Daten im Geschäft bedeuten. Wer im Data Engineering ein inhaltliches Gespräch mit Finanzwesen, Marketing oder Produkt führen kann, erzeugt deutlich bessere Daten als jemand, der Daten als undurchsichtige Frachten behandelt.

Laufbahnen führen meist vom Einstieg im Data Engineering (Pipelines unter Anleitung bauen) über die erfahrene Ebene (Systeme und Standards verantworten) entweder in die technische Führung (Staff oder Principal Engineer), in die Personalführung oder in Spezialrichtungen (Plattform-Engineering, ML-Engineering, Analytics Engineering).

Fazit

Data Engineering ist die tragende Disziplin unter allem, was Organisationen sonst mit Daten tun. Analytik, BI, ML, KI, Governance und Compliance ruhen alle auf Pipelines, die jemand gebaut hat und jemand pflegt. Die sichtbare Arbeit des Data Engineering steckt in Dashboards und ML-Modellen, die auftauchen; die unsichtbare steckt im Ausbleiben von Störungen, in der Beständigkeit der Kennzahlen und darin, dass neue Datenquellen eingebunden werden, ohne bestehende Verbraucher zu stören. Organisationen, die in Data Engineering als strategische Disziplin investieren, mit erfahrenen Leuten, modernen Werkzeugen und Verantwortung für den Betrieb, bekommen einen Hebel auf jede andere Investition in Daten. Organisationen, die es als Funktion hinter der Bühne behandeln, bekommen erwartbar das Gegenteil.