Früher folgten Daten-Pipelines einer strikten Abfolge: Daten mittels Pull-Methode aus Quellsystemen abrufen, in ein sauberes, strukturiertes Format transformieren und das fertige Produkt dann in eine Datenbank laden. Diese Abfolge (Extrahieren, Transformieren, Laden oder ETL) war sinnvoll, als Speicher teuer war und die Zielsysteme nicht leistungsstark genug waren, um rechenintensive Aufgaben auszuführen.

Aber Cloud-Warehouses haben das alles verändert und ELT (Extrahieren, Laden, Transformieren) wurde zu dem Muster, das viele Analytics-Teams heute standardmäßig verwenden. Obwohl das traditionelle ETL einen Marktanteil von fast 40 % behält, verliert es schnell an Boden gegenüber anderen Arten von Daten-Pipelines wie ELT.

Im Folgenden erörtern wir, was ELT ist, wie es funktioniert und wo es sich anbietet und wo nicht.

Das Wichtigste auf einen Blick

• Ein ELT-Prozess (Extrahieren, Laden, Transformieren) lädt Rohdaten zuerst in ein Cloud-Warehouse und transformiert sie dann. Dies bietet Analystinnen und Analysten schnelleren Zugriff auf Daten und mehr Flexibilität zur Verbesserung von Modellen.

• Cloud-Warehouses eignen sich gut für ELT, da sie Speicher und Rechenleistung trennen, elastisch skalieren und es Analystinnen und Analysten ermöglichen, Transformationslogik in Structured Query Language (SQL) zu schreiben.

• Die Zusammenarbeit mit einem Zahlungsanbieter, der direkt mit Ihrem Warehouse synchronisiert, ohne den Umweg über die Infrastruktur von Drittanbietern zu nehmen, reduziert die Pipeline-Komplexität und Sicherheitsrisiken.

Was ist ELT und wie funktioniert es?

ELT (Extrahieren, Laden, Transformieren) ist ein Datenintegrationsmuster, das auf drei Schritten basiert: Extrahieren von Daten aus Quellsystemen, Laden als Rohdaten an ein zentrales Ziel und anschließendes Transformieren innerhalb des Ziels für Analytics, Berichterstattung oder maschinelles Lernen.

So läuft ein typischer ELT-Workflow in der Praxis ab:

• Extrahieren: Ein Konnektor oder Pipeline-Job ruft Datensätze (inkrementell, nach einem Zeitplan oder durch Ereignisse ausgelöst) aus einem Quellsystem ab und schreibt sie in ihrer ursprünglichen Struktur in das Ziel.

• Laden: Rohtabellen landen im Warehouse, oft in einem dedizierten Schema, wobei Feldnamen, Datentypen und Beziehungen genau so beibehalten werden, wie sie in der Quelle existierten.

• Transformieren: Die Transformationslogik läuft innerhalb des Warehouses ab, da SQL-basierte Tools wie dbt (Data Build Tool) es Teams ermöglichen, Versionen dieser Modelle zu steuern, sie zu testen und Datensätze auf der Rohschicht aufzubauen.

Da Rohdaten zuerst landen, können Analystinnen und Analysten sie sofort abfragen und mehrere nachgelagerte Ansichten können aus einer einzigen Quelle erstellt werden, ohne erneut zu extrahieren. Wenn ein Transformationsmodell falsch ist, schreiben Sie es um und führen es erneut für Daten aus, die sich bereits im Warehouse befinden.

Wie unterscheidet sich ELT in der Praxis von ETL?

Der wichtigste architektonische Unterschied zwischen ETL und ELT besteht darin, wo die Transformation stattfindet: bei ETL außerhalb des Ziels, bei ELT innerhalb des Ziels.

Hier sind die größten Unterschiede zwischen ETL und ELT:

• Datenverfügbarkeit: In einer ETL-Pipeline können Daten erst abgefragt werden, wenn sie transformiert und geladen wurden. Bei ELT landen die Rohdaten zuerst, sodass Analystinnen und Analysten damit arbeiten können, während Transformationsjobs separat ausgeführt werden.

