Die Data Vault 2.0-Methodik verwendet nicht nur Modellierungstechniken, sondern bietet eine vollständige Methodik für alle Data Warehouse-Projekte. Indellient sieht die Data Vault-Modellierung als einen sehr praktikablen Ansatz, um die Anforderungen von Data-Warehousing-Projekten zu erfüllen, bei denen sowohl die historische Verfolgung als auch die Überprüfbarkeit zwei wichtige Faktoren sind.

Seit vielen Jahren arbeiten Business Intelligence (BI)-Projekte nach einem Wasserfallmodell. Es wird durch eine lang gestreckte Abfolge jeder Phase definiert, die eine erschöpfende Liste von Upfront-Anforderungen erfordert, ein vollständiges Datenmodelldesign, gefolgt von der Kodifizierung aller harten und weichen Geschäftsregeln in ETL-Prozesse. Die Visualisierungsebene wird nacheinander erstellt und den Endbenutzern für die Abmeldung präsentiert – Monate oder sogar Jahre ab dem ursprünglichen Startdatum.

Ziemlich oft sehen wir auch, dass Teams eine „Reduced Scope“ -Version von Waterfall übernehmen, die darauf abzielt, große BI-Initiativen in kleinere Projekte aufzuteilen. Dies trägt zwar zur Verringerung der Gesamtkomplexität bei, ist jedoch bei Anwendung auf BI aus zwei Hauptgründen immer noch recht riskant:

  • die Geschäftsanforderungen ändern sich jetzt schneller als die Lieferfähigkeit;
  • und Budgetinhaber sind nicht bereit, in langfristige Projekte ohne kurzfristige Ergebnisse zu investieren.

Aus den oben genannten Gründen haben wir eine Verschiebung der Projektmethoden vom Wasserfall zum iterativen, flinken Ansatz von Agile festgestellt, der diese Probleme erkennt und einige Antworten darauf gibt.

Im Bereich der Datenanalyse adressiert Agile allein nicht die erheblichen Herausforderungen, denen wir auf den detaillierteren Ebenen von Data Warehousing- oder BI-Projekten begegnen. Dazu gehören:

  • Iteration über die Datenmodellierung
  • Minimierung des Refactorings
  • Entwurf von ETL- oder ELT-Routinen, die eine schnelle Reaktion auf Änderungen der Geschäftslogik oder Neuzugänge von Daten ermöglichen
  • ein Ansatz zur Erfassung von Geschäftsanforderungen, der eng mit dem für Designentscheidungen erforderlichen Input verknüpft ist

Als Reaktion auf diese Herausforderungen, Daniel Linstedt, Autor von Building Scalable Data Warehouse mit Data Vault 2.0, definiert eine Methodik, die sich darauf konzentriert, das Beste aus agilen Praktiken mit anderen bewährten Disziplinen und Techniken herauszuholen, um den bisher iterativsten Ansatz für BI zu liefern.

Einführung in Data Vault

Entgegen der landläufigen Meinung ist Data Vault (DV) nicht nur eine Modellierungstechnik, sondern eine gesamte Methodik für Data Warehouse-Projekte. Es verbindet Aspekte von Agile, BEAM Requirements Gathering, CMMI, TQM, Six Sigma und Data Vault Modelling, um einen Ansatz zu definieren, der darauf abzielt, sowohl die Geschwindigkeit als auch die Qualität von BI-Projekten zu verbessern. Ich bezeichne es als „Lenkwaffenansatz“, da es sowohl die Anpassung als auch die Genauigkeit fördert.

DV umfasst auch agile Methoden zur DW-Projektschätzung und agile Task Sizing, um die traditionell übersehene Komplexität oder den Arbeitsaufwand für die gemeinsamen DW-Komponenten zu bestimmen. Auf den unteren Ebenen bietet es auch einen sehr prägnanten und iterativen Ansatz zur Bewältigung gemeinsamer technischer Ergebnisse (innerhalb der BI-Welt) mit neuen oder sich ändernden Funktionsanforderungen. Dazu gehören durchdachte, wiederholbare, schrittweise und agile Prozesse, um häufige Aufgaben zu erledigen.

