Wenn Sie eine Daten-Pipeline aufbauen, um ein Business-Intelligence-Tool zu speisen oder ein Modell für maschinelles Lernen zu trainieren, ist eine der ersten Entscheidungen, die Sie treffen müssen, wo die Transformation stattfindet: bevor die Daten in Ihrem Warehouse landen oder danach. Das bedeutet, Sie müssen sich zwischen „Extract, Transform, Load“- (ETL) und „Extract, Load, Transform“-Pipelines (ELT) entscheiden.

Die Wahl bestimmt, wie schnell Analystinnen und Analysten auf Rohdaten zugreifen können, wie viel Rechenleistung Sie wo aufwenden und wie einfach Sie sich anpassen können, wenn sich Ihr Datenmodell ändert. Der Markt für globale Daten-Pipeline-Tools wird bis 2030 voraussichtlich einen Wert von 48,33 Mrd. USD erreichen, und ETL verliert gegenüber ELT und anderen Arten von Pipelines an Boden.

Im Folgenden gehen wir darauf ein, wie jedes Modell funktioniert, wann ETL oder ELT sinnvoller ist und wie speziell entwickelte Connectoren in beide Ansätze für bestimmte Datenquellen passen.

Das Wichtigste auf einen Blick

• ETL transformiert Daten, bevor sie den Zielort erreichen. ELT lädt Rohdaten und transformiert sie innerhalb des Warehouses unter Verwendung seiner eigenen Rechenleistung.

• ELT ist das Standardmuster für die meisten modernen Datenteams. ETL bleibt beliebt für eingeschränkte Zielorte, strenge Governance-Anforderungen und veraltete Pipelines.

• Speziell entwickelte Connectoren für bestimmte Datenquellen können das Risiko von Datenqualitätsproblemen verringern, die generische Connectoren manchmal mit sich bringen.

ETL- vs. ELT-Pipelines: Was ist der Unterschied?

ETL steht für „Extract, Transform, Load“. In einem ETL-Modell rufen Sie Daten aus einem Quellsystem ab, leiten sie durch eine Transformationsschicht, die sie bereinigt, umformt und filtert, und laden das verarbeitete Ergebnis dann an einen Zielort, wie ein Data-Warehouse oder einen Data Mart.

Bei ETL übernimmt eine separate Verarbeitungs-Engine die Hauptarbeit, bevor Daten den Zielort erreichen. Das Warehouse empfängt strukturierte Daten, die bereit sind, abgefragt zu werden, anstelle der rohen Quelldatensätze. Eine erneute Verarbeitung aus der Quelle bedeutet entweder ein erneutes Extrahieren oder das Beibehalten einer separaten Rohkopie an einem anderen Ort.

ELT, was für „Extract, Load, Transform“ steht, kehrt die letzten beiden Schritte um. Rohdaten landen zuerst am Zielort, und dann werden Transformationen innerhalb des Warehouses unter Verwendung seiner eigenen Rechenleistung ausgeführt.

Diese Verlagerung wurde praktisch, als Cloud-Data-Warehouses es kostengünstig und schnell machten, SQL-Transformationen (Structured Query Language) über große Datensätze hinweg auszuführen. Anstelle einer separaten Transformations-Engine, die zwischen Quelle und Zielort angesiedelt ist, ist Ihr Warehouse die Transformationsumgebung.

Wie funktioniert ETL?

Eine ETL-Pipeline läuft in drei Phasen ab, jede mit einer bestimmten Zuständigkeit.

So funktioniert ETL:

• Extrahieren: Ein Connector oder Ingestion-Job ruft Daten aus der Quelle ab, z. B. aus einer Datenbank, einer Zahlungs-API (Application Programming Interface), einer SaaS-Plattform (Software-as-a-Service) oder einer Flatfile. Dieser Schritt handhabt Authentifizierung, Paginierung, inkrementelle gegenüber vollständiger Aktualisierungslogik und Ratenbegrenzungen.

• Transformieren: Die extrahierten Daten gelangen in eine Verarbeitungsschicht, wo sie bereinigt (z. B. Nullwerte behandelt, Typen umgewandelt), umgeformt (z. B. Joins, Aggregationen, Spaltenumbenennungen), gefiltert und manchmal mit Referenzdaten aus anderen Quellen angereichert werden.

