Wie verwendet man Point-in-Time-Tabellen (PIT) in der Versicherungsbranche?

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:

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.

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.

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.

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.