ETL oder ELT: der Unterschied und die Wahl

ETL (Extract, Transform, Load) und ELT (Extract, Load, Transform) sind die beiden grundlegenden Muster, um Daten zwischen Systemen zu bewegen und aufzubereiten. Beide beginnen damit, Daten aus einer oder mehreren Quellen zu holen, und enden damit, dass die Daten für Analyse und nachgelagerte Nutzung bereitstehen. Sie unterscheiden sich darin, wo und wann transformiert wird, und das hat Folgen für Geschwindigkeit, Kosten, Governance und Wartbarkeit.

Die Wahl zwischen ETL und ELT ist längst keine vorwiegend technische Entscheidung mehr: Moderne Cloud Data Warehouses haben ELT für die meisten Fälle praktikabel gemacht. Wichtiger sind die Fragen nach Data Lineage, nach der Governance der Transformationen und danach, wie sichergestellt wird, dass die ankommenden Daten verlässlich und nachvollziehbar sind.

Was ist ETL?

In einer ETL-Pipeline gilt:

1. Extract: Daten aus den Quellsystemen holen, also aus Datenbanken, APIs, Dateien, Event-Streams. Das ist meist der einfachste Schritt, auch wenn Verfügbarkeit und Ratenbegrenzungen der Quellen für Betriebsaufwand sorgen.
2. Transform: fachliche Logik, Typumwandlungen, Entfernen von Duplikaten, Verdichtung und Qualitätsprüfungen in einer eigenen Verarbeitungsschicht anwenden, oft in einem dedizierten ETL-Werkzeug oder in eigenem Code, bevor die Daten ihr Ziel erreichen.
3. Load: die transformierten, sauberen Daten in das Zielsystem schreiben, in ein Data Warehouse, einen Data Lake oder eine operative Datenbank.

ETL wurde groß, als Data Warehouses im eigenen Rechenzentrum teuer und im Speicher knapp waren. Rohe, schmutzige Daten zu laden und später zu putzen, konnte sich niemand leisten: Ohne Transformation vor dem Laden waren Speicher- und Rechenkosten nicht zu halten.

Was ist ELT?

In einer ELT-Pipeline gilt:

1. Extract: wie bei ETL, die Rohdaten aus den Quellsystemen holen.
2. Load: die Rohdaten sofort und ohne Transformation ins Zielsystem laden. Moderne Cloud-Warehouses (Snowflake, BigQuery, Databricks) speichern Rohdaten günstig und transformieren sie mit eigener Rechenleistung effizient.
3. Transform: die Transformationen im Warehouse anwenden, in SQL oder über DataFrame-Operationen. Werkzeuge wie dbt haben diesen Schritt strukturiert, testbar und versionierbar gemacht.

Praktikabel wurde ELT mit den Cloud Data Warehouses der 2010er-Jahre. Die Rechnung hat sich verschoben: Cloud-Speicher ist billig, und die Rechenleistung im Warehouse trägt auch aufwendige Transformationen. Der Vorteil von ELT ist, dass die Rohdaten für Prüfung und erneute Verarbeitung erhalten bleiben und sich Transformationen ändern lassen, ohne erneut aus den Quellen zu extrahieren.

ETL und ELT: die wichtigsten Unterschiede

Die Unterschiede zwischen ETL und ELT im Betrieb und in der Governance reichen über die Architektur hinaus:

• Wo die Transformationslogik liegt: ETL legt sie in das Extraktions- und Transformationswerkzeug, oft ein proprietäres. ELT legt sie ins Warehouse, in SQL und dbt, also versionierbar, testbar und für das Datenteam sichtbar.
• Aufbewahrung der Rohdaten: ETL verwirft oder archiviert Rohdaten meist nach der Transformation. ELT behält sie in einer Staging- oder Rohschicht, was erneute Verarbeitung und Prüfung ohne neue Extraktion erlaubt.
• Änderungsgeschwindigkeit: Hier gewinnt ELT. Ein dbt-Modell zu ändern und neu laufen zu lassen, dauert Minuten. Eine ETL-Transformation zu ändern, neu auszurollen und historische Daten neu zu verarbeiten, dauert deutlich länger.
• Datenschutz und Compliance: Bei personenbezogenen Daten hat ETL einen Vorteil, weil sich Sensibles maskieren oder tokenisieren lässt, bevor es überhaupt gespeichert wird. Bei ELT landen personenbezogene Rohdaten vor der Transformation im Warehouse, was strenge Zugriffsregeln auf die Rohschicht verlangt.

