Die Anbindung einer neuen Datenquelle an ein Data Warehouse sollte ein einfacher Prozess sein. Jedes Quellsystem hat jedoch eigene Anforderungen an Export und Transport der Daten. Zudem gibt es auf Seiten der BI nicht den einen Standard für die Gestaltung einer Schnittstelle. Im Artikel ‚Datenlieferungen an BI‘ in BI-Spektrum vom 5/2019 (Link auf PDF von TDWI) wurde beschrieben, was zu beachten ist, wenn man eine neue Schnittstelle zu einem liefernden System aufsetzt.
Wie hält man also eine Schnittstelle einfach? Oder braucht es grundsätzlich eine komplexe Lösung, die allen Ansprüchen genügt? Beginnend mit einer einfachen Schnittstelle, werden nach und nach typische Probleme einer Datenschnittstelle betrachtet und Änderungen an der Lösung vorgenommen. So entsteht ein Entscheidungspfad für die Anbindung einer neuen Datenquelle oder besser für die Implementierung einer neuen Schnittstelle.
Begrifflichkeiten
Eine Schnittstelle zu einer Datenquelle lässt sich über Typ und Umfang der Lieferung bestimmen.
Typ
|
Lieferumfang
|
In der Kombination gibt es folgende Möglichkeiten:
Die einfache Schnittstelle
Eine einfache Schnittstelle exportiert Daten an der Quelle und importiert diese in die eigene Datenbank. Keinerlei Delta Bildung, die Daten werden zu jeweils einem Zeitpunkt (Snapshot) abgezogen.
Diese Schnittstelle wird noch einfacher, wenn die Kopie direkt in der Datenbank vorgenommen werden kann, d.h. von einer Instanz der DB in die andere. Ist dies nicht möglich, muss eine Routine für den Import gefunden werden. Nicht alle Datenbanken haben hier eigene Mittel bzw. ausreichende eigene Mittel.
Beim Laden werden alle Daten übernommen. Die Lademuster für Data Vault sorgen dafür, dass nur neue oder geänderte Daten übernommen werden. Somit gibt es bei dieser Form keine Löschungen im Core Warehouse. Wenn zu einem Lieferdatum (load date timestamp) keine Werte im Core Warehouse hinterlegt sind, kann die Ursache sowohl keine Änderung der Daten als auch eine Löschung der Daten im Quellsystem sein. Will man hier die Löschungen während der Auswertung ableiten, muss die Lieferung jedes Datensatzes gekennzeichnet werden. In Data Vault übernimmt das der ‚record tracking satellite‘. Hier wird an einem Hub bzw. Link hinterlegt, ob der Satz im aktuellen Ladeprozess enthalten war. Aus diesem Satelliten kann man ableiten, in welchem Zeitraum bzw. Zeiträumen der Satz gültig ist.
Hinderungsgründe für eine einfache Schnittstelle
Die erste Lösung ist – wie versprochen – sehr einfach. Die häufigsten Probleme, die einem solchen einfachen Ansatz entgegenstehen sind:
- Daten sollen in der Stage für n Monate vorgehalten werden
- Performanceprobleme beim Abzug der Daten
- Jede Änderung wird gebraucht
- Direkte Integration in die Architektur der Quellsysteme: Messaging und Events
- Export durch die Quelle notwendig
- Nicht normalisierte Daten
- Nicht persistierte Daten im Quellsystem
Daten in der Stage für n Monate
Falls die Daten für mehrere Monate vorgehalten werden, z.B. um Probleme beim Laden der Daten nachvollziehbar zu machen, dann ist es sinnvoll Platz zu sparen und nur die Veränderungen, also das Delta zu speichern. Speicherplatz wird immer billiger und kostet doch immer noch viel Geld. Ändern sich nur etwa 30% der Daten, dann kann bei jedem Abzug 70% des Platzes eingespart werden. Die Lademuster von Data Vault haben im Input nur etwa 30% der Sätze und sind dadurch schneller beim Laden. Die Gesamtladezeit reduziert hierdurch jedoch nicht. Für die Ermittlung des Deltas wird weiterhin ein kompletter Abgleich aller Daten benötigt.
Die Bildung des Deltas kann mit einem einfachen SQL-Muster ermittelt werden. Der Code hierfür kann mit Hilfe von Metadaten generiert werden (Templating). Diese Form des Deltas der Stage wird auch von der sogenannten Persistent Staging Area (PSA) verwendet. Die PSA hat weitere Vorteile, beispielsweise bei der Virtualisierung oder bei einer prototypischen Entwicklung. Eine sehr gute Zusammenfassung über die Vorteile der PSA findet sich in folgendem Artikel: http://roelantvos.com/blog/why-you-really-want-a-persistent-staging-area-in-your-data-vault-architecture.
Performanceprobleme beim Abzug der Daten
Der direkte Export der Daten kann die Performance eines operativen Systems massiv beeinflussen. Wenn nun innerhalb der nächtlichen Batchverarbeitung keine Zeit ist, der Abzug mehrfach am Tag passieren soll oder das System global genutzt wird und ein einfacher Export deshalb ohne Performanceverluste nicht möglich ist, dann braucht es ein Werkzeug für CDC oder für die Spiegelung der Daten.
Systeme für CDC oder zur Spiegelung der Daten werten die Logs der Datenbank aus und können die Daten so ohne Performanceverlust kopieren. In diesem Fall macht es Sinn, sich nur das Delta, die Änderungen liefern zu lassen. Denn diese Werkzeuge nutzen ja das Log, also die Veränderungen in der Datenbank und besitzen so schon die Information über die Änderungen. Das spart Performance beim Laden des Core Warehouse, da die Tabelle in der Ladeschicht weniger Sätze hat.
Weitere Details zu CDC und eine kleine Übersicht zu verfügbaren Systemen findet sich in https://medium.com/daimler-tss-tech/change-data-capture-lessons-learnt-7976391cf78d.
Jede Änderung wird gebraucht
Wenn die Daten immer als Komplettladung übernommen werden, stehen nur Momentaufnahmen zur Verfügung. Wurde ein Datensatz zwischen den Momentaufnahmen zwei- oder mehrmals geändert, sind einzelne Änderungen bereits überschrieben. Die zwischenzeitlichen Änderungen stehen also nicht zur Verfügung.
Ob dieser Verlust hingenommen werden kann, hängt von den fachlichen Anforderungen ab. Häufig ist der Datenverlust irrelevant, die Daten waren nur kurz zwischen zwei Ladezyklen gültig. Manchmal ist es aber wichtig, alle Zustandsänderungen zu dokumentieren. In diesem Fall braucht es eine komplette Änderungshistorie. Hier braucht es einen Mechanismus, der zuverlässig alle Änderungen liefert, wie beispielsweise ein CDC Werkzeug, eine event-getriebene Schnittstelle oder ein Programm zum Export der Daten.
Direkte Integration in die Architektur der Quellsysteme:
Messaging und Events
Moderne Architekturen verwenden Messagesysteme mit denen Verarbeitungsanfragen eines Subsystems an andere Subsysteme gesendet werden. Es macht Sinn, das Data Warehouse genauso über bestimmte Events anzubinden. Beim Einsatz einer Messagequeue für die Lieferung von Daten an die BI können die Daten direkt mit der Nachricht in das Core Warehouse geladen werden. In Data Vault ist der Raw Vault die komplette Kopie aller Daten. Es gibt somit keinen Grund, die Daten in einer Stage vorzuhalten. Auch eine Sammlung der Events, um diese dann zu einem Zeitpunkt gesammelt zu laden, macht wenig Sinn: Wenn man die Daten in Echtzeit erhält, sollte man diese auch genauso zeitnah auswerten können.
Eine Parallelhaltung der Daten in der Stage kann bei Einsatz einer PSA sinnvoll sein. Hierzu werden die Daten zusätzlich in die Stage geladen.
Export durch die Quelle notwendig
Mitunter gibt es keinen direkten Zugriff auf die Daten des Quellsystems. Neben rechtlichen Gründen oder den bereits angesprochenen nicht persistierten Daten kann dies vor allem bei SaaS Lösungen vorkommen. Für manche Systeme gibt es Werkzeuge zur Extraktion von Daten oder es gibt Schnittstellen, über die man auf die Daten zugreifen kann.
Hier braucht es eine klare Schnittstellenvereinbarung und ein Service Level Agreement. Es gilt eine langfristige tragbare Lösung zu finden, die auch für künftige Entwicklungen trägt. Leider ist dies oft eine individuelle Lösung des jeweiligen Anbieters der SaaS Lösung. Ein Standard würde Wartung und Pflege erleichtern.
Nicht normalisierte Daten
Nicht alle Quellsysteme speichern normalisierte Daten. Standardisierte Schnittstellen sind oft nicht relational. Datenformate wie XML oder JSON machen denormalisierte Daten möglich. Während in einem Dokument die Daten eines mehrfach vorkommenden Elements (oder in JSON: Array, Objekt) immer in einer 1:n Beziehung zum Schlüssel des Dokuments stehen, kann es durchaus ein zweites Dokument geben, in dem die Unterordnung umgekehrt ist. Beispielsweise kann ein Kunde mehrere Verträge haben und es gibt ein anderes, zweites Dokument, in dem der Vertrag mehrere Kunden haben kann.
Aus diesem Grund sollte bei diesen Formaten das logische Datenmodell angeschaut werden. Anhand des logischen Datenmodells können dann Entscheidungen getroffen werden, wie die Daten in der Stage zu speichern sind, um eine einfache und idealerweise automatisierte Übernahme der Daten zu gewährleisten.
Moderne relationale Datenbanken können JSON und XML speichern. Nutzt man diese Elemente, um Daten in den Raw Vault zu laden, müssen die Lademuster einen Filter enthalten, um die jeweils richtigen Teile zu laden. Einfacher ist es, die Daten in der Stage zu normalisieren. Die Normalisierung kann virtuell über Views auf die in der Datenbank hinterlegten JSON bzw. XML Objekte erfolgen.
Eine Abweichung von dieser Regel ist sinnvoll, wenn es sich um hochvolatile Datenstrukturen handelt, die zu einem Event oder Geschäftsobjekt geliefert werden. Diese Daten können als JSON Struktur in einem Satelliten gespeichert werden. Die Entscheidung über die tatsächliche Auswertestruktur erfolgt dann zum Zeitpunkt der Auswertung, wenn klar ist, welche Datensätze ausgewählt werden und welche Informationen verfügbar bzw. gewünscht sind.
Nicht persistierte Daten im Quellsystem
Es kommt vor, dass ein System relevante Daten nicht speichert, sondern nur auf Anfrage auf dem jeweilig aktuellen Stand berechnet. Die Ergebnisse der Berechnung stehen nicht in der Datenbank. Die Daten stehen nicht zur Verfügung.
In diesem Fall muss das Quellsystem unter der Verwendung ihrer Algorithmen einen Datenexport implementieren. Werden diese Daten vom Data Warehouse selbst berechnet, bedeutet das eine Doppelentwicklung und damit bei Änderungen vor allem eine Doppelwartung – Inklusive der höheren Fehleranfälligkeit durch Abweichungen zwischen den beiden Implementierungen. In diesem Fall muss das operative System in jedem Fall einen Datenexport programmieren oder die Daten persistieren. Alles andere ist zu teuer.
Der Komplettabzug ist nicht immer die Lösung
Aus den verschiedenen Anforderungen haben sich nun mehrere unterschiedliche Lösungen ergeben. In der konkreten Anwendung treten typischerweise Mischformen auf, die in noch mehr Lösungsvarianten resultieren. So kann es beim Export durch die Quelle nötig sein, die Daten zu normalisieren oder nur das Delta zu speichern. In den Daten aus dem CDC Tool sind supertypisierte Tabellen wie Partner enthalten, die u.U. auch durch Normalisierung getrennt werden sollen. Hier sind nur einige gängige Anforderungen und Lösungen geschildert. Allein diese Lösungen bilden bereits 7 Gruppen:
Für eine einfache Schnittstelle sollte die Behandlung der Daten möglichst gleichförmig sein. Wenn Abweichungen nötig sind, sollte diese lokal begrenzt sein. So bleiben spätere Bearbeitungsschritte unabhängig von der Lösung in der Schnittstelle. Wechselt ein Mitarbeiter von einer Datenquelle zu einer anderen, sollte sich der Mitarbeiter nur mit den inhaltlichen Unterschieden beschäftigen müssen. Das Handling der Daten sollte gleichlaufen. Diese Maßnahmen reduzieren nachhaltig die Komplexität im Data Warehouse.
Wo sind also Unterschiede im Ablauf zwischen diesen 7 Gruppen?
Ein deutlicher, offensichtlicher Unterschied ist das direkte Laden aus der Message Queue in den Raw Vault. An diesem Unterschied führt kein Weg vorbei. Der Vorteil in der Geschwindigkeit des Ladens muss realisiert werden, um near-realtime Auswertungen möglich zu machen.
Die zentralen Lademuster für Hub, Link und Satellit sind für alle 7 Gruppen gleich. Doch es gibt Unterschiede bei den Status-Satelliten. Für die Snapshot Daten wird im Record Tracking Satellite die Lieferhistorie vorgehalten. Bei einer CDC Verarbeitung hingegen wird das CDC Kennzeichen mit Insert, Update oder Delete in einem Status Tracking Satellite gespeichert.
Das macht beim Auslesen der Satelliten einen großen Unterschied. Abhängig vom Lieferumfang, wird jeweils anders auf die Daten im Satelliten zugegriffen. Die Frage, wie beim Zugriff auf einen Satelliten vorzugehen ist, wird hier zum Glück selbsterklärend beantwortet: Ob CDC oder snapshot ist am Typ des Tracking Satelliten abzulesen.
Dennoch bleibt die Frage, wie divers die Schnittstellen und die Stage sein können, bis es als zu komplex empfunden wird. Gleichzeitig sollen die Daten schnell und einfach geladen werden, ohne für die operativen System Mehraufwand zu erzeugen.
Für Lösungen braucht es eine aktive Gestaltung von Datenschnittstellen. Mehr hierzu können Sie demnächst hier in einem weiteren Blog-Artikel lesen.