Auch bei Schnittstellen reduzieren Standards die Komplexität und senken den Aufwand. Je weniger Ausnahmen es gibt, desto leichter sind Wartung und Pflege. Weniger Ausnahmen bedeuten, dass neue Mitarbeiter sich schneller zurechtfinden. Standardisierung ist zudem das Fundament auf dem sich automatisieren lässt.
Im Blogbeitrag ‚Einfache und schnelle Schnittstellen für BI‘ wurde skizziert, wann die einfachste und schnellste Form der Schnittstelle, der Komplettabzug keine Lösung ist. Daraus hat sich folgendes Bild ergeben:
Die hier beschriebenen Schnittstellen haben teilweise Auswirkungen bis hin zum Abgriff der Daten, da entweder das CDC Kennzeichen oder die Lieferhistorie im Tracking Satellite hinterlegt werden. Eine Normalisierung der Daten kann auf dem Weg zur Stage stattfinden oder beim Laden in den Raw Vault. Eine Struktur wie oben beschrieben hat viele Eigenheiten und erinnert verdächtig an gewachsene Strukturen eines langjährig laufenden Data Warehouse. Wenn hier die Komplexität gering bleiben soll, braucht es mehr Einheitlichkeit. Je weniger Ausnahmen ein Mitarbeiter im Kopf haben muss, desto leichter ist die Einarbeitung neuer Mitarbeiter oder die Übernahme von Arbeitspaketen bei Lastspitzen durch andere Team-Mitglieder.
Wie kann die Schnittstelle vereinfacht und die Abläufe standardisiert werden?
(K)eine einfache Lösung: Das Quellsystem stellt die veränderten Daten bereit
Warum das ganze Problem nicht delegieren und an die liefernden Quellsysteme abgeben?
Gerade vor dem Hintergrund von Datenmodelländerungen und daraus folgenden Änderungen an den Lieferungen macht es Sinn, die Verantwortung komplett beim liefernden System zu verankern. Mit jeder Änderung kann so die Auswirkung auf die Schnittstelle geprüft und ggf. eine Änderung umgesetzt werden.
Damit bestimmt das Quellsystem auch, welche Daten an das Data Warehouse weitergegeben werden. Und genau hier liegt ein großer Konflikt. Die Entwicklungsleistung für den Datenexport konkurriert mit der Funktionalität für das Quellsystem. Wenn der Auftraggeber nicht gleichzeitig auch für das Data Warehouse verantwortlich ist, passiert es mitunter, dass der Datenexport herunter priorisiert wird. Damit stehen die Daten nicht rechtzeitig für die Auswertungen zur Verfügung.
Dazu kommt noch, das mit modernen Architekturen die Notwendigkeit zur Batch-Verarbeitung verschwindet. Immer weniger Entwickler haben Erfahrung mit Batch-Verarbeitung oder Schnittstellen. Es gibt kein Werkzeug, dass dem operativen System beim Erstellen dieser Exporte hilft. Wohingegen für die Ermittlung von CDC es sehr wohl Werkzeuge gibt. Diese Werkzeuge sind typischerweise im Bereich der BI angesiedelt, da sie außer der Datenbankstruktur keine weiteren Informationen über das operative System benötigen. So kann sich ein Team mit Tool Know-how um alle Exporte kümmern.
Aus diesen Gründen ist die grundsätzliche Bereitstellung der veränderten Daten durch die Quellsysteme keine empfehlenswerte Lösung.
CDC als Arbeitstier
Das CDC Tool löst etwaige Performanceprobleme für die operative Datenbank, die ein Datenbankabzug verursachen kann. Mit der automatischen Deltabildung werden alle Änderungen übertragen und es gibt ein eindeutiges Kennzeichen, wenn Daten gelöscht wurden.
Wenn ein CDC Tool angeschafft wurde oder günstig zu bekommen ist, dann sollte es für alle Quellen eingesetzt werden, deren Datenbank durch dieses CDC Werkzeug unterstützt wird. Somit bleibt der Datenbankabzug nur für Systeme, bei denen kein CDC Werkzeug zur Verfügung steht.
Die Stage als Abstraktionsebene
Um die Komplexität zu reduzieren, sollten die Anzahl der Schnittstellentypen so gering wie möglich gehalten werden. Die 7 Gruppen lassen sich auf vier verschiedene Schnittstellentypen reduzieren.
Macht man das Delta in der Stage zur Pflicht, sind die Lademuster in den Raw Vault gleich. Der Record Tracking Satellite wird nicht benötigt. Der Entwickler muss nichts über die Schnittstelle wissen, wenn er auf die Satellitendaten zugreift.
Das Eingangsbild vereinfacht sich dadurch. Vor einer Deltabildung müssen die Daten auf den Primärschlüssel normalisiert werden, so dass für jeden Satz ein Kennzeichen ermittelt werden kann. Untergeordnete 1:n Gruppen müssen getrennt werden und erhalten ein eigenes CDC Kennzeichen. Die Normalisierung als optionaler Bereinigungsschritt kommt hinzu.
Das führt zu folgendem Bild von Data Interface und Stage:
Fast alle Daten werden auf die gleiche Art geladen, und die Stage fungiert als Abstraktionsebene. Leider ist dies nicht möglich für Lieferungen über ein Message System. Das Message System muss weiterhin die Möglichkeit haben, Daten direkt in den Raw Vault zu laden. So werden near-realtime Auswertungen am besten unterstützt. Die Speicherung der Messages als Einzelsätze in der Stage kann dazu führen, dass es zu Verzögerungen kommt.
Bei der Verwendung einer PSA (Persistant Staging Area) würden aus diesem Grund die Daten der Message Queue parallel auch in die Stage geladen.
Damit lassen sich die 7 Gruppen und deren Mischformen abbilden. Die Stage wird zu einer Abstraktionsebene, die Daten sind als Insert, Update und Delete in Bezug auf den jeweiligen Primärschlüssel gespeichert. Je nach individueller Anforderung lassen sich diese 4 Gruppen weiter reduzieren und es ist klar, wie neue Anforderungen umzusetzen sind.
Die Abstraktion ist erkauft mit einem weiteren Arbeitsschritt, da der Abgleich der kompletten Daten zweimal passiert. Inwieweit dies die gesamte Verarbeitungskette verlangsamt hängt vom individuellen Fall ab. Wenn eine Tabelle in der Stage 3 Satelliten befüllt und der Delta-Vergleich die Satzanzahl auf 25% der Sätze reduziert, dann sind statt 3*100% der Sätze nun 1*100% und 3*25% der Sätze zu vergleichen. Die Änderungshäufigkeit und die Gesamtzahl der zu ladenden Sätze sind hier die bestimmenden Faktoren. Hubs sind schneller geladen, weil nur hinzugefügte Sätze verglichen werden. Für Links gilt dasselbe wie für Satelliten. Hubs und Links sind jedoch nicht ganz so wichtig, da der komplette Vergleich aller Attribute der größte Aufwand ist.
Persistent Staging Area (PSA)
Speichert man alle gelieferten Daten in der Stage, hat man eine Persistent Staging Area (PSA) umgesetzt. Dank der PSA können alle Daten jederzeit erneut geladen werden. Das Core Warehouse lässt sich so schnell an neue Anforderungen und Erkenntnisse anpassen. Gerade in den ersten Wochen und Monaten der Anbindung einer neuen Datenquelle ist dies hilfreich. Auf der PSA können neue Lösungen schnell ausprobiert werden – virtualisiert oder persistiert. Spätere Anpassungen an der Architektur können durch einen Reload der Daten umgesetzt werden, ohne dass Aufwand für Transformationsskripte entsteht. Mehr zur PSA findet sich hier: http://roelantvos.com/blog/why-you-really-want-a-persistent-staging-area-in-your-data-vault-architecture.
Damit wird aber auch neben dem Core Warehouse ein weiterer Ort geschaffen, an dem alle Daten zur Verfügung stehen. Über die Vor- und Nachteile kann man lange streiten, es ist letztlich eine Frage der Anforderungen und der zur Verfügung stehenden Ressourcen. Doch selbst wenn man die Daten nicht komplett doppelt hält und sie nur für einen bestimmten Zeitraum oder nur für neue Datenquellen vorhält, können bereits viele Vorteile der PSA umgesetzt werden.
Nur die schnelle Verfügbarkeit der Daten zählt
Dennoch zählt in der BI nur die schnelle Verfügbarkeit der Daten. Kostet diese Abstraktionsebene Zeit? Werden hohe Realisierungsaufwände nötig?
Die beschriebene Normalisierung muss auf den Weg in den Raw Vault auf jeden Fall erfolgen. Zusätzlicher Realisierungsaufwand entsteht nur durch die Delta-Bildung. Dies kann als einfache Mengenoperation zwischen aktueller und letzter Lieferung in SQL umgesetzt werden:
- nur in aktueller Lieferung: Insert
- nur in letzter Lieferung: Delete
- in der Schnittmenge und verändert: Update
Mit Hilfe von Metadaten und einem Template kann dieses SQL generiert werden. Der Implementierungsaufwand bleibt gering. Die Verarbeitungszeit ist abhängig von der Anzahl der Satelliten, Links und Hubs und kann je nach Situation die Performance verbessern oder verschlechtern. Die Performance ist nur im Extremfall ein Hinderungsgrund. Wobei im Extremfall auch die Frage nach einem CDC Werkzeug gestellt werden kann.
Die schnelle Verfügbarkeit der Daten ist auch ein Kriterium beim ersten Anbinden einer neuen Datenquelle. In diesen Fällen ist der komplette Datenbankabzug in der Geschwindigkeit unschlagbar. Schnell aufgesetzt und schon sind Daten verfügbar, mit denen sich das Data Warehouse füllen lässt. Genauso schnell sollte ein zweiter Abzug erfolgen, um die Änderungen korrekt in das Data Warehouse zu laden. So wird schnell ein System aufgesetzt, das zuverlässig regelmäßig Daten liefern kann. Die Deltabildung in der Stage ermöglicht frühe Fehler schnell durch ein erneutes Laden der Daten zu beseitigen. Wenn dann später z.B. das CDC Tool bereitsteht, kann die Schnittstelle einfach nur ausgetauscht werden.
Die Abstraktion in der Stage kostet nicht viel, schafft Ordnung und erleichtert das Refactoring. Sie schafft nachhaltig Mehrwert und sollte immer Eingang in die Entwicklungsrichtlinien finden.