Multi-Active Satellites in Data Vault 2.0
In unserem ersten Beitrag über Multi-Active-Satelliten haben wir kurz verschiedene Implementierungen erläutert, die zur Behandlung von Multi-Activity eingesetzt werden können. Nun gehen wir genauer auf die Vor- und Nachteile dieser Ansätze ein – je nachdem, ob Delta-Checks aktiviert oder deaktiviert sind.
In this article:
Kurze Zusammenfassung zu Multi-Active Satellites
Multi-Active-Satelliten ermöglichen Ihnen die Implementierung multi-aktiver Datensätze pro Business-Key in Data Vault 2.0. Um die Notwendigkeit dieser Lösung zu verdeutlichen, betrachten wir den häufigen Fall eines Quellsystems, das die benötigten Metadaten nicht liefert – wie etwa bei der Arbeit mit XML-Dateien.
Eine Lösung für dieses Problem besteht darin, einen Multi-Active-Satelliten zu erstellen, indem eine Subsequence-Nummer pro Business-Key hinzugefügt wird. Dies deckt jeden Fall ab, in dem die Quelle selbst kein multi-aktives Attribut liefert. Bezogen auf Telefonnummern könnte diese Information ein Tag für eine geschäftliche, private oder mobile Telefonnummer sein. Eine weitere Möglichkeit besteht darin, einen zusätzlichen Hub für das multi-aktive Attribut zu erstellen. Da dieser jedoch kein reales Business-Objekt darstellt, ist die erste Lösung oft effektiver.
Delta-Check AUS
Es gibt zwei Möglichkeiten, neue Datensätze in einen Multi-Active-Satelliten einzufügen: mit aktivierten oder deaktivierten Delta-Checks. Wenn die Delta-Checks ausgeschaltet sind, werden alle Datensätze eines Business-Keys aus Ihrer Quelllieferung in den Satelliten eingefügt.
Der Vorteil dabei ist, dass die Ladevorgänge schneller sind und einen konsistenten Load Date Timestamp (LDTS) zum übergeordneten Hash-Key aufweisen, unabhängig vom multi-aktiven Attribut.
Dies vereinfacht die spätere Abfrage basierend auf den multi-aktiven Daten (siehe Abbildung 1). Ein entscheidender Nachteil ist jedoch, dass die geladene Datenmenge stark ansteigen kann, wenn vollständige Datenladungen (Full Data Loads) verarbeitet werden.
In diesem Fall sollten Sie Ihre Daten nach dem Load Date Timestamp partitionieren.
Abbildung 1: Verknüpfen von Datensätzen über eine PIT-Tabelle bei einem einheitlichen LDTS für alle aktiven Datensätze pro Key.
Delta-Check EIN
Um die Datenmenge zu reduzieren, nutzen Sie Delta-Checks. Dabei vergleichen Sie die eingehenden Daten mit dem neuesten LDTS pro Hash-K
Die Funktion LISTAGG() ist hierbei sehr nützlich, um den Delta-Check zu unterstützen. Sie wandelt Werte aus einer Gruppe von Zeilen in eine geordnete Liste um. Dadurch sind Sie in der Lage, eine zeilenübergreifende Hash-Differenz der multi-aktiven Attribute pro Business-Key zu erstellen (siehe Abbildung 2).
Abbildung 2: Zeilenübergreifende Hash-Differenz unter Verwendung der LISTAGG()-Funktion.
Wenn neue Daten eintreffen, können diese mithilfe der zeilenübergreifenden Hash-Differenz verglichen werden. Dadurch lässt sich ein großer Teil unveränderter Daten ignorieren. Wird ein Delta erkannt, werden alle Datensätze pro Hash-Key eingefügt – selbst wenn sich der Inhalt nur für eine einzelne Subsequence geändert hat. Das Ergebnis ist ein konsistenter Load Date Timestamp pro Hash-Key. Zudem wird ein Delta auch dann erkannt, wenn sich lediglich die Reihenfolge der Datensätze ändert. Dieser Ansatz bildet einen Kompromiss, um die Anzahl der Datensätze zu reduzieren und gleichzeitig einen konsistenten LDTS pro Hash-Key beizubehalten, sodass nur eine einzige PIT-Tabelle erforderlich ist.
Verwendung von Type-Codes
Eine weitere Möglichkeit, Multi-Activity zu handhaben, besteht darin, die Typen der Attribute zu verwenden, sofern diese vorhanden sind , wie im vorherigen Beitrag erläutert.
Wenn Sie Type-Codes im Einsatz haben, können Sie Zeile für Zeile vergleichen und nur die spezifischen geänderten Daten laden. Die Konsequenz daraus ist jedoch, dass Sie unterschiedliche LDTS-Werte pro multi-aktivem Attribut erhalten. Wenn Sie PIT-Tabellen im Business Vault verwenden, benötigen Sie daher eine zusätzliche Multi-Active-PIT-Tabelle. Dieses Szenario ist in Abbildung 3 dargestellt.
Abbildung 3: Die Notwendigkeit einer MA-PIT-Tabelle bei unterschiedlichen LDTS-Werten aktiver Datensätze pro Key.
Wenn Sie die multi-aktive Spalte in mehrere Spalten pivotieren können (eine Spalte pro Ausprägung), müssen Sie die oben genannten Vor- und Nachteile nicht berücksichtigen. In diesem Fall wandeln Sie den Multi-Active-Satelliten in einen Standard-Satelliten um. Bezogen auf unser Beispiel mit den Telefonnummern würden Sie einige neue Spalten pro Telefontyp erstellen.
Diese Lösung ist gut anwendbar, wenn Sie sicher sein können, dass sich die Ausprägungen der Telefontypen in Zukunft nicht ändern. Andernfalls müssen Sie Ihren Ladeprozess bei neuen Typen anpassen, um weiterhin alle gelieferten Daten zu erfassen.
Fazit
In diesem zweiten Beitrag zu Multi-Active-Satelliten haben wir die Hintergründe der verschiedenen Modellierungsansätze untersucht. Sie können diese Informationen nutzen, um abhängig von Ihren Datenstrukturen die optimale Multi-Active-Lösung zu wählen.
Beachten Sie dabei, dass es meist ratsam ist, die zu ladende Datenmenge frühzeitig zu begrenzen – wozu sich die LISTAGG()-Funktion hervorragend eignet. Wenn Sie eine Lösung mit potenziell unterschiedlichen LDTS-Werten nutzen, denken Sie daran, diese bei der Abfrage über entsprechende PIT-Tabellen zu berücksichtigen.
