Multi-Active Satellites in Data Vault 2.0

In unserem ersten Beitrag über Multi-Active-Satelliten haben wir kurz verschiedene Implementierungen erläutert, die zur Behandlung von Multi-Activity eingesetzt werden können. Nun gehen wir genauer auf die Vor- und Nachteile dieser Ansätze ein – je nachdem, ob Delta-Checks aktiviert oder deaktiviert sind.

Kurze Zusammenfassung zu Multi-Active Satellites

Multi-Active-Satelliten ermöglichen Ihnen die Implementierung multi-aktiver Datensätze pro Business-Key in Data Vault 2.0. Um die Notwendigkeit dieser Lösung zu verdeutlichen, betrachten wir den häufigen Fall eines Quellsystems, das die benötigten Metadaten nicht liefert – wie etwa bei der Arbeit mit XML-Dateien.

Eine Lösung für dieses Problem besteht darin, einen Multi-Active-Satelliten zu erstellen, indem eine Subsequence-Nummer pro Business-Key hinzugefügt wird. Dies deckt jeden Fall ab, in dem die Quelle selbst kein multi-aktives Attribut liefert. Bezogen auf Telefonnummern könnte diese Information ein Tag für eine geschäftliche, private oder mobile Telefonnummer sein. Eine weitere Möglichkeit besteht darin, einen zusätzlichen Hub für das multi-aktive Attribut zu erstellen. Da dieser jedoch kein reales Business-Objekt darstellt, ist die erste Lösung oft effektiver.

Delta-Check AUS

Es gibt zwei Möglichkeiten, neue Datensätze in einen Multi-Active-Satelliten einzufügen: mit aktivierten oder deaktivierten Delta-Checks. Wenn die Delta-Checks ausgeschaltet sind, werden alle Datensätze eines Business-Keys aus Ihrer Quelllieferung in den Satelliten eingefügt.

Der Vorteil dabei ist, dass die Ladevorgänge schneller sind und einen konsistenten Load Date Timestamp (LDTS) zum übergeordneten Hash-Key aufweisen, unabhängig vom multi-aktiven Attribut.

Dies vereinfacht die spätere Abfrage basierend auf den multi-aktiven Daten (siehe Abbildung 1). Ein entscheidender Nachteil ist jedoch, dass die geladene Datenmenge stark ansteigen kann, wenn vollständige Datenladungen (Full Data Loads) verarbeitet werden.

In diesem Fall sollten Sie Ihre Daten nach dem Load Date Timestamp partitionieren.

Abbildung 1: Verknüpfen von Datensätzen über eine PIT-Tabelle bei einem einheitlichen LDTS für alle aktiven Datensätze pro Key.

Delta-Check EIN

Um die Datenmenge zu reduzieren, nutzen Sie Delta-Checks. Dabei vergleichen Sie die eingehenden Daten mit dem neuesten LDTS pro Hash-K
Die Funktion LISTAGG() ist hierbei sehr nützlich, um den Delta-Check zu unterstützen. Sie wandelt Werte aus einer Gruppe von Zeilen in eine geordnete Liste um. Dadurch sind Sie in der Lage, eine zeilenübergreifende Hash-Differenz der multi-aktiven Attribute pro Business-Key zu erstellen (siehe Abbildung 2).

Abbildung 2: Zeilenübergreifende Hash-Differenz unter Verwendung der LISTAGG()-Funktion.

Wenn neue Daten eintreffen, können diese mithilfe der zeilenübergreifenden Hash-Differenz verglichen werden. Dadurch lässt sich ein großer Teil unveränderter Daten ignorieren. Wird ein Delta erkannt, werden alle Datensätze pro Hash-Key eingefügt – selbst wenn sich der Inhalt nur für eine einzelne Subsequence geändert hat. Das Ergebnis ist ein konsistenter Load Date Timestamp pro Hash-Key. Zudem wird ein Delta auch dann erkannt, wenn sich lediglich die Reihenfolge der Datensätze ändert. Dieser Ansatz bildet einen Kompromiss, um die Anzahl der Datensätze zu reduzieren und gleichzeitig einen konsistenten LDTS pro Hash-Key beizubehalten, sodass nur eine einzige PIT-Tabelle erforderlich ist.

