ETL versus ELT: Wo die Transformation läuft und was das ändert

Worum es geht

Die zitierte Seite des Azure Architecture Center beschreibt Extract, Transform, Load (ETL) als einen Datenintegrationsprozess, der Daten aus verschiedenen Quellen in einem einheitlichen Speicher zusammenführt, wobei die Transformationsphase von einer spezialisierten Engine ausgeführt wird, oft über Staging-Tabellen, mit typischen Operationen wie Filtern, Sortieren, Aggregieren, Verknüpfen, Bereinigen, Deduplizieren und Validieren. Sie hält fest, dass sich Extract, Load, Transform (ELT) von ETL einzig darin unterscheidet, wo die Transformation stattfindet: In der ELT-Pipeline erfolgt die Transformation im Zielspeicher selbst, mit dessen eigener Verarbeitungsleistung statt einer separaten Engine. Die Seite merkt an, dass dadurch die Transformations-Engine aus der Architektur entfällt, dass die Skalierung des Zielspeichers auch die Pipeline skaliert, und dass ELT nur dann gut funktioniert, wenn das Zielsystem leistungsfähig genug ist, um die Daten effizient zu transformieren. Werkzeuge wie dbt sitzen beim T von ELT; dessen Dokumentation beschreibt es als das Transformieren roher Warehouse-Daten in vertrauenswürdige Datenprodukte.

Warum es wichtig ist

Die Reihenfolge der Buchstaben ändert vier praktische Dinge. Wo Rechenleistung verrechnet wird: ELT bezahlt mit Abfragezeit im Warehouse, ETL mit einem separaten Cluster oder Dienst. Was roh landet: ELT kopiert Quelltabellen so, wie sie sind, daher müssen Entscheidungen zur Datenminimierung bereits bei der Extraktion oder per Zugriffskontrolle im Warehouse getroffen werden. Wie erneute Läufe funktionieren: Eine ELT-Transformation ist eine Abfrage über Daten, die noch vorhanden sind, daher bedeutet eine Korrektur, SQL erneut auszuführen; eine ETL-Korrektur erfordert unter Umständen eine erneute Extraktion aus einer Quelle, die sich inzwischen geändert hat. Wer Logik ändern kann: SQL im Warehouse ist für Analystinnen und Analysten lesbar; Code in einer separaten Engine gehört, wem auch immer diese Engine betreibt.

So wird es angewendet

• ELT wählen, wenn das Ziel ein spaltenorientiertes Warehouse oder Lakehouse ist, das das Datenvolumen bereits bewältigt, und sich die Transformationen als SQL über geladene Tabellen ausdrücken lassen.
• ETL wählen, oder einen Transformationsschritt vor dem Laden, wenn die Quelle Daten enthält, die das Ziel nie erreichen dürfen (Geheimnisse, per Richtlinie ausgeschlossene Felder), wenn das Ziel eine kleine operative Datenbank ist, oder wenn die Transformation Code oder Bibliotheken benötigt, die das Ziel nicht ausführen kann.
• In beiden Fällen den Rohextrakt unveränderlich und getrennt von transformierten Ausgaben halten, damit eine Transformation aus demselben Input reproduziert werden kann.
• Für jede Ausgabetabelle festhalten, welcher Quell-Snapshot und welche Transformationsversion sie erzeugt hat.

Stolpersteine

Alles roh zu laden und die Modellierung aufzuschieben, erzeugt ein Warehouse, das nur die Autorin oder der Autor selbst abfragen kann. Die ELT-Rechnung skaliert damit, wie oft Modelle vollständig neu gebaut werden; inkrementelle Modelle brauchen die im verwandten Artikel beschriebene Idempotenz-Disziplin. Gemischte Designs, bei denen ein Teil der Bereinigung vor und ein Teil nach dem Laden stattfindet, müssen dokumentieren, was wo geschieht, sonst wird eine Dedup-Regel am Ende zweimal oder gar nicht angewendet.