Data Vault-Modellierungsdesign-Anwendungen

Data Vault ist ein Designparadigma und keine Technologie. Es kann für jede relationale Datenbank oder jeden Data Lake verwendet werden. Es entstand aus dem Wunsch heraus, eine bessere Methode zur Datenspeicherung zu finden und von den in Data Warehouses häufig verwendeten Stern-/Sternhaufen-/Konstellations- und Schneeflockenschemata (nicht von der DB-Firma) wegzukommen.

Dabei bietet es jedoch ein anderes Muster, das Endbenutzer tatsächlich ausschließt oder zumindest einschränkt. Es kann schwierig sein, Endbenutzer abzufragen, und die Organisation der Entitäten ist nicht intuitiv. Es kann ein Warehouse oder einen Betriebsdatenspeicher ersetzen, wenn die primäre Zielgruppe Ingenieure und nicht Endbenutzer sind. Es ist definitiv kein Data Mart-Ersatz.

Warum sollte man sich davon abwenden? Funktionieren sie nicht? Wie so oft in der Technologiebranche hängt die Frage, ob sie funktionieren oder nicht, vom Anwendungsfall ab. Für welchen Zweck und welche Funktion soll das Produkt eingesetzt werden? Die Akteure, die in den Rollen von Konsumenten und Produzenten agieren, bestimmen im Allgemeinen die Parameter des Anwendungsfalls, d. h., wo der Fokus und die Grenzen liegen.

Bei den oben genannten Varianten von Sternschemata liegt der Fokus auf den Endbenutzern. Sie greifen entweder ad hoc mithilfe interaktiver Tools und Abfragen auf die Daten zu oder nutzen die erstellten Berichte. Zur Veranschaulichung des obigen Schemas habe ich unten ein einfaches Sterndiagramm dargestellt. Die drei oberen Tabellen enthalten die Quelldaten des Sternschemas und sind grün hervorgehoben.

Die Variationen sind im folgenden Diagramm dargestellt, mit Ausnahme von Snowflake. Snowflake fügt grundsätzlich dimensionslose Referenztabellen hinzu, die sich in den meisten Fällen auf Dimensionen beziehen. Beispielsweise verschiedene Typtabellen zur Kategorisierung von Daten innerhalb von Dimensionen. Denken Sie an die Transportarten (Luft, Land, See) und deren jeweilige Merkmale.

Stern: Eine Tatsache mit vielen Dimensionen

Typical Star Schema Pattern

Sternhaufen - Mehrere Fakten mit Dimensionen

Depiction of Potential Star Cluster Pattern

Sternbild: Viele Fakten und Dimensionen

Multiple related Facts and Dimensions

Wie Sie wahrscheinlich erraten können, konzentrieren sich alle drei Designs auf die Erstellung und Bereitstellung von Analysen für Verbraucher, sei es als interaktives Tool mit Abfragen oder Berichten.

Aus Sicht des Endbenutzers erfolgt im Hintergrund eine umfangreiche Datenqualitätsprüfung und -transformation, um Daten in die Dimensionstabellen (Dim) schreiben zu können. Dies geschieht, bevor Sie mit der Befüllung der Faktentabellen (Facts) mit Analysen beginnen.

Da alle Dimensionen und Fakten „dumme“ oder Surrogatschlüssel verwenden, was im Mart- und Warehouse-Design weitgehend Standard ist, besteht die Möglichkeit der Duplikatbildung. Dies liegt daran, dass es Anwendungsfälle gibt, in denen Duplikate zulässig sind, und das Surrogatschlüssel-Entwurfsmuster berücksichtigt dies. Dies ist besonders nützlich bei der Verwendung von Zeitreihendaten, da Zeitstempelwerte zwar identisch sein können, sich aber durch die Reihenfolge unterscheiden.

Datenqualität

Datenqualitätskontrollen müssen präzise sein, sonst können Ihre Daten leicht verzerrt werden. Wenn Sie ML-Modelle mit verzerrten Daten ausführen, driften diese und liefern nicht die gewünschten Ergebnisse. Übermäßiges Driften deutet in der Regel auf Probleme mit der Datenqualität oder der Sensibilität des ML-Modells hin. Dies ist zumindest teilweise ein Vorteil der Verwendung von Data-Vault-Designmustern: Es verhindert Duplikate und stellt die Eindeutigkeit bestimmter Datenklassifizierungen sicher, um den Aufwand für die Datenqualität zu reduzieren. Theoretisch sollte dies zusätzlich dazu beitragen, das Driftproblem zu vermeiden.

