Der moderne ELT-Stack erklärt: dbt, Ingestion und Orchestrierung im Zusammenspiel
Der Wechsel von ETL zu ELT hat die Art verändert, wie Datenteams Pipelines bauen. Die eigentliche Komplexität liegt aber darin, zu verstehen, wie die drei Schichten Ingestion, Transformation und Orchestrierung tatsächlich zusammenwirken. Dieser Artikel zerlegt die Mechanik des modernen Stacks anhand konkreter Beispiele und zeigt, wo die echten Tradeoffs für Führungskräfte liegen, die Architekturentscheidungen treffen.
Claude VectorData & Analytics Lead28. Juli 2026Podcast anhören
4 min
Im Zentrum dieses Artikels steht der moderne ELTELTELT (Extract, Load, Transform) ist ein Muster der Datenintegration, bei dem Rohdaten zuerst in ein Zielsystem geladen und dann dort mit der Rechenleistung der Plattform transformiert werden.Vollständige Definition ansehen →-Stack: konkret die Kombination aus einem Cloud Data WarehouseData WarehouseEin zentrales Repository, das Daten aus vielen Quellsystemen in einem strukturierten, abfrageoptimierten Speicher zusammenführt, ausgelegt für Analytics, Reporting und Business Intelligence.Vollständige Definition ansehen →, einer Transformationsschicht auf Basis von dbt (data build tool), einer Ingestion-Schicht, die typischerweise von Tools wie Fivetran oder Airbyte abgedeckt wird, und einem Orchestrator wie Airflow oder Dagster. Die meisten Datenverantwortlichen kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen diese Tools benennen. Deutlich weniger können präzise erklären, was jede Schicht tut, wo die eine endet und die andere beginnt und warum die Reihenfolge so großen Einfluss auf die Ergebnisse in der Organisation hat.
Genau in dieser Lücke zwischen Benennen und Verstehen entstehen schlechte Architekturentscheidungen.
Warum das speziell für CDOs relevant ist
Ein CDO, der die Mechanik dieses Stacks nicht erklären kann, ist dauerhaft darauf angewiesen, dass Engineering-Teams sie übersetzen. Das erzeugt ein Filterproblem: Bis eine Entscheidung auf Ihrem Schreibtisch landet, ist sie verdichtet, vereinfacht und oft schon getroffen. Wer die Architektur versteht, kann am eigentlichen Gespräch teilnehmen, Tradeoffs erkennen, bevor sie zu technischen Schulden werden, und glaubwürdig argumentieren, wenn Budget zwischen Anbietern verteilt wird.
Dazu kommt der Talentaspekt. Der moderne ELT-Stack ist heute das Standardcurriculum für Data Engineers, die in den Arbeitsmarkt eintreten. Wenn Sie den Stack kennen, können Sie beurteilen, ob Ihr bestehendes Team ihn gut nutzt oder eben nur nutzt.
Und schließlich sitzt hier die Governance. Column-Level Lineage, Data ContractsData ContractsFormale Vereinbarung zwischen dem Team, das Daten erzeugt, und denen, die sie nutzen: legt Struktur, Bedeutung, Qualität und Verantwortung bei Fehlern fest.Vollständige Definition ansehen →, Freshness-SLAs und die Dokumentation der Transformationslogik leben innerhalb dieses Stacks oder direkt daneben. Wenn Sie sich für Audit Trails und regulatorische Risiken interessieren, müssen Sie verstehen, an welcher Stelle der PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen → diese Kontrollen tatsächlich greifen.
Wie der moderne ELT-Stack wirklich funktioniert
Das Akronym ELT steht für Extract, Load, TransformExtract, Load, TransformELT (Extract, Load, Transform) ist ein Muster der Datenintegration, bei dem Rohdaten zuerst in ein Zielsystem geladen und dann dort mit der Rechenleistung der Plattform transformiert werden.Vollständige Definition ansehen →. Der Unterschied zum älteren ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →-Modell ist erheblich: Statt Daten zu transformieren, bevor sie im Warehouse ankommen, laden Sie zuerst die Rohdaten und transformieren sie anschließend im Warehouse per SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →. Praktikabel wurde das erst, als Cloud-Warehouses wie Snowflake, BigQuery und Databricks Compute günstig und skalierbar genug machten, um große Transformationen on demand auszuführen.
So teilen sich die drei Schichten in der Praxis auf.
Ingestion ist der Extract-and-Load-Teil. Tools wie Fivetran (kommerziell, Angaben des Anbieters) oder das Open-Source-Projekt Airbyte holen Daten aus Quellsystemen, darunter Salesforce, Postgres-Datenbanken, Google Analytics, Stripe und hunderte weitere, und legen sie als Rohtabellen in Ihrem Data Warehouse ab. Die Ingestion-Schicht transformiert so gut wie nichts. Sie repliziert. Ein Fivetran-Connector zu Salesforce landet eine Tabelle namens `opportunity`, die fast identisch mit dem aussieht, was Salesforce intern speichert. Ihr Warehouse hat nun eine mit Zeitstempel versehene Kopie dieser Daten, aktualisiert in einem Rhythmus, den Sie festlegen.
Transformation ist der Ort, an dem dbt lebt. dbt (entwickelt von dbt Labs, einem kommerziellen Unternehmen) ist ein Framework, mit dem Datenanalysten und Engineers SQL-SELECT-Statements schreiben, sogenannte Models, die dbt zu CREATE TABLE- oder CREATE VIEW-Statements kompiliert und gegen Ihr Warehouse ausführt. Der entscheidende Punkt: dbt behandelt Transformationslogik als Code. Sie liegt versioniert in Git, erzeugt einen Dependency-Graph (einen DAG) über alle Models und generiert Dokumentation und Lineage automatisch. Ein einfaches Beispiel: Ihre rohe Salesforce-Tabelle `opportunity` hat eine Spalte `amount` in USD. Ihr Finance-Team braucht sie in EUR, gejoint mit den Tabellen `account` und `user`, gefiltert auf Closed-Won-Deals und dedupliziert. Diese Logik liegt in einem dbt-Model, das etwa `fct_revenue` heißt. Beim dbt-Run wird dieses Model als Tabelle im Warehouse materialisiert, die nachgelagerte BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Tools wie Looker oder Tableau abfragen können.
Orchestrierung ist die Schicht, die alles plant und in die richtige Reihenfolge bringt. Tools wie Apache Airflow (Open Source, gepflegt von der Apache Software Foundation), das kommerzielle Angebot von Astronomer oder die neueren Dagster und Prefect legen fest, wann Jobs laufen und in welcher Abfolge. Ein Orchestrator sorgt dafür, dass Ihre dbt-Transformation nicht startet, bevor Fivetran die aktuellen Daten fertig geladen hat, und dass der BI-Cache nicht aktualisiert wird, bevor die Transformation abgeschlossen ist. Ohne Orchestrierung haben Sie eine Sammlung von Jobs ohne garantierte Reihenfolge, und die Aktualität der Daten wird unvorhersehbar.
Ein konkretes Produktionsszenario: Ein Handelsunternehmen lässt um 6 Uhr die Fivetran-Ingestion aus Shopify und dem ERPERPEine integrierte Kernsoftware für zentrale Abläufe: Finanzen, Einkauf, Supply Chain, HR und Produktion auf gemeinsamer Datenbasis.Vollständige Definition ansehen → laufen. Airflow erkennt, dass die Ingestion abgeschlossen ist, und löst dann einen dbt-Run aus, der gut zwanzig Models neu aufbaut, darunter Berechnungen zum Customer Lifetime ValueCustomer Lifetime ValueLifetime Value: der gesamte Umsatz (oder Gewinn), den ein Kunde über die komplette Dauer seiner Beziehung zu Ihrem Unternehmen generiert.Vollständige Definition ansehen → und Bestandsaggregate. Um 7 Uhr zeigt das Management-Dashboard in Looker die Daten des Vortags. Der Orchestrator übernimmt Retries, wenn der Shopify-Connector langsam ist, und alarmiert das Datenteam, wenn etwas fehlschlägt.
Wann dieser Stack passt und wann nicht
Diese Architektur passt gut, wenn Ihre Datenquellen SaaS-Anwendungen mit vorhandenen Connectors sind, Ihre Transformationslogik überwiegend SQL ist, Ihr Warehouse schon in der Cloud läuft und Ihr Team mindestens zwei oder drei Engineers hat, die mit Git vertraut sind. Das beschreibt 2026 einen großen Teil der Mid-Market- und Enterprise-Unternehmen.
Es gibt Fälle, in denen es weniger glatt passt. Wenn Ihre Transformationslogik stark Python-basiert ist, etwa weil Sie ML-Feature-Pipelines oder komplexe statistische Modelle betreiben, reicht dbt allein nicht. Sie müssen es dann mit Python-Models erweitern oder Teile der Pipeline an ein anderes Framework übergeben. dbt Labs hat Support für Python-Models nachgezogen (verfügbar auf Snowflake und Databricks), aber ererDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist nicht so ausgereift wie die SQL-Schicht, und die Dokumentation spiegelt das wider.
Wenn Ihre Datenmengen klein sind und Ihr Team aus einem Analysten ohne Engineering-Unterstützung besteht, kann dieser Stack überdimensioniert sein. Eine einzelne Airbyte-Instanz, ein paar dbt-Models und ein Cron-Job, der sie ausführt, sind für ein Unternehmen in der Frühphase eine legitime Architektur. Airflow bringt einen erheblichen operativen Aufwand mit und ist eine schlechte Wahl, solange Sie niemanden haben, der es betreiben kann.
Auch die Kosten sind kein Nebenaspekt. Das Pricing von Fivetran skaliert mit den Monthly Active Rows und kann mit wachsendem Datenvolumen teuer werden. Das sind Angaben des Anbieters, und die tatsächlichen Kosten hängen stark von den Nutzungsmustern ab. Mehrere Organisationen sind teilweise auf selbst gehostetes Airbyte oder neuere Tools wie Estuary umgestiegen, um diese Kosten zu steuern. Rechnen Sie mit eigenen Zahlen, statt sich auf Case Studies der Anbieter zu verlassen.
Der Stack funktioniert am besten, wenn seine drei Schichten als System behandelt werden. Werden sie unabhängig voneinander eingekauft oder konfiguriert, ohne Rücksicht darauf, wie sie ineinander übergeben, vervielfacht sich der operative Aufwand. Bei der Orchestrierung entscheidet sich, ob diese Integration hält oder auseinanderfällt.
Mehr dazu
Die Lektionen, die diesen Artikel weiterführen, frei zugänglich.
- 1dbt (data build tool): industrialisierte SQL-TransformationModerne Datenarchitektur
- 2Data Pipelines: ETL/ELT, Batch, Streaming und Medallion-ArchitekturModerne Datenarchitektur
- 3Data Contracts: der neue Standard für Qualitätsvereinbarungen zwischen TeamsData Governance & Compliance
- 4Data Lineage & Impact AnalysisModerne Datenarchitektur
- 5Data FinOps: Cloud-Datenkosten im GriffModerne Datenarchitektur
Artikel gelesen?
Bestätigen Sie Ihre Lektüre, um XP zu sammeln und Ihr Radar zu füttern.