ETL vs. ELT: Pipeline-Diagramme, Trade-offs und wann sich welcher Ansatz eignet

Die Finanzabteilung möchte den Umsatz nach Rabattcode für die letzten zwei Jahre. In einem Unternehmen ist das eine kleine SQL-Änderung und ein Neuaufbau, weil jede jemals geladene Bestellzeile noch in einer Rohtabelle liegt. In einem anderen hat der nächtliche Job die Rabattspalte nie behalten, also ändert jemand den Job und extrahiert zwei Jahre Historie erneut aus der Produktion.

Der Unterschied liegt darin, wo die Transformation läuft. ETL (Extract, Transform, Load) bringt Daten auf einer separaten Engine in Form, bevor sie das Warehouse erreichen. ELT (Extract, Load, Transform) kopiert Rohdaten ins Warehouse und formt sie dort mit SQL. Diese Entscheidung bestimmt deine Compute-Rechnung, wie aktuell die Daten sind, wie leicht sich Logik ändern lässt und wo personenbezogene Daten landen.

Dieser Beitrag geht beide Pipelines durch, vergleicht sie, zeigt, wo ETL weiterhin gewinnt und wie der verbreitete Hybrid aussieht, und endet mit einem Diagramm, das beide nebeneinanderstellt.

Wie eine ETL-Pipeline funktioniert

Bei ETL sitzt eine Transformations-Engine zwischen den Quellen und dem Warehouse. Ein nächtlicher Lauf:

1. Extrahiert neue und geänderte Zeilen, per Abfrage auf eine updated_at-Spalte oder aus einem Change-Data-Capture-Stream.
2. Transformiert sie auf der Engine: Werte bereinigen, Duplikate entfernen, Referenzdaten joinen, personenbezogene Daten maskieren und das Ergebnis in Fakten- und Dimensionstabellen umformen.
3. Lädt das Ergebnis per Insert oder Merge ins Warehouse.

Die Engine kann Informatica, SQL Server Integration Services (SSIS), ein Spark-Job oder ein Python-Skript sein. Rohe Extrakte liegen oft in einem Staging-Bereich, den der Job nach einem erfolgreichen Lauf leert, sodass das Warehouse keine Frage beantworten kann, die der Job nicht vorhergesehen hat.

Wie eine ELT-Pipeline funktioniert

Bei ELT übernimmt das Warehouse die Transformationsarbeit:

1. Extrahieren und laden. Ein Loader wie Fivetran oder Airbyte kopiert Quelltabellen nahezu unverändert in ein raw-Schema und fügt Metadatenspalten wie _fivetran_synced oder _airbyte_extracted_at hinzu, die festhalten, wann jede Zeile synchronisiert wurde.
2. Transformieren. SQL-Modelle, meist mit dbt verwaltet, lesen die Rohtabellen und bauen daraus bereinigte und verknüpfte Tabellen in anderen Schemas.
3. Bereitstellen. BI-Tools fragen die finalen Tabellen ab, die meist Marts heißen.

ELT hat sich mit Cloud-Warehouses verbreitet, die Speicher und Compute trennen, etwa BigQuery und Snowflake: Rohkopien sind günstig aufzubewahren, und die Transformationskapazität skaliert mit dem Warehouse. Weil jede geladene Zeile erhalten bleibt, kannst du ein Modell korrigieren, eine Spalte ergänzen oder eine neue Metrik definieren und aus der Historie neu aufbauen, ohne die Quelle anzufassen.

ETL und ELT im Vergleich

Zeitpläne zählen mehr als das Akronym: Der Standard-Sync von Fivetran läuft alle sechs Stunden, das ist weniger aktuell als ein stündlicher ETL-Job.

Wann ETL weiterhin gewinnt

• Personenbezogene Daten dürfen nicht roh landen. Wenn E-Mail-Adressen oder Kartennummern im Klartext nie das Warehouse erreichen dürfen, maskiere sie vor dem Laden. Maskierungsrichtlinien im Warehouse ändern nichts daran, was gespeichert ist: Dynamic Data Masking von Snowflake, ein Feature der Enterprise Edition, maskiert Klartextwerte zur Abfragezeit.
• Das Ziel kann nicht transformieren. Ein Legacy-Warehouse mit fester Kapazität, ein Suchindex oder die Dateiablage eines Partners erwarten fertige Daten.
• Anreicherung, die SQL schlecht beherrscht, etwa API-Aufrufe pro Zeile, Geocoding, PDF-Parsing oder Model-Scoring, passt oft besser in Python oder Spark.
• Streaming mit knapper Latenz. Apache Flink oder Kafka Streams transformieren Events Sekunden nach ihrem Eintreten; das Kafka-Architekturdiagramm zeigt, woraus sie lesen.
• Volumen, das du nicht aufbewahren willst. 10.000 Sensoren mit einem Messwert pro Sekunde erzeugen 864 Millionen Zeilen pro Tag (10.000 × 86.400). Minutenmittelwerte, die vor dem Laden berechnet werden, senken das auf 14,4 Millionen (10.000 × 1.440), 60-mal weniger.

