Skip to main content
search
0
CartClose Cart
All Posts By

Marc Winkelmann

Marc Winkelmann is a Senior Managing Consultant and Certified Data Vault 2.1 Trainer at Scalefree with over 8 years of BI experience. A Snowflake SnowPro Advanced Data Engineer and dbt Certified Developer, he specializes in cloud migrations (AWS, Azure, Snowflake) and enterprise data strategy. Marc holds a Master’s in BI & Analytics and is an expert in coaching teams through complex data transformations.

In Data Vault

Hash Keys in Data Vault

Hash Keys in Data Vault 2.0 for MPP

Hash-Keys in DV 2.0Hash Keys in DV2.0

Data Vault 2.0 führt Hash-Keys ein, um das traditionelle Data-Vault-Modell zu erweitern, was dem Data Warehousing mehrere Vorteile bringt. Hash-Keys beschleunigen nicht nur den Ladeprozess; sie stellen auch sicher, dass sich das Enterprise Data Warehouse über mehrere Umgebungen erstrecken kann: On-Premises-Datenbanken, Hadoop-Cluster und Cloud-Speicher.

Lassen Sie uns zuerst über den Performance-Gewinn sprechen: Um die Ladevorgänge zu beschleunigen, müssen Abhängigkeiten im Ladeprozess minimiert oder sogar eliminiert werden. In Data Vault 1.0 wurden Sequenznummern verwendet, um eine Business-Entity zu identifizieren, was folglich zu Abhängigkeiten während des Ladeprozesses führte.

Diese Abhängigkeiten haben den Ladeprozess verlangsamt, was insbesondere bei Echtzeit-Feeds ein Problem darstellt. Hubs mussten zuerst geladen werden, bevor der Ladeprozess von Satellites und Links starten konnte. Das Ziel ist es, diese Abhängigkeiten aufzubrechen, indem Hash-Keys anstelle von Sequenznummern als Primärschlüssel verwendet werden.

In this article:

Business-Keys vs. Hash-Keys

Vorab: Business-Keys können eine von einem einzelnen Quellsystem erstellte Sequenznummer sein, z. B. die Kundennummer.

Business-Keys können jedoch auch ein zusammengesetzter Schlüssel sein, um eine Business-Entity eindeutig zu identifizieren – beispielsweise wird ein Flug in der Luftfahrtindustrie durch die Flugnummer und das Datum identifiziert, da die Flugnummer jeden Tag wiederverwendet wird.

Allgemein gilt: Ein Business-Key ist der natürliche Schlüssel, der vom Fachbereich verwendet wird, um ein Business-Object zu identifizieren.

Die Verwendung von Business-Keys im Data Vault ist zwar eine Option, aber eine langsame, die viel Speicherplatz beansprucht (sogar mehr als Hash-Keys).

Insbesondere in Links und den davon abhängigen Satellites sind viele zusammengesetzte Business-Keys erforderlich, um die Beziehung oder Transaktion bzw. das Ereignis in einem Link zu identifizieren – und im Satellite zu beschreiben.

Dies würde viel Speicherplatz erfordern und den Ladeprozess verlangsamen, da nicht alle Datenbank-Engines in der Lage sind, effiziente Joins über Business-Keys mit variabler Länge auszuführen.

Andererseits hätten wir zu viele Spalten im Link, da jeder Business-Key ein Teil des Links sein muss.

Das Problem dabei ist, dass in den Links auch unterschiedliche Datentypen mit verschiedenen Längen vorliegen. Dieses Problem verschärft sich noch, da es auch erforderlich ist, die Business-Keys in die zugehörigen Satellites zu replizieren.

Um eine konsistente Join-Performance zu garantieren, besteht die Lösung darin, die Business-Keys mithilfe von Hash-Funktionen zu einem einzigen Spaltenwert zu kombinieren, um eine eindeutige Repräsentation eines Business-Objects zu berechnen.

Massively Parallel Processing (MPP)

Da die Ladeprozesse von Hubs, Links und Satellites voneinander unabhängig sind, können diese vollständig parallel ausgeführt werden.

Hash Keys in Data Vault 2.0 for MPP

Die Idee basiert auf der Tatsache, dass ein Hash-Key von einem Business-Key oder einer Kombination von Business-Keys abgeleitet wird, ohne dass eine Abfrage (Lookup) in der übergeordneten Tabelle erforderlich ist.

Anstatt also die Sequenz eines Business-Keys in einem Hub nachzuschlagen, bevor der Business-Key im Satellite beschrieben wird, lässt sich einfach der Hash-Key des Business-Keys berechnen.

Die korrekte Implementierung der Hash-Funktion stellt sicher, dass derselbe semantische Business-Key zu exakt demselben Hash-Key führt, unabhängig von der geladenen Ziel-Entity.

