ELT: Definition und Abgrenzung zu ETL und Zero-ETL

ELT steht für Extract, Load, Transform (auf Deutsch: Extrahieren, Laden, Transformieren). Der Begriff bezeichnet ein Verfahren der Datenintegration (das Zusammenführen von Daten aus mehreren Quellen), bei dem Rohdaten (unveränderte Ausgangsdaten) zuerst in ein Zielsystem geladen und erst dort in die gewünschte Form gebracht werden. Der Ansatz kehrt die Reihenfolge des klassischen ETL (Extract, Transform, Load) um und hat sich mit modernen Cloud-Datenplattformen durchgesetzt, weil diese Speicher und Rechenleistung getrennt bereitstellen und je nach Bedarf skalieren.

Was ist ELT?

ELT ist ein Ablauf-Muster für Datenintegration mit drei Schritten. Extract liest Daten aus einer oder mehreren Quellen, zum Beispiel aus operativen Datenbanken (etwa aus dem ERP- oder CRM-System), aus Cloud-Anwendungen mit Schnittstelle oder aus abgelegten Dateien. Load schreibt diese Rohdaten unverändert in ein Zielsystem, meist in ein zentrales Analyse-System in der Cloud (Data Warehouse oder Lakehouse, eine Kombination aus Data Lake und Data Warehouse). Transform formt sie dort mit der Rechenleistung des Zielsystems in nutzbare Strukturen um: bereinigen, anreichern, zusammenfassen, in ein einheitliches Schema (die Tabellenstruktur) bringen.

Der Ansatz ist an eine technische Voraussetzung geknüpft: Das Zielsystem muss Storage und Compute getrennt bereitstellen und Rechenleistung elastisch skalieren können. Genau das leisten Cloud-Data-Warehouses (Redshift, BigQuery, Snowflake) und Lakehouse-Architekturen (Delta Lake, Iceberg auf Databricks, Fabric, Athena). Erst diese Trennung macht es wirtschaftlich, Transformationslasten im Zielsystem laufen zu lassen, statt sie in eine separate ETL-Engine auszulagern.

Historisch entstand ELT als Antwort auf zwei Verschiebungen. Erstens die Verlagerung analytischer Workloads in die Cloud, bei der Storage-Preise fielen und Compute variabel abgerechnet wurde: Rohdaten-Landung wurde billig, dedizierte Transformations-Server teuer. Zweitens der Aufstieg deklarativer Transformations-Werkzeuge (dbt, Databricks Declarative Pipelines), die SQL-basiert im Zielsystem laufen und keine eigene Laufzeitumgebung mehr brauchen. Die klassische ETL-Ära war umgekehrt geprägt von knappen Warehouse-CPUs, die für Reporting reserviert blieben, während dedizierte Server (Informatica, DataStage, SSIS) die Transformation übernahmen.

In der Referenz-Architektur des Medaillon-Modells findet die Transformation schichtweise statt. Der Load füllt einen Bronze-Layer mit Rohdaten, Silver-Transformationen konformisieren und reinigen, Gold-Transformationen aggregieren zu konsumierbaren Kennzahlen. Der Begriff „ELT" bezeichnet dabei das Reihenfolge-Muster, nicht die konkrete Implementierung; die technische Ausführung reicht von SQL-Statements über dbt-Modelle bis zu PySpark-Jobs.

Abgrenzung zu ETL, Zero-ETL, Reverse ETL und Data Transformation

ELT wird häufig mit verwandten Begriffen verwechselt, die im Umfeld von Datenintegration und Warehouse/Lakehouse zirkulieren. Die folgende Tabelle sortiert die vier häufigsten Verwechslungen.

Begriff	Verhältnis zu ELT	Kernunterschied
ETL	Umgekehrte Reihenfolge	ETL transformiert vor dem Load in einer separaten Engine (SSIS, Informatica, Talend). ELT lädt Rohdaten zuerst und transformiert im Zielsystem.
Zero-ETL	Betriebs-Form	Zero-ETL ist ein Managed-Angebot eines Cloud-Anbieters, das die Pipeline zwischen zwei Systemen verwaltet und vor dem Nutzer verbirgt. ELT ist ein Reihenfolge-Muster in der Verantwortung des Datenteams.
Reverse ETL	Gegenrichtung	Reverse ETL transportiert transformierte Daten aus dem Warehouse oder Lakehouse zurück in operative Systeme (CRM, Marketing-Tools, Ad-Plattformen). ELT bewegt Rohdaten in Richtung Analytik.
Data Transformation	Teilschritt	Data Transformation ist der reine Umformungs-Schritt (das „T"). ELT ist das umgebende Reihenfolge-Muster, das den Ort und den Zeitpunkt dieser Transformation festlegt.

Zwei Trennlinien sind für Architektur-Entscheidungen zentral. Erstens der Ort der Transformation: ETL nutzt eine separate Engine vor dem Zielsystem, ELT nutzt das Zielsystem selbst. Zweitens die Betriebs-Verantwortung: Klassisches ETL und ELT liegen beim Datenteam, Zero-ETL beim Cloud-Anbieter. Die drei Buchstaben können identisch sein, die Ownership unterscheidet sich.

Beispiel: ELT-Pipeline im Databricks Lakehouse

Ein Handelsunternehmen führt Bestell-, Produkt- und Kundendaten in einem Databricks Lakehouse zusammen. Bestellungen kommen als JSON-Dateien aus einer Shop-Plattform in einen Cloud-Objektspeicher, Produktdaten aus einer PIM-Datenbank, Kundenstammdaten aus dem CRM. Die Pipeline folgt dem ELT-Muster.

Der Extract-Load-Schritt läuft über Auto Loader (für die Shop-Dateien im Objektspeicher) und Lakeflow Connect (für die CRM- und PIM-Datenbanken per Change Data Capture). Beide Konnektoren schreiben die Rohdaten unverändert in Bronze-Delta-Tabellen. Schema-Drift wird protokolliert, aber nicht behandelt; die Bronze-Schicht bleibt vollständig und rekonstruierbar.

Die Transform-Schritte laufen als Databricks Declarative Pipelines im selben Lakehouse. Ein Silver-Modell dedupliziert Bestellungen, joint Kundenstammdaten und filtert Storno-Positionen und Testdatensätze. Ein Gold-Modell aggregiert die Silver-Tabellen zu Tageskennzahlen für BI-Konsumenten und einem Forecasting-Modell. Rechenleistung stellt der Databricks-Cluster über Photon; eine separate ETL-Engine ist nicht im Spiel. Die Reihenfolge Extract → Load → Transform ist damit vollständig umgesetzt, die Transformationslogik liegt versioniert als SQL-Code im selben System wie die Daten.