Zum Hauptinhalt springen
Suche
0

Ein Problem bei der Abfrage der Daten aus dem Raw Data Vault tritt auf, wenn sich mehrere Satelliten an einem Hub oder einer Verbindung befinden:

Abbildung 1: Data Vault-Modell einschließlich PIT (logisch)

Im obigen Beispiel gibt es mehrere Satelliten auf dem Hub Customer und Link, die im Diagramm enthalten sind. Dies ist eine sehr häufige Situation für data warehouse-Lösungen, da sie Daten aus mehreren Quellsystemen integrieren. Allerdings erhöht diese Situation die Komplexität bei der Abfrage der Daten aus dem Raw Data Vault. Das Problem entsteht, weil die Änderungen an den in den Quellsystemen gespeicherten Geschäftsobjekten nicht gleichzeitig erfolgen. Stattdessen wird ein Geschäftsobjekt, z. B. ein Kunde (eine versicherte Person), zu einem bestimmten Zeitpunkt in einem der vielen Quellsysteme aktualisiert, dann zu einem anderen Zeitpunkt in einem anderen System, usw. Beachten Sie, dass die PIT-Tabelle bereits mit dem Hub verbunden ist, wie durch das Band angezeigt wird. Die Änderungen wurden zu verschiedenen Zeitpunkten vorgenommen, die nicht miteinander zusammenhängen. Die meisten Aktualisierungen wurden bei Abschluss einer Versicherung hinzugefügt, betrafen aber nicht alle operativen Systeme zur gleichen Zeit. Folglich wirkte sich eine Änderung nicht auf alle Satelliten aus. Stattdessen betraf sie nur den Satelliten, für den die Änderung gelten sollte (was ein Vorteil ist).

Beim Aufbau eines Data Marts aus diesen Rohdaten wird die Abfrage der Kundendaten zu einem bestimmten Datum kompliziert: Die Abfrage sollte die Kundendaten so zurückgeben, wie sie gemäß dem data warehouse-Delta-Verfahren zum ausgewählten Datum aktiv waren. Um dieses Ziel zu erreichen, sind Outer-Join-Abfragen mit komplexer Zeitbereichsbehandlung erforderlich. Bei mehr als drei Satelliten an einem Knotenpunkt oder einer Verbindung wird dies kompliziert und langsam. Der bessere Ansatz ist die Verwendung von Equal-Join-Abfragen zum Abrufen der Daten aus dem Raw Data Vault. Um dies zu erreichen, wird in der Data Vault-Modellierung ein spezieller Entitätstyp verwendet: Point-in-Time-Tables (PIT). Diese Entität wird in ein Data Vault-Modell eingeführt, wenn die Abfrageleistung für einen bestimmten Hub oder Link und die umliegenden Satelliten zu gering ist.

Abbildung 2: Struktur der PIT-Tabelle

Da die Daten in einer PIT-Tabelle vom System berechnet werden und nicht aus einem Quellsystem stammen, sind die Daten nicht zu prüfen und befinden sich nicht im Raw Vault, so dass die Struktur so geändert werden kann, dass sie berechnete Spalten enthält.

Die PIT dient zwei Zwecken:

Vereinfachen Sie die Kombination mehrerer Deltas zu verschiedenen "Zeitpunkten".

Eine PIT-Tabelle erstellt Schnappschüsse von Daten für Daten, die von den vorgelagerten Datenkonsumenten angegeben werden. So ist es beispielsweise häufig üblich, täglich den aktuellen Stand der Daten zu melden. Um diesen Anforderungen gerecht zu werden, enthält die PIT-Tabelle das Datum und die Uhrzeit des Snapshots in Kombination mit dem Geschäftsschlüssel als eindeutigen Schlüssel der Entität (a Hash-Schlüssel einschließlich dieser beiden Attribute, die als KundenSchlüssel in Abbildung 2). Für jede dieser Kombinationen enthält die PIT-Tabelle die Ladedaten und die entsprechenden Hash-Schlüssel von jedem Satelliten, der am besten mit dem Schnappschussdatum übereinstimmt.

Reduzieren Sie die Komplexität von Joins aus Leistungsgründen