Der verbreitete Hybrid

In der Praxis enthalten viele ELT-Pipelines eine kleine Transformation vor dem Laden, manchmal EtLT geschrieben. Transformiere unterwegs nur, was nie roh landen darf; erledige alles andere im Warehouse, wo es versioniert, getestet und leicht neu aufzubauen ist.

Für personenbezogene Daten hasht das Column Hashing von Fivetran eine Spalte während des Syncs mit SHA-256 und einem Salt pro Ziel, sodass sich gehashte E-Mail-Adressen weiterhin joinen lassen; Data Blocking lässt eine Spalte ganz weg. Die Mappings von Airbyte können Felder pro Stream hashen oder verschlüsseln. Egal mit welchem Tool: Bevorzuge einen gesalzenen Hash, denn ein einfacher SHA-256-Hash einer E-Mail-Adresse lässt sich mit einer Liste bekannter Adressen abgleichen. Zwei weitere Einschränkungen: Hashing gilt für künftige Syncs, die Historie braucht also einen Re-Sync, und ein gesalzener Hash ist eine Pseudonymisierung, keine Anonymisierung. Nach der DSGVO sind pseudonymisierte Daten weiterhin personenbezogene Daten (Erwägungsgrund 26). Dieser Beitrag ist keine Rechtsberatung; lies den offiziellen Text mit deinem Datenschutzteam und führe eine Datenlandkarte, die zeigt, wohin personenbezogene Daten fließen.

ELT mit geschichteten SQL-Modellen

Der Leitfaden zur Projektstruktur von dbt beschreibt drei Schichten, die mit jedem SQL-Tool funktionieren:

Lakehouses nutzen dieselbe Idee unter den Namen Bronze, Silber und Gold; siehe das Medallion-Architekturdiagramm.

dbt bringt vier generische Datentests mit, unique, not_null, accepted_values und relationships, und jede Abfrage, die fehlerhafte Zeilen zurückgibt, kann zu einem Test werden. Freshness-Checks erkennen einen Loader, der still und leise stehen geblieben ist. Eine einzige Source-Definition deklariert beides:

sources:
  - name: shop
    schema: raw_shop
    config:
      loaded_at_field: _fivetran_synced
      freshness:
        warn_after: {count: 12, period: hour}
        error_after: {count: 24, period: hour}
    tables:
      - name: orders
        columns:
          - name: id
            data_tests:
              - unique
              - not_null

dbt source freshness (oder dbt freshness in dbt v2) warnt, wenn der neueste _fivetran_synced-Wert älter als 12 Stunden ist, und meldet nach 24 Stunden einen Fehler.

Orchestrierung und Datenqualität

Ein Orchestrator führt die Schritte der Reihe nach aus. In Airflow stößt ein DAG (Tasks mit Abhängigkeiten und einem Zeitplan) den Sync des Loaders an, wartet darauf und führt dann dbt aus. Die dbt-Integration von Dagster macht aus jedem dbt-Modell ein Asset, also eine Tabelle, die existieren sollte, sodass ein Mart direkt von der Tabelle abhängen kann, die ein Fivetran-Sync schreibt.

So oder so hält dbt build schlechte Daten aus den Dashboards fern: Es führt Modelle, Tests, Snapshots und Seeds in DAG-Reihenfolge aus, und bei einem fehlschlagenden Test wird alles Nachgelagerte übersprungen. Ergänze Freshness-Checks und einen Alert an das verantwortliche Team, dann fallen falsche wie veraltete Daten auf, bevor ein Stakeholder es merkt.

Reverse ETL, bei Airbyte Data Activation genannt, läuft in die andere Richtung: Es kopiert modellierte Daten aus dem Warehouse in Tools wie ein CRM oder einen Support-Desk. Zum Zeitpunkt des Schreibens (November 2026) bietet Hightouch es als eigenständiges Produkt an, während Fivetran (das Census übernommen hat) und Airbyte es zusammen mit der Ingestion anbieten.

Das ETL-vs.-ELT-Diagramm

So liest du es:

• Zwei Bahnen, gleiche Enden: dieselbe Postgres-Bestelldatenbank und dieselben BI-Dashboards. Nur die Mitte ändert sich.
• Bernstein markiert die Transformation: bei ETL eine separate Engine vor dem Warehouse, bei ELT der Kasten mit den dbt-Modellen im Warehouse.
• Die Warehouse-Rahmen zeigen, was gespeichert ist. Der von ETL enthält nur fct_orders; der von ELT enthält raw.orders wie geladen, die Modelle und marts.fct_orders.
• Die lila Kante ist der Hybrid: Der Loader hasht personenbezogene Daten, bevor die Zeilen landen.
• Der Markdown-Block listet die Ausführungsreihenfolge von ELT, die Freshness-Schwellen und welches Schema BI liest.

