Ratgeber & Vergleiche · Stand: 18. Oktober 2026

ETL vs. ELT: Welche Reihenfolge passt zu Ihren Daten?

Bei ETL werden Daten extrahiert, außerhalb des Zielsystems transformiert und anschließend dorthin geladen. Bei ELT gelangen die extrahierten Daten zuerst ins Ziel; die fachliche Aufbereitung übernimmt dessen Rechenumgebung. Beide dienen der Datenintegration. Für die Auswahl zählt, welche Daten ins Ziel dürfen, welche Verarbeitung dort möglich ist und wer den Ablauf verantwortet.

Die drei Buchstaben beantworten eine Architekturfrage. Wie oft Daten ankommen, welche Werkzeuge Sie einsetzen und wie viel Arbeit Sie automatisieren, sind zusätzliche Entscheidungen. Ein laufender Datenstrom kann ebenso Transformationen enthalten wie ein nächtlicher Ladeprozess.

Derselbe Datensatz, zwei Verarbeitungswege

Ein fiktives Serviceunternehmen möchte aus abgeschlossenen Vorgängen einen Tagesbericht erstellen. Die Quelldatei enthält eine Vorgangs-ID, einen Statuscode und die Erfassungszeit. Für den Bericht sollen die Codes verständliche Statusnamen erhalten und alle Zeitangaben in derselben Zeitzone vorliegen. Das Beispiel veranschaulicht die Verarbeitung; es beschreibt kein Kundenprojekt und keinen gemessenen Geschwindigkeitsvorteil.

Die fachlichen Regeln bleiben in beiden Wegen gleich. Die folgende Darstellung zeigt, an welcher Stelle sie ausgeführt werden.

ETL: Vor dem Laden aufbereiten

Extract: Ein Connector liest die vereinbarte Quelldatei. Dabei müssen bereits Umfang und erfolgreicher Abschluss des Lesens erkennbar sein. Eine fehlende Datei darf im Beispiel nicht als Tag ohne abgeschlossene Vorgänge erscheinen.

Transform: Eine separate Verarbeitungsumgebung prüft die ID, übersetzt D anhand der Statustabelle und berechnet den Berichtstag. Unbekannte Codes und ungültige Zeitangaben gelangen in einen Fehlerbereich, statt stillschweigend einen plausiblen Ersatzwert zu erhalten. Hier können auch unnötige Felder entfernt oder erforderliche Schutzmaßnahmen vor dem Ziel angewendet werden.

Load: Erst die aufbereiteten Datensätze werden in die Berichtstabelle des Zielsystems geschrieben. Die Transformationslast liegt in diesem Modell vor dem Ziel. Das kann sinnvoll sein, wenn dessen Rechenmöglichkeiten begrenzt sind oder die Aufbereitung eine besondere Verarbeitungsumgebung benötigt. Laden, Überwachung und Wiederanlauf bleiben trotzdem Aufgaben des Gesamtablaufs.

ELT: Im Ziel aufbereiten

Extract: Der Connector liest dieselben Vorgänge. Load: Die für diese Umgebung zugelassenen Quelldaten gelangen zunächst in einen eingeschränkten Rohdatenbereich der Zielplattform. Transform: Dort übersetzt beispielsweise SQL den Status und berechnet den Berichtstag. Erst das geprüfte Ergebnis wird für den Bericht freigegeben.

Die Plattform muss dafür ausreichend Rechenleistung und die benötigten Funktionen bereitstellen. Ein möglicher Nutzen liegt in der erneuten Verarbeitung: Ändert sich die fachliche Statuszuordnung, lässt sich aus aufbewahrten Quelldaten eine weitere Auswertung erzeugen. Ob das möglich ist, hängt von deren Vollständigkeit und Aufbewahrungsdauer ab. Rohdaten benötigen eigene Berechtigungen; ihre Speicherung und wiederholte Verarbeitung verursachen ebenfalls Aufwand.

ETL und ELT nach denselben Kriterien vergleichen

Strukturierte oder unstrukturierte Daten entscheiden die Reihenfolge nicht allein. Auch bei ELT können vorab Dateiformate geprüft und Datensätze gefiltert werden. Entscheidend ist, wo die wesentliche fachliche Transformation stattfindet. Cloudplattformen können dafür geeignete Rechenfähigkeiten bereitstellen; „Cloud“ gehört jedoch nicht zur Definition von ELT. Microsoft nennt ausdrücklich Zielkapazität und benötigte Transformationsfunktionen als Auswahlbedingungen.

Geschwindigkeit und Kosten am fertigen Ergebnis beurteilen