Die PIT-Tabelle ist wie ein Index, der von der Abfrage verwendet wird und Informationen über die aktiven Satelliteneinträge pro Snapshot-Datum liefert. Ziel ist es, so viel von der Verknüpfungslogik wie möglich zu materialisieren und am Ende eine innere Verknüpfung nur mit Gleichheitsbedingungen zu erhalten. Dieser Join-Typ ist auf den meisten (wenn nicht sogar allen) relationalen Datenbankservern die leistungsfähigste Version des Join. Um die Leistung der PIT-Tabelle zu maximieren und gleichzeitig den Speicherbedarf gering zu halten, ist nur ein Ghost-Datensatz in jedem von der PIT-Tabelle verwendeten Satelliten erforderlich. Dieser Ghost-Datensatz wird verwendet, wenn in dem referenzierten Satelliten kein Datensatz aktiv ist, und dient als der unbekannte oder NULL-Fall. Durch die Verwendung des Ghost-Datensatzes können NULL-Prüfungen im Allgemeinen vermieden werden, da die Verknüpfungsbedingung immer auf einen aktiven Datensatz in der Satellitentabelle verweist: entweder auf einen tatsächlichen Datensatz, der zum gegebenen Snapshot-Datum aktiv ist, oder auf den Ghost-Datensatz.

Tabelle 1: Beispiel einer PIT-Tabelle

Die obige Tabelle (Tabelle 1) zeigt eine versicherte Person mit eingefrorenen Datenständen, einen vom 8. und einen vom 9. Oktober 2018. Am 8. Oktober gab es keinen Datensatz für diesen Kunden im Rechtsschutzversicherungssatelliten. Aus diesem Grund sind sowohl der Hash-Schlüssel als auch der Zeitstempel des Ladedatums NULL. Um die Abfrageleistung zu verbessern, werden diese NULL-Werte auf den Geisterdatensatz in der zugehörigen Satellitentabelle verwiesen, um zu vermeiden, dass ein Datensatz gesucht wird, der nicht existiert.

Wenn Kundendaten nur für ein Unternehmen gelöscht werden müssen und PII-Informationen als Geschäftsschlüssel verwendet werden, müssen nur der Link-Eintrag und die beschreibenden Attribute in dem spezifischen Satelliten gelöscht werden. Die Aktivitätshistorie ist weiterhin verfügbar, kann für analytische Zwecke verwendet werden und ist nicht auf den Kunden selbst zurückzuführen. Der zusätzliche Vorteil dieser "Geschäftsaufteilung" besteht darin, dass bei der Löschung von Kundendaten nur ein Geschäft betroffen ist, d.h. jedes Geschäft kommt aus verschiedenen Niederlassungen, und nur die Kfz-Versicherungsdaten gelöscht werden müssen. Außerdem ist zu bedenken, dass die Löschung nur des Geschäftsschlüssels (und die Beibehaltung der Hash Key) nicht zur Einhaltung der GDPR führt (und ohnehin nicht dem Data Vault 2.0-Standard entspricht, da der Geschäftsschlüssel in Verknüpfungstabellen verwendet wird). Die Hash Key in Data Vault 2.0 wird nicht zur Verschlüsselung von Daten verwendet, sondern aus Leistungsgründen. Der Schlüssel in den Links und den geschäftsorientierten Hubs, um die es hier geht, kann nicht zurückgerechnet werden, da es sich um einen vollständigen Surrogatschlüssel handelt. Sobald der Kunde vollständig gelöscht werden soll, da er kein Kunde mehr in einem Ihrer Geschäfte ist, löschen Sie den Datensatz auch aus dem Haupt-Hub.

Andernfalls, wenn es keinen zusätzlichen künstlichen Schlüssel für den Kunden gibt, können Sie nach dem Löschen von PII-Daten Ihre Daten nicht an ein Objekt (einen Ankerpunkt) zurückbinden, was sie (in vielen Fällen) nutzlos macht.

Schlussfolgerung

Der Zweck von PIT-Tabellen besteht darin, die Abfrageleistung zu verbessern, indem äußere Joins eliminiert werden und innere Joins mit gleichwertigen Join-Bedingungen möglich sind (beste Leistung). Außerdem verbessern PIT-Tabellen die Partitionierung und ermöglichen die volle Skalierbarkeit von Sternschemata (die vollständig virtualisiert werden sollten) auf dem Data Vault. Darüber hinaus müssen Endbenutzer nicht alle Satellitentabellen verknüpfen, sondern nur eine Tabelle für ein Geschäftsobjekt, was die Abfragekomplexität bei Ad-hoc-Abfragen verringert.

Scalefree

Updates und Support erhalten

Bitte senden Sie Anfragen und Funktionswünsche an [email protected]

Für Anfragen zu Data Vault-Schulungen und Schulungen vor Ort wenden Sie sich bitte an [email protected] oder registrieren Sie sich unter www.scalefree.com.

Um die Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio zu unterstützen, wurde eine Schablone implementiert, die zum Zeichnen von Data Vault-Modellen verwendet werden kann. Die Schablone ist erhältlich bei www.visualdatavault.com.