Es handelt sich nur um einen Aspekt, die Eindeutigkeit, und die Validierung des Dateninhalts wird nicht speziell behandelt. Wenn beispielsweise eine Spalte nur Werte mit neun alphanumerischen Zeichen enthalten darf, ist eine Validierung erforderlich, oder wenn eine Spalte auf eine Werteliste beschränkt ist, ist dennoch eine Überprüfung erforderlich. Die gängigsten Arten der Datenqualitätsvalidierung (IMO) sind die Überprüfung von Spaltenwerten aufgrund von Einschränkungen. Länge, Datentyp, Wortanzahl usw. Wenn Ihre Datenquellen ausschließlich aus relationalen Datenbanken mit Spaltenbeschränkungen bestehen, erleichtert dies die Datenqualitätsprüfung erheblich. Dies kommt jedoch nur sehr selten vor.

Daten stammen aus strukturierten, halbstrukturierten und unstrukturierten Formaten. Man könnte also sagen, dass Prüfprogramme eine lange Lebensdauer vor sich haben. Die Verwendung regulärer Ausdrücke (kurz: Regex) in verschiedenen Formen, von Python-Skripten bis hin zu SQL, ist für diejenigen, die eine eigene Lösung erstellen müssen, weit verbreitet. Es gibt verschiedene Python-Frameworks und -Programme zur Datenvalidierung, wie beispielsweise pydantic und cerberus, um nur einige zu nennen. Im Laufe der Jahre gab es viele Datenqualitätstools, aber sie scheinen sich aufgrund ihrer hohen Preise nicht mehr durchsetzen zu können und wurden daher von viel größeren Unternehmen aufgekauft und in deren Produkte integriert. Informatica , IBM , SAS und Ab Initio haben in den letzten zwei Jahrzehnten Datenqualitäts- und Business-Intelligence-Produkte erworben.

Data Quality Remediation

Die anderen häufigsten Datenqualitätsprüfungen sind die Datensatzzählung. Dabei wird im Wesentlichen geprüft, ob die Ein- und Ausgaben beim Laden übereinstimmen. Dies ist eine der wenigen allgemeinen Datenqualitätsprüfungen, die Sie durchführen können, da spezifische Zählungen nach der Datentransformation verloren gehen. Sie benötigen ein Profil des Input-/Output-Verhältnisses für die Transformation, um den möglichen Zählbereich der Transformationsergebnisse berechnen zu können. Wie bereits erwähnt, war die Datenqualität ein Faktor bei der Entwicklung von Data Vault, es gibt jedoch noch weitere.

Datentresor

Sein Entwickler Dan Linstedt beschreibt es als „einen detailorientierten, historischen und eindeutig verknüpften Satz normalisierter Tabellen, der einen oder mehrere Funktionsbereiche unterstützt. Es handelt sich um einen hybriden Ansatz, der die besten Eigenschaften der dritten Normalform (3NF) und des Sternschemas vereint.“ Laut Dan Linstedt ist es von einer vereinfachten Sichtweise auf Neuronen, Dendriten und Synapsen inspiriert.

Data Vault bietet zahlreiche Vorteile, darunter die Schlüsselorientierung aller Beziehungen und die Skalierbarkeit des Entwurfsmusters auf Datenbanken mit mehreren Petabyte (PB). Data Vault ist ein Beispiel für Ankermodellierung, einen agilen Ansatz zur Datenmodellierung. Dadurch können Änderungen erfasst werden, ohne dass das bestehende Modell dadurch stark beeinträchtigt wird. Data Vault ist zudem geschäftsprozessorientiert, was idealerweise auch für ein Sternschema und seine Varianten gilt.

Die Modellierungsmethodik ähnelt der Erstellung von Entity-Relationship-Datenmodellen: Erstellen Sie ein logisches Modell, das den Geschäftsprozess und die darin enthaltenen Datenelemente darstellt. Data Vault ist ein hochgradig normalisierter Ansatz zur Erstellung eines entitätsbasierten Modells. Dies bietet hohe Flexibilität, da Datenelemente im gesamten Schema nicht wiederholt werden.

Ein weiterer Vorteil dieser Modellierungsmethode ist die vollständige Prüfbarkeit und Rückverfolgbarkeit. Sie ist außerdem SEI CMM Level 5-konform (wiederholbare, konsistente, redundante Architektur) und liefert Modelle, die Sarbanes-Oxley, HIPPA und BASIL II entsprechen.

Data Vault Hubs, Satellites, and Links