Hash-Keys zur Verknüpfung von Apache™ Hadoop®-Datensätzen

Ohne Hashing erfordert das Laden in Hadoop® oder NoSQL eine Abfrage (Lookup) der Hub- oder Link-Sequenz im relationalen System, bevor die Daten eingefügt oder angehängt werden können.

Hashing anstelle von Sequenzierung bedeutet, dass Ladevorgänge in alle Hubs, Links und Satellites in absolut zu 100 % parallelen Operationen erfolgen können. Gleichzeitig lassen sich alle Hadoop®- oder NoSQL-basierten Dokumente parallel anreichern.

Dies ermöglicht es dann auch, plattformübergreifende Joins über mehrere heterogene Plattformen hinweg durchzuführen – beispielsweise von einer Teradata-Datenbank zu Apache™ Hadoop®.

Hash-Difference

Die Hash-Difference-Spalte wird auf die Satellites angewendet. Der Ansatz ist derselbe wie bei den Business-Keys, nur dass hier alle beschreibenden Daten gehasht werden.

Das reduziert den Aufwand während eines Ladeprozesses, da nur eine einzige Spalte nachgeschlagen werden muss. Der Satellite-Ladeprozess prüft zuerst, ob der Hash-Key bereits im Satellite vorhanden ist, und zweitens, ob es Unterschiede zwischen den Hash-Difference-Werten gibt.

Hash Keys and Hash Difference in Data Vault 2.0

Die obige Abbildung zeigt den Prozess, wenn das Quellsystem Ihnen eine vollständige Datenlieferung sendet.

Der Zeitpunkt, an dem die Werte gehasht werden, sollte auf dem Weg in die Staging-Area liegen, da zu diesem Zeitpunkt genügend Zeit vorhanden ist, um auf Hash-Kollisionen zu prüfen und Hashing-Probleme zu behandeln, bevor die Daten in den Data Vault geladen werden.

Welche Hash-Funktion sollte verwendet werden?

Es stehen viele Hash-Funktionen zur Auswahl: MD5, MD6, SHA-1, SHA-2 und einige mehr.

Wir empfehlen in den meisten Fällen die Verwendung des MD5-Algorithmus mit einer Länge von 128 Bit, da dieser auf den meisten Plattformen allgegenwärtig verfügbar ist und eine angemessen geringe Wahrscheinlichkeit für eine Hash-Kollision bei akzeptablem Speicherplatzbedarf aufweist.

Ein zusätzlicher Vorteil des Hashings besteht darin, dass die Hashes dieselbe Länge haben und vom selben Datentyp sind, woraus sich eine Performance-Steigerung ergibt.

Darüber hinaus sind generierte Hash-Werte deterministisch, sodass sie nie verloren gehen und sich jederzeit reproduzieren lassen.

Kollisionen

Hashing birgt ein sehr geringes Risiko: die Kollision. Das bedeutet, dass zwei unterschiedliche Datenwerte denselben Hash-Wert erhalten.

Dieses Risiko ist jedoch extrem gering. Ein Beispiel: In einer Datenbank mit mehr als einer Billion Hash-Werten ist die Wahrscheinlichkeit, dass Sie eine Kollision erhalten, in etwa so hoch wie die Wahrscheinlichkeit, dass ein Meteorit auf Ihrem Rechenzentrum einschlägt.

Zusammenfassung

Hash-Keys sind im Data Vault nicht zwingend erforderlich, werden aber dringend empfohlen. Die Vorteile von

  • Massively Parallel Processing (MPP),
  • Data-Load-Performance,
  • Konsistenz und
  • Auditierbarkeit

sind unverzichtbar und können mit Sequenzen oder Business-Keys nicht erreicht werden.

Hash-Keys sind kein Allheilmittel… aber sie bieten weitaus mehr Vorteile, als sie Nachteile (wie erhöhten Speicherplatzbedarf) mit sich bringen.

In Datenmodellierung

Der Wert von Non-Historized Links

So verwenden Sie Non-Historized Links

Non-Historized Links in Data Vault 2.0

Non-Historized Links in Data Vault 2.0 vereinfachen die Datenmodellierung, indem sie sich auf aktuelle Beziehungen konzentrieren statt auf historische Änderungen. Dies verbessert die Effizienz, reduziert die Komplexität und steigert die Abfrageleistung für agilere Analysen.

In this article:

Einführung in Non-Historized Links

