Im Januar dieses Jahres veröffentlichten wir einen Artikel, in dem wir einen Ansatz für die Handhabung von Löschungen und Änderungen von Geschäftsschlüsseln in Data Vault, ohne dass ein Prüfpfad vorhanden ist.
Dieser Ansatz ist eine Alternative zur Driving Key-Struktur, die Teil der Data Vault-Normen ist und eine gültige Lösung darstellt.
Allerdings kann es manchmal schwierig sein, die Geschäftsschlüssel in einer Beziehung zu finden, die sich nie ändern und daher als Ankerschlüssel, Link Driving Key, bei Abfragen verwendet werden. Die vorgestellte Methode fügt Zählerdatensätze für geänderte oder gelöschte Datensätze ein, insbesondere für Transaktionsdaten, und ist ein unkomplizierter und pragmatischer Ansatz. Der Artikel hat jedoch eine Menge Fragen, Verwirrung und Unstimmigkeiten hervorgerufen.
In diesem Blogpost wollen wir uns daher mit der technischen Umsetzung befassen, die wir durch den Einsatz des Systems verbessern könnten.
Die folgende Tabelle zeigt eine leicht veränderte Zielstruktur des Links vom vorheriger Blogpost bei der Verwendung von Zählersätzen.
In diesem Fall konzentrieren wir uns auf Transaktionen, die vom Quellsystem geändert wurden, ohne dass die Quelle selbst Prüfdaten über die Änderungen und Gegenbuchungen liefert.
Es ist wichtig zu beachten, dass der Link die Verkaufspositionen speichert, indem er auf den Kunden und das Produkt verweist. Daher sind die Verknüpfung Hash Key und das Ladedatum die Primärschlüssel, da wir in diesem Fall nicht in der Lage sind, eine konsistente singuläre Datensatz-ID zu erfassen. Der Link Hash Key wird also aus dem Customer Business Key, dem Product Business Key, dem Verkaufspreis und dem Zeitstempel der Transaktion berechnet.
Abbildung 1: Verknüpfung mit Zählersätzen
Um den Link zu laden, sind die folgenden Schritte erforderlich:
Fügen Sie zunächst ein und prüfen Sie, ob eine Zählerbuchung überhaupt notwendig ist, da im ersten Schritt neue Daten aus dem Staging-Bereich in den Link geladen werden. Bitte beachten Sie, dass die Ladelogik in diesem Schritt derjenigen des Standard-Ladevorgangs für Links ähnelt, mit einigen Unterschieden:
Abbildung 2: Einfüge-Logik
Der Zählerdatensatz sollte die jüngsten Datensätze von Link Hash Key identifizieren, die in der Verknüpfung vorhanden sind, aber aufgrund von Löschungen oder Änderungen an Datensätzen nicht im Staging-Bereich vorhanden sind. Daher werden die Abfrageergebnisse mit einem Wert für "Zähler" von -1 "gekontert", was bedeutet, dass diese Datensätze in dieser Phase nicht gefunden werden können. Beachten Sie, dass wir in dieser Abfrage den vorhandenen Datensatz aus der Verknüpfungstabelle im Rohdatenspeicher ausgewählt haben, beachten Sie aber auch, dass die Ankunftszeit des Datensatzes die LDTS des aktuellen Stapels sein sollte. Daher ist die LDTS in der gezeigten Anweisung eine Variable mit dem Ladedatum des Staging-Batch:
Abbildung 3: Zählerlogik
In den Fällen, in denen er zum ursprünglichen Datensatz zurückkehrt, gilt das gleiche Verfahren: Der aktuelle fehlende Wert wird durch den neuen ersetzt, der wiederum mit einem neuen LDTS eingefügt wird.
Daraus können wir schließen, dass dieser Ansatz gut für Tabellen funktioniert, die ein Hotspot nur für gemessene Werte sind, sowie wenn Änderungen möglich sind, obwohl die Daten "Transaktionen" darstellen und verwendet werden sollen, wenn CDC nicht verfügbar ist.
Anstelle eines "Get the most recent record per Hash Key (Driving Key)" ist es möglich, Berechnungen sowie Aggregationen direkt auf einer Tabelle durchzuführen, was im Endstadium zu einer besseren Performance führt.
Falls noch Fragen offen sind, können Sie gerne einen Kommentar hinterlassen.
Wir freuen uns auf einen Austausch und Ihre Gedanken zu diesem Thema.
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.
Tut mir leid, wenn ich es vielleicht zu sehr vereinfache, aber mir scheint, dass das Grundproblem darin besteht, dass man nicht wirklich eine Identität für die Zeilen hat, so dass man sie einfach als Ganzes behält oder entfernt.
Sie erstellen vollständige Zeilenschlüssel, indem Sie so gut wie die gesamte Zeile mit einem Hashwert versehen und prüfen, was sowohl im Stadium als auch im Ziel (unverändert) vorhanden ist, was neu ist (einzufügen) und was verschwunden ist (zu löschen).
Dies (Zusammenführen von stage mit destination und picking where dest is null) ist das einzige Änderungsmanagementverfahren, das in diesem Fall zur Verfügung steht, da es keine CDC gibt und man davon ausgehen kann, dass eine Zeile, die in stage verschwindet, für immer verschwunden ist (oder geändert wurde, was dasselbe ist, wenn man keine stabile Identität hat).
Dann beschließen Sie, dass Sie, anstatt das Verschwinden einfach mit einem Status zu verfolgen (in einer Gültigkeitsliste oder auf eine andere Weise, um eine binäre Information zu erhalten), eine neue Zeile eingeben, die die Zeile ausgleicht, die in der Stufe verschwunden ist.
Das gleicht natürlich nicht alles aus, sondern funktioniert hauptsächlich für Summen. Z.B. sind die Zählungen und Durchschnitte kaputt, es sei denn, sie werden mit komplexeren Regeln berechnet, um die gelöschten und ihre gegnerischen Freunde zu entfernen.
Während dies bei ereignisbasierten Systemen ein wohlbekanntes Muster ist (da man einen autorisierten Kreditkartenkauf oder ein Flugticket nicht löschen kann), bei dem die Semantik des Ereignisses und seiner Umkehrung von den Anwendungen verwaltet wird, die die erforderliche Logik einbetten, sehe ich viele Komplexitäten bei der Verwendung für BI, da BI-Tools alles andere als gut darin sind, eine nicht triviale Geschäftslogik anzuwenden (geschweige denn, dass ihre Geschäftsanwender sie kodieren können).
Daher sehe ich dies als eine praktische Lösung für ein sehr spezifisches Problem und eine sehr spezifische Art der Nutzung dieser Informationen. Keine allgemein nützliche Lösung für BI.
Ein Beispiel: Wenn einer Ihrer BI-Anwender versuchen würde, den Durchschnittspreis zu berechnen, käme er auf 500 statt auf 1500 (und doppelt so viel Glück, wenn er einem BI-Tool beibringen könnte, wie man das richtig berechnet).
Ich würde gerne wissen, was Sie darüber denken, und vor allem, ob dieses Muster generell für die Erstellung von "fertigen" BI-Tabellen geeignet ist.
BR, RZ
Hallo Roberto,
Marc hier von Scalefree.
Der Hauptgrund für diese Vorgehensweise ist die Leistung, um die zusätzliche Verknüpfung mit einem Gültigkeits-Satelliten (der deltabasiert ist) zu vermeiden, und sie funktioniert am besten, wenn man mit gemessenen Daten arbeitet. Denken Sie daran, dass dies immer noch Teil des Raw oder Business Vault ist. BI-Benutzern (nicht Power-Usern) können und sollten Sie einen (virtualisierten) Information Mart zur Verfügung stellen, in dem die Durchschnittslogik bereits angewendet wird, in diesem Fall durch Division durch eine bestimmte Zahl des Kunden-Hash-Schlüssels. In anderen Fällen, insbesondere wenn Sie beispielsweise mit vielen Zeichenketten arbeiten, ist der Effektivitätssatellit in der Regel die bessere Lösung. Bedenken Sie auch, dass dieser Ansatz die "Datenalterung" außer Acht lässt. Es handelt sich um Maßnahmen, die zwar einen Transaktionscharakter haben, aber nicht aus einer technischen/lieferungsbezogenen Perspektive.
BR
Marc Finger
Die Lösung für Zähler oder Durchschnitt ohne Verwendung des Operators distinct ist zu einfach @Roberto Zagni.
Wir graben sie nur ein wenig tiefer.
für Zähler Kunde: Anzahl der Kunden = [count(Kunde) mit Zähler = 1] - [count(Kunde) mit Zähler = -1] = 2 -1 = 1
für Zähler Produkt: Menge des Produkts= [count(Produkt) mit Zähler = 1] - [count(Produkt) mit Zähler = -1] = 2 -1 = 1
für den Durchschnittspreis pro Kunde: Summe(Preis)/Menge der Kunden = 1500/1 = 1
für den Durchschnittspreis nach Kunde: Summe(Preis)/Menge des Produkts = 1500/1 =1
Ich denke, dieses Muster von Marc Finger ist gut und wir können darüber nachdenken, wie wir es erweitern können, besonders in der Welt der großen Daten, einige Prozesse/Transformationen durchführen, um die Geschäftsfrage anzupassen.