Implementierung von Data-Vault-2.0-Ghost-Records
Während der Entwicklung von Data Vault, von der ersten Iteration bis hin zu Data Vault 2.0, haben wir die beiden Begriffe „Ghost-Records“ und „Zero-Keys“ sowohl in unserer Literatur als auch in unseren Data-Vault-2.0-Bootcamps erwähnt. Seitdem haben wir festgestellt, dass diese Konzepte oft synonym verwendet werden.
In diesem Blogbeitrag werden wir die Implementierung von Ghost-Records in Data Vault 2.0 besprechen. Bitte beachten Sie, dass dieser Artikel der erste Teil einer mehrteiligen Blogserie ist, die den Unterschied zwischen Ghost-Records und Zero-Keys verdeutlicht.
Warum Sie Ghost-Records implementieren sollten?
Das Konzept der Ghost-Records wird üblicherweise im Zusammenhang mit der Implementierung von Point-in-Time-Tabellen (PIT-Tabellen) genannt. PIT-Tabellen werden als Query-Assistant-Objekte im Business Vault verwendet, um Snapshots von Daten für bestimmte, von den Datenkonsumenten definierte Zeitintervalle zu erstellen. Es ist wichtig zu beachten, dass diese Intervalle täglich, wöchentlich oder gar in Echtzeit erfolgen können. Jeder Eintrag in einer PIT-Tabelle materialisiert Joins von einem Data-Vault-Spine-Objekt (entweder einem Hub oder einem Link) zu seinen umliegenden Satellitenstrukturen, um Joins bei Abfragen im Data Vault zu reduzieren und so die Abfrageperformance zu steigern.
In einigen Fällen kann es jedoch beim Joinen beispielsweise eines Hubs mit einem seiner Satelliten vorkommen, dass für bestimmte Snapshots kein entsprechendes Satelliten-Delta existiert. Der Grund dafür könnte sein, dass der Business-Key zu diesem Zeitpunkt in der Datenquelle nicht verfügbar oder unbekannt war.
Referenz auf ein Ghost-Record in einer PIT-Tabelle
Um dieses Problem zu lösen, werden Ghost-Records zu Satelliten-Entitäten hinzugefügt, um Lücken am Anfang der Zeitachse virtuell aufzufüllen, sodass Equal Joins bei Ad-hoc-Abfragen im Raw Vault ermöglicht werden. Equal Joins (auch bekannt als Equi-Joins) sind Joins, die ausschließlich Gleichheitsoperatoren verwenden und die wohl effizienteste und schnellste Art von SQL-Joins darstellen.
Wie sieht ein Ghost-Record aus?
Ein Ghost-Record kann als Dummy-Datensatz verstanden werden, der Standardwerte enthält. In der vorherigen Iteration von Data Vault (DV1) bestand die Lösung darin, ein Ghost-Record pro Key und Satellitenstruktur zu erstellen. Dies erfüllte zwar den Zweck, Lücken am Anfang der Zeitachse zu füllen, skalierte jedoch bei größeren Datenmengen nicht gut. Stellen Sie sich einen Hub vor, der 10 Millionen Business-Keys enthält und an den drei Satelliten angebunden sind. Jeder Satellit würde dann 10 Millionen Ghost-Records enthalten, was insgesamt 30 Millionen Datensätze über alle drei Satelliten hinweg bedeuten würde. Zudem müsste jedes Mal, wenn ein Business-Key zum Hub hinzugefügt wird, ein entsprechendes Ghost-Record in jedem Satelliten ergänzt werden. Die schiere Menge an Ghost-Records würde in diesem Fall den eigentlichen Zweck, Equi-Joins für schnellere Abfragen zu ermöglichen, völlig zunichte machen.
Daher ist seit der Einführung von DV2.0 nur noch das Einfügen eines einzigen Ghost-Records pro Satellitenstruktur erforderlich.
Beispiel: Ghost-Record mit Attributen verschiedener Datentypen
Das Ghost-Record enthält typischerweise einen konstanten Hash-Key 00000000000000000000000000000000 (32-mal das Zeichen „0“). Dieser Hash-Key ist auch als Zero-Key bekannt – mehr zu Zero-Keys erfahren Sie im nächsten Teil dieser Blogserie. Der Load-Timestamp wird üblicherweise auf den frühestmöglichen Zeitstempel innerhalb des DBMS gesetzt, was den „Anfang der Zeit“ darstellt. Die Record-Source „SYSTEM“ bedeutet schlichtweg, dass der Datensatz künstlich generiert wurde.
Danach folgt eine Liste von Standard-NULL-Werten für jedes beschreibende Attribut innerhalb der Satellitenstruktur. Für jeden Datentyp definieren wir einen Standardwert für das Ghost-Record. Beispielsweise können Attribute mit numerischen Datentypen mit einer (numerischen) Null belegt werden, während String-Attribute je nach Längendefinition des Attributs entweder mit „(unknown)“ oder „?“ gefüllt werden können.
Es wird empfohlen, das Ghost-Record mit Standardwerten zu füllen, anstatt es mit NULL- oder leeren Werten zu belegen, da diese Standardwerte in nachgelagerten Prozessen (downstream) verwendet und angezeigt werden können. Ein gutes Beispiel hierfür zeigt sich in Dimensionen: Ein „(unknown)“-String ist wohl weitaus aussagekräftiger als ein bloßer NULL-Wert.
So fügen Sie Ghost-Records ein
Es gibt verschiedene Möglichkeiten, Ghost-Records in Satellitenstrukturen einzufügen.
Die erste Variante besteht darin, die Ghost-Records bei der Objekterstellung als einmaligen Vorgang einzufügen und danach nicht mehr daran zu denken. So einfach ist das!
Eine andere Möglichkeit besteht darin, das Ghost-Record während des Ladeprozesses der Satelliten einzufügen. Der Ladeprozess sollte mit dem Einfügen eines Ghost-Records in das Zielobjekt beginnen, falls dieses noch nicht existiert. Anschließend kann der Prozess mit dem normalen Laden des Satelliten mit den eingehenden Daten fortfahren. Diese Variante mag als recht aufwendig angesehen werden. Sie stellt jedoch sicher, dass das Ghost-Record immer verfügbar ist und wieder in jeden Satelliten eingefügt wird – falls beispielsweise aus irgendeinem Grund Objekte geleert (truncated) werden oder das Ghost-Record selbst versehentlich gelöscht wird, etwa während der Entwicklung
Beide Varianten können im Data-Vault-Automatisierungstool Ihrer Wahl für Ihr Projekt vollständig automatisiert werden.
Fazit
Wir hoffen, dass dieser Blogbeitrag dazu beiträgt, die Implementierung von Ghost-Records in einer Data-Vault-2.0-Lösung zu verdeutlichen. Als Nächstes möchten wir mit Ihnen den „anderen technischen Begriff“, die Zero-Keys, sowie den Unterschied zwischen Ghost-Records und Zero-Keys besprechen, ein Thema, das für viele Data-Vault-Anwender recht verwirrend war.