• Laden: Der verarbeitete Datensatz wird als vollständiges Überschreiben, als Upsert oder als Anfügen an den Zielort geladen, abhängig davon, wie die Pipeline konfiguriert ist.

ETL ist in diesen spezifischen Situationen weiterhin sinnvoll:

• Eingeschränkte Zielorte: Ältere Data-Warehouses oder lokale Systeme mit begrenzter Rechenleistung können große Transformationen vor Ort nicht effizient ausführen, sodass das Laden vortransformierter Daten die einzige realistische Option ist.

• Strenge Governance-Anforderungen: Einige Unternehmen müssen sicherstellen, dass personenbezogene Daten oder sensible Finanzdaten niemals in Rohform im Warehouse landen. Eine Transformation und Maskierung im Vorfeld erfüllt diese Anforderung architektonisch.

• Edge-Umgebungen: Das Internet der Dinge (IoT) und eingebettete Systeme, die Daten an eine zentrale Infrastruktur senden, können oft keine großen Rohdatenmengen übertragen, was eine lokale Transformation vor der Übertragung zu einer praktischen Notwendigkeit macht.

• Veraltete Pipeline-Infrastruktur: Viele etablierte Unternehmen verfügen über ETL-Pipelines, die seit Jahren zuverlässig laufen. Sie als ELT neu aufzubauen birgt ein Risiko, das es möglicherweise nicht wert ist, eingegangen zu werden.

Wie funktioniert ELT?

ELT-Pipelines extrahieren und laden rohe oder leicht formatierte Quelldaten direkt an den Zielort. Transformationen werden im Anschluss ausgeführt, aktiviert nach Zeitplan oder auf Abruf, unter Verwendung der eigenen Rechenleistung des Warehouses.

Beispielsweise kann ein Connector Daten aus einer Quelle extrahieren und in ein Rohschema in Ihrem Warehouse schreiben. Ein Analytics-Engineer schreibt dbt-Modelle (Data Build Tools), die aus diesem Rohschema lesen, die Geschäftslogik anwenden und bereinigte Tabellen erstellen, die Business-Intelligence-Tools (BI) abfragen können. Wenn sich die Logik ändern muss, wird das Modell einfach aktualisiert und erneut mit den bereits vorhandenen Daten ausgeführt.

ELT ist aus folgenden Gründen eine intelligente Wahl:

• Schnellerer Zugriff auf Rohdaten: Daten landen schnell im Warehouse, sodass Teams mit der Untersuchung und Validierung beginnen können, bevor die Transformationsschicht abgeschlossen ist.

• Kostengünstigere Verbesserungen: Das Ändern einer Transformation in ETL bedeutet oft, eine Pipeline zu modifizieren, neu abzuwickeln und neu zu laden. Bei ELT aktualisieren Sie einfach ein SQL-Modell und führen es erneut mit bereits vorhandenen Daten aus.

• Rechenleistung auf Warehouse-Ebene: Cloud-Warehouses sind dafür ausgelegt, große Datensätze schnell abzuwickeln. Das bedeutet, dass Sie beträchtliche Rechenleistung für die Transformation aufwenden, anstatt eine separate Middleware-Schicht unabhängig zu erweitern.

• Vollständiger Rohdatenverlauf: Da sich die Rohdaten immer im Warehouse befinden, können Sie jede nachgelagerte Tabelle von Grund auf neu ableiten, was wichtig ist, wenn sich Geschäftsdefinitionen ändern oder wenn Sie ein Datenqualitätsproblem beheben müssen.

Wie entscheiden Sie sich zwischen ETL und ELT?

Große Unternehmen betreiben in der Regel beide Datenverarbeitungsmodelle parallel für unterschiedliche Quellen. Die Anforderungen Ihres Unternehmens helfen Ihnen bei der Entscheidung, welche Methode die richtige ist.

Folgendes sollten Sie beachten.

Datenvolumen und -geschwindigkeit

Hochvolumige, hochfrequente Daten begünstigen im Allgemeinen eine ELT-Daten-Pipeline. Cloud-Warehouses können gut damit umgehen, und die Kosten für den vorgeschalteten Betrieb einer rechenintensiven Transformations-Engine steigen schnell. Als Kompromiss steigen Ihre Compute-Kosten für das Warehouse bei umfangreichen Transformationen, und auch die Speicherung von Rohdaten ist mit Kosten verbunden.

