Ein Sicherheitsnetz für das Zahlen-Rückgrat
Großer europäischer Energieversorger · Kunde auf Wunsch anonymAusgangslage
Ein Data Warehouse ist das Zahlen-Rückgrat eines Energieversorgers. Verbrauch, Handel, Abrechnung, Reporting — nahezu jede Entscheidung stützt sich auf Daten, die dort aufbereitet werden. Und dieses System steht nie still: Es wird laufend angepasst, weil neue Anforderungen, neue Felder und neue Auswertungen dazukommen.
Genau darin lag das Problem. Jede Anpassung glich einem Umbau am fahrenden Zug. Prüfen ließ sich das bisher nur von Hand und nur stichprobenartig — langsam, aufwendig und mit einem unangenehmen Restrisiko: stille Datenfehler. Das sind Zahlen, die auf den ersten Blick plausibel aussehen, in Wahrheit aber falsch sind. Sie fallen oft erst dann auf, wenn bereits auf ihrer Grundlage entschieden wurde.
Die Aufgabe war deshalb doppelt: Das Risiko solcher Fehler sollte sinken — und gleichzeitig sollten Änderungen schneller produktiv gehen können. Bisher vergingen vom Wunsch bis zur Freigabe schnell einige Wochen.
Unsere Lösung
Wir haben nicht versucht, das gesamte, über Jahre gewachsene System auf einen Schlag abzusichern. Das wäre teuer, langwierig und riskant gewesen. Stattdessen sind wir mit einem Piloten gestartet: Eine repräsentative Datenstrecke wurde vollständig mit automatischen Tests ausgestattet — als Beweis, dass der Ansatz trägt, und zugleich als Blaupause.
Regressionstests sollen sicherstellen, dass eine Änderung die bestehende Verarbeitung nicht unbemerkt verändert. Die Pipeline wird dafür ganz normal ausgeführt — mit ihrer echten, vorhandenen Logik. Der Knackpunkt ist die Frage: Woran misst man, dass das Ergebnis „richtig" ist? Für jede der über tausend Transformationen von Hand Soll-Werte zu hinterlegen, wäre bei dieser Größe und Komplexität unrealistisch.
Wir gehen deshalb den pragmatischen Weg: Maßstab ist der zuletzt fachlich geprüfte und freigegebene Stand. Produziert die Pipeline nach einer Änderung noch exakt dieselben Zahlen wie dieser Referenzstand, ist alles gut. Weicht etwas ab, schlägt das System an — bevor die Änderung live geht. Der freigegebene Stand ist damit selbst die Messlatte; genau so, wie ein Fachbereich die Zahlen am Ende auch nutzt.
Das besondere Merkmal dabei ist die Genauigkeit: Es ist keine Stichprobe und keine grobe Näherung, sondern ein exakter 1:1-Abgleich. Jede einzelne Zeile und jeder einzelne Wert des neuen Laufs wird mit dem freigegebenen Referenzstand verglichen. Schon eine einzige abweichende Zahl fällt auf — und zwar punktgenau: Der Report zeigt nicht nur „es gibt eine Abweichung", sondern welche Zeilen betroffen sind. Nichts verschwindet im Durchschnitt, nichts rutscht durch eine zu grobe Prüfung.
Ein solcher Abgleich hat allerdings eine natürliche Grenze, und die benennen wir offen: Er beantwortet die Frage „Hat sich etwas verändert?" — nicht die Frage, ob der Referenzstand selbst richtig ist. Steckt dort bereits ein bisher unbemerkter Fehler, bestätigt ein reiner Vergleich ihn, statt ihn zu finden. Deshalb prüft das Framework auf einer zweiten Ebene explizite Regeln, unabhängig vom Referenzstand: fachliche und Qualitätsprüfungen, die festlegen, was unabhängig von jeder Vorperiode gelten muss — etwa keine fehlenden Pflichtwerte, eindeutige Schlüssel oder Beträge im erwarteten Rahmen. Beide Ebenen zusammen decken zwei verschiedene Fragen ab: „Hat sich etwas verändert?" (1:1-Abgleich) und „Ist das Ergebnis in sich korrekt?" (explizite Regeln).
Dieser Test läuft nicht mehr von Hand, sondern automatisch — jede Nacht und bei jeder Änderung. Das Ergebnis ist ein verständlicher Report: grün, wenn alles passt; rot mit konkretem Hinweis, wenn eine Abweichung auftritt.
Das Entscheidende an diesem Piloten ist, dass er wiederverwendbar ist. Weil er als Vorlage angelegt wurde, lassen sich weitere Datenstrecken nach demselben Muster absichern, ohne jedes Mal von vorne zu beginnen. Jede zusätzliche Strecke wird dadurch schneller und günstiger als die davor.
Komplett mit KI gebaut — und mit KI erweiterbar
Das gesamte Framework wurde mit KI-Unterstützung entwickelt. Entscheidend ist aber, was das für die Zukunft bedeutet: Es bleibt mit KI erweiterbar.
Der Grund liegt im Aufbau. Das komplette Wissen, das zum Absichern einer Datenstrecke nötig ist — die Datenmodelle, das Testkonzept, die Testlogik und die Beschreibung jeder einzelnen Strecke — liegt strukturiert und an einem Ort in den Code-Repositories. Damit ist es nicht nur für Menschen lesbar, sondern auch für eine KI nutzbar: Sie kann diese Informationen auswerten und daraus die Absicherung weiterer Strecken ableiten.
Das ist der eigentliche Hebel hinter der Blaupause. Die Vorlage ist nicht nur eine Schablone zum Abschreiben, sondern eine maschinenlesbare Wissensbasis. Weitere Strecken anzuschließen wird damit zu einer Aufgabe, die eine KI auf Basis des vorhandenen Kontexts weitgehend vorbereiten kann — schnell, konsistent und zu einem Bruchteil des Aufwands einer Neuentwicklung von Hand.
Ergebnisse
- Ein automatisches Sicherheitsnetz – Jede Änderung wird gegen einen geprüften Referenzstand abgeglichen, statt auf manuelle Stichproben angewiesen zu sein.
- Exakter 1:1-Abgleich – Geprüft wird jede Zeile und jeder Wert, nicht nur eine Stichprobe; schon eine einzelne abweichende Zahl wird punktgenau sichtbar.
- Von Wochen auf Tage – Änderungen können deutlich schneller freigegeben werden, weil die Prüfung automatisiert passiert.
- Fehler vor der Produktion – Stille Abweichungen fallen im Test auf, nicht erst im Reporting oder in einer Entscheidung.
- Eine Blaupause, die skaliert – Der Pilot ist Vorlage für weitere Strecken; jede zusätzliche Absicherung baut auf dem gleichen Muster auf.
- KI-erweiterbar – Weil das gesamte Wissen strukturiert im Code liegt, kann eine KI die Absicherung weiterer Strecken vorbereiten — ohne jedes Mal bei null zu beginnen.
- Nachweisbare Qualität – Jeder Lauf hinterlässt einen nachvollziehbaren Beleg darüber, was geprüft wurde und mit welchem Ergebnis.
Lessons Learned
Das Schwierige an solchen Tests ist nicht der Vergleich zweier Zahlenstände — das ist der einfache Teil. Schwierig ist es, jeden Testlauf sauber, wiederholbar und ohne Nebenwirkungen auf das produktive System zu kapseln. Wer dieses Fundament richtig legt, bekommt verlässliche Tests fast geschenkt.
Zweitens hat sich bestätigt: Der zuletzt freigegebene Stand ist der beste Maßstab. Bei vielen und teils komplexen oder nicht vollständig einsehbaren Transformationen ist es unrealistisch, jede Regel von Hand als Soll-Wert zu hinterlegen. Der Vergleich gegen den freigegebenen Referenzstand testet die bestehende Logik an ihrem Ergebnis — und bleibt auch bei internen Umbauten stabil, solange das fachliche Ergebnis gleich bleibt. Und schließlich gehört der Datenschutz von Anfang an ins Design: Referenzdaten werden maskiert, sensible Felder redigiert — nicht als Nachrüstung, sondern als Teil des Fundaments.
Unter der Haube (für Technik-Interessierte)
Für alle, die es genauer wissen möchten — so ist das Framework technisch umgesetzt:
- Plattform & Stack – Das Data Warehouse läuft auf Snowflake; die Datenaufbereitung erfolgt in einem dbt-Projekt mit über 1.500 Modellen in Medaillon-Schichtung (Staging → Integration → Derivation/Data-Mart). Azure Data Factory orchestriert die ELT-Kette (Extract & Load), Azure DevOps steuert Pipelines, Scheduling und Reporting, Python bildet die Steuerungsschicht des Test-Runners. Bewusst wurde kein zusätzliches Test-Produkt eingeführt — das Framework nutzt den vorhandenen Stack und bleibt so im Haus wartbar.
- Golden-Dataset-Ansatz mit exaktem 1:1-Diff – Der „geprüfte Referenzstand" ist ein eingefrorener Golden-Datensatz; die Prüfung ist ein mengenbasierter
EXCEPT-Abgleich in beide Richtungen zwischen frischem Lauf und Referenz. Verglichen wird Zeile für Zeile und Wert für Wert — keine Stichprobe, keine Toleranzschwelle; Abweichungen werden bis auf die einzelnen betroffenen Zeilen ausgewiesen (bestimmte technische Spalten wie Zeitstempel/Prozess-IDs sind bewusst ausgenommen). - Vier Qualitäts-Gates (zwei Prüf-Ebenen) – Jeder Lauf durchläuft Build (Gate 1), Logik (Gate 2), Datenqualität (Gate 3) und Golden-Diff (Gate 4). Gate 2 + 3 sind explizite, regelbasierte dbt-Tests, die unabhängig vom Referenzstand prüfen, ob das Ergebnis in sich korrekt ist (und damit auch latente Fehler im Baseline-Stand aufdecken können); Gate 4 ist der 1:1-Abgleich gegen den freigegebenen Stand, der jede unbeabsichtigte Veränderung findet. Rot an einem Gate = rot im CI.
- Testisolation ohne Redeploy – Jeder Lauf baut über Per-Request-Overrides in ein eigenes, isoliertes Schema/Warehouse — ohne Nebenwirkungen auf Produktion und ohne erneutes Deployment.
- Rename-robuste Auflösung – Modellnamen werden über die dbt-Manifest-Metadaten auf physische Tabellen aufgelöst; laufende Umbenennungen und Refactorings am produktiven Modellbestand brechen die Tests dadurch nicht.
- CI/CD & Nachweis – Nightly-Lauf der kompletten Suite mit sicherer Key-Pair-Authentifizierung; Ergebnisse als JUnit (Tests-Tab) und als konsolidierter HTML-Report direkt auf der Build-Seite.
- Governance – Referenzdaten werden vor Ablage maskiert, personenbezogene Felder redigiert.
- KI-fähig durch Selbstbeschreibung – Jede Strecke ist über ein deklaratives Test-Manifest beschrieben (Modell, Slice, Baseline, Isolationsstrategie, Gates). Zusammen mit Modellen, Macros und Testkonzept liegt das gesamte Kontextwissen versioniert in den Repos — eine KI kann es direkt als Grundlage nutzen, um neue Manifeste zu erzeugen und weitere Strecken anzuschließen.
Relevante Leistungen
Wie wir ähnliche Qualitäts-Gates aufbauen:
Vertiefend lesen
Hintergründe zu den eingesetzten Werkzeugen:
Ähnliches Projekt in Ihrem Haus?
30 Minuten, unverbindlich. Wir teilen, was wir in vergleichbaren Projekten gelernt haben.
Gespräch vereinbaren