Im vorherigen Artikel habe ich über die Grundlagen von DATA VAULT gesprochen und die Hauptelemente von DATA VAULT und ihren Zweck beschrieben. An dieser Stelle kann das Thema DATA VAULT nicht als erschöpft betrachtet werden, es ist notwendig, über die nächsten Schritte in der Entwicklung von DATA VAULT zu sprechen.
Und in diesem Artikel werde ich mich auf die Entwicklung von DATA VAULT und den Übergang zu BUSINESS DATA VAULT oder einfach BUSINESS VAULT konzentrieren.
Gründe für die Entstehung des BUSINESS DATA VAULT
Es sollte beachtet werden, dass DATA VAULT trotz seiner gewissen Stärken nicht ohne Mängel ist. Einer dieser Nachteile ist die Schwierigkeit, analytische Abfragen zu schreiben. Abfragen haben eine beträchtliche Anzahl von JOINs, der Code ist lang und umständlich. Außerdem unterliegen die Daten, die in den DATA VAULT gelangen, keiner Transformation, daher hat DATA VAULT in seiner reinen Form aus geschäftlicher Sicht keinen unbedingten Wert.
Um diese Mängel zu beseitigen, wurde die DATA VAULT-Methodik um Elemente erweitert wie:
- PIT-Tabellen (Point-in-Time);
- BRIDGE-Tische;
- VORDEFINIERTE ABLEITUNGEN.
Schauen wir uns den Zweck dieser Elemente genauer an.
PIT-Tabellen
In der Regel kann ein Geschäftsobjekt (HUB) Daten mit unterschiedlichen Aktualisierungsraten enthalten. Wenn es sich beispielsweise um Daten handelt, die eine Person charakterisieren, können wir sagen, dass Informationen zu einer Telefonnummer, Adresse oder E-Mail eine höhere Aktualisierungsrate aufweisen als B. vollständiger Name, Passdaten, Familienstand oder Geschlecht.
Daher sollte man bei der Bestimmung von Satelliten die Häufigkeit ihrer Erneuerung berücksichtigen. Warum ist es wichtig?
Wenn Sie Attribute mit unterschiedlichen Aktualisierungsraten in derselben Tabelle speichern, müssen Sie der Tabelle jedes Mal eine Zeile hinzufügen, wenn das am häufigsten geänderte Attribut aktualisiert wird. Dadurch erhöht sich der Speicherplatz und die Ausführungszeit von Abfragen.
Nachdem wir die Satelliten nun nach Aktualisierungsrate getrennt haben und Daten unabhängig voneinander in sie laden können, müssen wir sicherstellen, dass wir aktuelle Daten erhalten. Besser ohne unnötige JOINs zu verwenden.
Lassen Sie mich zum Beispiel erklären, dass Sie aktuelle Informationen (bis zum Datum der letzten Aktualisierung) von Satelliten mit unterschiedlichen Aktualisierungsraten erhalten müssen. Dazu müssen Sie nicht nur einen JOIN durchführen, sondern auch mehrere verschachtelte Abfragen (für jeden Satelliten, der Informationen enthält) mit der Auswahl des maximalen Aktualisierungsdatums MAX (Aktualisierungsdatum) erstellen. Mit jedem neuen JOIN wächst dieser Code und wird sehr schnell schwer zu verstehen.
Die PIT-Tabelle soll solche Abfragen vereinfachen. PIT-Tabellen werden gleichzeitig mit dem Schreiben neuer Daten in den DATA VAULT gefüllt. PIT-Tabelle:
Somit verfügen wir über Informationen über die Relevanz der Daten aller Satelliten zu jedem Zeitpunkt. Mithilfe von JOINs auf der PIT-Tabelle können wir verschachtelte Abfragen vollständig eliminieren, natürlich unter der Bedingung, dass die PIT täglich und lückenlos gefüllt wird. Selbst wenn es Lücken im PIT gibt, können Sie aktuelle Daten nur mit einer einzigen verschachtelten Abfrage an den PIT selbst erhalten. Eine verschachtelte Abfrage funktioniert schneller als verschachtelte Abfragen für jeden Satelliten.
BRIDGE
BRIDGE-Tabellen werden auch verwendet, um analytische Abfragen zu vereinfachen. Der Unterschied zu PIT besteht jedoch darin, dass Anfragen zwischen verschiedenen Hubs, Links und ihren Satelliten vereinfacht und beschleunigt werden.
Die Tabelle enthält alle notwendigen Schlüssel für alle Satelliten, die häufig in Abfragen verwendet werden. Darüber hinaus können gehashte Geschäftsschlüssel bei Bedarf durch Schlüssel in Textform ergänzt werden, wenn die Namen der Schlüssel für die Analyse benötigt werden.
Tatsache ist, dass ohne die Verwendung von BRIDGE beim Abrufen von Daten, die sich in Satelliten befinden, die zu verschiedenen Hubs gehören, nicht nur die Satelliten selbst, sondern auch die Verbindungen, die die Hubs verbinden, verbunden werden müssen.
Das Vorhandensein oder Fehlen von BRIDGE wird durch die Speicherkonfiguration und die Notwendigkeit bestimmt, die Geschwindigkeit der Abfrageausführung zu optimieren. Es ist schwierig, ein universelles Beispiel für BRIGE zu finden.
VORDEFINIERTE ABLEITUNGEN
Eine andere Art von Objekten, die uns dem BUSINESS DATA VAULT näher bringt, sind Tabellen mit vorberechneten Indikatoren. Solche Tabellen sind für Unternehmen wirklich wichtig, sie enthalten Informationen, die nach vorgegebenen Regeln aggregiert sind, und ermöglichen einen relativ einfachen Zugriff darauf.
Architektonisch sind VORDEFINIERTE DERIVATIONEN nichts anderes als ein weiterer Satellit eines bestimmten Hubs. Es enthält wie ein normaler Satellit einen Geschäftsschlüssel und das Datum, an dem der Datensatz im Satelliten erstellt wurde. Hier enden jedoch die Ähnlichkeiten. Die weitere Zusammensetzung der Attribute eines solchen „spezialisierten“ Satelliten wird von Geschäftsanwendern anhand der gängigsten, vorberechneten Indikatoren bestimmt.
Beispielsweise kann ein Hub, der Informationen über einen Mitarbeiter enthält, einen Satelliten mit Indikatoren umfassen wie:
- Mindestlohn;
- Maximales Gehalt;
- Durchschnittsgehalt;
- Kumulierte Summe der aufgelaufenen Löhne usw.
Es ist logisch, VORDEFINIERTE ABLEITUNGEN in die PIT-Tabelle desselben Hubs aufzunehmen, dann können Sie ganz einfach Mitarbeiterdaten-Slices für ein bestimmtes Datum abrufen.
FAZIT
Wie die Praxis zeigt, ist die Nutzung von DATA VAULT durch Geschäftsanwender aus mehreren Gründen etwas schwierig:
- Der Abfragecode ist komplex und umständlich;
- Die Fülle an JOINs wirkt sich auf die Abfrageleistung aus;
- Das Verfassen analytischer Abfragen erfordert hervorragende Kenntnisse der Lagerstruktur.
Um den Datenzugriff zu vereinfachen, wird DATA VAULT um zusätzliche Objekte erweitert:
- PIT-Tabellen (Point-in-Time);
- BRIDGE-Tische;
- VORDEFINIERTE ABLEITUNGEN.
Nächste Ich habe vor, meiner Meinung nach das Interessanteste für diejenigen zu erzählen, die mit BI arbeiten. Ich werde Möglichkeiten zum Erstellen von Tabellen – Fakten und Tabellen – Dimensionen basierend auf DATA VAULT vorstellen.
Die Materialien des Artikels basieren auf:
- Auf Kenta Graziano, das neben einer detaillierten Beschreibung auch Modelldiagramme enthält;
- Buch: „Aufbau eines skalierbaren Data Warehouse mit DATA VAULT 2.0“;
- Artikel .
Source: habr.com