ETL- und ELT-Diagramme klar zeichnen

• Zeichne die Transformation dort, wo sie läuft. Wer die ELT-Transformation außerhalb des Warehouse zeichnet, versteckt ihre größten Kosten und Risiken.
• Zeichne das Warehouse als Grenze. Raw, Staging und Marts in einem Rahmen sind Schemas in einem System, keine separaten Datenbanken.
• Beschrifte Kanten mit dem, was fließt (Rohzeilen, gehashte Zeilen, gebaute Tabellen), und mit dem Zeitplan, wenn er wichtig ist.
• Markiere, wo personenbezogene Daten maskiert werden und wo sie noch im Klartext existieren.
• Zeig Schichten, nicht jedes Modell. Eine Beispieltabelle pro Schicht reicht; die Lineage gehört in die von dbt generierte Doku.
• Halte den Kontrollfluss getrennt. Zeichne Trigger des Orchestrators als gestrichelte Kanten, damit niemand sie für Daten hält.

Das Architekturdiagramm einer Datenpipeline zeigt eine vollständige Pipeline mit CDC, Kafka und einem Warehouse.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge zwei Rahmen-Nodes aus dem Basis-Pack übereinander für die ETL- und die ELT-Bahn hinzu und in jeder Bahn an derselben horizontalen Position einen verschachtelten Rahmen für das Warehouse.
3. Füge in der ETL-Bahn einen Postgres-Node aus dem Daten-Pack, einen Kasten aus dem Basis-Pack für die Transformations-Engine, einen Datenlager-Node aus dem Daten-Pack für fct_orders im Warehouse-Rahmen und einen Kasten aus dem Basis-Pack für BI hinzu. Beschrifte die Kanten mit „raw rows“, „cleaned and conformed rows“ und „SQL queries“.
4. Füge in der ELT-Bahn einen Postgres-Node und einen Kasten aus dem Basis-Pack für den Loader hinzu. Setz in den Warehouse-Rahmen Datenlager-Nodes für raw.orders und marts.fct_orders und dazwischen einen Kasten aus dem Basis-Pack für die dbt-Modelle. Schließ mit einem Kasten aus dem Basis-Pack für BI ab und beschrifte die Kanten genauso.
5. Färbe beide Transformationskästen bernsteinfarben und die ausgehende Kante des Loaders lila. Füge unter den Nodes, die eine Erklärung brauchen, Text-Notizen aus dem Basis-Pack hinzu, dazu eine kurze Farblegende.
6. Füge einen Markdown-Block aus dem Basis-Pack mit der Ausführungsreihenfolge und den Freshness-Schwellen hinzu.

Wenn die Pipeline schon als Mermaid-Flowchart existiert, füge sie für einen ersten Entwurf in das Tool Mermaid-Flowchart als bearbeitbares Diagramm ein. Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan.

FAQ

Was ist der Unterschied zwischen ETL und ELT? Wo die Transformation läuft. ETL transformiert Daten auf einer separaten Engine und lädt nur das Ergebnis. ELT lädt zuerst Rohdaten ins Warehouse und transformiert sie dort mit SQL, sodass die Rohkopie für einen Neuaufbau verfügbar bleibt.

Ist ETL veraltet? Nein. ELT ist auf Cloud-Warehouses der übliche Standard, aber ETL passt weiterhin, wenn personenbezogene Daten maskiert werden müssen, bevor sie landen, wenn das Ziel nicht transformieren kann, und für aufwendige Anreicherung oder Streaming mit niedriger Latenz.

Ist dbt ein ETL-Tool? dbt deckt das T in ELT ab. Es führt SQL-Modelle und Tests in deinem Warehouse aus, extrahiert oder lädt aber keine Daten; das übernimmt ein Loader wie Fivetran oder Airbyte.

Ist ELT günstiger als ETL? Das hängt von Volumen und Gewohnheiten ab. ELT spart die separate Engine, rechnet aber jeden Modelllauf als Warehouse-Compute ab und speichert Rohkopien. Inkrementelle Modelle halten die Kosten niedrig; stündliche vollständige Neuaufbauten großer Tabellen nicht.

Was ist Reverse ETL? Das Kopieren modellierter Daten aus dem Warehouse in operative Tools wie ein CRM. Es sollte aus Marts lesen, nach Zeitplan laufen und dieselben Tests und dieselbe klare Verantwortung bekommen wie jede andere Pipeline.

Kostenlos starten — ein Seat, keine Kreditkarte.