Extract Transform Load oder Extract Load Transform?

Was bedeutet ETL?

Extract (Extraktion) bedeutet: Daten werden aus einer oder mehreren Datenquellen entnommen und in einen Arbeitsbereich (Staging) übertragen. Dabei ist zu entscheiden, welche Daten relevant sind und wie häufig sie extrahiert werden (z.B. täglich, stündlich, near-real-time).

Transform (Transformation) bedeutet: Daten werden in ein einheitliches, zielkonformes Format gebracht. Dazu gehören u.a. Standardisierung (Datums-/Währungs-/Schreibweisen), Bereinigung (Fehler korrigieren/entfernen), Integration (Schlüsselabgleich, Dubletten, Referenzen) und fachliche Regeln (Business Rules).

Load (Laden) bedeutet: Daten werden in das Zielsystem geschrieben. In der Praxis unterscheidet man häufig zwischen Initial Load (einmalige Erstbeladung) und Refresh (regelmäßige Nachladung/Delta-Ladung), inklusive Protokollierung, Fehlerbehandlung und Abstimmung (Reconciliation) mit Quelle und Ziel.

Merksatz: ETL macht aus „Transaktionsdaten“ eine „Analyse-fähige Datenbasis“ – und zwar reproduzierbar, kontrollierbar und prüfbar (Audit-fähig).

Was ist der Unterschied zu ELT und wann findet das Anwendung?

Bei ETL wird vor dem Laden transformiert: Quelle → Staging/ETL → Ziel. Das passt gut, wenn das Zielsystem eher „klassisch“ ist (z.B. relationales DWH) oder wenn Transformationen zentral gesteuert, versioniert und als stabile Datenprodukte bereitgestellt werden sollen.

Bei ELT (Extract-Load-Transform) werden Daten zunächst roh oder nur leicht aufbereitet geladen (z.B. in einen Data Lake / Lakehouse) und erst im Zielsystem transformiert – oft mit SQL, Spark oder Modellierungswerkzeugen. Das ist besonders nützlich, wenn sehr große Datenmengen anfallen, Cloud-Skalierung genutzt wird und mehrere Teams unterschiedliche Sichten/Transformationen benötigen.

Praxisregel: ELT eignet sich häufig für moderne Plattformen (Lakehouse, Fabric, Databricks, BigQuery), weil Rechenleistung elastisch im Zielsystem verfügbar ist. ETL ist oft passend, wenn Transformationen streng standardisiert sind, Datenqualität früh „abgesichert“ werden soll oder Quellsysteme geschützt werden müssen (Last/Performance).

In Power BI siehst du ELT-Denken z.B. dann, wenn Rohdaten in einem Lake/SQL landen und Transformationen (Power Query/SQL) sowie das semantische Modell (DAX/Measures) darauf aufsetzen.

Welche wichtigen Schritte gibt es im ETL/ELT?

In der Praxis ist ETL nicht nur „E-T-L“, sondern ein End-to-End-Prozess mit Qualitäts- und Betriebsaspekten: Datenanbindung & Extraktionsstrategie (Voll/Delta/CDC), Staging, Datenprofiling, Datenbereinigung, Standardisierung, Integration/Key-Management, Historisierung, Validierung/Tests, Laden (Initial/Refresh), Monitoring/Logging, sowie Metadaten- und Regelmanagement.

Besonders prüfungs- und praxisrelevant: Staging/Arbeitsbereich als Puffer, um Quellsysteme und DWH im laufenden Betrieb zu schützen (Entkopplung), sowie die Idee, Daten nach Regeln zu transformieren und zu integrieren, bevor sie dauerhaft ins DWH wandern.

Optionaler Baustein: Ein ODS (Operational Data Store) kann eine integrierte, detaillierte und eher „zeitnahe“ Datenhaltung ermöglichen (z.B. für Auswertungen, die im Quellsystem schwierig sind). Er liegt konzeptionell näher am Operativen als ein historisiertes DWH.

Was unterscheidet operationale von dispositiven Daten? Kurze Zusammenfassung:

Operative Daten dienen der Abwicklung des Tagesgeschäfts: sehr aktuell, transaktions-/funktionsorientiert, granular, häufig redundant/inkonsistent, laufende Updates und konkurrierende Zugriffe.

Dispositive Daten dienen der Entscheidungsunterstützung: sachgebiets-/themenorientiert, konsistent modelliert, kontrollierte Redundanzen, historienfähig, verdichtet/transformiert, mit umfassendem Metadatenangebot für Analyse & Reporting.

Kurz gesagt: Operativ = „Was passiert gerade?“ — Dispositiv = „Was bedeutet das für Steuerung/Planung?“. ETL/ELT ist die Brücke zwischen beiden Welten.

Typische Stolpersteine im ETL-Betrieb (und wie man sie entschärft)

Häufige Ursachen für kaputte Reports sind nicht „falsche DAX-Formeln“, sondern Datenprobleme im ETL: fehlende Werte, uneinheitliche Codes (z.B. „DE“, „Deutschland“, „GER“), Dubletten, falsch interpretierte Datumsformate, oder „stille“ Schemaänderungen in Quellsystemen (neue Spalten, geänderte Bedeutung).

Gute Praxis ist daher: Data Profiling + Validierungsregeln (z.B. Wertebereiche, Referenzen), Logging (welcher Lauf, welche Anzahl, welche Fehler), und ein klarer Umgang mit Fehlern (Reject-Table/Quarantäne statt stiller Korrektur).

Ergänzend lohnt sich Metadatenpflege: Definitionen (fachlich), technische Informationen (Linage), Transformationsregeln und Historie – damit Anwender wissen, was eine Kennzahl wirklich bedeutet und wie sie entsteht.