Validierung von Beziehungen in Data Vault 2.0 handhaben

Validierung der Beziehungen in Data Vault 2.0

Je nachdem, wie die Daten geliefert werden, gibt es verschiedene Möglichkeiten, die Validierung von Beziehungen aus Quellsystemen zu handhaben (Vollextrakt oder CDC), und die Art und Weise, wie ein Löschvorgang vom Quellsystem durchgeführt wird, z. B. als Soft Delete oder Hard Delete. Unter Data Vault 2.0In der Regel werden die Daten nach Schlüsseln, Beziehungen und Beschreibungen unterschieden.

Ein oft unterschätzter Punkt ist jedoch die Handhabung und Validierung von Beziehungen in Data Vault 2.0.
Im folgenden Blogartikel erklären wir, was zu beachten ist und wie man damit umgeht. 

 

Löschvorgänge in Data Vault 2.0 

Lassen Sie uns zunächst die verschiedenen Arten von Löschungen in Quellsystemen erklären:

1. Hard delete – Ein Datensatz wird im Quellsystem endgültig gelöscht und ist nicht mehr im System vorhanden. 1
2. Soft delete – Der gelöschte Datensatz ist weiterhin in der Datenbank des Quellsystems vorhanden und als gelöscht markiert.

Zweitens wollen wir uns ansehen, wie wir die Daten im Staging-Bereich finden:

1. Vollextrakt – kann der aktuelle Stand des Quellsystems oder ein Delta-/Inkrementalextrakt sein
2. CDC (Change Data Capture) - Nur neue, aktualisierte oder gelöschte Datensätze, um Daten inkrementell/deltamäßig 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, auch wenn es keinen Audit-Trail vom Quellsystem gibt (Data Aging ist ein anderes Thema).

Löscherkennung und Validierung von Beziehungen in Data Vault 2.0

Löscherkennung Bei Business Keys bzw. Hubs ist dies unkompliziert. Soft Deletes werden als beschreibende Attribute direkt im Satelliten behandelt und berücksichtigen nicht, ob die Daten aus einem Vollextrakt oder CDC stammt. Für Hard Deletes im Quellsystem unterscheiden wir zwischen Fulll Extract und CDC.
Hier stellen wir die Effectivity Satellite. Im Fall von:

1. Vollextrakt - Führen Sie einen Lookup zurück in den Staging-Bereich durch, um zu prüfen, ob der Business Key noch existiert. Falls nicht, fügen Sie einen Datensatz mit den gelöschten Informationen (d.h. ein Kennzeichen und ein Datum) in den Gültigkeits-Satelliten ein. 
2. CDC - Wir erhalten "Lösch"-Informationen, die ein neuer Eintrag im Effectivity Satellite sind.

Die Erkennung des Löschens von Beziehungen erfordert etwas mehr Aufmerksamkeit und wird oft vergessen. Bei einem Vollextrakt können wir denselben Ansatz wie bei den Business Keys verfolgen: Prüfen Sie einfach, ob der Link Hash Key in der aktuellen Staging-Beladung existiert und gegebenenfalls einen neuen Eintrag in den Effectivity Satellite ein.

Heutzutage wird CDC jedoch immer häufiger eingesetzt. Da CDC jedoch nur Deltas liefert, besteht die Herausforderung nun darin, Beziehungen zu identifizieren, die nicht mehr existieren. Das folgende Beispiel zeigt eine Beziehung zwischen den Geschäftsobjekten Kunde und Unternehmen. Dies ist eine 1:n-Beziehung:

Bild 1: Tabellen Kunde und Unternehmen

Die Link-Tabelle in Data Vault sieht folgendermaßen aus:

Tabelle 1: Kundenverbindung

Zur besseren Lesbarkeit und Vereinfachung stellen wir die Geschäftsschlüssel anstelle von Hashkeys dar und zeigen keine Systemfelder wie den Ladezeitstempel und die Herkunftsangabe des Datensatzes.

Soweit so gut, aber was passiert, wenn der Kunde anfängt, für ein anderes Unternehmen zu arbeiten? Dies führt zu einem neuen Eintrag im Link. Der CDC-Mechanismus liefert uns die Daten als Aktualisierung der Kundentabelle.

Abbildung 2: Quelltabellen und Link nach Firmenwechsel

Woher bekommen wir die Information, dass Kunde 4711 nicht mehr für Unternehmen 1234 arbeitet, und wo wird diese Information gespeichert? Wir müssen den alten Link-Eintrag im Data Warehouse Soft-Delete-löschen, um die Daten wieder konsistent zu machen. Im Moment sieht es so aus, als würde der Kunde für beide Unternehmen arbeiten, da beide Links aktuell aktiv sind. 

Es gibt zwei mögliche Wege:

1. Sie erhalten das "Von" und das "Bis" in Ihrem Audit-Trail und identifizieren eine Differenz für die Company_ID.
   Wenn das der Fall ist, erstellen Sie 2 neue Einträge im Effectivity Satellite, wobei einer den alten (von) als gelöscht markiert und der andere den neuen (bis) als nicht gelöscht markiert. Es ist notwendig, neue Beziehungen als "nicht gelöscht" einzufügen, damit Sie Hashkeys hin und her aktivieren und deaktivieren können.
   Überlegen Sie, was passiert, wenn der Kunde 4711 wieder für das Unternehmen 1234 arbeitet.
2. Falls Sie die Angaben "von" und "bis" nicht haben, müssen Sie entweder die CDC Daten in eine persistente Staging-Area, in der Sie die vollständige Historie der per CDC gelieferten Daten aufbewahren, oder in eine Quellreplik, in der Sie ein Spiegelbild des Quellsystems erstellen, indem Sie es mit den CDC-Daten versorgen, wobei Sie Hard Updates durchführen, wenn ein "Updated" von der CDC kommt, und Hard Deletes, wenn ein "Delete" von der CDC kommt.
   Bei Verwendung der Quellreplik können Sie denselben Ansatz verfolgen wie zuvor bei Vollladungen: Joinen Sie in die Replik und finden Sie heraus, ob der Hash Key noch existiert oder nicht.
   Der größte Nachteil hierbei ist, dass Sie mehr Daten scannen müssen, was mehr IO bedeutet. Bei Verwendung einer persistenten Staging-Area können Sie eine Änderung in einer Beziehung mithilfe der Window-Funktion lead() ermitteln, wobei Sie nach der technischen ID, in diesem Fall Customer_ID, partitionieren und nach dem Ladezeitstempel sortieren.
   Sobald der Link Hash Key anders ist, wird die Beziehung geändert und die alte besteht nicht mehr.

Das Ergebnis im Effectivity Satellite (logisch):

Tabelle 2: Wirksamkeits-Satelliten auf dem Link

Fazit

Wir haben in diesem Artikel zwei wichtige Punkte behandelt. Der erste ist, dass in Data Vault 2.0Da wir die Beziehungsinformationen aus den Quelltabellen extrahieren, müssen wir der Validierung dieser Informationen mehr Aufmerksamkeit schenken.
Der zweite Punkt ist, dass die Art und Weise, wie Sie die Daten erhalten (Delta durch CDC oder vollständiger Extrakt), Ihnen unterschiedliche Möglichkeiten hinsichtlich der Art und Weise bietet, die Daten zu laden. Wenn Sie mit großen Datenmengen arbeiten, ist CDC definitiv der richtige Weg. Darüber hinaus erhalten Sie mit dem CDC-Mechanismus alle Aktualisierungen aus der Quelle und können Daten leichter in (fast) Echtzeit laden.

- von Marc Finger (Scalefree)