Pipelines mit geringerem Volumen und einer stabilen, klar definierten Transformationslogik können oft problemlos bei ETL bleiben.

Verantwortung für Transformationen

Wenn Ihre Transformationen SQL-basiert sind und von Analytics Engineers verantwortet werden, die sich schnell anpassen müssen, ist ELT mit dbt oder einem ähnlichen Tool wahrscheinlich die bessere Wahl.

Wenn Ihre Transformationen in Python oder Java programmiert sind und von einem Data-Engineering-Team verantwortet werden, fügt sich ETL möglicherweise auf natürliche Weise in Ihre bestehende Toolchain ein.

Zugriff auf Rohdaten

Wenn Analystinnen und Analysten Zugriff auf Quell-Rohdaten benötigen (z. B. für Ad-hoc-Untersuchungen, Audits oder weil sich die Transformationslogik noch in der Entwicklung befindet), ist ELT der bessere Standard. ETL-Pipelines, die keine Rohdaten speichern, machen es schwierig, einen solchen Zugriff nachträglich zu integrieren.

Governance und Compliance

Wenn bestimmte Daten maskiert oder anonymisiert werden müssen, bevor sie ein gemeinsames Ziel erreichen, bietet Ihnen ETL die Möglichkeit, diese Anforderung auf Architekturebene durchzusetzen.

ELT kann viele derselben Anforderungen durch Sicherheit auf Spaltenebene und Zugriffskontrollen auf Warehouse-Ebene erfüllen, aber die Implementierung unterscheidet sich und sollte im Hinblick auf Ihre Compliance-Verpflichtungen überprüft werden.

Team-Workflow

Ein Team mit umfassenden SQL-Kenntnissen und Versionskontrollgewohnheiten rund um dbt zieht mehr Nutzen aus einem ELT-Setup als aus der Wartung einer benutzerdefinierten ETL-Pipeline, die es nicht selbst entwickelt hat. Die Kompatibilität mit der Arbeitsweise Ihres Teams ist ein legitimer Faktor.

Wie passen Daten-Connectoren in ETL- und ELT-Pipelines?

Generische ETL- und ELT-Tools unterstützen eine Vielzahl von Quellen durch konfigurierbare Connectoren. Diese Bandbreite ist nützlich, bringt jedoch Kompromisse mit sich.

Zahlungsdaten sind ein gutes Beispiel. Das Datenmodell von Stripe deckt Ereignisse, Abbuchungen, Rückerstattungen, Zahlungsanfechtungen, Saldo-Transaktionen, Kundinnen und Kunden, Abonnements und Rechnungen ab. Ein generischer Connector, der nicht mit der API-Versionierung von Stripe Schritt hält oder die inkrementelle Synchronisierungslogik falsch verarbeitet, kann Fehler verursachen, die schwer zu erkennen sind, bis sie sich auf ein Dashboard oder einen finanziellen Abgleich auswirken.

Stripe Data Pipeline geht dies direkt an:

• Von Stripe entwickelt und verwaltet: Da Stripe der Connector gehört und dieser die interne Stripe-Infrastruktur direkt widerspiegelt, können Sie Daten kontinuierlich und zuverlässig synchronisieren und gleichzeitig Vollständigkeit und Richtigkeit gewährleisten – unabhängig davon, wie viele Daten Sie haben und ohne API-Ratenbegrenzungen.

• Direkte Warehouse-Synchronisierung: Daten werden zu Amazon Redshift, Snowflake, Databricks und mehr übertragen, ohne Routing über einen Drittanbieter-Connector, wodurch sensible Finanzdaten aus zusätzlicher Anbieter-Infrastruktur herausgehalten werden.

• Vollständiger Stripe-Datensatz: Die Synchronisierung deckt Stripe-Objekte, vorgefertigte Finanzberichte und kuratierte Datensätze ab, um Analyse und Berichterstattung zu beschleunigen.

• Einfache Einrichtung: Die Verbindung wird im Stripe-Dashboard konfiguriert, es ist kein Code erforderlich. Wenn Sie bereits ELT-Pipelines für andere Quellen ausführen, fügen sich Stripe-Daten in dasselbe Muster ein.