Was genau ist Data Vault? Data Vault ist eine Sammlung von Hubs, Satelliten und Links, die den in der Phase des logischen Datenmodells modellierten Geschäftsprozess abbilden (Voraussetzung). Es sollte repräsentativ für die Bereiche sein, in denen Sie arbeiten; ein hypothetischer Geschäftsfall ist unten dargestellt. Die besten Anwendungsfälle sind operative Datenspeicher oder Data Warehouses; sie sind kein Ersatz für Sternschemata.

Unten sehen Sie einen hypothetischen Datenfluss eines Vermögensverwalters, der mit Aktien, Anleihen, Futures, Optionen usw. handelt. Da ein Teil des Finanzhandels mittlerweile rund um die Uhr und zu einem erheblichen Teil algorithmisch abläuft, handelt es sich bei dem „Händler“ im Diagramm in diesen Fällen tatsächlich um eine Software. Broker und Market Maker können eine einzige Partei (ein Unternehmen) sein, und an großen institutionellen Geschäften können mehrere Depotbanken beteiligt sein.

Gelegentlich fungiert eine Depotbank als Drittpartei, deren einziger Zweck darin besteht, Gelder zwischen zwei oder mehr Depotbanken weiterzuleiten. Dies ist häufig auf internationalen Märkten der Fall. Diese Nuancen führen lediglich zu weiteren Handelsparteien, ändern aber nicht den Prozess an sich.

Asset Manager Trade Flow

Das Folgende stellt ein attributiertes logisches Datenmodell dar, basierend auf dem obigen Datenflussdiagramm. Ich habe allgemeine Attribute hinzugefügt, die mir auffallen. Normalerweise würden diese jedoch zusätzliche Elemente enthalten, die das Modell verfeinern, in diesem Beispiel aber zu Unklarheiten führen könnten. Daher habe ich sie weggelassen.

Trade Logical Data Model (LDM)

Nachfolgend wird die Übersetzung des obigen LDM in ein physisches Datentresorformat beschrieben. Normalerweise erfolgt die physische Übersetzung des LDM mit einer sehr ähnlichen Entität-Tabelle -Konvertierung, außer in Fällen, in denen n:n-logische Beziehungen physisch mit einer assoziativen Tabelle implementiert werden müssen. Auch hier kann es zu einer Denormalisierung im physischen Format kommen, diese Phase ist jedoch in der Regel das Ergebnis von Testzyklen, die Leistungsprobleme aufdecken. Kein Wortspiel beabsichtigt, aber Denormalisierung ist keine gängige Praxis – man beginnt nicht direkt damit; sie ist reaktiv oder folgt einem etablierten Muster.

Die Data-Vault-Implementierung eines physischen Modells unterscheidet sich stark vom LDM. Sie werden feststellen, dass sie nicht wie ein Sternschema oder eines seiner Derivate aussieht.

Trading Data Vault Example Schema

Es gibt einige Kernkonzepte, denen Data Vault im Entwurfsmuster folgt:

• Data-Vault-Designs sind kein Ersatz für OLAP, das in Sternschemata und den Derivaten implementiert ist, und auch nicht für OLTP, deren „Sweet Spot“ als Data Warehouse oder operativer Datenspeicher. Es handelt sich eher um eine Art Hybrid.

• Es ist für die Speicherung und nicht für benutzergesteuerte Abfragen optimiert, was teilweise auf die strikte Einhaltung der dritten Normalform (3NF) zurückzuführen ist.

• Drei Entitätstypen bestehend aus Hub, Satellit und Links. Sie können Referenztabellen haben, die statische Satelliten unterstützen, z. B. Länder- oder Währungstabellen, Postleitzahlen, Maße und Gewichte.

• Hubs sind Tabellen mit wenigen Datenänderungen. Sie sollten einen Geschäftsschlüssel enthalten. Man kann sie sich in gewisser Weise als eine Art langsam veränderliche Dimension vorstellen.

• Links sind Assoziationen zwischen Geschäftsschlüsseln, die in der Regel, aber nicht immer, Hubs sind. Es handelt sich um eine assoziative Entität, die Beziehungen zwischen den Schlüsseln auflöst.

• Satelliten dienen für zeitliche und beschreibende Attribute, wie z. B. Datums-/Uhrzeitdaten, ähnlich wie Transaktionsinhalte. Satelliten können Beziehungen zu anderen Satelliten, Referenzdaten und Links zu Hubs haben.

• Zwischen Hubs bestehen Links, wobei die Link-Tabelle die Primärschlüssel der Hubs enthält. Hubs können Satelliten als untergeordnete Elemente haben.

• Links können Satelliten als untergeordnete Elemente haben, jedoch nicht als übergeordnete Elemente. Der Primärschlüssel des Links wird vom Satelliten übernommen.