Non-Historized Links, auch als Transaction Links bekannt, sind ein wesentlicher Bestandteil des Data Vault 2.0 Frameworks – aber wie funktionieren sie innerhalb eines Modells? Als Dan Linstedt, Mitgründer von Scalefree, den Data Vault erfand, verfolgte er mehrere Ziele. Eines davon war es, Daten so schnell wie möglich aus der Quelle in ein Data Warehouse Modell zu laden, sie in Informationen umzuwandeln und dem Business Analysten in jeder gewünschten Zielstruktur bereitzustellen.

Für die Data Warehouse Automatisierung und Einfachheit besteht das Data Vault 2.0 Modell aus nur drei grundlegenden Entitätstypen:

  1. Hubs: eine eindeutige Liste von Business Keys
  2. Links: eine eindeutige Liste von Beziehungen zwischen Business Keys
  3. Satellites: beschreibende Daten, die das übergeordnete Element (Business Key oder Beziehung) aus einem bestimmten Kontext heraus beschreiben, versioniert über die Zeit.

Wie wir immer lehren (und manchmal predigen): Sie können alle Unternehmensdaten allein mit diesen drei Entitätstypen modellieren. Ein Modell, das jedoch nur diese Entitätstypen verwendet, hätte mehrere Nachteile: viele komplexe Joins, hoher Speicherverbrauch, eingeschränkte Ladeleistung und verpasste Möglichkeiten zur Virtualisierung.

Die Lösung? Das Hinzufügen weiterer Bausteine zu den Kernentitätstypen des Data Vault, um diese Probleme zu bewältigen. Einer dieser Bausteine ist die Verwendung von Non-Historized Links, auch als Transaction Links bekannt:

Sales - Non-historized Links

In diesem Beispiel können Verkäufe mit Non-Historized Links modelliert werden, die Verkaufstransaktionen eines Kunden in Bezug auf ein Geschäft erfassen. Das Ziel des Non-Historized Links ist es, eine hohe Performance sowohl beim Laden in als auch beim Auslesen aus dem Data Warehouse sicherzustellen. Vergessen Sie nicht: Das ultimative Ziel des Data Warehousing ist es, ein Data Warehouse zu bauen – nicht nur zu modellieren. Und der Aufbau eines Data Warehouse umfasst weit mehr als nur das Modell: Es erfordert Menschen, Prozesse und Technologie.

Wesentliche Merkmale von Non-Historized Links

Wie erfüllen Non-Historized Links diese Ziele? Denken Sie an Ihre Business Analysten. Was sind ihre Ziele? Ehrlich gesagt interessiert sie das Data Vault Modell am Ende nicht direkt. Stattdessen möchten sie dimensionale Modelle sehen – Star Schemas, Snowflake Schemas oder flache, breite Modelle für Data Mining. Oder gelegentlich möchten sie die unübersichtlichen Tabellen aus dem Mainframe sehen, manchmal verknüpft, manchmal nicht – und nicht mehr viele Menschen verstehen die Beziehungen noch vollständig… aber für die Abwärtskompatibilität ist das hervorragend.

Nachdem das Ziel definiert wurde, stellt sich die nächste Frage: Was ist die Zielgranularität? In einem dimensionalen Modell spiegelt die Zielgranularität von Faktentabellen beispielsweise häufig die zu analysierenden Transaktionen wider – denken Sie an Anrufaufzeichnungen in der Telekommunikationsbranche oder Banktransaktionen.

Interessanterweise ist diese gewünschte Zielgranularität häufig direkt in den Quellsystemen zu finden. Ein Telekommunikationsanbieter verfügt über ein operatives System, das jeden Telefonanruf aufzeichnet. Oder eine Bankanwendung, die jede Kontotransaktion erfasst. Diese Datensätze werden in der Regel ohne Aggregation in das Data Warehouse geladen – im Data Vault arbeiten wir auf der feinsten Granularität für Prüf- und Lieferzwecke.

Und hier liegt das Problem mit den Standard-Data Vault Entitätstypen. Obwohl sie sehr einfach und musterbasiert sind, haben sie ein Problem: Der Standard-Link speichert eine eindeutige Liste von Beziehungen. Das bedeutet, dass der Link nur an Beziehungen aus der Quelle interessiert ist, die dem Ziel-Link unbekannt sind. Wenn ein Kunde mehrmals in ein Geschäft geht und dasselbe Produkt kauft, ist die Beziehung zwischen Kunde, Geschäft und Produkt bereits bekannt – es wird kein weiterer Link-Eintrag hinzugefügt.

Infolgedessen wird die Granularität der eingehenden Daten beim Laden des Ziel-Links verändert. Wenn die dem Vorgang zugrunde liegende Beziehung bereits bekannt ist, wird die Transaktion ausgelassen – und stattdessen von einem Satellite erfasst.

