3 ETL-Fehler, die ich in meinen ersten Projekten gemacht habe
Es gibt Fehler, die man erst als Fehler erkennt, wenn man sie ein zweites Mal beobachtet – diesmal bei jemand anderem.
Ich habe in frühen ETL-Projekten Dinge gebaut, die technisch funktionierten – und trotzdem gescheitert sind. Nicht beim ersten Mal. Nicht beim zweiten. Sondern irgendwo zwischen Monat drei und Monat zwölf, wenn die Realität mit der ursprünglichen Annahme kollidiert.
Hier sind drei Fehler, die ich persönlich gemacht habe – was schiefgelaufen ist, warum, und was ich heute anders mache.
Fehler 1: Kein Monitoring – „es läuft doch“
Mein erstes größeres ETL-Projekt war eine Datenpipeline, die täglich Preisdaten von mehreren hundert Quellen zog und in eine zentrale Datenbank lud. Die Pipeline lief – zuverlässig, für einige Monate.
Dann änderte eine der Quellen ihr HTML-Layout. Mein Scraper lieferte weiterhin Ergebnisse – nur keine richtigen mehr. Er las Daten aus dem falschen Element, schrieb sie in die Datenbank, und die Datenbank wuchs.
Wir haben es bemerkt, als jemand die Ausgabe manuell überprüft hat. Drei Wochen nach der Quell-Änderung.
Was ich gelernt habe: Eine Pipeline ohne Monitoring ist eine Pipeline, von der du nicht weißt, ob sie funktioniert. „Es läuft“ und „es liefert korrekte Ergebnisse“ sind zwei verschiedene Aussagen.
Was ich heute mache: Jede Pipeline bekommt mindestens drei Checks: 1. Lautstärke-Check: Wird mindestens X Datensätze pro Tag geliefert? 2. Plausibilitäts-Check: Liegen Werte in erwarteten Ranges? 3. Frische-Check: Wann war der letzte erfolgreiche Import?
Wenn einer dieser Checks fehlschlägt, kommt eine Benachrichtigung. Nicht am nächsten Werktag – sofort.
Fehler 2: Kein Schema-Versioning – „die Quelle ändert sich doch nicht“
Ein anderes Projekt: eine B2B-Datenintegration, die Produktdaten aus einem externen System zog. Das externe System hatte eine gut dokumentierte API. Die Integration lief stabil.
Dann hat der Anbieter in einer Minor-Version ein Pflichtfeld umbenannt. `product_id` wurde zu `item_id`. Kein Breaking-Change aus ihrer Sicht – ein Alias wurde für sechs Monate parallel geführt.
Unser System schrieb still `null` in das entsprechende Feld. Sechs Monate lang.
Was ich gelernt habe: „Die Quelle ändert sich nicht“ ist eine Annahme, keine Zusicherung. Externe APIs, Webseiten, Exportformate – alles hat Änderungszyklen, die ich nicht kontrolliere.
Was ich heute mache: Explizites Schema-Versioning von Anfang an. Das bedeutet: Das erwartete Schema ist dokumentiert, Abweichungen werfen Alerts (keine stillen Nullen, keine Typen-Coercion ohne Log), und API-Versionen werden festgehalten und bei Updates geprüft. Wenn die Quelle ihr Schema ändert – will ich das wissen, bevor die Daten in der Datenbank landen.
Fehler 3: Kein Ownership – „das weiß ich noch“
Das dritte Beispiel ist kein technischer Fehler. Es ist ein organisatorischer.
Ich habe eine ETL-Pipeline für einen Kunden gebaut und deployt. Dokumentiert habe ich sie in meinem eigenen Stil – knapp, technisch, für mich verständlich. Der Kunde hatte jemanden, der „sich darum kümmert“ – aber das war kein Data Engineer, sondern jemand aus der IT-Abteilung, der auch andere Aufgaben hatte.
Als ich einige Monate später gefragt wurde, warum eine bestimmte Transformation so und nicht anders gemacht wurde – konnte ich die Frage beantworten. Als der Kunde es ein Jahr später ohne mich wissen wollte: keine Chance.
Was ich gelernt habe: Eine Pipeline ohne klaren Ownership ist eine Pipeline mit Ablaufdatum. Nicht weil die Technik versagt – sondern weil das Wissen irgendwann fehlt.
Was ich heute mache: Jede Pipeline, die ich baue, bekommt eine Betriebsdokumentation – nicht für mich, sondern für die Person, die in 18 Monaten damit arbeitet. Das umfasst: Was macht die Pipeline (in einem Satz), wo läuft sie, wie startet/stoppt man sie, welche Fehlermeldungen bedeuten was, und wer ist verantwortlich für welche Teile.
Das klingt selbstverständlich. Es ist es nicht.
Was diese drei Fehler gemeinsam haben
Alle drei sind keine Anfängerfehler im technischen Sinn. Die Pipelines haben funktioniert. Das war das Problem.
Wenn etwas funktioniert, hört man auf zu fragen, was passiert wenn es aufhört zu funktionieren. Man baut nicht für den Normalfall – man baut für den Ausnahmefall.
Monitoring ist für den Fall, dass die Quelle ihr Layout ändert. Schema-Versioning ist für den Fall, dass der Anbieter eine neue API-Version einführt. Ownership-Dokumentation ist für den Fall, dass derjenige, der die Pipeline gebaut hat, nicht mehr da ist.
Alle drei kosten Zeit beim Aufbau. Keiner davon kostet so viel Zeit wie die Konsequenzen, wenn sie fehlen.
Weitere Ressourcen
Wenn du eine Datenpipeline aufbauen oder outsourcen willst – mit Monitoring, Schema-Management und definiertem Ownership:
→ Datenpipeline-Service – brain-maze.de
Und die Make-or-Buy-Überlegung dahinter:
