Skip to main content
search
0
CartClose Cart
All Posts By

Trung Ta

Trung Ta is a Senior BI Consultant at Scalefree with over 7 years of experience in data projects. A Certified Data Vault 2.0 Practitioner, he specializes in data platform automation and leading large scale data teams. His expertise spans Snowflake, dbt, and cloud ecosystems like Azure and AWS.

In Data Vault

Implementierung von Data Vault 2.0 Zero Keys

Implementierung von Data Vault 2.0 Zero Keys

Erfahren Sie mehr über Zero-Keys – das andere Konzept, das oft synonym mit Ghost-Records verwendet wird, die wir bereits in einem früheren Blogbeitrag besprochen haben

In this article:

Warum Zero Keys implementieren?

Wie im vorherigen Teil dieser Serie besprochen, ist ein Ghost-Record ein Dummy-Datensatz in Satellite-Entitäten, der Standardwerte enthält. Einfach ausgedrückt sind Zero-Keys die Einträge in jeder Hub- und Link-Entität, die das Gegenstück zum Ghost-Record des Satelliten darstellen und dessen Hash-Key enthalten. Auf diese Weise wird der Begriff „Zero-Key“ oft verwendet, um den Hash-Key des Ghost-Records zu beschreiben, der in anderen Data-Vault-Entitäten wie Point-in-Time-Tabellen (PIT-Tabellen) oder Links auftauchen kann. Zusammen mit dem Zero-Hash-Key gibt es, ähnlich wie bei einem Ghost-Record, einen Standardwert für den Business-Key. Oder im Fall eines Composite-Business-Keys mehrere Standardwerte für jede seiner Komponenten.

Zero Key with a composite business key

Sobald der Hub- und Link-Eintrag für den Zero-Key vorhanden ist, verfügt jeder einzelne Eintrag im zugehörigen Satelliten über einen Parent-Hash-Key, wodurch sogenannte verwaiste Hash-Keys (Hash-Key-Orphans) vermieden werden.

Wie sieht ein Zero Key aus?

In Data Vault 2.0 ist es nur erforderlich, einen einzigen Ghost-Record in jede Satellite-Entität einzufügen. Es ist jedoch möglich, mehrere Zero-Keys zu verwenden. Intern bei Scalefree und in vielen unserer Projekte unterscheiden wir zwei Arten von fehlenden Objekten durch verschiedene Hub-Zero-Keys.
Bitte beachten Sie, dass der hier verwendete Hash-Algorithmus MD5 ist:

  • 00000000000000000000000000000000 (32-mal die Ziffer „0“) für allgemeine „unbekannte“ Fälle, in denen ein Business-Key fehlt.
  • ffffffffffffffffffffffffffffffff (32-mal der Buchstabe „f“): ein dedizierter Zero-Key für fehlerhafte Fälle, in denen Business-Keys fehlen.
Multiple zero keys in a Hub entity

Ein gutes Beispiel, das den „Error“-Zero-Key erfordert, ist eine fehlerhafte oder fehlende obligatorische Objektbeziehung in der Quelle. In diesem Fall wird der Zero-Key ffffffffffffffffffffffffffffffff in der Link-Entität gefunden, was auf eine unerwartet fehlende Hub-Referenz hinweist. Denken Sie daran: Sollten Sie sich für die Implementierung des Error-Zero-Keys entscheiden, ist es nicht erforderlich, einen Ghost-Record mit dem Error-Zero-Key als Parent-Hash-Key in Satellite-Entitäten einzufügen.

Für den Zero-Key in Link-Entitäten ist nur ein einziger Eintrag erforderlich, der den Zero-Hash-Key sowohl als Link-Hash-Key als auch als Hub-Referenz enthält.

Zero key in a Link entity

Es ist auch wichtig darauf hinzuweisen, dass alle Beispiele, die wir in dieser Blogserie zeigen, den Hash-Algorithmus MD5 verwenden, der 32-stellige hexadezimale Sequenzen ausgibt. Für Data-Vault-2.0-Projekte, die andere Hash-Algorithmen wie SHA256 verwenden, passen Sie einfach die Länge der von uns vorgeschlagenen Zero-Keys („0000…“ / „ffff…“) an die gewünschte Hash-Ausgabelänge an.

Fazit

Wir hoffen, dass dieser Blogbeitrag dazu beigetragen hat, die Implementierung von Zero-Keys in einer Data-Vault-2.0-Lösung sowie die Unterschiede zwischen den Konzepten von Ghost-Records und Zero-Keys zu verdeutlichen. Teilen Sie Ihre Erfahrungen bei der Implementierung dieser Konzepte gerne in den Kommentaren unten mit!

In Data Vault

Implementierung von Data-Vault-2.0-Ghost-Records

Ghost records

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.

In this article:

 

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.

Ghost records

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.

Ghost records

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.

Close Menu