Marc Winkelmann

Warum Data Vault 2.0?

Dieser Blogartikel befasst sich mit den Stärken von Data Vault 2.0 und zeigt auf, warum Sie diese Methode für Ihr Data Warehouse nutzen sollten. Als Datenbankentwickler, -administrator oder -anwender haben Sie wahrscheinlich schon von Data Vault gehört. Wenn Sie bereits eine Datenbanklösung im Einsatz haben, stellen Sie sich jedoch vielleicht die Frage, warum Sie Data Vault in Ihrem Enterprise Data Warehouse implementieren sollten.

Grund 1: Unterstützung mehrerer Quellsysteme und sich häufig ändernder Beziehungen

Data Vault 2.0 bietet die größten Vorteile, wenn Ihre Daten aus vielen verschiedenen Quellsystemen stammen oder sich ständig ändernde Beziehungen aufweisen.

Data Vault 2.0 eignet sich hervorragend für Umgebungen mit mehreren Quellsystemen oder für Datenstrukturen mit sich kontinuierlich ändernden Beziehungen.

Dies funktioniert in solchen Systemen deshalb so gut, weil sich neue Attribute ganz einfach hinzufügen lassen. Wenn sich ein Quellsystem ändert, muss diese Änderung nicht mühsam in allen anderen Quellsystemen abgebildet werden. Zudem lässt sich die Anzahl der anzupassenden Stellen minimieren, da Attribute getrennt von den Strukturdaten in Satellites gespeichert werden.

Darüber hinaus lassen sich neue und veränderte Beziehungen einfacher abbilden, indem ein Link geschlossen und ein neuer erstellt wird. Sie müssen weder historische Daten anpassen, um eine neue Beziehung zu berücksichtigen, noch ein bestehendes Schema aktualisieren. Sie müssen lediglich zukünftige Änderungen erfassen. Dies verleiht Ihrem Enterprise Data Warehouse eine enorme Flexibilität und Skalierbarkeit.

Grund 2: Einfache Nachverfolgung und Auditierung Ihrer Daten mit Data Vault 2.0

In einer modernen Datenumgebung durchlaufen Daten verschiedene Stationen. Um dennoch eine kontinuierliche Datenqualität zu gewährleisten, muss immer klar nachvollziehbar sein, woher die Daten stammen.

Abbildung 1: Data Lineage

Da die lückenlose Nachverfolgbarkeit und Auditierung von Daten heute unerlässlich sind, bietet Data Vault hierfür eine optimale Unterstützung. Dies gelingt durch die standardmäßige Auditierbarkeit, da für jede Zeile Ladezeiten (Load Times) und Datenquellen (Record Sources) zwingend erforderlich sind. Zudem werden alle historischen Änderungen in Satellites erfasst, wobei die Load Time Teil des Primary Keys ist.
Bei der Aktualisierung eines Attributs wird einfach ein neuer Datensatz angelegt.
Diese Auditierungsfunktionen ermöglichen es Ihnen, die Revisionssicherheit, sowohl für regulatorische Vorgaben als auch für die Data Governance mühelos zu gewährleisten. Da die gesamte Historie gespeichert bleibt können Sie jederzeit auf den Datenbestand zu einem beliebigen historischen Zeitpunkt zugreifen.

Grund 3: Schnelleres Laden von Daten aus mehreren Quellsystemen mit Data Vault 2.0

Data Vault ermöglicht ein schnelleres Laden von Daten, da eine Vielzahl von Tabellen parallel und unabhängig voneinander geladen werden kann. Das Modell reduziert die Abhängigkeiten zwischen den Tabellen während des Ladeprozesses und vereinfacht die Datenintegration (Ingestion), indem es ausschließlich auf Inserts setzt. Diese lassen sich deutlich schneller ausführen als Upserts oder Merges. Dies verringert zudem die Gesamtkomplexität des Systems.

Fazit

Data Vault 2.0 ist speziell für die Integration von Daten aus mehreren Quellsystemen konzipiert und bietet in komplexen Szenarien herausragende Vorteile.

Zusammenfassend lässt sich sagen: Wenn Sie nur geringe bis mittlere Anforderungen an Ihre Analytics-Plattform stellen und ein kleines Team aus Architekten, Designern und Entwicklern eine Lösung mit Daten aus nur wenigen Systemen bereitstellt, ist Data Vault für Ihre Anforderungen eventuell überdimensioniert.

Wenn Sie jedoch ein großes Projekt mit vielen Quellsystemen umsetzen, das hohe Anforderungen an die Datenintegration stellt, kann Data Vault Ihrem Projekt einen entscheidenden Mehrwert bieten.

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.

Complexity Factor	Person Hours per Function Point
Easy	0.1
Moderate	0.2
Difficult	0.7

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:

Component	Complexity Factor	Estimated Function Points	Estimated Total Hours
Hub Load	Easy	2	0.2
Dimension Load	Difficult	3	2.1
Report Build	Difficult	5	3.5

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.

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.