ETL steht für Extract, Transform, Load (auf Deutsch: Auslesen, Umformen, Laden). Das Verfahren holt Daten aus verschiedenen Vorsystemen (etwa ERP-, CRM- oder Buchhaltungssystemen), bereitet sie auf einem eigenen Rechner (der Transformations-Engine) auf und schreibt erst das fertige Ergebnis in das Ziel-System, meist ein zentrales Auswertungs-System (Data-Warehouse). Der Ansatz stammt aus einer Zeit, in der Speicher und Rechenleistung in diesen Ziel-Systemen knapp und teuer waren.
Was ist ETL?
ETL ist eine feste Reihenfolge aus drei Schritten für den Datentransport zwischen Systemen. Extract (Auslesen) holt die Daten aus dem laufenden Betrieb, zum Beispiel aus einer Kundendatenbank, aus Excel- oder Text-Dateien, aus Altsystemen (Mainframes) oder aus einem SAP-System. Transform (Umformen) findet auf einem separaten Rechner statt, nicht im späteren Auswertungs-System: Dubletten werden entfernt, Kennungen aus verschiedenen Systemen (etwa Kundennummern) auf ein gemeinsames Format gebracht, Kennzahlen berechnet und feste Geschäftsregeln angewendet. Load (Laden) schreibt am Ende nur die fertig aufbereiteten Daten in das Ziel-System, klassisch ein Data-Warehouse wie Teradata, Oracle Exadata, SAP BW oder Netezza.
Der Ansatz ist an eine historische technische Voraussetzung gebunden. In der klassischen Warehouse-Ära waren Storage und Compute im Zielsystem eng gekoppelt: CPUs und Speicher wurden gemeinsam mit der Appliance gekauft, waren teuer und für Reporting-Queries reserviert. Transformationslasten hätten den Reporting-Betrieb blockiert. Also lief die Transformation auf separaten ETL-Servern mit eigener Rechenleistung und eigenem Zwischenspeicher, oft im nächtlichen Batch-Fenster. Als spezialisierte Werkzeuge etablierten sich Informatica PowerCenter, IBM DataStage, SAP Data Services, Microsoft SSIS, Talend und Ab Initio. Sie brachten grafische Mapping-Editoren, Scheduler und Metadaten-Repositories mit und wurden zum Standard-Baustein in Warehouse-Projekten der 2000er und 2010er.
Historisch entstand das ETL-Muster aus der Data-Warehouse-Literatur der 1990er (Kimball, Inmon) als kanonisches Verfahren, um heterogene operative Systeme in ein integriertes, historisiertes und analysetaugliches Zielmodell zu überführen. Der Begriff bezeichnet dabei das Reihenfolge-Muster und die Trennung der Transformationslast vom Zielsystem, nicht eine konkrete technische Implementierung. Die Ausführung reicht von SQL-Prozeduren auf einer Zwischen-Datenbank über grafische Mapping-Tools bis zu Custom-Code in COBOL oder PL/SQL.
In modernen Cloud-Warehouse- und Lakehouse-Architekturen kehrt sich die Reihenfolge häufig um: Rohdaten werden zuerst in das elastisch skalierende Zielsystem geladen und dort transformiert. Das ist das ELT-Muster. ETL bleibt trotzdem präsent, weil viele produktive Datenlandschaften weiter auf klassischen Warehouse-Stacks laufen, Migrationsaufwand hoch ist und regulierte Umgebungen bestehende ETL-Strecken schwer ablösen. Bank-, Versicherungs- und SAP-BW-Landschaften sind typische Vertreter.
Abgrenzung zu ELT, Zero-ETL, Reverse ETL und Data Integration
ETL wird häufig mit verwandten Begriffen verwechselt, die im Umfeld von Datenintegration, Warehouse und Lakehouse zirkulieren. Die folgende Tabelle sortiert die häufigsten Verwechslungen.
| Begriff | Verhältnis zu ETL | Kernunterschied |
|---|---|---|
| ELT | Umgekehrte Reihenfolge | ELT lädt Rohdaten zuerst in das Zielsystem und transformiert dort mit dessen Compute. ETL transformiert vorher in einer separaten Engine (Informatica, DataStage, SSIS, Talend). |
| Zero-ETL | Betriebs-Form | Zero-ETL ist ein Managed-Angebot eines Cloud-Anbieters, das die Pipeline zwischen zwei Systemen verwaltet und für den Nutzer unsichtbar macht (AWS Aurora zu Redshift, Snowflake Unistore, OneLake-Mirroring). ETL liegt beim Datenteam. |
| Reverse ETL | Gegenrichtung | Reverse ETL transportiert transformierte Daten aus dem Warehouse oder Lakehouse zurück in operative Systeme (CRM, Marketing-Tools, Ad-Plattformen). ETL bewegt Rohdaten in Richtung Analytik. |
| Data Integration | Oberbegriff | Data Integration umfasst ETL, ELT, Change Data Capture, Data Federation, Data Virtualization und Data Sharing. ETL ist eine Ausprägung dieses Oberbegriffs. |
| Data Pipeline | Umgebender Fluss | Data Pipeline beschreibt den Ende-zu-Ende-Fluss inklusive Orchestrierung, Monitoring und Deployment. ETL beschreibt das Reihenfolge-Muster innerhalb dieser Pipeline. |
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: ETL-Strecke in einem SAP-BW-Warehouse
Ein Versicherungsunternehmen betreibt ein SAP-BW-Warehouse als zentrales analytisches Repository für Vertriebs-, Schaden- und Bestandsdaten. Die Datenquellen sind heterogen: das operative Vertragssystem in S/4HANA, ein Legacy-Schadensystem auf Oracle, ein externes Bonitäts-Feed als CSV und ein Provisions-System auf einer eigenen Datenbank. Die Analytik-Strecke folgt dem ETL-Muster.
Der Extract-Schritt läuft nächtlich. SAP-Extraktoren (ODP, LO-Cockpit) ziehen die relevanten Deltas aus S/4HANA, ein JDBC-Konnektor liest das Oracle-Schadensystem, ein File-Watcher greift die CSV-Bonitäts-Feeds ab, ein weiterer JDBC-Konnektor bedient das Provisions-System. Die Rohdaten landen in einer Staging-Zone außerhalb des BW, meist in einem separaten Datenbank-Schema oder auf einem Datei-Server.
Der Transform-Schritt läuft auf einer dedizierten ETL-Engine wie SAP Data Services oder Informatica PowerCenter. Die Mappings deduplizieren Vertragsnummern, konformisieren Vertriebseinheiten und Produktschlüssel aus den drei Systemen, filtern Testdatensätze und Storno-Positionen, berechnen abgeleitete Kennzahlen wie Jahresprämie und Deckungsbeitrag und historisieren Änderungen als Slowly Changing Dimensions. Business-Regeln (Provisionsberechnung, Bonitäts-Klassifizierung) laufen als deklarative Transformationen im ETL-Mapping.
Erst danach kommt der Load: Die aufbereiteten Daten werden in InfoObjects, DataStore-Objects und InfoCubes des BW geschrieben und dort für BusinessObjects- und SAP-Analytics-Cloud-Reporting bereitgestellt. Die BW-Datenbank sieht ausschließlich fertige, konsumierbare Strukturen. Die Rohdaten und Zwischenergebnisse bleiben in der Staging-Zone außerhalb des Warehouse, die Rechenlast der Transformation auf der ETL-Engine. Genau diese Architektur beschreibt der Begriff ETL.
ETL im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.
Entscheidungs-Frame zwischen den beiden Reihenfolge-Mustern
Data Engineering auf DatabricksCluster-Kontext für Ingest, Transformation und Orchestrierung im Lakehouse
Data Ingestion auf DatabricksExtract-und-Load-Schritt in modernen Pipelines
Databricks Declarative Pipelinesdeklarative Laufzeit für Transformations-Modelle im Zielsystem
ELTReihenfolge-Muster mit umgekehrter Abfolge und Transformation im Zielsystem
Zero-ETLManaged-Betriebs-Form, bei der die Pipeline vom Anbieter verwaltet wird
Data Transformationder reine Umformungs-Schritt in ETL und ELT
Data IntegrationOberbegriff über ETL, ELT, CDC und weitere Verfahren
Data IngestionExtract-und-Load-Muster ohne Transformation
Data Pipelineumgebender Ende-zu-Ende-Fluss inklusive Orchestrierung
Data FlowDatenfluss-Perspektive quer zu Pipeline und Reihenfolge-Muster
Change Data CaptureExtract-Verfahren mit niedriger Latenz
Data Warehouseklassische Ziel-Architektur für ETL
Data Lakehousemoderne Ziel-Architektur, in der eher ELT trägt