Diese Aufgaben umfassen (sind aber nicht beschränkt auf) das Hinzufügen von Datenattributen, Slices, neuen Quellen, erweiterten Quellen, historischer Verfolgung, veralteten Quellen und Quellstrukturänderungen sowohl in der ETL- als auch in der Modellierungsphase.

Das DV-Modell ist kurz gesagt eine Ebene zwischen der regulären dimensionalen Modellierung (OLAP, Sternschema) und dem Staging, die eine Skalierung mit wachsenden Geschäftsanforderungen ermöglicht und dazu dient, die Komplexität sowohl der Modellierung als auch der ETL abzubauen. Es besteht aus Hubs (Geschäftseinheiten), Links (Beziehungen) und Satelliten (beschreibende Attribute), die irgendwo zwischen dem 3NF- und dem Star-Schema modelliert sind. Das Modell befindet sich in der Datenintegrationsschicht des Data Warehouse, die allgemein als Rohdatentresor bezeichnet wird, und wird effektiv in Kombination mit dem Kimball-Modell verwendet.

Tipp: Wenn Sie daran interessiert sind, das Modell und seine Unterstreichungsregeln zu verstehen, schlage ich vor, sich eine Kopie von Dans oben erwähntem Buch zu schnappen.

Datentresor 2.0 Vorteile

Hier finden Sie einen Überblick über einige wichtige Vorteile des Data Vault 2.0-Ansatzes:

  • Es wird das Worst-Case-Szenario für Datenmodellierungsbeziehungen angenommen. N: M-Beziehungen zwischen Geschäftsobjekten, um Aktualisierungen zu vermeiden, wenn aus einem 1: M ein M: M wird. Dadurch ist praktisch keine zusätzliche Arbeit in Data Vault erforderlich, wenn sich der Grad der Beziehung ändert.
  • Es dient zur historischen Verfolgung aller Aspekte von Daten – Beziehungen und Attributen sowie der Herkunft der Daten im Laufe der Zeit. Satelliten, deren Abmessungen ähnlich sind, arbeiten ähnlich wie SCD Typ 2.
  • Legt eine Reihe von Entwurfsprinzipien & Strukturen zur Erhöhung der historischen Verfolgungsleistung innerhalb des Gewölbes (Grube und Brücke) fest. Das Data Vault-Modell ist flexibel genug, um diese Strukturen zu jedem Zeitpunkt innerhalb des iterativen Modellierungsprozesses zu übernehmen, und erfordert keine erweiterte Planung.
  • Wurde entwickelt, um Leerzeichen, die Rohdaten und geänderte Daten enthalten, logisch zu trennen. Raw Data Vault ist die Grundlage für Daten, die für Quellsysteme überprüfbar sind, und der Business Vault bietet einen Platz für Power-User, die einen Schritt weiter vom Information Mart entfernt Zugriff auf Daten benötigen.
  • Trennt weiche und harte Geschäftsregeln in verschiedene Teile der Datenintegration. Dies erzwingt die Wiederverwendbarkeit von Daten über mehrere Endanwendungen hinweg. Beispielsweise werden Rohdaten nur einmal innerhalb des Data Vault bezogen (weniger Reintegration in das Staging) und können mehrmals an nachgelagerte Anforderungen weitergeleitet werden.
  • Für jede agile Iteration ist das Data Vault-Modell, in dem die gesamte historische Verfolgung von Daten gespeichert ist, leicht erweiterbar, ohne dass Sie sich Gedanken über den Verlust historischer Daten machen müssen. Außerdem wird die historische Verfolgung unabhängig vom Dimensionsmodell gespeichert.
  • Data Vault 2.0 befürwortet die Hash-Key-Implementierung von Geschäftsschlüsseln, um Lookups zu reduzieren und somit die Parallelisierung des Ladens zu erhöhen. Dies führt zu weniger sequentiellen Ladeabhängigkeiten.
  • Der Rohdaten-Tresor ist so konzipiert, dass er vollständig auditierbar ist.
  • Insgesamt wird die Verarbeitung, die mit dem Übergang vom Staging zum Star Schema & OLAP verbunden ist, mit Data Vault viel reibungsloser & iterativ gestaltet.
  • Es bietet einen sehr durchdachten Ansatz zum Kombinieren von Daten mit mehreren verschiedenen Geschäftsschlüsseln aus heterogenen Datenquellen (ein häufiges Problem bei der Integration von Daten innerhalb des Lagers über mehrere Quellsysteme hinweg). Geschäftsschlüssel sind nicht immer 1:1 oder im gleichen Format.
  • Die „just in time“-Modellierungsmentalität passt gut zum agilen Ansatz.