• Verbesserungsgeschwindigkeit: Das Ändern einer Transformation in einer ETL-Pipeline bedeutet oft, dass die Pipeline selbst neu erstellt werden muss. In ELT aktualisieren Sie ein SQL-Modell und führen es erneut für Daten aus, die sich bereits im Warehouse befinden.

• Wo sich die Rechenleistung befindet: ETL-Transformationen werden auf der Pipeline-Infrastruktur ausgeführt (einem separaten Server oder Dienst, den Sie für diesen Zweck bereitstellen). ELT-Transformationen werden auf der Rechenleistung eines Data Warehouses ausgeführt, das elastisch skaliert und bereits bezahlt ist.

• Aufbewahrung von Rohdaten: ETL verwirft in der Regel Zwischenzustände, sobald die transformierte Ausgabe erstellt wurde. ELT behält die Rohschicht standardmäßig bei, was bedeutet, dass Sie historische Daten bei sich ändernden Anforderungen erneut verarbeiten können.

Warum eignet sich ELT für moderne Cloud-Data-Warehouses?

Die folgenden Eigenschaften machen ELT ideal für Cloud-Warehouses:

• Getrennter Speicher und Rechenleistung: Plattformen wie Snowflake und BigQuery berechnen die Datenspeicherung und -abfrage separat. Sie können beliebig viele Rohdaten ablegen, und Transformationsjobs verbrauchen nur dann Rechenleistung, wenn sie ausgeführt werden.

• Elastische Skalierung: Sie können die benötigte Rechenleistung bereitstellen, den Job ausführen und sie wieder reduzieren. Das Warehouse übernimmt die Parallelisierung.

• Spaltenbasierte Speicherung: Cloud-Warehouses speichern Daten im Spaltenformat, was analytische Abfragen (Aggregationen, Filter, Joins über große Datensätze) drastisch schneller macht als die zeilenbasierte Speicherung.

• Natives SQL: Die meisten Analystinnen und Analysten sowie Analytics-Fachleute kennen bereits SQL. Die Ausführung von Transformationen innerhalb des Warehouses bedeutet, dass die Personen, die die Geschäftslogik verstehen, die Transformationsmodelle direkt schreiben und verwalten können.

Wann ist ELT gut geeignet?

ELT ist nicht für jede Daten-Pipeline die richtige Antwort, passt aber zu einer erkennbaren Reihe von Bedingungen.

Hier funktioniert ELT in der Regel gut:

• Große oder schnell wachsende Datensätze: Wenn Sie Millionen von Ereignissen pro Tag synchronisieren, erfordert die Ausführung von Transformationen vor dem Laden eine beträchtliche Pipeline-Infrastruktur. Das Laden von Rohdaten und die Transformation innerhalb des Warehouses ist bei entsprechender Skalierung praktischer.

• Häufig wechselnde Transformationslogik: Wenn Transformationen als SQL-Modelle im Warehouse verbleiben, erfordert die Aktualisierung der Analytics-Anforderungen keine erneute Bereitstellung der Pipeline-Infrastruktur.

• Mehrere nachgelagerte Anwendungsfälle: Rohdaten im Warehouse können gleichzeitig ein Dashboard für Business Intelligence, einen Feature-Store für maschinelles Lernen und einen Betriebsbericht speisen. Sie bauen eine Pipeline auf und modellieren die Daten für jede nutzende Person unterschiedlich.

• Teams mit Kompetenzen im Bereich Analytics-Engineering: ELT verlagert die Verantwortung für Transformationen auf die Analytics-Schicht. Teams, die Tools wie dbt nutzen, sind hierfür bestens geeignet.

Unter den folgenden Umständen ist ELT nicht gut geeignet:

• Behördliche Einschränkungen für Rohdaten: In einigen Umgebungen für Gesundheits- und Finanzdaten ist das Speichern vertraulicher Daten vor dem Maskieren oder Filtern verboten. In diesen Fällen müssen Transformationen vorgelagert stattfinden.

• Starre Zielschemas: Wenn Ihr Ziel keine Rohdaten oder halbstrukturierten Daten aufnehmen kann, verursacht der Load-first-Ansatz von ELT mehr Probleme, als er löst.

• Kleine, stabile Datensätze: Wenn eine einfache ETL-Pipeline die Aufgabe erfüllt, stellt das Hinzufügen einer Infrastruktur für die Warehouse-Transformation einen Mehraufwand ohne großen Nutzen dar.

