Fehlerbehebung in Datenpipelines

Was macht Fehlerbehebung in Datenpipelines?

Wann verwenden

• Ein Pipeline-Job ist fehlgeschlagen oder die Ausgabedaten sind falsch/fehlen/dupliziert.
• Ein Dashboard ist veraltet oder eine Metrik stimmt nicht mit der Quelle überein.
• Ein Stakeholder meldet eine Abweichung und Sie müssen die Ursache finden.
• NICHT verwenden für toolspezifische Laufzeitfehler, die bereits durch debugging-dbt-runs / debugging-airflow-pipelines abgedeckt werden (dort beginnen, dann dies für Datenkorrektheitsvorfälle nutzen).

Workflow

- [ ] Symptom genau definieren (welche Tabelle, Spalte, Zeilen, Zeitfenster)
- [ ] Linage stromaufwärts verfolgen, um die erste Stufe zu finden, in der die Daten falsch sind
- [ ] Isolieren: Handelt es sich um einen Code-Fehler, schlechte Eingabedaten, verspätete Daten oder einen Lauffehler?
- [ ] Verdächtige Stufe mit ihrer Quelle abgleichen (Zeilenanzahlen/Summen)
- [ ] Ursache beheben, dann eine idempotente Nachberechnung der betroffenen Fenster planen
- [ ] Einen Check hinzufügen, damit es nicht stillschweigend wieder auftreten kann

1. Symptom eingrenzen. „Der Umsatz für 2026-01-15 ist in fct_orders ~30% niedriger“ ist debugbar; „Zahlen sehen komisch aus“ ist es nicht. Besorgen Sie sich Tabelle, Spalte, Zeilen und das Zeitfenster.
2. Linage stromaufwärts verfolgen. Gehen Sie vom falschen Ausgabepunkt rückwärts durch die Modelle/Aufgaben, um die erste Stufe zu finden, in der die Daten bereits falsch sind. Durchsuchen Sie den DAG binär, anstatt jede Stufe einzeln zu lesen.
3. Ursache klassifizieren: Code-Änderung, schlechte/verspätete Quelldaten, ein fehlgeschlagener/partieller Lauf oder ein nicht-idempotentes Duplikat.
4. Abgleich der verdächtigen Stufe mit ihrer Eingabe (Zeilenanzahlen, Schlüsselanzahlen, Summen), um zu bestätigen, wo die Abweichung auftritt.
5. Korrektur + Nachberechnung der betroffenen Fenster idempotent (siehe designing-backfills-and-replays).
6. Wiederkehr verhindern mit einem gezielten Datenqualitäts-Check.

Muster

Binäre Linagensuche – Überprüfen Sie eine Stufe auf halbem Weg im DAG: Wenn ihre Daten korrekt sind, liegt der Fehler stromabwärts; wenn falsch, gehen Sie weiter nach oben. Wiederholen.

Quelle gegen Ziel abgleichen für das betroffene Fenster:

-- Stimmen die Anzahlen/Summen zwischen der Stufe und ihrer Eingabe für das fehlerhafte Fenster überein?
SELECT 'Quelle' AS schicht, COUNT(*) n, SUM(betrag) gesamt
FROM staging.bestellungen WHERE bestelldatum = DATE '2026-01-15'
UNION ALL
SELECT 'Ziel', COUNT(*), SUM(betrag)
FROM marts.fct_bestellungen WHERE bestelldatum = DATE '2026-01-15';

Eine Lücke in der Anzahl → verworfene/gefilterte Zeilen oder ein fehlgeschlagener partieller Ladevorgang. Eine Summenlücke bei gleicher Anzahl → ein Transformations-/Logikfehler. Höhere Zielanzahl → Duplikation (nicht-idempotenter Ladevorgang).

Zeitleistenprüfung – Korrelieren Sie das Vorfallszeitfenster mit Deployments, Schemaänderungen der Quelle und dem Ausführungsverlauf; die meisten Vorfälle beginnen mit einer Änderung.

Häufige Fallstricke

• Beheben von Symptomen stromabwärts – Patchen des Marts, während der Fehler im Staging liegt, führt zu Wiederholung; beheben Sie die erste fehlerhafte Stufe.
• Manuelle Einmalkorrekturen an Produktionsdaten – nicht nachvollziehbar und nicht wiederholbar; korrigieren Sie stattdessen den Code und führen Sie ihn idempotent erneut aus.
• Lineares Lesen des gesamten DAG – verwenden Sie stattdessen die binäre Linagensuche.
• Abgleich überspringen – Raten, wo Daten divergieren, kostet Zeit; messen Sie Anzahlen/Summen pro Stufe.
• Kein präventiver Check nach der Korrektur – dieselbe Fehlerklasse kehrt unbemerkt zurück.