Unterscheiden Sie zwei Zeitpunkte: Wann sind die Daten im Ziel angekommen, und wann ist der fachlich verwendbare Bericht verfügbar? Ein schnell abgeschlossener Rohdatenimport beantwortet nur die erste Frage. Nachgelagerte Transformationen können den zweiten Zeitpunkt bestimmen. Bei ETL muss die vorgeschaltete Verarbeitung in dieselbe Betrachtung eingehen.

Vergleichen Sie für einen repräsentativen Lauf den Datentransfer, eine mögliche Zwischenablage, die Transformationsumgebung, Zielrechenleistung, Wiederholungen und Betriebsarbeit. Betrachten Sie außerdem Spitzenlast: Konkurriert die ELT-Aufbereitung im Ziel mit interaktiven Berichten? Wartet die ETL-Kette auf eine stark ausgelastete vorgelagerte Engine? Ein einzelner ruhiger Testlauf zeigt diese Abhängigkeiten nicht.

Für das Servicebeispiel wäre eine passende Messgröße der Zeitpunkt, ab dem der vollständige Tagesbericht mit geprüften Statuszuordnungen bereitsteht. Zusätzlich wird erfasst, was ein korrigierter und erneut ausgeführter Lauf kostet. Aus der Reihenfolge allein lässt sich weder eine Laufzeit noch eine Einsparung ableiten.

Welche Rohdaten dürfen bis wohin gelangen?

Klären Sie vor der technischen Auswahl, welche Felder der Bericht benötigt und ob deren Übertragung und Speicherung in der vorgesehenen Umgebung zulässig sind. Ein Datensatz kann Informationen enthalten, die für die Auswertung überflüssig sind. Vorab reduzieren, maskieren oder pseudonymisieren sind mögliche Maßnahmen; keine davon ersetzt die Prüfung von Zweck, Berechtigung und Aufbewahrung.

Beim ELT-Weg sollte deshalb nicht jeder Berichtsleser auch den Rohdatenbereich öffnen können. Trennen Sie dessen Zugriff von den freigegebenen Ergebnissen und legen Sie fest, wann Rohdaten gelöscht werden. Dieselben Fragen gelten für Zwischenablagen im ETL-Weg. Die Buchstabenfolge ist kein Nachweis für Datenschutz oder Sicherheit.

So wählen oder kombinieren Sie die Wege

Beginnen Sie mit der Rohdatengrenze und prüfen Sie anschließend die Verarbeitung:

1. Dürfen die benötigten Ausgangsdaten ins Ziel? Falls bestimmte Inhalte dort nicht ankommen sollen, gehört deren Entfernung oder geeignete Vorverarbeitung vor diese Grenze.
2. Kann das Ziel die fachlichen Regeln zuverlässig ausführen? Prüfen Sie benötigte Funktionen und Kapazität. Eine vorhandene SQL-Umgebung allein beantwortet noch nicht jede Anforderung.
3. Wie häufig ändern sich Fragen und Regeln? Sollen dieselben zulässigen Rohdaten unterschiedlich ausgewertet werden, kann ihre begrenzte Aufbewahrung im Ziel hilfreich sein.
4. Wer kann die gewählte Lösung betreiben? Berücksichtigen Sie Kenntnisse, Freigaben, Fehlersuche und Bereitschaftsdienst ebenso wie die Erstentwicklung.

Im Servicebeispiel könnte eine Quelldatei zusätzlich Namen und private Telefonnummern enthalten, die der Tagesbericht nicht braucht. Ein hybrider Ablauf entfernt diese Felder vor dem Laden. Statusübersetzung und Zeitzonenberechnung erfolgen anschließend im Ziel. Die Vorverarbeitung und der spätere ELT-Schritt erfüllen unterschiedliche Aufgaben.

Weder eine große Datenmenge noch ein älteres Quellsystem legt damit automatisch einen Weg fest. Die tragfähige Entscheidung lautet konkret: Diese Felder gelangen unter diesen Bedingungen bis zu dieser Grenze; diese Regeln laufen in dieser Umgebung; dieses Team übernimmt Fehler und Änderungen.

Batch oder Streaming separat festlegen

Ein täglicher Bericht kann mit einem abgeschlossenen Stapel von Vorgängen arbeiten. Eine laufende Serviceanzeige benötigt eventuell Änderungen während des Tages. Legen Sie dafür die fachlich benötigte Aktualität fest und prüfen Sie, ob die Quelle sie liefern kann. Häufigere Ausführung vergrößert auch den zu betreibenden Ablauf.

Streaming kann selbst Transformationen enthalten. Beispielsweise unterstützt PySpark mit Structured Streaming die fortlaufende Verarbeitung auf dem Spark-SQL-Unterbau. Das ist eine konkrete Werkzeugfähigkeit, keine Echtzeitgarantie für ELT. Definieren und messen Sie stattdessen die Verzögerung zwischen Quelländerung und verwendbarem Ergebnis.

