ETL vs. ELT auf Databricks: Wann welches Lademuster passt
Die Kernaussagen auf einen Blick.
- ETL transformiert Daten vor dem Laden, ELT lädt zuerst und transformiert in der Ziel-Engine. Auf Databricks bedeutet ELT konkret Bronze, Silver, Gold im Medallion-Muster.
- Die Wahl des Lademusters beeinflusst Speicherung, Wiederaufbereitung, Governance und die Belastung der Quellsysteme.
- Vor der Entscheidung sollte geklärt werden, wie personenbezogene Daten verarbeitet werden, welche Quell-Systeme Last vertragen und ob die Bronze-Schicht dauerhaft als Grundlage für erneute Verarbeitungen dienen soll.
- Mein Vorschlag: ELT als Default-Muster auf Databricks. Für jede Quelle sollte geprüft werden, ob eine Transformation vor dem Laden erforderlich ist (PII, Quell-Last, kleine komplexe Regeln).
- Die Aufgaben und Qualitätsanforderungen von Bronze, Silver und Gold sollten von Beginn an klar definiert werden.
Inhaltsverzeichnis
ETL oder ELT ist keine Tool-Frage
In Migrationsprojekten beginnt die Diskussion über ETL und ELT häufig mit der Auswahl eines Werkzeugs. Soll Fivetran oder Auto Loader eingesetzt werden? Sollen bestehende Informatica-Prozesse übernommen oder die Transformationen mit dbt neu aufgebaut werden? Für diese Entscheidungen muss zunächst das gewünschte Lademuster feststehen. Die Auswahl der Werkzeuge sollte sich aus dem gewählten Lademuster ergeben.
ETL und ELT unterscheiden sich vor allem darin, wann die Daten transformiert werden: An welcher Stelle in der Strecke vom Quell-System zur Auswertung passiert die Transformation der Rohdaten? Bei ETL erfolgt die Transformation vor dem Laden in einer separaten Verarbeitungsschicht, bevor die Daten überhaupt das Lakehouse erreichen. Bei ELT werden die Daten zunächst geladen und anschließend auf der Zielplattform transformiert, mit Bronze als reproduzierbarer Roh-Schicht und Silver/Gold als kuratierten Stufen. Diese Entscheidung beeinflusst zahlreiche weitere Aspekte der Plattform: Speicherkosten, Möglichkeiten zur erneuten Verarbeitung, Quell-Last, Verteilung der Governance-Verantwortung, Engine-Stack, Betriebsmodell.
Die vereinfachte Einordnung von ETL als veraltet und ELT als modern greift zu kurz. Auch Databricks selbst beschreibt ETL und ELT als zwei Datenverarbeitungsansätze mit jeweils eigenen Stärken, eingeordnet nach Anwendungsfall. ETL bleibt der richtige Schnitt, wenn personenbezogene Daten gefiltert werden müssen, bevor sie das Lakehouse erreichen, wenn Quellsysteme nur begrenzte zusätzliche Last verkraften oder wenn Bandbreiten begrenzt sind. Die wirtschaftlichen Vorteile von ELT gelten vor allem dann, wenn günstiger Objektspeicher und flexibel skalierbare Rechenleistung tatsächlich genutzt werden können. Die Entscheidung sollte deshalb für jede Datenquelle anhand ihrer konkreten Anforderungen getroffen werden.
Was ist der Unterschied zwischen ETL und ELT?
Zunächst haben beide Muster eine gemeinsame Grundlage. ETL und ELT sind beide Datenintegrations-Verfahren mit drei Schritten (Extract, Transform, Load) und sie unterscheiden sich in der Reihenfolge von Transformation und Laden. Beide bewegen Daten aus operativen Quell-Systemen in eine analytische Ziel-Umgebung. Beide benötigen Governance, Datenqualitätsprüfungen und klar geregelte Betriebsprozesse. Die praktischen Unterschiede zeigen sich bei Speicherung, Wiederaufbereitung und Betrieb: Wo passiert die Transformation, welche Engine trägt sie, was bleibt an Rohdaten erhalten.
ETL: Extract, Transform, Load. Daten werden aus der Quelle extrahiert, in einer dedizierten Engine zwischen Quelle und Ziel bereinigt, gefiltert, aggregiert und erst danach in das Ziel-System geladen. Klassisch waren das Engines wie Informatica, Talend, SSIS oder Oracle Data Integrator (ODI) zwischen den operativen Systemen und einem klassischen Data Warehouse. In das Data Warehouse wurden ausschließlich bereits transformierte Daten geladen. Die ursprünglichen Rohdaten wurden häufig nicht dauerhaft im Zielsystem gespeichert. Der ETL-Prozess hat seine Wurzeln in der DWH-Zeit der 1990er, als Storage teuer und Compute knapp war.
ELT: Extract, Load, Transform. Daten werden aus der Quelle extrahiert, in ihrer Rohform direkt in das Ziel-System geladen und erst dort mit der Ziel-Engine transformiert. Auf einem Lakehouse heißt das konkret: Auto Loader, Lakeflow Connect oder Zerobus übernehmen das Laden, Bronze hält die Roh-Tabellen mit Delta Lake unter Unity Catalog, Silver und Gold entstehen durch Transformationen mit Spark/Photon, orchestriert über Lakeflow Declarative Pipelines oder vergleichbare Werkzeuge. Ingestion und Transformation erfolgen auf derselben Plattform, während Bronze, Silver und Gold unterschiedliche Verarbeitungsstände abbilden.
ETL transformiert vor dem Laden in einer dedizierten Engine, ELT lädt zuerst roh ins Lakehouse und transformiert erst dort mit Spark/Photon. Die Position der Transform-Station ist der ganze Unterschied.
Der Unterschied geht über die bloße Reihenfolge der Verarbeitungsschritte hinaus. Entscheidend ist, welche Plattform die Transformation ausführt und wo Rohdaten dauerhaft gespeichert werden. Bei ETL liegt die Transformationslogik üblicherweise zwischen Quelle und Zielsystem. Bei ELT übernimmt die Zielplattform auch die Transformation. Daraus folgen unterschiedliche Profile in Storage-Wachstum, Wiederaufbereitung, Quell-Last und Governance. Wie diese Mechanik in das Engineering-Betriebsmodell auf Databricks eingebettet ist, zeigen wir im Überblick zu Data Engineering auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Warum früher vor dem Laden transformiert wurde
Die Verbreitung von ETL war wesentlich durch die damaligen Speicher- und Rechenkosten geprägt. Ein klassisches Data Warehouse aus der Inmon- und Kimball-Tradition der dimensionalen Modellierung lag auf teurem, vertikal skaliertem Storage wie Oracle, Teradata oder DB2 auf SAN. Zusätzlicher Speicher im Data Warehouse war teuer. Auch zusätzliche Rechenleistung erhöhte häufig unmittelbar die Lizenzkosten. Unter diesen Bedingungen war Filtern, Aggregieren und Bereinigen vor dem Laden zwingend. Deshalb wurden nur bereits bereinigte und für Analysen benötigte Daten in das Warehouse geladen. Die vorgelagerte ETL-Engine übernahm die Transformation, bevor die Daten das Warehouse erreichten.
Lakehouse-Plattformen verändern diese Rahmenbedingungen in zwei wesentlichen Punkten. Erstens ist Objekt-Speicher (S3, ADLS, GCS) um Größenordnungen billiger als DWH-Storage und elastisch. Cloud-Objektspeicher ist im Vergleich zu klassischem Warehouse-Speicher deutlich günstiger. Klassische DWH-Systeme rechneten im Lizenz-Bereich pro Terabyte und Jahr. Dadurch wird die dauerhafte Speicherung von Rohdaten wirtschaftlich praktikabel. Zweitens ist die Transformations-Compute auf einem Lakehouse elastisch und nutzungsabhängig: Spark/Photon-Cluster oder Serverless-Compute laufen, wenn transformiert wird, und ruhen sonst. Die Rechenleistung kann bedarfsgerecht bereitgestellt und nach der Verarbeitung wieder reduziert werden.
Dadurch wird ELT für viele Lakehouse-Anwendungsfälle zum naheliegenden Standard. Der Fokus verschiebt sich: Früher ging es vor allem darum, welche Daten vor dem Laden gefiltert oder verändert werden müssen. Heute geht es darum, wie die Bronze-Schicht aufgebaut sein muss, damit sich Transformationen zuverlässig wiederholen lassen. Eine erneute Verarbeitung lässt sich auf einem Lakehouse deutlich einfacher umsetzen, sofern die Rohdaten vollständig erhalten sind, etwa nach einer Regel-Änderung in der Geschäftslogik. Auf einem klassischen ETL-Stack ist es teuer oder unmöglich, weil die Rohdaten nach dem Laden verworfen wurden.
Diese veränderten Kostenstrukturen erklären, warum auf Lakehouse-Plattformen häufig ELT bevorzugt wird, ohne dass ETL deshalb verschwindet. Daraus folgt jedoch nicht, dass ELT für jede Quelle geeignet ist. Diese Frage hängt an anderen Faktoren.
Bronze, Silver, Gold und Medallion Architecture
ELT auf Databricks erfordert eine klar strukturierte Verarbeitung über mehrere Datenschichten. Bronze, Silver und Gold übernehmen jeweils klar definierte Aufgaben. Die Medallion-Architektur unterteilt den Datenfluss in drei Schichten:
Bronze, Silver, Gold: drei Schichten mit steigender Qualität.
Bronze hält die Rohdaten reproduzierbar, Silver konsolidiert und bereinigt über Quellen hinweg, Gold liefert geschäftsfertige Datenprodukte für BI und ML.
Bronze. Die Bronze-Schicht enthält die weitgehend unveränderten Quelldaten. Daten landen so, wie sie aus der Quelle kommen, nur minimal angereichert um Metadaten wie Ingestion-Zeitstempel und Quell-Identifikator. Bronze enthält weder Geschäftslogik noch Filter oder Aggregation. Bronze dient als nachvollziehbare Ausgangsbasis für erneute Verarbeitungen: Aus den dort gespeicherten Daten können Silver- und Gold-Tabellen bei Bedarf neu aufgebaut werden. Auf Databricks bauen wir Bronze typischerweise mit Auto Loader für inkrementelles File-Ingestion, Lakeflow Connect für Managed Connectoren zu SaaS-Quellen oder Zerobus für Streaming-Events. Speicherformat: Delta Lake mit Schema-Evolution und ACID-Garantien.
Silver. Die kuratierte Schicht. In Silver werden Daten bereinigt, vereinheitlicht und über mehrere Quellen hinweg zusammengeführt: Joins, Dedup, Standardisierung von Codes, Korrektur bekannter Datenfehler, Tokenisierung oder Maskierung personenbezogener Felder, soweit sie nicht schon vor Bronze gefiltert wurden. Silver stellt erstmals eine gemeinsam nutzbare fachliche Sicht auf die Daten bereit.
Gold. Gold enthält Daten, die für konkrete Berichte, Analysen und Anwendungen aufbereitet sind. Hier liegen die Datenprodukte, auf die BI-Anwendungen, Reports und Machine-Learning-Prozesse zugreifen, aggregiert, mit Geschäftskennzahlen, sauber dokumentiert. Für jede Gold-Tabelle sollten fachliche Verantwortung und Aktualisierungsrhythmus festgelegt sein.
Über alle drei Schichten liegt Unity Catalog als zentrale Governance-Schicht: Berechtigungen, Lineage, Audit. Die Transformations-Engine ist Spark/Photon, orchestriert über Lakeflow Declarative Pipelines oder klassische Lakeflow Jobs, je nach Komplexität. Transformation, Speicherung und Governance werden innerhalb einer gemeinsamen Plattform umgesetzt. Dadurch sinkt der Bedarf an mehreren getrennten Systemen für Laden, Transformation und Governance. Klassische ETL-Landschaften verteilen diese Aufgaben häufig auf mehrere separate Werkzeuge mit jeweils eigenem Berechtigungs- und Monitoring-Konzept.
Wann Transformation vor dem Lakehouse sinnvoll bleibt
Auch bei einem ELT-orientierten Zielbild kann eine vorgelagerte Transformation sinnvoll sein. In vier typischen Situationen ist ein ETL-Schritt vor dem Lakehouse die geeignetere Lösung:
PII vor dem Laden entfernen
Wenn DSGVO oder interne Vorgaben verlangen, dass Klartext-Passwörter, Bankverbindungen oder biometrische Daten gar nicht erst im Lake landen.
Last-empfindliche Quell-Systeme
Wenn ein älteres ERP- oder Fachverfahrens-System keine umfangreichen Vollabzüge verkraftet und vorab gefiltert oder aggregiert werden muss.
Kleine Quellen mit komplexer Regel
Wenn eine bestehende ETL-Lösung über Jahre gewachsene Sonderfälle zuverlässig abbildet und eine Neuformulierung mehr Risiko als Nutzen bringt.
Hybride Übergangs-Architektur
Wenn während einer Migration alte ETL-Strecken und neue ELT-Pipelines für Monate parallel Tabellen im Lakehouse befüllen.
Personenbezogene Daten, die vor dem Laden entfernt oder maskiert werden müssen. Wenn die DSGVO oder eine interne Compliance-Vorgabe verlangt, dass bestimmte personenbezogene Attribute gar nicht erst im Lake landen wie etwa Klartext-Passwörter, vollständige Bankverbindungen oder biometrische Identifikatoren, dann müssen die betroffenen Daten vor der Speicherung im Lakehouse entfernt oder verändert werden. Eine nachträgliche Maskierung in Silver genügt in diesem Fall nicht, weil das Klartext-Feld in Bronze bereits liegt. Auch RBAC und Row-Level-Security mit Column-Masking in Unity Catalog helfen hier nicht weiter: Sie steuern den Zugriff, entfernen die Klartext-Werte aber nicht aus dem Speicher. Hier ist ein ETL-Schnitt zwischen Quelle und Lake die technisch und regulatorisch geeignete Lösung, oft realisiert über eine Maskierungs-Schicht in der Quelle oder eine dedizierte Engine zwischen Quelle und Bronze.
Quell-Systeme mit eng begrenzter Last. Wenn die operative Datenbank (typischerweise ein älteres ERP- oder Fachverfahrens-System) keine umfangreichen Vollabzüge verkraftet, weil parallele Geschäftsprozesse darauf laufen, dann kann es sinnvoll sein, Daten bereits bei der Extraktion zu filtern, zu aggregieren oder inkrementell bereitzustellen. In das Lakehouse werden anschließend nur die seit dem letzten Lauf entstandenen Änderungen geladen. Das ist formal ein ETL-Schritt, auch wenn das Ziel ein Lakehouse ist.
Kleine Quellen mit komplexer fachlicher Regel. Manche Quellen sind klein im Volumen, tragen aber komplexe fachliche Regeln, die bereits zuverlässig in einer bestehenden ETL-Lösung umgesetzt sind und gut funktionieren. Eine Übersetzung in Spark/SQL kann mehr Risiko als Nutzen bringen, wenn die Logik über viele Jahre erweitert wurde und zahlreiche Sonderfälle enthält und niemand mehr alle Sonderfälle kennt. Dann kann der Weiterbetrieb der bestehenden Transformation vor dem Laden wirtschaftlicher und risikoärmer sein, oft als Brückentechnologie während einer längeren Migration.
Hybride Übergangs-Architekturen während einer Migration. Bei einer Migration aus einem Informatica-, Talend- oder SSIS-Stack auf Databricks läuft das Setup über Monate parallel. In dieser Übergangsphase mit parallelem ETL- und ELT-Betrieb füllen die alten ETL-Strecken bestimmte Tabellen im neuen Lakehouse, während neue Strecken bereits als ELT mit Bronze/Silver/Gold gebaut werden. Dies ist ein kontrollierter Ansatz, um die Migration schrittweise und mit begrenztem Risiko umzusetzen.
In allen vier Fällen gilt: Eine vorgelagerte Transformation sollte je Quelle nachvollziehbar begründet und dokumentiert werden. Sie wird pro Quelle getroffen.
Storage, Governance, Wiederaufbereitung und Quell-Last
| Aspekt | ETL | ELT auf Databricks |
|---|---|---|
| Transformations-Ort | dedizierte Engine vor dem Ziel | Spark/Photon im Lakehouse, nach dem Laden |
| Storage-Modell | gefilterte/aggregierte Daten im Ziel, Rohdaten nicht persistent | Roh in Bronze, kuratiert in Silver, geschäftsfertig in Gold |
| Wiederaufbereitung | nur möglich, wenn die ursprünglichen Daten weiterhin verfügbar sind | reproduzierbar aus Bronze, Delta Time Travel als Replay-Option |
| Quell-Last | reduzierbar durch vorgelagerte Aggregation | Abhängig vom Extraktionsverfahren vollständige oder inkrementelle Übertragung |
| Governance | pro Engine separat, schwer zu konsolidieren | Zentrale Governance über Bronze, Silver und Gold mit Unity Catalog |
| Engine-Stack | mehrere Systeme (ETL-Engine, DWH, BI) | ein Engine-Stack (Spark/Photon + Lakeflow) |
| Schema-Flexibilität | Schema on Write, strukturierte Daten, Schema-Wechsel teuer | Flexible Verarbeitung strukturierter und semistrukturierter Daten (Files, JSON, Binaries) |
| Datenqualitäts-Gate | hart vor dem Laden, validierte Daten im Ziel | nach dem Laden in Silver, fehlerhafte Quelldaten bleiben in Bronze erhalten und werden in späteren Schichten behandelt |
| PII-Behandlung | Filter vor dem Laden möglich, oft einfacher umzusetzen | Maskierung/Tokenisierung in Silver, harte Filter erfordern Vor-Schnitt |
| FinOps-Profil | Engine-Lizenz fix, Storage im Ziel teuer | Storage günstig und elastisch, Compute nutzungsabhängig |
Die Bedeutung der einzelnen Kriterien hängt von der Zielarchitektur ab. Bei hohen Speicherkosten und klar strukturierten Zielmodellen können die Vorteile von ETL stärker wiegen. Bei günstigem Objektspeicher und elastischer Rechenleistung bietet ELT meist größere Vorteile. Die Bewertungskriterien bleiben gleich, ihre Bedeutung unterscheidet sich jedoch je nach Plattform.
Wann ETL und wann ELT? Entscheidungsmatrix für Databricks
Die Frage „ETL oder ELT" lässt sich selten einheitlich für die gesamte Plattform beantworten. Die Entscheidung sollte für jede Datenquelle separat getroffen werden. Relevant sind insbesondere Quelltyp, Schutzbedarf der Daten und geplanter Anwendungsfall. Diese Matrix bildet die häufigsten Konstellationen ab, die wir in Beratungsprojekten sehen:
| Quell-Typ | Datenklasse | Workload-Ziel | Empfehlung |
|---|---|---|---|
| CDC aus OLTP (Oracle, Postgres) | intern | BI/Analytics | ELT mit Auto Loader/CDC nach Bronze, Transformation in Silver |
| CDC aus OLTP | personenbezogen (DSGVO) | BI/Analytics | Maskierung oder Filterung vor dem Laden, weitere Transformationen anschließend in Silver und Gold |
| SaaS-API (Salesforce, HubSpot) | gemischt | BI/CRM-Reporting | ELT mit Lakeflow Connect nach Bronze, fachliche Konsolidierung in Silver |
| File-Drop (CSV, Parquet, externe Lieferanten) | intern | BI/ML | ELT mit Auto Loader nach Bronze, Schemaänderungen in der Bronze-Ingestion kontrolliert behandeln |
| File-Drop mit harter PII-Filter-Pflicht | reguliert | BI/Reporting | Filterung oder Maskierung vor der Speicherung im Lakehouse, dann Bronze |
| Streaming-Events (Kafka, Event Hubs) | intern | Realtime-Dashboards | ELT mit Zerobus oder Auto Loader nach Bronze, Silver in DLT |
| IoT-Sensorik mit hoher Frequenz | intern | Realtime/ML | hybrid mit Edge-Aggregation oder Filterung an der Quelle, in Bronze werden bereits gefilterte oder aggregierte Sensordaten gespeichert |
| Operatives Kern-System mit Last-Limit | intern | BI | ETL mit Aggregation/Delta-Bildung vor dem Laden, dann ELT in Silver/Gold |
| Kleines Legacy-System mit komplexer Regel | intern | BI | ETL: bestehende Engine behalten, Output nach Bronze schreiben |
Aus der Matrix ergibt sich eine klare Grundtendenz: ELT als Default für die meisten modernen Quellen. Eine vorgelagerte Transformation ist vor allem bei regulatorischen Vorgaben, begrenzter Quellkapazität oder komplexer bestehender Logik sinnvoll. Streaming und CDC sind klassische ELT-Fälle, weil die Roh-Erhaltung in Bronze die Replay-Fähigkeit garantiert. Verpflichtende Vorfilterung und eingeschränkte Quellkapazitäten sprechen häufig für ETL.
Informatica, Talend und SSIS richtig ablösen
Eine Migration aus einem klassischen ETL-Stack auf Databricks sollte nicht automatisch als unveränderte technische Übernahme bestehender Prozesse verstanden werden. Sie ist eine Architektur-Entscheidung pro Strecke. Erforderlich ist ein Migrationsplan, der stabilen Betrieb und schrittweise Modernisierung miteinander verbindet. In Projekten mit 15 Jahren ETL-Logik in Informatica oder Talend sehen wir typischerweise drei typische Migrationspfade:
Strecken, die übernommen werden
Kleine, kritische Strecken mit komplexer fachlicher Regel: die Logik wird in Spark nachgebaut, die Transformation bleibt vor dem Schreiben in die Zieltabelle, ohne Bronze als Zwischen-Schicht.
Strecken, die als ELT umgebaut werden
Quellen mit hohem Volumen oder vielen nachgelagerten Anwendungsfällen: Ingestion mit Auto Loader oder Lakeflow Connect nach Bronze, fachliche Transformation in Silver und Gold.
Strecken in der Übergangsphase
Alte und neue Strecken laufen parallel, bis nachgelagerte Anwendungen schrittweise umgestellt sind, typischerweise sechs Monate bis zwei Jahre.
Engines wie Informatica, Talend, SSIS oder ODI sind in dieser Migration nicht „die alten Tools, die weg müssen". Sie bleiben während der Migration ein wichtiger Bestandteil des stabilen Betriebs. Für jede Strecke sollte festgelegt werden, ob sie übernommen, neu aufgebaut oder zunächst parallel betrieben wird, und in welcher Reihenfolge.
Ingestion, Orchestrierung und Medallion-Design
Diese Entscheidung zwischen ETL und ELT beantwortet ausschließlich die Frage, wann die Transformation erfolgt. Die Auswahl der Werkzeuge und die konkrete Ausgestaltung von Bronze, Silver und Gold müssen separat entschieden werden. Drei weiterführende Entscheidungen sind davon zu unterscheiden:
- Die Connector-Wahl für eine SaaS-Quelle oder ein OLTP-System steht in der Ingestion-Übersicht für Databricks. Dort findest du die Mechanik der einzelnen Connectoren von Auto Loader über Lakeflow Connect bis Zerobus mit den Kriterien für die Wahl.
- Ausführung und Abhängigkeiten der Pipelines (also wann Lakeflow Declarative Pipelines und wann klassische Jobs tragen) beantwortet die Pipeline-Orchestrierung mit Lakeflow. Hier geht es um Quality-Gates, Pipeline-Topologie und Wiederanlauf-Logik.
- Die inhaltliche und technische Ausgestaltung von Bronze, Silver und Gold (welche Granularität, welcher Schema-Schnitt, welche Owner-Konstellation) steht in der Medallion-Architektur im Lakehouse. Das ist die Modellierungs-Disziplin, die ein ELT-Pattern erst tragfähig macht.
Grenzen von ETL und ELT auf Databricks
Beide Muster haben Grenzen, die in einem Architektur-Vergleich oft unter den Tisch fallen, weil sie in vereinfachten Produktdarstellungen häufig nicht ausreichend berücksichtigt werden. Wir nennen sie, weil sie in jedem Lakehouse-Projekt früher oder später relevant werden.
Bronze ohne klare Nutzung
Ohne Aufbewahrungsregeln und durchgehaltene Silver/Gold-Disziplin wächst Bronze zu einer dauerhaft wachsenden Rohdatenablage bis in den Petabyte-Bereich, ohne dass daraus zwangsläufig fachlicher Nutzen entsteht.
Wiederaufbereitung bei ETL
Eine rückwirkende Regel-Änderung ist bei ETL nur möglich, wenn historische Rohdaten anderweitig erhalten wurden. Sonst braucht es neue Extrakte aus der Quelle oder einen Rebuild aus dem Ziel-Stand, der das Original nicht vollständig rekonstruiert.
PII in Bronze
Ein ELT-Setup mit Maskierung erst in Silver braucht harte technische und organisatorische Abriegelung der Bronze-Zugriffe, sonst bleiben unmaskierte Daten für berechtigte Nutzer mit Bronze-Zugang einsehbar.
Mischbetrieb
Laufen ETL-Strecken und ELT-Pipelines parallel, was während Migrationen normal ist, braucht es eindeutig geregelte Zuständigkeiten und eine klare Antwort, welcher Datenbestand in der Übergangsphase verbindlich ist.
Plattformabhängigkeit
ELT auf Databricks konzentriert Ingestion, Transformation und Governance auf einer Plattform. Das vereinfacht den Betrieb, erhöht aber zugleich die Abhängigkeit von deren Diensten und Schnittstellen.
Streaming-ELT
CDC- und Event-Streams in Bronze ermöglichen erneute Verarbeitung, verlagern aber Verantwortung für Ordnung, Idempotenz und verspätet eintreffende Ereignisse vom Quell-System ins Lakehouse, und werden oft unterschätzt.
Keine dieser Grenzen ist ein Argument gegen ELT auf Databricks. Sie markieren, was vor dem Produktivbetrieb geklärt sein muss: Owner und Aufbewahrungsregeln für die Bronze-Schicht, der Umgang mit dem Storage-Wachstum und eine bewusste Entscheidung zur Plattformabhängigkeit. Bleiben diese Punkte offen, wächst die Bronze-Schicht ohne klare Verantwortung und ohne Aufbewahrungsregeln weiter.
Sobald operative Geschäftsprozesse an Silver/Gold-Tabellen hängen, muss die Schichten-Disziplin Teil des Betriebsmodells werden, also mit fachlichen Tabellen-Ownern, klaren Update-Profilen und einer Lifecycle-Politik für Bronze. Das ist die Stelle, an der eine ELT-Plattform zu einem geschäftskritischen Bestandteil des laufenden Betriebs wird.
Fazit
ETL und ELT sind zwei Lademuster mit unterschiedlichen Auswirkungen auf Architektur und Betrieb.
Auf einem Lakehouse mit kostengünstigem Objekt-Speicher, elastischer Compute, Delta Lake und Medallion-Schichten ist ELT für viele Databricks-Anwendungsfälle der geeignetere Standard. Rohdaten landen in Bronze, Transformation passiert in Silver/Gold, Ingestion und Transformation werden auf derselben Plattform umgesetzt. Aber ELT ist kein universeller Default. Sobald personenbezogene Daten gefiltert werden müssen, Quellen Last-empfindlich sind oder kleine Quellen komplexe und bewährte Bestandslogik enthalten, bleibt ein ETL-Schnitt vor dem Lakehouse die saubere Wahl.
ELT als Default-Muster auf Databricks setzen, ETL-Schnitte bewusst pro Quelle entscheiden, Medallion-Disziplin von Anfang an verankern. Das passende Muster sollte für jede Datenquelle einzeln festgelegt werden. Die Entscheidungsmatrix oben kann als Ausgangspunkt für die Bewertung der eigenen Quellen dienen. Das Ergebnis ist eine nachvollziehbare Zuordnung der Quellen zu ETL- oder ELT-Verfahren und damit eine Grundlage für Kostensteuerung, Governance und langfristig reproduzierbare Datenverarbeitung.
FAQ
Bei ETL vs. ELT entscheidet der Transformations-Ort: ETL transformiert Daten vor dem Laden in das Ziel-System, ELT lädt Rohdaten zuerst und transformiert sie danach in der Ziel-Engine. Strukturell unterscheiden sich beide Verfahren in der Verantwortungstrennung zwischen Transformations-Engine, Speicher und Ziel-System. ETL trennt sie, ELT führt sie zusammen, mit Konsequenzen für Storage, Wiederaufbereitung und Governance.