Beteiligen Sie sich an der Diskussion 6 Comments

  • Angad sagt:

    Hallo @Michael,

    Erstaunliche und wichtige Erkenntnisse.
    Aber da die Systeme immer heterogener werden, wo DWH in einer Umgebung und MART in einer anderen ist, denke ich, dass es an der Zeit ist, auch die Data Vault-Objekte zu erweitern.

    PIT speichert also im Wesentlichen die Belastungsdaten für jede BK aus allen SATs.
    Wie wäre es mit einer PIT_SAT, die alle Attribute von SATs enthält? Dies wird die untergeordnete Tabelle von PIT sein.

    Vorteil:
    1. Meine virtuelle Dimension (in Mart) ist einfach eine innere Verknüpfung von PIT und PIT_SAT.
    2. Wenn es sich bei meinem DWH um ein (verwaltetes) HIVE handelt und MART auf Teradata oder Exasol oder Oracle läuft, muss ich nur PIT und PIT_SAT (2 Tabellen) synchronisieren und nicht alle DWH-SATs.

    Bitte lassen Sie mich wissen, ob das gut klingt?
    Angad

    • Hallo Angad,

      danke für Ihren Kommentar.

      Da die PIT nicht Teil des Raw Data Vault ist, können Sie die Tabelle nach Ihren eigenen Vorstellungen erweitern, was auch bedeutet, dass Sie entweder eine zusätzliche PIT-Tabelle (PIT_SAT) erstellen, in der die beschreibenden Attribute enthalten sind, oder diese Attribute direkt in die Haupt-PIT-Tabelle einfügen. Sobald die Business-Keys und die Ladedaten von den Satelliten drin sind, können Sie die PIT erweitern.

      Mit freundlichen Grüßen,
      Marc (Lösungsmanager)

  • Slavon sagt:

    Hallo,
    Sehr guter Artikel! 🙂
    Könnten Sie uns bitte mitteilen, warum Sie zusätzliche Hash-Key-Spalten in der PIT-Tabelle haben?
    Beispielsweise hat CustomerCAR_HashKey den gleichen Wert wie der Customer_HashKey für die entsprechende Zeile.
    Könnte man bei der Verknüpfung von PIT mit CustomerCAR_SAT nicht PIT.Customer_HashKey = CustomerCAR_SAT.Customer_HashKey verwenden (+ join on LDTS)?
    Ich danke Ihnen,

    • Hallo Slavon,
      Dies würde aus logischer Sicht funktionieren, aber aus Leistungsgründen empfehlen wir diesen Ansatz nicht (und deshalb verwenden wir PIT-Tabellen). Die Suche nach Hash Keys in Satelliten verringert die Abfrageleistung, da die Abfrage versuchen würde, einen Wert zu suchen, der nicht existiert. Außerdem muss eine äußere Verknüpfung verwendet werden, was die Leistung verringert.
      Sie müssen dem Satelliten einen Geistereintrag hinzufügen. Dabei handelt es sich um den ersten Eintrag in einer Satellitentabelle, auf den die PIT über einen Inner Join mit Equi-Bedingung verweist, wenn die Hash Key nicht in einem der Satelliten vorhanden ist. Dies ist aus Sicht der Leistung die beste Methode.
      Mit freundlichen Grüßen,
      Ihr Scalefree-Team

    • Hallo Slavon,
      der Kunden-HashKey im Hub/Link und seinen Satelliten gleich ist, WENN der Kunde in einem Satelliten existiert.

      Wenn Sie in die PIT nur den Cust_HKey aus dem Hub/Link und die LDTS für jeden Satelliten eingeben, haben Sie bei der Verwendung der PIT-Ergebnisse für die Verknüpfung mit einem Satelliten (auf der Grundlage von Cust_HKey und LDTS) zwei Möglichkeiten: (1) Verwendung einer äußeren Verknüpfung, um mit Nullen umzugehen, oder (2) "Nachbearbeitung" der PIT-Daten bei der Eingabe in die Verknüpfung, um BEIDE, Cust_HKey und LDTS, mit denen für einen Geisterdatensatz zu ersetzen, wenn Sie eine Null-LDTS aus der PIT erhalten.

      Es scheint mir viel einfacher und leistungsfähiger zu sein, diese Substitutionslogik nur an einer Stelle zu platzieren (bei der Erstellung des PIT), wo das Ergebnis der Substitution gespeichert wird, anstatt diese Logik in jede Abfrage einzufügen, die das PIT jemals verwenden wird, und die Substitutionslogik bei jeder Abfrage neu zu bewerten.

      Ciao, Roberto

      • Obaid sagt:

        Hallo Roberto

        Ja, ich stimme zu! Wir entscheiden uns hier bei Scalefree für die zweite Möglichkeit und verwenden Ghost-Records für Nullwerte.

        Prost
        Obaid

Eine Antwort hinterlassen

Menü schließen