Verwendung von Type-Codes

Eine weitere Möglichkeit, Multi-Activity zu handhaben, besteht darin, die Typen der Attribute zu verwenden, sofern diese vorhanden sind , wie im vorherigen Beitrag erläutert.
Wenn Sie Type-Codes im Einsatz haben, können Sie Zeile für Zeile vergleichen und nur die spezifischen geänderten Daten laden. Die Konsequenz daraus ist jedoch, dass Sie unterschiedliche LDTS-Werte pro multi-aktivem Attribut erhalten. Wenn Sie PIT-Tabellen im Business Vault verwenden, benötigen Sie daher eine zusätzliche Multi-Active-PIT-Tabelle. Dieses Szenario ist in Abbildung 3 dargestellt.

Abbildung 3: Die Notwendigkeit einer MA-PIT-Tabelle bei unterschiedlichen LDTS-Werten aktiver Datensätze pro Key.

Wenn Sie die multi-aktive Spalte in mehrere Spalten pivotieren können (eine Spalte pro Ausprägung), müssen Sie die oben genannten Vor- und Nachteile nicht berücksichtigen. In diesem Fall wandeln Sie den Multi-Active-Satelliten in einen Standard-Satelliten um. Bezogen auf unser Beispiel mit den Telefonnummern würden Sie einige neue Spalten pro Telefontyp erstellen.
Diese Lösung ist gut anwendbar, wenn Sie sicher sein können, dass sich die Ausprägungen der Telefontypen in Zukunft nicht ändern. Andernfalls müssen Sie Ihren Ladeprozess bei neuen Typen anpassen, um weiterhin alle gelieferten Daten zu erfassen.

Fazit

In diesem zweiten Beitrag zu Multi-Active-Satelliten haben wir die Hintergründe der verschiedenen Modellierungsansätze untersucht. Sie können diese Informationen nutzen, um abhängig von Ihren Datenstrukturen die optimale Multi-Active-Lösung zu wählen.
Beachten Sie dabei, dass es meist ratsam ist, die zu ladende Datenmenge frühzeitig zu begrenzen – wozu sich die LISTAGG()-Funktion hervorragend eignet. Wenn Sie eine Lösung mit potenziell unterschiedlichen LDTS-Werten nutzen, denken Sie daran, diese bei der Abfrage über entsprechende PIT-Tabellen zu berücksichtigen.

Aufwandsschätzung in Data-Vault-2.0-Projekten

In Data-Vault-2.0-Projekten empfehlen wir, den Aufwand mithilfe einer Function-Point-Analyse (FPA) zu schätzen. Bei der Auswahl einer Methode zur Aufwandsschätzung in agilen IT-Projekten stehen zahlreiche Optionen zur Verfügung. In diesem Artikel erfahren Sie, warum die FPA eine gute Wahl ist und warum Sie die Nutzung dieser Methode für Ihre eigenen Data-Vault-2.0-Projekte in Betracht ziehen sollten.

Das gute alte Planning Poker zur Aufwandsschätzung

Die wahrscheinlich bekannteste Methode zur Aufwandsschätzung in agilen Projekten ist Planning Poker. Im Verlauf des Prozesses werden sogenannte Story Points verwendet, die auf der Fibonacci-Folge (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 und 100) basieren, um den Aufwand einer bestimmten Aufgabe zu schätzen. Zu Beginn des Prozesses kommt das gesamte Entwicklungsteam zusammen und jedes Mitglied weist jeder User Story gleichzeitig die aus seiner Sicht angemessenen Story Points zu. Stimmen die Story Points überein, steht die finale Schätzung fest. Kann kein Konsens erzielt werden, wird der Aufwand so lange diskutiert, bis eine Entscheidung getroffen ist.

