Zero-ETL beschreibt Architekturen, in denen der Cloud-Anbieter die Daten-Kopierstrecke zwischen der Datenbank einer Anwendung (dem operativen System, das Bestellungen oder Buchungen entgegennimmt) und der Datenbank für Auswertungen (dem analytischen System für Reports und Dashboards) selbst betreibt. Die Daten liegen weiterhin zweimal vor; die Übertragung dazwischen wird nur so weit vor den Nutzern versteckt, dass keine eigene Pipeline mehr eingerichtet werden muss. „ETL" steht dabei für Extract, Transform, Load, also die drei klassischen Schritte einer solchen Kopierstrecke.
Was ist Zero-ETL?
Zero-ETL ist ein Sammelbegriff für mehrere herstellerspezifische Integrationen, kein technischer Standard. Gemeinsam ist ihnen das Versprechen, die Übertragung zwischen der Anwendungs-Datenbank und dem Analyse-System aus der Verantwortung der Engineering-Teams zu nehmen. Die Strecke existiert weiterhin, sie wird aber vom Cloud- oder Plattform-Anbieter betrieben: Änderungen an der Tabellenstruktur (Schema-Änderungen, etwa eine neue Spalte in der Bestell-Tabelle) werden automatisch nachgezogen, das erstmalige Übertragen historischer Datenbestände (Backfills) läuft verwaltet, und Verbindungs-Konfigurationen entfallen.
Aufgesetzt wird Zero-ETL meist über zwei eng verzahnte Dienste desselben Anbieters. AWS bietet eine Integration zwischen Aurora und Redshift sowie zwischen DynamoDB und Redshift. Microsoft Fabric Mirroring spiegelt Daten aus SQL Server, Cosmos DB und Snowflake in den OneLake. Snowflake Unistore und Hybrid Tables bilden transaktionale und analytische Workloads in der Snowflake-Plattform ab. Google AlloyDB lässt sich mit BigQuery verbinden. Allen Ansätzen ist gemeinsam, dass operative und analytische Daten weiterhin in getrennten Engines mit eigenen Storage-Schichten liegen; Zero-ETL bewegt die Daten zwischen ihnen, ohne sie konzeptionell zusammenzuführen.
Die Abkürzung „ETL" bleibt im Begriff präsent, weil die drei Schritte (Extract, Transform, Load) weiterhin ausgeführt werden. Geändert wird die Verantwortung dafür: Zero-ETL ist primär ein Operations-Versprechen, das die Pipeline-Wartung in den Plattform-Betrieb verlagert, kein Storage-Versprechen, das eine einzige Quelle der Wahrheit schaffen würde. Diese Unterscheidung ist für Architektur-Entscheidungen relevant, weil Latenzen, Konsistenz-Garantien und Lock-in von der konkreten Anbieter-Implementierung abhängen.
Abgrenzung gegen HTAP und LTAP
Zero-ETL, HTAP und LTAP adressieren dieselbe Fragestellung (wie lassen sich operative und analytische Workloads ohne klassische ETL-Strecke verbinden), setzen aber an unterschiedlichen Architektur-Schichten an.
| Ansatz | Engines | Speicher | Datenkopien |
|---|---|---|---|
| Zero-ETL | zwei getrennte Engines | je Engine eigener Store | bleiben bestehen, Pipeline ist nur verborgen |
| HTAP | eine Engine für OLTP und OLAP | gemeinsamer Store, oft hybrides Layout | konzeptionell keine |
| LTAP | zwei spezialisierte Engines | gemeinsamer Objektspeicher | konzeptionell keine, gemeinsamer Store noch angekündigt |
Zero-ETL automatisiert die Pipeline zwischen zwei Stores und nimmt die Datenkopie in Kauf. [HTAP](/insights/glossar/htap/) löst das Problem durch eine einzige Engine, die OLTP und OLAP auf demselben Datenbestand bedient, und nimmt dafür den Engine-Physik-Kompromiss zwischen Zeilen- und Spaltenformat in Kauf. [LTAP](/insights/glossar/ltap/) trennt die Engines wieder, vereint dafür die Speicher-Schicht und vermeidet so konzeptionell die Datenkopie.
Beispiel: Aurora und Redshift mit AWS Zero-ETL
In einer Bestellplattform liegt die operative Anwendung auf einer Aurora-PostgreSQL-Datenbank. Bestellungen, Artikel, Kunden und Bestände werden dort transaktional geschrieben. Analytisches Reporting, Self-Service-BI und ML-Pipelines arbeiten auf einem Redshift Data Warehouse. Klassisch würde dazwischen eine CDC-Strecke laufen, etwa mit AWS DMS oder Debezium, die das Engineering-Team einrichten, überwachen und bei Schema-Änderungen anpassen müsste.
Mit AWS Zero-ETL zwischen Aurora und Redshift entfällt diese Eigenbau-Pipeline. Der AWS-Service erkennt Änderungen in den Aurora-Tabellen und spiegelt sie kontinuierlich in eine Redshift-Datenbank. Die Konfiguration besteht aus einer Integration zwischen Source- und Target-Cluster, Schema-Mapping und Initial-Load werden vom Dienst übernommen. Aus Sicht der Engineering-Teams sieht es so aus, als wäre keine Pipeline mehr im Spiel.
Physisch liegen die Daten weiterhin in beiden Systemen: in Aurora als zeilenorientiertes OLTP-Format, in Redshift als spaltenorientiertes OLAP-Format. Die Latenz zwischen Aurora-Schreibvorgang und Sichtbarkeit in Redshift hängt von der Integration ab (AWS nennt für Aurora-Zero-ETL eine Latenz im Sekundenbereich). Bei Schema-Änderungen oder bei großen Backfills bleibt der Dienst eine verwaltete Black Box, deren Verhalten in der konkreten Last bekannt sein muss.
Zero-ETL im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.