• Jede Tabelle verfügt über ein Ladedatum und eine Datensatzquelle für jede Zeile. Sie sollten einen eindeutigen Schlüssel erzeugen, wenn sie zum „natürlichen“ oder „geschäftlichen“ Schlüssel einer Tabelle hinzugefügt werden. Für Tabellen ohne „natürlichen“ Schlüssel können Sie den Ersatzschlüssel verwenden. Verwenden Sie eindeutige Schlüsseleinschränkungen oder eindeutige Schlüsselindizes, um diese Einschränkung zu erzwingen (letzteres ist mein Beitrag), vorausgesetzt, Sie verwenden ein relationales DBMS.

• Wenn Sie das Modell in einem Datalake implementieren, in dem es keine Constraints oder Indizes gibt, können Sie stattdessen Partitionsdefinitionen verwenden und die entsprechende Logik natürlich in Ihren Code integrieren. Es sei denn, Sie schreiben für Apache Iceberg, wo Constraints in der Metadatenebene implementiert werden können.

• Abhängig von der von Ihnen verwendeten Dokumentdatenbank können Sie auch Einschränkungen verwenden.

Vorgehensweisen beim Laden von Daten

Die Reihenfolge beim Laden der Tabellen ist wichtig, insbesondere bei der Verwendung von Schlüsseln/Indizes. Zuerst werden die Hubs geladen, was parallel erfolgen kann, um neue Ersatzschlüssel zu erstellen. Im nächsten Schritt werden die Links geladen, wobei beliebige Attributwerte geladen und Verknüpfungen zwischen den Hubs hergestellt werden. Zuletzt folgen die Satelliten, die die Links oder Hubs empfangen und parallel zueinander geladen werden können.

Um die Eindeutigkeit von Datensätzen zu gewährleisten, beachten Sie bitte die 3NF-Funktion. Hashing wird häufig im Rahmen der ETL/ELT-Verarbeitung verwendet, um den Hash des eingehenden Datensatzes mit den Hashes der aktuell in der Tabelle vorhandenen Datensätze zu vergleichen. Datensätze werden niemals aus dem Datentresor gelöscht.

Anwendungsfälle Die wichtigsten Anwendungsfälle für Data-Vault-Designs sind Operational Data Stores (ODS) und Enterprise Data Warehouses (EDW). Beide Anwendungsfälle eignen sich aufgrund mehrerer Faktoren gut:

• Bei der strikten Einhaltung der dritten Normalform (3NF) werden Felder in Tabellen weder denormalisiert noch dupliziert, was zu einer äußerst effizienten Speichernutzung führt.

• Beim Ladevorgang werden Prüfungen auf Dateneindeutigkeit durchgeführt. Mithilfe von Hashes wird bestätigt, ob der jeweilige Datensatz bereits gespeichert wurde. Dadurch wird eine Duplizierung von Datensätzen vermieden. Dies reduziert auch den Speicherplatzbedarf.

• Abfragen für Endbenutzer können schwierig sein. Für die Abfrage der Tabellen in einem Data-Vault-Design benötigen Sie im Vergleich zu typischen Endbenutzern fortgeschrittenere SQL-Kenntnisse. Der Datenzugriff ist eher für Ingenieure geeignet und daher nicht benutzerfreundlich. Wenn Sie die Daten Endbenutzern zugänglich machen möchten, können Sie in herkömmlichen RDBMS Ansichten erstellen, um deren Zugriff zu vereinfachen.

• Weniger gespeicherte Datensätze bedeuten, dass weniger Daten durch Abfragen gescannt werden. Daher ist die Abrufzeit für die Ausgabe mit einer effizienten Abfrage im Vergleich zu einer denormalisierten Struktur kürzer.

• Das Tabellendesign ist eher für Ingenieure geeignet. Es konzentriert sich strikt auf Normalisierung und Strukturen, die eher eine effiziente Datenspeicherung als einen Geschäftsprozessfluss widerspiegeln.

Ich denke, das Data-Vault-Designmuster hat definitiv seine Berechtigung, insbesondere in Fällen, in denen Sie buchstäblich die größtmögliche Datenmenge speichern möchten. Sei es in einem Datalake oder einem RDBMS. Es ist wahrscheinlich die effektivste Lösung für dieses Problem im Vergleich zu jedem Sternschema oder dessen Derivat. Der ODS-Fall umfasst in der Regel Daten von einer Woche bis zu mehreren Monaten und ist auch hierfür gut geeignet, da die Normalisierung rundum hilfreich ist. Diese speziellen Anwendungen sind eine Evaluierung wert.