Es ist jedoch wichtig zu beachten, dass diese Technik einen hohen Aufwand verursacht, wenn entweder zu viele Aufgaben vorliegen oder das Team zu groß ist. Es stellt sich also die Frage: Funktioniert Planning Poker für Data-Vault-Projekte? Die kurze Antwort lautet: „Es ergibt wenig Sinn“. Da in Data Vault 2.0 die fachlichen Anforderungen in kleine Einheiten zerlegt werden, gibt es zahlreiche Aufgaben, die alle diskutiert und bewertet werden müssen. Zudem handelt es sich bei den Teilaufgaben in Data Vault 2.0 um standardisierte Artefakte wie Hubs, Links und Satellites. Im Prinzip stellen diese Artefakte stets denselben Aufwand dar.

Warum eignet sich die Function-Point-Analyse so gut?

Hier kommt die FPA ins Spiel und das ist auch der Grund, warum sie in agilen Softwareprojekten weit verbreitet ist. Die Idee besteht darin, dass Software aus den folgenden Charakteristika besteht, welche die Function Point Types darstellen:

• External Inputs (EI) → Daten, die in das System gelangen
• External Outputs (EO), External Inquiries (EQ) → Daten, die das System auf die eine oder andere Weise verlassen
• Internal Logical Files (ILF) → Daten, die innerhalb des Systems erzeugt und gespeichert werden
• External Interface Files (EIF) → Daten, die außerhalb des Systems verwaltet werden, aber zur Ausführung der Aufgabe erforderlich sind

Bei der FPA zerlegen Sie die Funktionalität für eine bessere Analyse in kleinere Einheiten. Wie bereits erwähnt, geschieht dies in Data-Vault-2.0-Projekten aufgrund der standardisierten Artefakte ohnehin schon. Aus diesem Grund eignet sich die FPA hervorragend für Data-Vault-Projekte.

Wie Sie die FPA in Data Vault 2.0 anwenden

Um die FPA in der Data-Vault-2.0-Methodik gewinnbringend einzusetzen, müssen die funktionalen Merkmale von Software – External Inputs, External Outputs, External Inquiries, Internal Logical Files und External Interface Files – an Data-Vault-Projekte angepasst werden. Die funktionalen Merkmale von Data Warehouses, die mit Data Vault aufgebaut sind, werden wie folgt definiert:

• Stage load (EI)
• Hub load (ILF)
• Link load (ILF)
• Satellite load (ILF)
• Dimension load (ILF)
• Fact load (ILF)
• Report build (EO)

Bitte beachten Sie, dass auch weitere funktionale Komponenten definiert werden können, wie beispielsweise Business-Vault-Entitäten, Point-in-Time-Tabellen usw. Sobald Sie diese Komponenten definiert haben, sollten Sie eine Tabelle erstellen, die diese den Function Points zuordnet. Function Points dienen dazu, den Umfang der fachlichen Funktionalität zu quantifizieren, die ein Element einem Anwender bietet. Im Allgemeinen wird empfohlen, zunächst einen Komplexitätsfaktor hinzuzufügen.

Verwenden Sie anschließend die Komplexitätsfaktoren und die zugewiesenen Function Points pro Komponente, um die geschätzte Stundenzahl zu berechnen, die für das Hinzufügen der jeweiligen Funktionalität erforderlich ist. Hier ist ein kurzes Beispiel dafür, wie eine solche Zuordnungstabelle für Sie aussehen könnte:

Das Ziel der Schätzung besteht darin, die Entwicklung operationaler Informationssysteme zu standardisieren, indem der Aufwand berechenbarer gemacht wird. Wenn Sie einen systematischen Ansatz verwenden, um den erforderlichen Aufwand für das Hinzufügen von Komponenten zu schätzen, können Sie die geschätzten Werte nach Bereitstellung der Funktionalität mit den tatsächlichen Werten vergleichen. Durch den Vergleich beider Werte kann Ihr Team aus vergangenen Schätzungen lernen und künftige Schätzungen verbessern, indem die Function Points pro Komponente angepasst werden. Denken Sie auch daran, dass Ihre Entwickler im Laufe der Zeit an Erfahrung gewinnen oder durch Personalwechsel Erfahrung verloren gehen kann.