Die Nachteile

Data Vault bietet zwar viele Vorteile, weist jedoch auch Mängel auf, wie z:

  • Data Vault ist im Wesentlichen eine Schicht zwischen dem Information Mart / Star-Schema und dem Staging. Es gibt einige zusätzliche Overhead, der mit der Entwicklung dieser Schicht sowohl in Bezug auf die ETL-Entwicklung und Modellierung kommt. Wenn das Projekt klein ist oder die Lebensdauer des Projekts nur von kurzer Dauer ist, lohnt es sich möglicherweise nicht, ein Data Vault-Modell zu verfolgen.
  • Einer der Hauptgründe für die Verwendung von Data Vault ist sowohl für Audit- als auch für historische Nachverfolgungszwecke. Wenn keine davon für Sie oder Ihre Organisation wichtig ist, kann es schwierig sein, den Overhead zu verbrauchen, der für die Einführung einer weiteren Ebene in Ihre Modellierung erforderlich ist. Wenn man jedoch von langfristigen Anforderungen spricht, kann es eine lohnende Investition im Voraus sein.
  • Data Vault stellt einen zerlegten Ansatz für Beziehungen, Geschäftsschlüssel und Attribute dar, und daher ist die Anzahl der erstellten Tabellen im Vergleich zu denormalisierten Strukturen wie dem Sternschema hoch. Beachten Sie jedoch, dass Data Vault das Sternschema ergänzt, sodass dieser Vergleich nur zu kontrastierenden Zwecken dient. Aus diesem Grund sind viele Verknüpfungen erforderlich, um Daten innerhalb des DV anzuzeigen.
  • Zum Zeitpunkt des Schreibens dieser – DV-Ressourcen sind begrenzt. Komplexe Projekte mit DV 2.0 sind keine weit verbreiteten Informationen.
  • Der Modellierungsansatz kann im Allgemeinen sehr unkonventionell für diejenigen sein, die unter Kimball und (weniger) Inmons Modellen operiert haben.

Sollten Sie Data Vault verfolgen?

Die Antwort hängt von einigen Variablen ab.

Wir sehen die Data Vault-Modellierung als einen sehr praktikablen Ansatz, um die Anforderungen von Data Warehousing-Projekten zu erfüllen, bei denen sowohl die historische Verfolgung als auch die Überprüfbarkeit zwei wichtige Faktoren sind.

Wenn sich die Beziehungen zwischen Geschäftseinheiten in Ihren Daten ständig weiterentwickeln (Beispiel 1: M bis M:M), vereinfacht Data Vault die Erfassung dieser Beziehungen und ermöglicht es Ihnen, sich mehr auf die Bereitstellung von echtem Wert zu konzentrieren.

Wenn Ihre Organisation plant, PII-Daten im Lager zu speichern und der DSGVO, HIPPA oder anderen Vorschriften unterliegt, hilft Data Vault bei Datenaudits und Rückverfolgbarkeit.

Es ist wichtig, sowohl die oben aufgeführten Vor- als auch Nachteile zu berücksichtigen, um zu entscheiden, ob ein Data Vault-Ansatz für Ihren Anwendungsfall vorteilhaft ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

lg