Bei der Umsetzung einer Datenschnittstelle für BI ist es wichtig, diese Schnittstellen abzusichern. Sind die Datenlieferungen nicht zuverlässig zum vereinbarten Zeitpunkt verfügbar, sind die Lieferungen falsch oder unvollständig, dann entsteht ungeplante Arbeit. In der Folge muss Entwicklungszeit für die Korrekturen abgezweigt werden. Das gilt es zu vermeiden.
In den ersten beiden Blogbeiträgen wurde vorgestellt, wie Schnittstellen am besten aufgebaut und einfach gehalten werden. Die Reduktion der möglichen Wege bringt eine Reduktion der Komplexität. Und es werden weniger Mechanismen zur Absicherung der Datenschnittstelle benötigt.
Aus den Überlegungen in den vorangegangenen Blogbeiträgen ergibt sich folgendes Zielbild:
Da die Frage, ob ein Datenbankimport stattfindet, relevant für die Absicherung ist, wurde ergänzt, an welcher Stelle ein DB-Import stattfinden könnte.
Folgende Themen sind für Schnittstellen zu prüfen:
- Ist das überlieferte Delta korrekt?
- Sind die Daten in der korrekten Struktur?
- Ist der Inhalt der Daten korrekt? Hat sich eventuell die Erfassung grundsätzlich verändert?
- Werden die Änderungen in der richtigen Reihenfolge geliefert?
Prüfung des Delta
Es passiert: Das Data Warehouse weicht von den Daten im operativen System ab. Ein Problem, dass sich beim einfachen Datenabzug mit der nächsten Lieferung vollautomatisch löst. Auf diesem Weg lassen sich auch Fehler in der Delta-Ermittlung finden und beheben. Ein vollständiger Abzug der Daten wird als Inventurlieferung an das Data Warehouse übermittelt und gegen die bisher geladenen Daten geprüft. Im Ergebnis erhält man alle Unterschiede.
Die Prüfung kann gegen die Stage oder gegen die Core Warehouse Schicht erfolgen. Gegen die Stage kann nur geprüft werden, wenn eine Persitant Staging Area (PSA) mit allen bisher gelieferten Sätzen zur Verfügung steht. Die Prüfung der Vollständigkeit kann nur gegen die aktuell gültigen Sätze erfolgen. Das Schöne an dieser Lösung: Die Abweichungen sind bereits im richtigen Format und können sofort zur Korrektur der Daten verwendet werden. Die Mechanismen für den Vergleich sind hierbei dieselben wie die Ermittlung des Deltas. Die Grundsatzentscheidung, immer nur das Delta zu laden, hilft auch hier und ermöglicht Prüfung und Ermittlung der notwendigen Korrektursätze in einem Schritt.
Bei der Prüfung gegen das Core Warehouse hingegen empfiehlt es sich, mit einer View sowohl den entsprechenden Teil des Core Warehouse als auch die Inventurlieferung in die Struktur der entsprechenden Stage-Tabellen zu bringen. Nach dem Vergleich hat man auch hier die Abweichungen gleich in der richtigen Form für die nachfolgende Korrektur.
Dieser Ansatz kann auch sehr gut eingesetzt werden, um die Beladung des Core Warehouse zu prüfen. Der Test gegen die Stage zeigt, ob alle Daten in das Core Warehouse übernommen wurden. Wenn nur einzelne Deltalieferungen auf korrekte Beladung getestet werden, müssen die Tabellen aus dem Warehouse entsprechend gefiltert werden. Es empfiehlt sich, die korrekte Beladung zu testen, um bei einem Vergleich der Inventurlieferung gegen das Core Warehouse auszuschließen, dass der Fehler in den Beladungsroutinen entstanden ist.
Inventurlieferung zur Löschungserkennung nutzen
Manchmal ist es aus verschiedenen Gründen nicht möglich, die gelöschten Sätze zu ermitteln und an die Stage zu liefern. In diesen Fällen macht es Sinn, regelmäßig alle Schlüssel aus dem Quellsystem zu extrahieren. Dies ist nur eine kleine Menge an Daten, die man täglich oder wöchentlich exportieren kann.
Die gelöschten Sätze lassen sich aus dem Vergleich der aktuellen Lieferung mit dem letzten Export ermitteln. So werden gelöschten Schlüssel bzw. deren Sätze ermittelt. Für diese Sätze wird dann das Löschkennzeichen in den Status-Satelliten Satelliten geladen. Eine einfache Lösung für ein ansonsten anstrengendes Problem.
Fehlerhafte Datenstrukturen
Alles verändert sich laufend. Quellsysteme werden gewartet und weiterentwickelt. Damit ändert sich manchmal auch das Datenmodell. Eine gute Kommunikation hilft und sorgt für eine rechtzeitige planvolle Änderung im Data Warehouse.
Funktioniert die Kommunikation mit dem Entwicklungsteam des Quellsystems nicht, kommen auch die Daten nicht in der gewünschten Struktur an. Dieses Problem tritt nicht auf bei einem CDC Tool oder wenn die Daten direkt in der Datenbank kopiert werden. Hier sorgt der Unterschied in den Strukturen meist für einen Abbruch der Routinen während der Datenbereitstellung.
Werden die Daten in Dateien angeliefert, muss zunächst festgestellt werden, ob es sich um einen Übertragungsfehler handelt oder um eine Änderung in den Strukturen. Diese Unterscheidung ist wichtig, um festzulegen, ob die Daten dennoch geladen werden können.
Werden die Daten über einen Dateitransfer geliefert, bei dem die Metadaten nicht automatisch enthalten sind, es also weder JSON noch XML ist, dann kann man keine Unterscheidung treffen. Die gelieferten Daten passen nicht auf die Zielstruktur. Es kann keine Anpassung stattfinden. Die Daten können nicht geladen werden.
Wenn man diesen Fall absichern will, dann empfiehlt es sich die Daten anhand einer mitgelieferten Metadatenstruktur zu laden bzw. zu prüfen.
Fehlerhaft übermittelte Daten
Laden oder nicht laden, das ist die Frage. Wenn die Daten nicht geladen werden können, stoppt die weitere Verarbeitung. Es gibt keine Aktualisierung der Auswertungen. Wenn das Laden der Daten einen Abbruch verursacht, muss jemand diese Daten prüfen und den Fehler korrigieren oder entscheiden, dass 98% der Daten korrekt sind und die weitere Verarbeitung mit einer kleineren Satzanzahl laufen kann.
Das ist die eingangs erwähnte ungeplante Arbeit. Und in diesem Fall kann sie kaum verhindert werden. Korrupte Daten zu laden, macht wenig Sinn. Die Aufräumarbeiten sind zu aufwändig. Was nicht heißt, dass andere Dateien aus dieser Lieferung nicht geladen werden können. Es gibt beim Laden der Daten bis ins Core Warehouse keine Abhängigkeiten, da grundsätzlich die Möglichkeit für late arriving facts eingeräumt werden sollte. Die einzige Ausnahme wären Dateien, bei denen eine Normalisierungsaktion mit der korrupten Datei vorgesehen ist. Die sind natürlich nicht zu laden.
Änderungen in der Datenstruktur
Mit Hilfe der Metadaten lassen sich Änderungen in den Datenstrukturen feststellen. Folgende Änderungen sind in den gelieferten Datenstrukturen möglich:
- Änderung eines Datentyps
- Löschen von einem oder mehreren Attributen
- Löschen von Tabellen
- Hinzufügen von einem oder mehreren Attributen
- Hinzufügen von Tabellen
Die Änderung eines Datentyps kann ignoriert werden, wenn der neue Datentyp automatisch in die bisherigen Strukturen überführbar ist. Ist der Datentyp jedoch nicht konvertierbar, kann das Attribut bei der Überführung in das Core Warehouse nur mit NULL gefüllt werden. In einem nachfolgenden Schritt, ist dann ein neues Attribut mit dem neuen Datentyp anzulegen. Später kann dann entschieden werden, ob die bisherigen Daten in das neue Format übertragen werden und, ob dann das bisherige Attribut aus dem Core Warehouse entfernt wird.
Gelöschte Attribute werden einfach im weiteren Ablauf leer gelassen. Das Laden kann wie gewohnt erfolgen. Handelt es sich um ein notwendiges Attribut, dass für die Erfüllung einer Logik zwingend vorhanden sein muss, dann sollte dieser Fehler an der entsprechenden Stelle behandelt werden. Innerhalb der Ladeschicht steht dieses Wissen nicht zur Verfügung. Davon abgesehen: Was, wenn das Attribut an anderen Stellen verwendet wird und dort nicht diese Relevanz hat? Auch diese Auswertungen wären blockiert. Besser ist es, später differenziert pro Datenprodukt zu entscheiden, ob die Qualität ausreichend für eine Veröffentlichung ist.
Gelöschte Tabellen werden nicht geladen.
Neue Attribute könnte man laden. Analysiert man das Mapping der bisher vorhandenen Attribute, kann daraus geschlossen werden, wo dieses Attribut im Core Warehouse und im Data Mart sinnvoll hinzugefügt werden kann. Für die Umsetzung dieser Funktionalität bedarf es der Fähigkeit die Datenstrukturen im Data Warehouse automatisch anzupassen. Doch Vorsicht: Aus rechtlichen Gründen braucht es die korrekten Data Governance Daten zur Datensicherheitsklasse sowie zur Datenschutzklasse. Ohne den ebenfalls automatischen Zugriff auf die korrekten Schutzklassen darf diese Funktionalität nicht implementiert werden, da sonst u. U. Personendaten frei verfügbar zur Auswertung bereitstehen.
Neue Tabellen werden zunächst nicht geladen. Keine Datenquelle sollte ohne explizite Anforderung bereitgestellt werden.
Systematische Änderung der Inhalte durch eine Nutzungsanpassung
Bis hierhin wurde die Vollständigkeit und die strukturelle Integrität der Daten geprüft. Wie prüft man die Inhalte? Welche inhaltlichen Änderungen sind denn überhaupt problematisch?
Beim Erstellen der Ladeprozeduren für ein Data Warehouse werden die Daten analysiert, um festzustellen, ob aus den Inhalten die gewünschten Resultate generiert werden können. Wenn sich Inhalt und Informationsbedarf nicht decken, erfolgt entweder eine Anpassung der Erfassung in den Quellsystemen oder eine Anpassung der Daten über spezielle Anforderungen – den sogenannten Business Rules.
Was, wenn sich nun die Erfassung in den Quellsystemen ändert und die Daten nicht mehr ausreichend sind? Was, wenn die Datenqualität nicht ausreicht? Was, wenn die Voraussetzungen für eine Business Rule nicht mehr ausreichend sind?
Die Information für eine solche Prüfung stehen in der Ladeschicht nicht zur Verfügung. Die Business Rules laufen in einem späteren Schritt. Dort ist auch zu prüfen, ob die Voraussetzungen alle noch ausreichend sind. Prinzipiell erfolgt die Ladung der Daten unabhängig von den Business Rules. Im Sinne des Single Responsibility Principles sollte das Wissen um die Business Rules nur an einer Stelle vorhanden sein. Dort muss dann auch die Prüfung der Prämissen stattfinden.
Die Datenqualität kann durchaus in der Ladeschicht geprüft werden. Das ist jedoch ein eigener Schritt und ist unabhängig von den Ladeprozessen. Die Prüfung der Datenqualität kann zeitintensiv sein und sollte deshalb unabhängig vom Laden der Daten erfolgen. So sollten Prüfungen zur Datenqualität nur auf Anforderung implementiert oder gezielt in Einzelfällen untersucht werden. Die Beurteilung, ob die Inhalte für eine Berichterstattung ausreichend sind, liegt komplett beim Fachbereich.
Sicherstellen der korrekten Reihenfolge von Lieferungen
In derselben Reihenfolge, wie die Daten exportiert wurden, sollten die Daten auch geladen werden. Gerade wenn nur Änderungen geladen werden, ist die Reihenfolge essenziell. In den meisten Fällen wird eine Reihenfolge nur selten verletzt. Wenn es dann dennoch passiert, kann das Problem durch ein erneutes Laden der Daten korrigiert werden, da der Fehler innerhalb eines kleinen Zeitfensters liegt. Alternativ kann das Problem auch mit einer Inventurlieferung gelöst werden.
Schwieriger ist es, wenn eine Reihenfolge nicht sichergestellt werden kann. Einige Message-Systeme liefern die Daten nicht in Sendefolge. In diesen Fällen braucht es dann das Datum des Exports der Daten an der Quelle. Vor dem Zugriff auf die Daten in der Core Warehouse Schicht muss anhand dieser Zeitangabe die Reihenfolge der Datensätze korrigiert werden.
Das ist nicht zu verwechseln mit einer nachträglichen Änderung bzw. Korrektur der Daten oder mit einer fachlichen Gültigkeit der Daten. Das Exportdatum dient einzig und allein dazu die korrekte Reihenfolge der Änderungen zu rekonstruieren.
Die Korrektur der Reihenfolge beim Zugriff auf die Daten ist eine zusätzliche Aufgabe, die durch eine bessere Schnittstellengestaltung vermieden werden kann. Die Lieferung der Daten in der Reihenfolge ihrer Änderungen ist am besten systematisch zu gewährleisten. Die Schnittstelle wird einfacher, denn so kommt es gar nicht erst zu einer falschen Reihenfolge der Änderungsdaten.
Datenlieferungen sichern
Je weniger Varianten in der Datenlieferung verwendet werden, desto leichter wird die Absicherung der Datenübertragung. Eine systematische Absicherung der Lieferungsreihenfolge sorgt zudem für eine Vereinfachung beim Zugriff auf die Daten.
Ein Abbruch mit Systemstillstand verursacht ungeplante Arbeit, weshalb ein Abbruch des Ladeprozess nur dann erfolgen sollte, wenn die Daten vermutlich korrupt sind. Änderungen an der Datenstruktur sind mit Hilfe von Metadaten abzufangen. Besser ist, wenn Änderungen an den Quellsystemen rechtzeitig mitgeteilt werden und so im Rahmen der normalen Entwicklungsarbeit erledigt werden. Ein regelmäßiger Austausch mit den Quellsystemen zu künftiger Entwicklungsarbeit verhindert Überraschungen und spart viel Ärger.