Einleitung und Systembeschreibung
Es war einmal eine Behörde, die hatte ein Data Warehouse(DWH) in der Statistikabteilung …
Das DWH wird einmal täglich von mehreren verschiedenen Quellsystemen beliefert. Die Daten einiger Quellsysteme haben Abhängigkeiten untereinander (z.B. zeigen die Zahlungen aus einem System auf die Stammdaten aus einem anderen System) sodass der tägliche ETL-Prozess nur abgeschlossen werden kann, wenn die Daten aus allen wichtigen Quellsystemen geliefert wurden.
Aus historischen Gründen erfolgt die Belieferung des DWH von jedem Quellsystem mithilfe von „Flat Files“. Die Vollständigkeit der Dateien wird über von den Quellsystemen erzeugte „end of delivery“-Dateien, oder über die für die Lieferung verwendeten Programme technisch sichergestellt. Es besteht keine zusätzliche Möglichkeit aus dem DWH Anfragen an die Quellsysteme zu stellen um dort Daten manuell abfragen zu können. Um die Lieferung so performant wie möglich zu gestalten, wird von allen Quellsystemen stets nur die Differenz zum Vortag geliefert.
Das DWH ist in zwei Teile gegliedert auf, welche in separaten Ladeprozessen bewirtschaftet werden:
Zum einen gibt es einen Bereich, in welchem die Informationen aus allen Quellsystemen verarbeitet werden. Dieser Bereich besteht aus einem aus Versions- Anker- und Bewegungsdaten-Tabellen aufgebautem CDW und einem aus Dimensions- und Faktentabellen aufgebauten DM. Der tägliche Ladeprozess für diesen Bereich dauert ca. 8 Stunden (im Folgenden wird dieser Bereich als Bereich der Gesamtdaten bezeichnet).
Der andere Bereich stellt einen Operational Data Store (ODS) des Hauptquellsystems da. Dieser Bereich spiegelt die Quellinformationen 1 zu 1 wieder und wurde erstellt um die Informationen mit den Reporting Programmen der Statistikabteilung darstellen zu können. Der tägliche Ladeprozess für diesen Bereich dauert ca. 15 Minuten. (im Folgenden wird dieser Bereich als ODS-Bereich bezeichnet)
Eine Besonderheit des DWH der Statistikabteilung ist, dass der tägliche Ladeprozess aufgrund von fachlichen Anforderungen indirekt als Qualitätssicherung für die Quellsysteme fungiert:
Von den Experten aus den Fachabteilungen wurden Regeln festgelegt, welche zum Beispiel die minimal auf einem Datensatz erhaltenen Informationen, oder die Einzigartigkeit von Schlüsselfeldern bestimmen. Da für die Statistikabteilung die Integrität der Daten von höchster Wichtigkeit ist und der Datenstand nicht tagesaktuell sein muss, wird der Ladeprozess bei einem Verstoß gegen diese Regeln unterbrochen. Erst, nachdem die Daten in den Quellsystemen korrigiert worden sind und daraufhin ein aktualisierter Datensatz geliefert worden ist, kann der betroffene Ladeprozess beendet werden.
Dennoch darf der Ladeprozess nicht beliebig lange verzögert sein, denn die folgende Rahmenbedingung muss eingehalten werden: Zum 10ten eines Monats müssen die Daten des vorherigen Monats komplett geladen sein, damit das Reporting für den vorherigen Monat durchgeführt werden kann.
Entdeckung der fehlerhaften Datenlieferung und Problembeschreibung
Im Rahmen eines täglichen Ladeprozesses im ODS-Bereich kam es eines Tages zu einer Unterbrechung, da für bestimmte Schlüsselfelder Duplikate vorhanden waren, welche die gleiche fachliche Gültigkeit hatten. Der Ladeprozess im Bereich der Gesamtdaten lief parallel ohne Abbruch durch, da hier andere fachliche Regeln festgelegt sind. Um den abgebrochenen Ladeprozess fortsetzen zu können, wurden die fehlerhaften Datensätze nach einer Anfrage an das Quellsystem aus den gelieferten Dateien entfernt. Durch diese Anpassungen konnte schließlich auch der Ladeprozess im ODS-Bereich fertiggestellt werden.
Nach einer Analyse des Quellsystems stellte sich heraus, dass die fehlerhafte Lieferung durch ein automatisches Einspielen von Backups aufgetreten war. Nach einer tiefergehenden Analyse wurde festgestellt, dass es auch Monate vor dem Zwischenfall schon zu diesem Problem gekommen war. Die vorherigen Fälle hatten aber keinen direkten Abbruch des Ladeprozesses zur Folge. Zudem konnte der Fehler durch die Analyse des Quellsystems auf 4 Dateien eingegrenzt werden. Die explizit betroffenen Datensätze konnten vom Quellsystem aber nicht identifiziert werden.
Für das DWH der Statistikabteilung hatten diese fehlerhaften Lieferungen 2 Auswirkungen:
- Akut konnte es immer wieder zu Abbrüchen des täglichen Loads kommen, da eine Diskrepanz zwischen dem Quellsystem und den DWH bestand. Diese Abbrüche erforderten manuelle Eingriffe auf Seiten des für die Bewirtschaftung des DWH zuständigen Teams und manuelle Überprüfungen auf Seiten des Quellsystems.
- Die Diskrepanz zwischen Quellsystem und dem DWH ist aus fachlicher Sicht nicht gewünscht. Neben den technischen Problemen durch die Abbrüche konnten auch fachliche Probleme durch fehlerhafte Statistiken nicht ausgeschlossen werden.
Analyse des Problems und Problemlösung
Um das Problem beheben zu können und das Ausmaß abschätzen zu können, musste der Datenstand des Quellsystems mit dem Datenstand des DWH verglichen werden. Mit relativ geringem Arbeitsaufwand konnten für die 4 betroffenen Dateien Vollabzüge aus dem Quellsystem erstellt und an das DWH geliefert werden.
Um den produktiven Betrieb nicht einzuschränken, wurde im DWH eine temporäre Umgebung aufgesetzt, welche mit dem Datenstand zum Zeitpunkt des Vollabzugs eingefroren wurde. Dieser Datenstand wurde dann auf der DB in neuen Schemas gespeichert, sodass die Daten als Referenz verfügbar waren. Danach wurden die 4 betroffenen Dateien mit den vorhandenen Bewirtschaftungsprozessen im ODS-Bereich in die eingefrorene DB geladen. Somit konnte nun der eingefrorene Datenstand des DWH mit dem Datenstand des DWH nach dem Laden des Vollabzugs verglichen werden. Zudem wurde hierdurch sichergestellt, dass es durch das Laden eines Vollabzugs im ODS-Bereich nicht zu unerwünschten Nebenwirkungen kommt, da dieser eigentlich nur für das Laden von Differenz-Dateien ausgelegt ist.
Das Einspielen und Laden der 4 Dateien verlief ohne größere Probleme und die Nachfolgende Analyse lieferte folgende Ergebnisse:
- Die betroffenen 4 Tabellen im ODS-Bereich können ohne weitere Anpassungen mit einem Vollabzug beladen werden.
- Die Abweichungen waren selbst auf Monatsebene so gering, dass keine signifikanten Auswirkungen für die Statistik zu erwarten sind.
Die Probleme ODS-Bereich konnten also ohne größere Herausforderungen bereinigt werden. Somit blieb (nur) noch die Bereinigung im Bereich der Gesamtdaten als Aufgabe übrig.
In diesem Bereich ist die Bewirtschaftungslogik so stark auf Differenzlieferungen ausgelegt, dass es nicht möglich ist einen Vollabzug zu laden. Aus diesem Grund wurde für die 4 verschiedenen Dateien mit deren Inhalt jeweils eine Anker- und eine Versions-Tabelle befüllt wird, die Logik in SQL nachgebaut. Die Logik wurde danach so angepasst, dass die Verarbeitung eines Vollabzugs möglich ist. Dafür mussten unter anderem Logiken zur Versionsgültigkeit und zum Löschen von Einträgen (was im normalen Betrieb nicht vorkommen kann) entwickelt werden. Nach einigen hundert Zeilen SQL-Code war somit auch die Bereinigung im Bereich der Gesamtdaten erledigt. Parallel dazu konnte manuell sichergestellt werden, dass alle Tabellen im CDW und im DM, welche mit den Daten aus den 4 Dateien bewirtschaftet werden, täglich ein Update erhalten, oder sogar komplett neu erstellt werden. Dadurch wurde bestätigt, dass die Korrekturen an den Anker- und Versions-Tabellen beim nächsten Ladeprozess automatisch an alle betroffenen Folgetabellen verteilt werden.
Dieses an der temporären Umgebung getestete Vorgehen konnte zunächst an der Testumgebung und im weiteren Verlauf an der Produktionsumgebung angewandt werden. Dazwischen lag natürlich der Durchlauf der Qualitätssicherung und das Ausführen und Dokumentieren von Tests.
Fazit und Designempfehlungen
Obwohl es in diesem Fall kein Problem gewesen ist, sollte bei einer Schnittstelle, welche auf der Lieferung von Dateien basiert, zusätzlich sichergestellt werden, dass alle gesendeten Daten vollständig im Zielsystem ankommen. Im vorliegenden Fall wurde diese Kontrolle von der verwendeten Software zur Datenlieferung durchgeführt. Bei der zusätzlichen Verwendung einer Prüfsumme oder einer anderen Art der Validierung hätte das Zielsystem die Möglichkeit einen Datenverlustes im Lieferungsprozess auszuschließen.
Das Vorhandensein von „Data-Lineage“ hätte den Aufwand beim Suchen nach betroffenen Fakten- und Dimensions-Tabellen deutlich reduziert. „Data-Lineage“ hätte aber nicht nur in diesem Fall den Aufwand verringert und die Gefahr von Fehlern durch manuelle Arbeit reduziert, sondern würde auch im Betrieb zum Beispiel bei Anfragen von Nutzern nach der Datenherkunft, oder bei Erweiterungen des DWH helfen.
Generell ist es hilfreich, wenn alle Bewirtschaftungsprozesse sowohl mit Differenzlieferungen als auch mit Vollabzügen umgehen können. Dadurch wäre in dem vorliegenden Fall sowohl in der Umsetzung als auch beim Testen viel Aufwand gespart worden. Alles in Allem konnte das DWH der Statistikabteilung wieder mit dem Quellsystem synchronisiert werden.
… und wenn sie nicht gestorben sind, dann laden sie [die täglichen Daten] noch heute.
