Point in time tables are useful when querying data from the Raw Vault that has multiple satellites on a hub or a link:
About Point In Time Tables Tables
In the above example, there are multiple satellites on the hub Customer and link included in the diagram. This is a very common situation for data warehouse solutions because they integrate data from multiple source systems. However, this situation increases the complexity when querying the data out of the Raw Data Vault. The problem arises because the changes to the business objects stored in the source systems don’t happen at the same time. Instead, a business object, such as a customer (an assured person), is updated in one of the many source systems at a given time, then updated in another system at another time, etc. Note that the point in time table (PIT) is already attached to the hub, as indicated by the ribbon. 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).
When building a data mart from this raw data, querying the customer data on a given date becomes complicated: the query should return the customer data as it was active according to the data warehouse delta process on the selected date. It requires outer join queries with complex time range handling involved to achieve this goal. With more than three satellites on a hub or link, this becomes complicated and slow. The better approach is to use equal-join queries for retrieving the data from the Raw Data Vault. To achieve this, a special entity type is used in Data Vault 2.0 Modellierung: point in time tables (PIT). This entity is introduced to a Data Vault 2.0 model whenever the query performance is too low for a given hub or link and surrounding satellites.
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.
Point in time tables serve two purposes:
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.
Reduce the complexity of joins for performance reasons with Point in Time Tables
The point in time table is like an index used by the query and provides information about the active satellite entries per snapshot date. The goal is to materialize as much of the join logic as possible and end up with an inner join with equi-join conditions only. This join type is the most performant version of joining on most (if not all) relational database servers. In order to maximize the performance of the PIT table while maintaining low storage requirements, only one ghost record is required in each satellite used by the point in time table. This ghost record is used when no record is active in the referenced satellite and serves as the unknown or NULL case. By using the ghost record, it is possible to avoid NULL checks in general, because the join condition will always point to an active record in the satellite table: either an actual record which is active at the given snapshot date or the ghost record.
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.
When customer data must be deleted for one business only and PII information is used as Business Key, just the Link entry and the descriptive attributes in the specific Satellite have to be deleted. The activity history is still available, can be used for analytical reasons and is not traceable to the customer itself. The additional advantage of this “business split” is when only one business is affected in case of deleting customer data, i.e. each business comes from different subsidiaries, and only the car insurance data must be deleted. Furthermore, keep in mind that deleting the Business Key only (and keep the Hash Key) does not result in GDPR compliance (and does not meet the Data Vault 2.0 standard anyway as the Business Key is used in link tables). The Hash Key in Data Vault 2.0 is not used to encrypt data, but for performance reasons. The key in the Links and the business driven Hubs, as we are talking about, can not be calculated back as it is a complete surrogate key. As soon as the customer wants to be deleted completely as he/she is no longer a customer in any of your business, you delete the record from the main Hub as well.
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
The purposes of point in time tables are to improve the query performance by eliminating outer joins and allow inner joins with equi join conditions (best performance). Additionally point in time tables enhance partitioning and enable full scalability of star schemas (which should be completely virtualized) on top of the Data Vault. Furthermore, end users don’t have to join through all satellite tables, but join just one table for one business object what reduces the query complexity for ad-hoc queries.
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.
Zur Unterstützung bei der Erstellung von Visual Data Vault-Zeichnungen in Microsoft Visio wurde eine Schablone entwickelt, mit der Data Vault-Modelle gezeichnet werden können. Die Schablone ist erhältlich bei www.visualdatavault.com.
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)
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
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