Wann welches Muster passt

In der Praxis fahren die meisten modernen Datenplattformen zweigleisig: ELT für die meisten Datenflüsse, gezieltes ETL für Quellen mit Compliance-Bezug. Die Entscheidungspunkte:

ELT, wenn ein modernes Cloud-Warehouse im Einsatz ist, sich die Transformationslogik häufig ändert, das Datenteam SQL beherrscht und Rohdaten für erneute Läufe erhalten bleiben sollen. Das deckt die große Mehrheit der heutigen Fälle ab.

ETL, wenn Daten maskiert, anonymisiert oder gefiltert werden müssen, bevor sie überhaupt rechtmäßig gespeichert werden dürfen, also bei personenbezogenen Daten nach DSGVO, bei Zahlungskartendaten nach PCI-DSS oder bei Gesundheitsdaten nach HIPAA. Ebenso bei Quellen, deren Extraktion selbst teuer oder ratenbegrenzt ist, sodass es sich lohnt, die geladene Menge vorher zu verkleinern.

Data Lineage für Pipelines

Die wichtigste Governance-Anforderung an ETL wie ELT ist Data Lineage: der dokumentierte Weg von der Quelle bis zur Nutzung, der beantwortet, woher ein Wert stammt und welche Transformationen auf ihn angewendet wurden.

Ohne Lineage hat jemand, dem eine Zahl im Bericht seltsam vorkommt, keinen Weg, das zu prüfen. Unbekannt bleibt, welche Pipeline die Tabelle erzeugt hat, welche Logik angewendet wurde, welche Quellsysteme beigetragen haben und welche Qualitätsprüfungen gelaufen sind. Fehlersuche wird zum Raten.

Im modernen Data Stack

Im modernen Data Stack hat sich ELT durchgesetzt. Das übliche Muster: Fivetran oder Airbyte für Extraktion und Laden, Snowflake, BigQuery oder Databricks für Speicher und Rechenleistung, dbt für die Transformation. Diese Kombination macht die Transformationslogik SQL-nah, versionierbar in Git, testbar über Datentests und automatisch dokumentiert. Gegenüber den Blackbox-Transformationen der ETL-Ära ist das ein deutlicher Gewinn an Governance.

Data Catalog und Interactive Data Lineage von Dawiso binden sich in die Werkzeuge des modernen Data Stack ein und verfolgen Lineage über die gesamte ETL- und ELT-Kette, von der Extraktion aus der Quelle über die Transformationsmodelle bis zu Berichten und Dashboards. Genau das macht es möglich, „Woher kommt diese Kennzahl?“ in Sekunden zu beantworten statt in Tagen.

Fazit

ETL und ELT sind zwei architektonische Antworten auf dieselbe Grundaufgabe des Data Engineering: Daten verlässlich und im großen Maßstab von den Quellsystemen zu den analytischen Zielen zu bringen. Für moderne, cloudbasierte Plattformen ist ELT zur Voreinstellung geworden, weil es besser skaliert, schnellere Änderungen erlaubt und über SQL-nahe Werkzeuge mehr Governance mitbringt. Wichtiger als die Wahl des Musters ist jedoch die Disziplin dahinter: Pipelines ohne Lineage, ohne Qualitätsüberwachung und ohne geregelten Zugriff liefern früher oder später unzuverlässige Daten und untergraben das Vertrauen in die gesamte Analyseplattform.