Das nächste Problem besteht darin, dass die Link-Granularität nun von der Zielgranularität abweicht, weil der Business Analyst einen Datensatz pro Transaktion und nicht pro eindeutiger Business Key-Beziehung wollte. Eine weitere Granularitätsverschiebung ist erforderlich, die typischerweise das Verknüpfen des Satellite des Links mit dem Link selbst beinhaltet, um die ursprüngliche Granularität wiederherzustellen.

Wie wir in unserem Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ erläutert haben, ist eine Granularitätsverschiebung in Bezug auf die Performance relativ kostspielig. Dies liegt daran, dass der Vorgang aufwendige GROUP BY-Anweisungen oder LEFT und RIGHT JOINS erfordert.

Und wofür? Das Endergebnis beider Operationen entspricht oft der ursprünglichen Granularität aus dem Quellsystem. Zwei aufwendige Granularitätsverschiebungen für nichts – das klingt nach einem schlechten Tausch.

non-historized Links

Und genau das ist der Fall.

Hier kommen Non-Historized Links ins Spiel: Der Link ist eine einfache Variation des Standard-Links mit dem Ziel, die Quelltransaktionen und -ereignisse in der ursprünglichen Granularität zu erfassen.

In einem Standard-Link wird die Granularität durch die Anzahl der Hub-Referenzen im Link definiert. Dies wäre nicht ausreichend, um mehrere Transaktionen zu erfassen, die dieselben Business Keys (z. B. denselben Kunden, dasselbe Geschäft und dasselbe Produkt) im selben Ziel-Link beinhalten. Um das Problem zu lösen, ist ein zusätzliches Element des alternativen Schlüssels in den Non-Historized Links erforderlich – typischerweise eine Transaktions- oder Ereignis-ID, wie die Anruf-ID oder eine Warenkorb-ID im Einzelhandel (die auch als eigener Hub modelliert werden kann). In Kombination mit den Hub-Referenzen sollte der kombinierte Business Key pro Transaktion eindeutig sein. Auf diese Weise können wir nun einen Datensatz im Ziel-Link pro Quelldatensatz aus dem operativen System erfassen.
How to use non-historized Links
How to use non-historized Links

Abbildung: Non-Historized Link mit der Verkaufs-ID als zusätzlichem Schlüssel

Ein tiefergehendes Szenario wäre, wenn dasselbe Produkt (in diesem Fall die höchste Granularität) zweimal in einem Verkauf vorkommt – beispielsweise aufgrund unterschiedlicher Rabatte. In diesem Fall wäre die Positionsnummer ein zusätzlicher Schlüssel (Dependent Child Key), um jeden Datensatz eindeutig zu machen.

Aus der Ladeperspektive wird der Aufnahmeprozess der eingehenden Daten erheblich verbessert, da keine Granularitätsverschiebung mehr erforderlich ist. Alle Daten werden direkt aus der Quelle in das Ziel geladen. Solange der Business Analyst genau auf dieser Granularität berichten möchte, ist es möglich, die Non-Historized Link-Tabelle in eine Faktentabelle umzustrukturieren, indem eine virtuelle SQL-Ansicht darüber gelegt wird.
Ein wesentlicher Punkt ist, dass Non-Historized Links keine Änderungen der beschreibenden Daten erlauben – das bedeutet, dass für die Fakten nie eine Historie erstellt wird (z. B. bei sensor- oder maschinenerzeugten Daten). Da sich die beschreibenden Daten nicht ändern können, müssen sie nicht in einem Satellite gespeichert werden, sondern werden direkt in den Non-Historized Links gehalten.

Aus Performance-Gründen sollten Granularitätsverschiebungen beim Auslesen vermieden werden. Wenn eine andere Zielgranularität erforderlich ist und es nicht möglich ist, diese Granularität aus dem Quellsystem oder aus dem Data Vault Modell zu laden, sollten Sie eine Bridge Table in Betracht ziehen. Der Zweck dieses Entitätstyps besteht darin, die Granularitätsverschiebung zu materialisieren und dabei den Vorteil zu behalten, das Ziel gemäß den individuellen Anforderungen des dimensionalen Ziels anzupassen.

So verwenden Sie Non-Historized Links

Abbildung: Virtuelle Bridge Table als Faktentabelle mit GROUP BY Store Hash Key

Fazit

Non-Historized Links bieten einen effizienten Ansatz zur Data Vault Modellierung, der die Performance optimiert und Datenstrukturen vereinfacht. Indem sie sich auf aktuelle Beziehungen statt auf historische Änderungen konzentrieren, steigern sie die Effizienz, reduzieren den Speicherbedarf und verbessern die Abfragegeschwindigkeit. Die Integration in Ihre Datenarchitektur kann zu einer agileren und skalierbareren Analyseumgebung führen.

Close Menu