Welche Herausforderungen bringt ELT mit sich?

Das Speichern von Rohdaten in einem Warehouse ist leistungsstark, kann jedoch Herausforderungen in Bezug auf Governance und Kosten mit sich bringen.

Beachten Sie diese potenziellen Herausforderungen von ELT.

Zugangskontrolle

Rohtabellen enthalten oft Daten, die nicht allgemein zugänglich sein sollten, wie z. B. personenbezogene Daten (PII), Finanzunterlagen oder interne Identifikatoren. Bei ETL können vertrauliche Felder maskiert oder verworfen werden, bevor die Daten überhaupt das Ziel erreichen. Bei ELT landen die Daten jedoch zuerst im Ziel. Ohne Sicherheit auf Zeilenebene, Spaltenmaskierung oder eng gefasste Warehouse-Rollen können Analystinnen und Analysten Felder abfragen, die sie nicht sehen sollten.

Datenqualität

Schlechte Daten aus vorgelagerten Quellen landen in Ihrem Warehouse, bevor irgendwelche Überprüfungen ausgeführt werden. Null-Felder, doppelte Datensätze, Schemaänderungen und Typkonflikte können sich in nachgelagerte Modelle übertragen, wenn Sie nicht mithilfe des Test-Frameworks von dbt oder Warehouse-nativen Datenqualitätsfunktionen Qualitätstests in die Transformationsschicht integrieren.

Kostenmanagement

Transformationsjobs werden auf Warehouse-Ressourcen ausgeführt und schlecht geschriebenes SQL (wie z. B. unbegrenzte Scans, fehlende Partitionsfilter oder redundante vollständige Tabellenaktualisierungen) kann erhebliche Kosten verursachen. Die Festlegung von Limits für die Kosten von Abfragen, die Verwendung inkrementeller Modelle (wo möglich) und die Überwachung der Rechnernutzung sollten von Anfang an in Ihren Workflow integriert werden.

Wie handhabt ein ELT-Workflow Zahlungsdaten?

Viele Teams erstellen eine benutzerdefinierte Integration für die API (Anwendungsprogrammierschnittstelle) ihres Zahlungsanbieters oder verwenden den Konnektor eines Drittanbieters. Benutzerdefinierte Integrationen erfordern jedoch eine fortlaufende Wartung, wenn sich die API ändert, und Konnektoren von Drittanbietern bedeuten, dass sensible Finanzdaten über die Infrastruktur eines zusätzlichen Anbieters geleitet werden.

Stripe Data Pipeline ist eine native Option, die direkt in das Stripe-Dashboard integriert ist. Sie synchronisiert Stripe-Daten und -Berichte mit wenigen Klicks mit Snowflake, Databricks, Amazon Redshift und anderen. Es gibt keinen Code (No-Code), keine Konnektorkonfiguration und keine separaten Anmeldeinformationen, die verwaltet werden müssen. Die Synchronisierung erfolgt über die eigene Infrastruktur von Stripe, sodass bei der Übertragung keine Drittanbietersysteme mit Ihren Finanzdaten in Berührung kommen.

Einige Besonderheiten, die man kennen sollte:

• Historische Abdeckung: Stripe Data Pipeline umfasst historische Daten ab dem Beginn Ihres Stripe-Kontos und nicht erst ab dem Zeitpunkt, an dem Sie die Synchronisierung aktivieren.

• Schema: Daten landen in Tabellen, die das Datenmodell von Stripe widerspiegeln (z. B. Belastungen, Kundinnen und Kunden, Abonnements), was es einfach macht, Transformationsmodelle darauf aufzubauen, ohne dass eine umfangreiche Bereinigung der Rohschicht erforderlich ist.

• Datenvollständigkeit: Zusätzlich zu den reinen Objektdaten umfasst Stripe Data Pipeline den Zugriff auf vorgefertigte Finanzberichte und kuratierte Datensätze, was die Berichterstattung beschleunigen und die Transformationsarbeit für häufige Anwendungsfälle wie den monatlich wiederkehrenden Umsatz (MRR) und die Betrugsanalyse reduzieren kann.