Fazit

Ich hoffe, dieser erste Einblick in die FPA hilft Ihnen zu verstehen, welchen grundlegenden Mehrwert sie Ihrem Team in Data-Vault-2.0-Projekten bieten kann. Einen tieferen Einblick in die Anwendung der FPA in Data-Vault-2.0-Projekten erhalten Sie im Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ von Michael Olschimke und Dan Lindstedt.

Information Marts in Data Vault 2.0

In der Data-Vault-2.0-Architektur werden Information Marts genutzt, um Endanwendern Informationen bereitzustellen. Konzeptionell entspricht ein Information Mart der Definition eines Data Marts im klassischen Data Warehousing. Dort dient ein Data Mart jedoch dazu, nutzbare Informationen statt Rohdaten bereitzustellen. Aus diesem Grund wurde die Komponente in Data Vault 2.0 in Information Mart umbenannt, um diesen Anwendungsfall präziser abzubilden.

Einführung in Information Marts

Die Definition von Information Marts umfasst jedoch noch weitere Facetten. Im Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ stellen wir drei Arten von Marts vor:

• Information Marts: Dienen der Bereitstellung von Informationen für Fachanwender, typischerweise über Dashboards und Berichte.
• Metrics Mart: Wird in Kombination mit einem Metrics Vault genutzt, der EDW-Logdaten in einem Data-Vault-Modell erfasst. Der Metrics Mart wird aus dem Metrics Vault abgeleitet. Er stellt Metriken bereit, mit denen sich Performance-Engpässe sowie der Ressourcenverbrauch von Power Usern und Data Scientists in verwalteten Self-Service-BI-Lösungen analysieren lassen.
• Error Mart: Speichert diejenigen Datensätze, die beim Laden der Daten in das Enterprise Data Warehouse typischerweise eine Hard Rule verletzen.

Information Marts im Consulting

Zusätzlich zu diesen klassischen Information Marts setzen wir in unserer Beratungspraxis weitere Typen ein:

• Interface Mart: Hierbei handelt es sich im Prinzip um einen Information Mart. Die Informationen werden jedoch nicht an Menschen (etwa über ein Dashboard oder einen Bericht) übermittelt, sondern an eine nachgelagerte Anwendung oder als Write-Back an das Quellsystem geliefert – beispielsweise wenn das Enterprise Data Warehouse zur Datenbereinigung genutzt wird.
• Quality Mart: Ein Information Mart, der nicht der Bereinigung fehlerhafter Daten dient, sondern der Berichterstattung darüber. Im Wesentlichen stellt er die Logik zur Datenbereinigung auf den Kopf: Nur fehlerhafte Daten (manchmal auch als „bad and ugly data“ bezeichnet) werden an den Endanwender, beispielsweise den Data Steward, geliefert. Dies geschieht häufig in Kombination mit Data-Cleansing-Frontends, in denen Data Stewards Quelldaten korrigieren oder Ausnahmen kommentieren und verschlagworten können.
• Source Mart: Ebenfalls ein Information Mart, der jedoch auf gängige Strukturen wie Star-Schemata, Snowflake-Schemata oder vollständig denormalisierte Schemata verzichtet. Stattdessen nutzt er das Datenmodell der Quellanwendung, ähnlich dem Schema eines Operational Data Store (ODS). Der Source Mart ist keine physische Kopie der Daten, sondern ein virtualisiertes Modell auf Ebene des Data-Vault-Modells, das die ursprünglichen Strukturen widerspiegelt. Er eignet sich hervorragend für Ad-hoc-Berichte und bietet Data Scientists sowie Power Usern einen hohen Mehrwert.

Damit ist unsere Übersicht der Information Marts komplett. Wir haben diese Varianten in zahlreichen Kundenprojekten erfolgreich eingesetzt, um den konkreten Nutzen und den Einsatz von Information Marts in Organisationen verständlich zu vermitteln.

Fazit

