ETL (Extract, Transform, Load)
Daten liegen in Unternehmen oft verstreut in unterschiedlichen Systemen, in unterschiedlichen Formaten und mit unterschiedlicher Qualität. Bevor sie gemeinsam ausgewertet werden können, müssen sie zusammengeführt, bereinigt und in ein einheitliches Zielsystem übertragen werden. Diesen dreistufigen Ablauf bezeichnen Fachleute als ETL: Extract, Transform, Load.
Drei Phasen, ein Ziel: konsistente Daten
ETL gliedert sich in drei aufeinanderfolgende Schritte. Zuerst werden Rohdaten aus verschiedenen Quellen extrahiert. Dann werden diese Daten bereinigt, vereinheitlicht und in eine Zielstruktur gebracht. Zuletzt werden die aufbereiteten Daten in ein Zielsystem geladen.
Beispiel: Ein Handelsunternehmen betreibt ein ERP-System für Warenwirtschaft, ein CRM für Kundenbeziehungen und eine separate Buchhaltungssoftware. Ein ETL-Prozess liest täglich Daten aus allen drei Systemen aus, bringt Kunden-IDs und Datumsformate auf einen einheitlichen Standard und schreibt die konsolidierten Datensätze in ein zentrales Data Warehouse.
Beispiel: Ein Online-Marktplatz extrahiert Produktbewertungen aus einer relationalen Datenbank und Nutzungsstatistiken aus einem Log-System. Im Transformationsschritt werden doppelte Einträge entfernt, Bewertungsskalen normalisiert und Zeitstempel auf UTC vereinheitlicht. Das Ergebnis landet in einer analytischen Datenbank für das Reporting-Team.
Extraktion: Daten aus Quellsystemen lesen
Die Extraktion greift auf heterogene Quellen zu: relationale Datenbanken, REST-APIs, Dateisysteme mit CSV- oder JSON-Exporten, Message Queues oder SaaS-Plattformen. Entscheidend ist die Strategie: Bei der Vollextraktion werden alle Datensätze gelesen, bei der inkrementellen Extraktion nur die seit dem letzten Lauf geänderten.
Beispiel: Ein Versicherungsunternehmen extrahiert Schadenmeldungen aus einer Oracle-Datenbank per SQL-Abfrage. Als Änderungsindikator dient eine Spalte modified_at. Bei jedem Lauf werden nur Zeilen gelesen, deren modified_at nach dem Zeitstempel des letzten erfolgreichen Laufs liegt.
Beispiel: Ein Medienunternehmen ruft täglich Nutzungsdaten von einer Streaming-Plattform über eine paginierte REST-API ab. Die Extraktion iteriert über alle Seiten, bis die API eine leere Antwort liefert, und speichert die Rohdaten als JSON-Dateien in einem Staging-Bereich.
Fachliche Einordnung: Die Wahl zwischen Voll- und inkrementeller Extraktion beeinflusst Laufzeit, Netzwerklast und Systembelastung der Quelle erheblich. Inkrementelle Extraktion setzt voraus, dass die Quelle einen zuverlässigen Änderungsindikator bereitstellt. Fehlt dieser, bleibt nur die Vollextraktion oder ein Change-Data-Capture-Mechanismus auf Datenbankebene.
Transformation: Daten bereinigen und vereinheitlichen
In der Transformationsphase werden Rohdaten in eine konsistente Zielstruktur überführt. Typische Operationen umfassen: Datentyp-Konvertierung, Entfernung von Duplikaten, Normalisierung von Einheiten, Anreicherung durch Lookup-Tabellen, Aggregation und Filterung fehlerhafter Datensätze.
Beispiel: Eine internationale E-Commerce-Plattform erhält Bestellungen mit Preisen in unterschiedlichen Währungen. Die Transformation rechnet jeden Betrag anhand des Tageskurses in Euro um, rundet auf zwei Dezimalstellen und fügt den originalen Währungscode als eigene Spalte hinzu.
Beispiel: Ein Gesundheitsdienstleister führt Patientendaten aus drei Kliniken zusammen. Klinik A speichert Geburtsdaten als DD.MM.YYYY, Klinik B als YYYY-MM-DD, Klinik C als Unix-Timestamp. Die Transformation vereinheitlicht alle Datumsangaben auf ISO 8601 und prüft, ob die Werte in einem plausiblen Bereich liegen.
Transformationen können unterschiedlich komplex ausfallen. Einfache Mappings ordnen Quellspalten Zielspalten zu. Komplexe Transformationen berechnen abgeleitete Kennzahlen, verbinden Datensätze aus mehreren Quellen über Schlüsselfelder oder wenden Geschäftsregeln an.
Laden: Daten in das Zielsystem schreiben
Die letzte Phase überträgt die transformierten Daten in das Zielsystem. Häufig handelt es sich um ein Data Warehouse, eine analytische Datenbank oder einen Data Lake. Die Ladestrategie bestimmt, wie mit bestehenden Daten im Ziel umgegangen wird.
Beispiel: Ein Finanzdienstleister lädt täglich Transaktionsdaten in ein Data Warehouse. Die Strategie ist append-only: Neue Datensätze werden angefügt, bestehende bleiben unverändert. So entsteht eine lückenlose Historie für Auditierungszwecke.
Beispiel: Ein Logistikunternehmen aktualisiert Bestandsdaten per upsert-Strategie: Existiert ein Datensatz mit gleicher Artikel-ID bereits, wird er überschrieben. Existiert er nicht, wird er neu eingefügt. So spiegelt das Zielsystem immer den aktuellen Lagerbestand wider.
Beim Laden spielen Transaktionssicherheit und Fehlerbehandlung eine zentrale Rolle. Schlägt das Laden fehl, muss der gesamte Batch zurückgerollt werden können, ohne das Zielsystem in einem inkonsistenten Zustand zu hinterlassen.
Aufbau einer ETL-Pipeline
In der Praxis werden ETL-Pipelines durch einen Orchestrator gesteuert. Dieser plant die Ausführung zeitgesteuert oder ereignisbasiert, überwacht den Fortschritt und startet fehlgeschlagene Schritte erneut. Verbreitete Werkzeuge sind Apache Airflow, dbt, Talend, Informatica und AWS Glue.
Abgrenzung: ETL und ELT
Bei ETL findet die Transformation vor dem Laden statt. Bei ELT (Extract, Load, Transform) werden die Rohdaten zuerst in das Zielsystem geladen und dort transformiert. Der Unterschied liegt darin, wo die Rechenleistung für die Transformation aufgebracht wird.
Beispiel: Ein Unternehmen nutzt ein Cloud-Data-Warehouse mit hoher Rechenkapazität. Statt einen separaten Transformationsserver zu betreiben, lädt der ELT-Prozess die Rohdaten direkt in das Warehouse und führt die Bereinigung dort per SQL aus. Die Transformation profitiert so von der Skalierbarkeit des Zielsystems.
ETL eignet sich besonders, wenn die Transformation rechenintensiv ist und das Zielsystem entlastet werden soll, wenn Datenschutzanforderungen erfordern, dass sensible Daten vor dem Laden anonymisiert werden, oder wenn das Zielsystem keine leistungsfähige Abfragesprache bietet. ELT bietet Vorteile, wenn das Zielsystem sehr leistungsfähig ist und Rohdaten für spätere, noch unbekannte Analysen aufbewahrt werden sollen.
Fachliche Einordnung: Die Grenze zwischen ETL und ELT verschwimmt in modernen Architekturen. Viele Pipelines kombinieren beide Ansätze: Leichte Transformationen (Typkonvertierung, Deduplizierung) erfolgen während der Extraktion, komplexe Geschäftslogik erst im Zielsystem. In der Literatur wird diese Mischform gelegentlich als ETLT bezeichnet.
ETL im Kontext von Machine Learning und KI
Für Machine Learning und KI-Anwendungen übernimmt ETL eine besondere Rolle: die Aufbereitung von Trainingsdaten. Die Qualität eines Modells hängt direkt von der Qualität der Eingabedaten ab. Fehlerhafte, unvollständige oder verzerrte Daten führen zu unzuverlässigen Modellen.
Beispiel: Ein Unternehmen trainiert ein Modell zur Kundensegmentierung. Der ETL-Prozess extrahiert Kaufhistorien, Supporttickets und Webanalysedaten. Die Transformation entfernt Testkonten, anonymisiert personenbezogene Daten, normalisiert numerische Merkmale auf einen einheitlichen Wertebereich und kodiert kategoriale Variablen. Das Ergebnis ist ein bereinigter Datensatz, der direkt als Trainingsgrundlage dient.
Beispiel: Ein NLP-Projekt benötigt einen Textkorpus aus Kundenbewertungen. Der ETL-Prozess extrahiert Bewertungstexte aus einer Datenbank, entfernt HTML-Tags und Sonderzeichen in der Transformationsphase und filtert Einträge mit weniger als zehn Wörtern heraus. Die bereinigten Texte werden als strukturierte Datei für die Tokenisierung bereitgestellt.
Im Bereich Deep Learning wachsen die Datenmengen und damit auch die Anforderungen an ETL-Pipelines. Bildklassifikation erfordert die Extraktion und Normalisierung tausender Bilddateien, Sprachmodelle benötigen bereinigte Textkorpora im Terabyte-Bereich. Skalierbare ETL-Architekturen mit verteilter Verarbeitung (etwa Apache Spark) sind in solchen Szenarien verbreitet.
Datenqualität und Monitoring
Eine ETL-Pipeline ist nur so zuverlässig wie ihre Fehlererkennung. Produktive Pipelines enthalten Prüfschritte, die Datenqualität während der Transformation und nach dem Laden überwachen.
Beispiel: Nach jedem Ladevorgang prüft ein Validierungsschritt, ob die Anzahl der geladenen Datensätze mit der Anzahl der extrahierten Datensätze übereinstimmt. Bei einer Abweichung von mehr als zwei Prozent wird der Lauf als fehlerhaft markiert und das Monitoring-Team benachrichtigt.
Typische Qualitätsprüfungen umfassen: Vollständigkeitschecks (Anzahl Datensätze, Nicht-Null-Anteile), Plausibilitätsprüfungen (Wertebereiche, statistische Verteilungen), Aktualitätsprüfungen (maximales Alter eines Datensatzes) und Konsistenzprüfungen (Fremdschlüsselbeziehungen).
Beispiel: Ein ETL-Prozess berechnet nach der Transformation die Verteilung eines Merkmals (etwa Bestellwert) und vergleicht sie mit der Verteilung des Vortages. Eine plötzliche Verschiebung des Medians deutet auf ein Quellsystemproblem oder eine fehlerhafte Transformation hin.
Grenzen und Herausforderungen
ETL ist kein Allzweckwerkzeug. Die Architektur hat klare Einschränkungen, die bei der Planung berücksichtigt werden müssen.
Latenz ist ein strukturelles Merkmal klassischer ETL-Pipelines. Da Daten in Batches verarbeitet werden, entsteht zwischen Extraktion und Verfügbarkeit im Zielsystem eine Verzögerung. Für Echtzeitanwendungen wie Betrugserkennung oder Live-Dashboards reicht Batch-ETL nicht aus. Hier kommen Stream-Processing-Systeme wie Apache Kafka oder Apache Flink zum Einsatz.
Komplexität steigt mit der Anzahl der Quellen und Transformationsregeln. In großen Organisationen können ETL-Pipelines hunderte Transformationsschritte umfassen. Ohne saubere Dokumentation und Versionierung wird die Wartung aufwändig.
Fehlerfortpflanzung ist ein weiteres Risiko. Ein Fehler in einem frühen Transformationsschritt kann sich unbemerkt durch die gesamte Pipeline ziehen und erst im Reporting sichtbar werden. Systematisches Monitoring und Data Lineage (die Rückverfolgbarkeit jedes Datensatzes zu seiner Quelle) wirken dem entgegen.
Fachliche Einordnung: ETL entstand in den 1970er-Jahren im Kontext früher Data-Warehouse-Systeme. Trotz neuerer Architekturkonzepte wie Data Mesh, Lakehouse oder Streaming-First-Architekturen bleibt der Grundgedanke erhalten: Daten müssen aus Quellen gelesen, aufbereitet und in Zielsysteme geschrieben werden. Die Werkzeuge und Ausführungsmodelle ändern sich, das Grundmuster nicht.