Welche Aufgaben Pipeline und Werkzeuge übernehmen

Eine Pipeline verbindet die Arbeitsschritte einschließlich ihrer Abhängigkeiten und Zustände. Sie braucht mehr als eine Transformationsfunktion: Wer startet den Lauf? Was bedeutet „erfolgreich“? Darf nach einem Teilfehler erneut geschrieben werden? Wann wird ein Ergebnis sichtbar? Microsoft unterscheidet dafür den Datenfluss von der Steuerung seiner Aufgaben.

Ein Connector stellt den Zugang zur Quelle her. Eine Bibliothek hilft beim Lesen oder Umformen. Eine Orchestrierung steuert Aufgaben und deren Abhängigkeiten. Eine Integrationsplattform kann mehrere dieser Fähigkeiten bündeln. Prüfen Sie deshalb zuerst die erforderlichen Aufgaben und anschließend, welche davon ein vorhandenes Werkzeug tatsächlich trägt.

Was Python bei ETL übernimmt

Mit Python lassen sich Daten lesen, umformen, validieren und schreiben. Die Sprache ist besonders dann eine Option, wenn Regeln präzise im Code ausgedrückt und passende Bibliotheken eingebunden werden sollen. Beim Beispiel wären Statusübersetzung und Prüfung fehlerhafter Zeitangaben überschaubare Aufgaben.

Der Code benötigt jedoch eine Betriebsumgebung. Verfügbarer Arbeitsspeicher, Datenmengen, Parallelisierung, Bibliotheksabhängigkeiten, Tests und Wartung gehören zur Entscheidung. Ein erfolgreiches Skript auf einem Arbeitsplatzrechner ist noch kein vollständig betriebener Datenprozess.

Fünf Namen mit unterschiedlichen Rollen

Diese Zuordnung folgt den Projektinformationen von pandas, SQLAlchemy, Airflow und Luigi. Die fünf Namen sind deshalb keine Liste austauschbarer Komplettprodukte.

Mit einem kleinen Ablauf lernen

Für einen ersten Versuch reichen wenige bekannte Vorgänge und die Frage, wie viele davon je Berichtstag abgeschlossen wurden. Lesen Sie zunächst nur die Quelle und prüfen Sie den Umfang. Führen Sie danach die Status- und Zeitregeln aus. Laden Sie zuletzt das Ergebnis und vergleichen Sie es mit den erwarteten Datensätzen.

Wiederholen Sie den Lauf absichtlich. Fügt er Vorgänge doppelt ein? Testen Sie außerdem einen unbekannten Status, einen ungültigen Zeitwert und eine fehlende Quelldatei. Erst wenn diese Fälle nachvollziehbar behandelt werden, lässt sich beurteilen, ob die Aufteilung der Schritte funktioniert. Das ist ein eigener Lernvorschlag, keine an ein bestimmtes Produkt gebundene Kursfolge.

Einen bestehenden ETL-Prozess auf ELT umstellen

Erfassen Sie vor einer Verlagerung die tatsächliche Logik: Quellzugänge, Filter, Schlüssel, Typumwandlungen, Qualitätsregeln, nachgelagerte Berichte und Ausführungsabhängigkeiten. Eine sichtbare SQL-Abfrage kann weitere Regeln in vorgeschalteten Skripten oder manuellen Tätigkeiten voraussetzen. Prüfen Sie auch, ob die Zielkapazität Transformation und bestehende Nutzerlast gleichzeitig tragen soll.

Vereinbaren Sie, wer die neuen Abläufe entwickelt, fachlich freigibt und betreibt. Dazu gehören die nötigen Fähigkeiten und Zugriffsrechte. Vergleichen Sie alte und neue Ergebnisse anhand derselben Quelldaten, einschließlich Fehler- und Wiederholungsfällen. Bestimmen Sie vor der Umschaltung, wie ein fehlgeschlagener neuer Lauf behandelt wird und ob der bisherige Weg noch einen gültigen Rückfall bietet.

Eine neue Plattform erfordert keinen vollständigen Umstieg. Im Servicebeispiel kann die bewährte Extraktion bleiben, während nur die fachliche Aufbereitung verlagert wird. Übernommen werden sollte dabei auch die Kenntnis, warum die bisherigen Regeln existieren.

Über den einzelnen Datenlauf hinaus automatisieren

ETL oder ELT beschreibt nicht den gesamten Lebenszyklus eines Data Warehouse. Vor der ersten Extraktion müssen Anforderung und Datenmodell geklärt sein. Nach der Entwicklung bleiben Tests, Bereitstellung, Dokumentation, Betrieb und spätere Änderungen. Diese Arbeit kann ebenfalls automatisiert oder durch Werkzeuge unterstützt werden, unabhängig von der Transformationsreihenfolge.