Information Marts sind in Data Vault 2.0 essenziell, um aufbereitete Daten über Berichte und Dashboards für Endanwender bereitzustellen. Varianten wie Metrics Marts und Error Marts optimieren die Performance-Analyse sowie das Datenqualitätsmanagement. Darüber hinaus decken spezialisierte Typen wie Interface, Quality und Source Marts spezifische Fachanforderungen ab und gewährleisten eine flexible sowie effiziente Datenbereitstellung.

Validierung von Beziehungen in Data Vault 2.0

Es gibt verschiedene Möglichkeiten, die Validierung von Beziehungen aus Quellsystemen zu handhaben. Dies hängt davon ab, wie die Daten geliefert werden (Full-Extract oder CDC) und wie ein Löschvorgang vom Quellsystem übermittelt wird – beispielsweise als Soft Delete oder Hard Delete. In Data Vault 2.0 unterscheiden wir Daten nach Schlüsseln (Keys), Beziehungen und Beschreibungen.

Dennoch ist die Handhabung und Validierung von Beziehungen in Data Vault 2.0 ein oft unterschätzter Aspekt.
Im folgenden Blogartikel erklären wir, was Sie beachten müssen und wie Sie am besten damit umgehen.

Löschungen in Data Vault 2.0

Zuerst betrachten wir die verschiedenen Arten von Löschungen (Deletes) in Quellsystemen:

1. Hard Delete – Ein Datensatz wird im Quellsystem physisch gelöscht und existiert dort nicht mehr.
2. Soft Delete – Der gelöschte Datensatz bleibt in der Datenbank des Quellsystems bestehen, wird jedoch als gelöscht gekennzeichnet.

Als Nächstes untersuchen wir, wie wir diese Daten in der Staging Area identifizieren:

1. Full-Extract – Dies kann der aktuelle Zustand des Quellsystems oder ein Delta- bzw. inkrementeller Extrakt sein.
2. CDC (Change Data Capture) – Es werden nur neue, aktualisierte oder gelöschte Datensätze geliefert, um Daten inkrementell oder als Delta zu laden.

Um die folgende Erklärung so einfach wie möglich zu halten, gehen wir davon aus, dass wir Beziehungen als gelöscht markieren wollen, sobald wir die Löschinformationen erhalten – selbst wenn kein Audit-Trail aus dem Quellsystem vorliegt (Data Aging ist hierbei ein anderes Thema).

Erkennung von Löschungen und Validierung von Beziehungen in Data Vault 2.0

Die Erkennung von Löschungen für Business Keys oder Hubs ist unkompliziert. Soft Deletes werden direkt als beschreibende Attribute im Satelliten behandelt – unabhängig davon, ob die Daten aus einem Full-Extract oder über CDC eingehen. Bei Hard Deletes im Quellsystem müssen wir hingegen zwischen Full-Extract und CDC unterscheiden.
Hier führen wir den Effectivity-Satelliten ein. Dabei gilt:

1. Full-Extract – Führen Sie einen Abgleich (Lookup) mit der Staging Area durch, um zu prüfen, ob der Business Key noch existiert. Wenn nicht, fügen Sie einen Datensatz mit den Löschinformationen (d. h. ein Flag und ein Datum) in den Effectivity-Satelliten ein.
2. CDC – Sie erhalten eine „Delete“-Information, was direkt zu einem neuen Eintrag im Effectivity-Satelliten führt.

Die Erkennung gelöschter Beziehungen erfordert etwas mehr Aufmerksamkeit und wird oft übersehen. Bei einem Full-Extract können Sie denselben Ansatz wie bei Business Keys verfolgen: Prüfen Sie einfach, ob der Link-Hash-Key im aktuellen Staging-Ladevorgang vorhanden ist, und fügen Sie bei Bedarf einen neuen Eintrag in den Effectivity-Satelliten ein.

Heutzutage setzt sich CDC immer mehr durch. Da diese Methode jedoch nur Deltas liefert, besteht die Herausforderung darin, nicht mehr existierende Beziehungen zu identifizieren. Das folgende Beispiel zeigt eine Beziehung zwischen den Business-Objekten Customer und Company. Dies ist eine 1:n-Beziehung:

