Point-in-Time-Tabellen
Point-in-Time-Tabellen (PIT-Tabellen) sind nützlich, wenn Sie Daten aus dem Raw Vault abfragen, bei denen mehrere Satellites an einen Hub oder Link angebunden sind:
Über Point-in-Time-Tabellen
Im obigen Beispiel sind mehrere Satellites für den Hub „Customer“ und den Link im Diagramm dargestellt. Dies ist eine sehr häufige Situation bei Data-Warehouse-Lösungen, da sie Daten aus mehreren Quellsystemen integrieren. Diese Situation erhöht jedoch die Komplexität bei der Abfrage von Daten aus dem Raw Data Vault. Das Problem entsteht, weil Änderungen an den in den Quellsystemen gespeicherten Business-Objekten nicht gleichzeitig erfolgen. Stattdessen wird ein Business-Objekt, wie z. B. ein Kunde (eine versicherte Person), zu einem bestimmten Zeitpunkt in einem der vielen Quellsysteme aktualisiert, zu einem anderen Zeitpunkt in einem anderen System usw. Beachten Sie, dass die Point-in-Time-Tabelle (PIT) bereits an den Hub angehängt ist, wie durch das Band dargestellt.
Änderungen gingen zu unterschiedlichen Zeiten ein, die nicht miteinander in Beziehung standen. Die meisten Aktualisierungen wurden beim Abschluss einer Versicherung vorgenommen, betrafen jedoch nicht alle operativen Systeme gleichzeitig. Folglich wirkte sich eine Änderung nicht auf alle Satellites aus. Stattdessen betraf sie nur denjenigen Satellite, der die Änderung abbilden sollte (was ein Vorteil ist).
Beim Erstellen eines Data Marts aus diesen Rohdaten wird die Abfrage von Kundendaten zu einem bestimmten Stichtag kompliziert: Die Abfrage muss die Kundendaten so zurückgeben, wie sie gemäß dem Delta-Prozess des Data Warehouses am ausgewählten Datum aktiv waren. Um dieses Ziel zu erreichen, sind Outer-Join-Abfragen mit komplexer Zeitbereichslogik erforderlich. Bei mehr als drei Satellites an einem Hub oder Link wird dies kompliziert und langsam. Der bessere Ansatz ist die Verwendung von Equi-Join-Abfragen, um die Daten aus dem Raw Data Vault abzurufen. Um dies zu erreichen, wird in der Data-Vault-2.0-Modellierung ein spezieller Entitätstyp verwendet: Point-in-Time-Tabellen (PIT). Diese Entität wird immer dann in ein Data-Vault-2.0-Modell integriert, wenn die Abfrageperformance für einen bestimmten Hub oder Link und die zugehörigen Satellites zu gering ist.
] Da die Daten in einer PIT-Tabelle systemgeneriert sind und nicht aus einem Quellsystem stammen, müssen sie nicht auditiert werden und befinden sich nicht im Raw Vault. Daher kann ihre Struktur so angepasst werden, dass sie berechnete Spalten (Computed Columns) enthält.
Point-in-Time-Tabellen dienen zwei Zwecken:
Vereinfachung der Kombination mehrerer Deltas zu verschiedenen „Points in Time“
Eine PIT-Tabelle erstellt Snapshots von Daten für Stichtage, die von den nachgelagerten Datenkonsumenten definiert wurden. Beispielsweise ist es üblich, täglich den aktuellen Zustand der Daten bereitzustellen. Um diesen Anforderungen gerecht zu werden, enthält die PIT-Tabelle das Datum und die Uhrzeit des Snapshots in Kombination mit dem Business-Key als eindeutigen Schlüssel der Entität (ein Hash-Key, der diese beiden Attribute enthält und in Abbildung 2 als „CustomerKey“ bezeichnet wird). Für jede dieser Kombinationen enthält die PIT-Tabelle die Load-Dates und die entsprechenden Hash-Keys aus jedem Satellite, die am besten mit dem Snapshot-Datum übereinstimmen.
Reduzierung der Join-Komplexität aus Performancegründen mit Point-in-Time-Tabellen
Die Point-in-Time-Tabelle fungiert wie ein von der Abfrage verwendeter Index und liefert Informationen über die aktiven Satellite-Einträge pro Snapshot-Datum. Das Ziel besteht darin, so viel Join-Logik wie möglich zu materialisieren, um am Ende einen Inner Join mit ausschließlichen Equi-Join-Bedingungen zu erhalten. Dieser Join-Typ ist auf den meisten (wenn nicht allen) relationalen Datenbankservern die performanteste Join-Variante. Um die Performance der PIT-Tabelle zu maximieren und gleichzeitig den Speicherbedarf gering zu halten, ist in jedem von der Point-in-Time-Tabelle referenzierten Satellite nur ein einziger Ghost-Record erforderlich. Dieser Ghost-Record wird verwendet, wenn im referenzierten Satellite kein Datensatz aktiv ist, und dient als Fallback für unbekannte oder NULL-Werte. Durch die Verwendung des Ghost-Records können NULL-Prüfungen im Allgemeinen vermieden werden, da die Join-Bedingung immer auf einen aktiven Datensatz in der Satellite-Tabelle verweist: entweder auf einen tatsächlichen Datensatz, der zum angegebenen Snapshot-Datum aktiv ist, oder auf den Ghost-Record.
Die obige Tabelle (Tabelle 1) zeigt eine versicherte Person mit historischen Datenständen vom 8. und 9. Oktober 2018. Am 8. Oktober gab es für diesen Kunden keinen Datensatz im Rechtsschutzversicherungs-Satellite. Aus diesem Grund sind sowohl der Hash-Key als auch der Load-Date-Zeitstempel NULL. Für eine bessere Abfrageperformance verweisen diese NULL-Werte auf den Ghost-Record in der zugehörigen Satellite-Tabelle, um die Suche nach einem nicht existierenden Datensatz zu vermeiden.
Wenn Kundendaten nur für einen bestimmten Geschäftsbereich gelöscht werden müssen und personenbezogene Daten (PII) als Business-Key dienen, müssen lediglich der Link-Eintrag und die beschreibenden Attribute im spezifischen Satellite gelöscht werden. Der Aktivitätsverlauf bleibt weiterhin verfügbar, kann für analytische Zwecke genutzt werden und lässt sich nicht mehr auf den konkreten Kunden zurückführen. Der zusätzliche Vorteil dieses „Business Splits“ zeigt sich, wenn beim Löschen von Kundendaten nur ein einzelner Geschäftsbereich betroffen ist – beispielsweise wenn die Geschäftsbereiche zu verschiedenen Tochtergesellschaften gehören und nur die Kfz-Versicherungsdaten gelöscht werden müssen. Denken Sie außerdem daran, dass das Löschen des reinen Business-Keys (unter Beibehaltung des Hash-Keys) nicht zur DSGVO-Konformität führt (und ohnehin nicht dem Data-Vault-2.0-Standard entspricht, da der Business-Key in Link-Tabellen verwendet wird). Der Hash-Key in Data Vault 2.0 wird nicht zur Verschlüsselung von Daten verwendet, sondern dient reinen Performancegründen. Der Schlüssel in den Links und den geschäftsorientierten Hubs, von denen hier die Rede ist, kann nicht zurückgerechnet werden, da es sich um einen reinen Surrogatschlüssel handelt. Sobald ein Kunde die vollständige Löschung seiner Daten wünscht, da er oder sie kein Kunde mehr in einem Ihrer Geschäftsbereiche ist, löschen Sie den Datensatz auch aus dem Haupt-Hub.
Andernfalls können Sie Ihre Daten nach dem Löschen der personenbezogenen Daten (PII) sofern kein zusätzlicher künstlicher Schlüssel für den Kunden existiert nicht mehr mit einem Objekt (einem Ankerpunkt) verknüpfen, was sie in vielen Fällen unbrauchbar macht.
Fazit
Der Zweck von Point-in-Time-Tabellen besteht darin, die Abfrageperformance zu verbessern, indem Outer Joins eliminiert und Inner Joins mit Equi-Join-Bedingungen (für die beste Performance) ermöglicht werden. Darüber hinaus verbessern Point-in-Time-Tabellen die Partitionierung und ermöglichen eine vollständige Skalierbarkeit von Star-Schemas (die vollständig virtualisiert sein sollten) auf dem Data Vault. Zudem müssen Endanwender nicht alle Satellite-Tabellen miteinander verknüpfen, sondern verbinden nur eine einzige Tabelle mit einem Business-Objekt, was die Komplexität von Ad-hoc-Abfragen erheblich reduziert.