Sieben Anlässe für zusätzliche Automatisierung

Prüfen Sie den wiederkehrenden Aufwand anhand konkreter Situationen:

1. Unklare Anforderungen: Muss das Team häufig nachvollziehen, welche Quelle eine gewünschte Kennzahl überhaupt tragen kann? Eine dokumentierte Erkundung hilft, bevor Code generiert wird.
2. Wechselnde Anforderungen: Werden Datenmodelle und Regeln regelmäßig angepasst? Änderungen sollten versioniert und betroffene Ergebnisse auffindbar sein.
3. Wiederholte manuelle Entwicklung: Entstehen ähnliche Tabellen und SQL-Schritte immer wieder von Hand? Vorlagen können gemeinsame Regeln konsistent anwenden.
4. Uneinheitliche Standards und Dokumentation: Fehlen nachvollziehbare Benennungen, Herkunft oder Beschreibungen? Gemeinsame Metadaten können diese Arbeit mit der Entwicklung verbinden.
5. Quelländerungen: Werden neue Felder oder andere Codes erst im fehlerhaften Bericht entdeckt? Eine Prüfung des vereinbarten Quellformats kann früher ansetzen.
6. Langsame Bereitstellung: Wartet eine geprüfte Änderung lange auf manuelle Übergaben und Deployment? Ein wiederholbarer Freigabeablauf kann dort ansetzen.
7. Aufwendiger Betrieb: Erfordern Fehler, Wiederanläufe und Wartung regelmäßig dieselben Handgriffe? Diese Schritte lassen sich gezielt vereinheitlichen.

Jeder Anlass benennt zunächst ein Problem, noch keinen Kaufgrund. Für einen kleinen einmaligen Import kann eine weitere Plattform mehr Integrationsaufwand als Nutzen verursachen. Automatisierung löst auch keine fachlich ungeklärte Kennzahl von selbst.

Metadaten bis zum betroffenen Bericht verfolgen

Für das Beispiel wären mindestens Quellfeld, Zielfeld, Transformationsregel, Abhängigkeit, Laufzustand und fachliche Beschreibung zu dokumentieren. Ändert die Quelle den Code für abgeschlossene Vorgänge von D zu DONE, muss erkennbar sein, welche Übersetzung und welcher Tagesbericht davon abhängen. Dann kann das Team die Regel anpassen und die Auswirkung prüfen.

Ob ein Produkt diese Informationen automatisch gewinnt, daraus Verarbeitung erzeugt oder Abhängigkeiten aktuell hält, ist eine konkret zu prüfende Fähigkeit. Die Bedeutung von „abgeschlossen“ und die fachliche Abnahme bleiben beim verantwortlichen Team. Eine gezeichnete Verbindung zwischen Tabellen beantwortet diese Frage noch nicht.

Vorhandene Verarbeitung einbinden

Brauchbare Connectoren, Transformationslogik und Schnittstellen können weiterverwendet werden. Beispielsweise lässt sich eine vorhandene Statusübersetzung in einen geregelten Ausführungs- und Freigabeablauf einbetten, während Metadaten und Betriebsbeobachtung ergänzt werden. Dafür müssen Aufruf, Ein- und Ausgabe, Fehlerzustände und Zuständigkeit klar sein.

Vergleichen Sie den Nutzen mit den Kosten für Integration, zusätzliche Abhängigkeiten und Pflege. Eine tragfähige Kombination erhält funktionierende Teile und verbessert die tatsächlich schwache Stelle im Lebenszyklus.

KI und Low-Code mit überprüfbaren Aufgaben einsetzen

Als mögliche Hilfen lassen sich Vorschläge für Feldzuordnungen, Transformationscode oder Qualitätsregeln beurteilen. Prüfen Sie am Servicefall etwa, ob eine vorgeschlagene Statusübersetzung alle bekannten Codes abdeckt und unbekannte Werte sichtbar lässt. Ein plausibel formulierter Vorschlag ist noch keine fachliche Freigabe.

Zugriffsrechte, zulässige Eingabedaten, menschliche Verantwortung und Ergebnisprüfung gehören deshalb auch zu solchen Werkzeugen. Ob sie einen Nutzen bringen, lässt sich an der konkreten Aufgabe prüfen; eine Entwicklung hin zu mehr Echtzeit oder Automatisierung ist kein Grund, sie überall einzuführen.

Wenn Sie die Transformationsreihenfolge zusammen mit Plattform, Datenzugängen und Betrieb festlegen möchten, bietet Cloud Data & Intelligence von eBiz einen passenden Anknüpfungspunkt. Als Ausgangspunkt genügt ein nachvollziehbarer Datenweg mit einer offenen Entscheidung – beispielsweise, welche Aufbereitung vor der Zielgrenze erforderlich ist und welche im Ziel bleiben kann.