Abbildung 1: Tabellen Customer und Company

Die Link-Tabelle in Data Vault sieht wie folgt aus:

Tabelle 1: Customer-Link

Zur besseren Lesbarkeit und Vereinfachung stellen wir die Business Keys anstelle von Hash-Keys dar und verzichten auf die Darstellung von Systemfeldern wie dem Load-Date-Timestamp und der Record-Source.

So weit, so gut. Was passiert jedoch, wenn ein Kunde für ein anderes Unternehmen tätig wird? Dies führt zu einem neuen Datensatz in der Link-Tabelle. Der CDC-Mechanismus liefert die Daten als Update der Customer-Tabelle.

Abbildung 2: Quelltabellen und Link nach Unternehmenswechsel

Woher stammt die Information, dass Customer 4711 nicht mehr für Company 1234 arbeitet, und wo wird diese gespeichert? Es muss ein Soft Delete für den alten Link-Eintrag im Data Warehouse durchgeführt werden, um die Datenkonsistenz zu wahren. Aktuell sieht es so aus, als ob der Kunde für beide Unternehmen tätig wäre, da beide Links aktiv sind.

Hierfür gibt es zwei mögliche Lösungswege:

1. Sie erhalten die „Gültig von“- und „Gültig bis“-Angaben in Ihrem Audit-Trail und identifizieren eine Differenz bei der company_id. In diesem Fall erstellen Sie zwei neue Einträge im Effectivity-Satelliten: Der erste markiert die alte Beziehung (von) als gelöscht, der zweite die neue Beziehung (bis) als aktiv (nicht gelöscht). Es ist notwendig, neue Beziehungen als „nicht gelöscht“ einzufügen, damit Sie Hash-Keys flexibel aktivieren und deaktivieren können.
   Bedenken Sie dabei auch das Szenario, dass Customer 4711 später wieder für Company 1234 tätig wird.
2. Falls diese Angaben fehlen, müssen Sie die CDC-Daten entweder in eine Persistent Staging Area (PSA) laden, um die gesamte Historie der gelieferten Daten aufzubewahren, oder in ein Source Replica überführen. Im Source Replica erstellen Sie ein Spiegelbild des Quellsystems, indem Sie es mit den CDC-Daten speisen. Dabei führen Sie bei einem „Update“-Signal ein Hard Update und bei einem „Delete“-Signal ein Hard Delete durch. Bei der Verwendung eines Source Replica können Sie denselben Ansatz wie bei Vollabzügen (Full-Loads) verfolgen: Sie führen einen Join auf das Replica aus, um zu prüfen, ob der Hash-Key noch existiert.
   Der größte Nachteil dieser Methode ist der höhere Scan-Aufwand, was zu einer höheren I/O-Last führt. Bei der Verwendung einer Persistent Staging Area können Sie Änderungen in einer Beziehung mithilfe der Window-Funktion lead() ermitteln. Dabei partitionieren Sie nach der technischen ID (in diesem Fall Customer_ID) und sortieren nach dem Load Date Timestamp.
   Sobald sich der Link-Hash-Key unterscheidet, hat sich die Beziehung geändert und die vorherige existiert nicht mehr..

Das Ergebnis ist der folgende (logische) Effectivity-Satellit:

Tabelle 2: Effectivity-Satellit auf dem Link

Fazit

In diesem Artikel haben wir zwei wesentliche Aspekte behandelt. Erstens extrahieren wir in Data Vault 2.0 Beziehungsinformationen direkt aus den Quelltabellen, weshalb die Validierung dieser Informationen besondere Aufmerksamkeit erfordert.
Zweitens bietet Ihnen die Art der Datenbereitstellung (Delta via CDC oder Full-Extract) unterschiedliche Optionen für den Ladevorgang. Bei großen Datenmengen ist CDC definitiv die bevorzugte Methode. Zudem erfasst der CDC-Mechanismus alle Änderungen direkt aus der Quelle, was das Laden von Daten in (nahezu) Echtzeit erheblich erleichtert.