Technische Tests einer EDW mit Data Vault

Einführung

In diesem Newsletter geben wir Ihnen einen Überblick über die verschiedenen Methoden und Ansätze bei der Durchführung technischer Tests einer Data Vault-gestützten EDW.
Die im Folgenden beschriebenen Prüfverfahren zielen darauf ab, die Integrität, Zuverlässigkeit, Genauigkeit, Konsistenz und Prüfbarkeit der in Ihre Data Vault-Einheiten geladenen Daten sowie die Informationskataloge die auf ihnen aufbauen. So wird sichergestellt, dass Ihr Unternehmen auf der Grundlage dieser Daten sichere Entscheidungen treffen kann.

In einer Webinarsitzung wurde dieses Thema vertieft, wobei der Schwerpunkt auf dem Testen der Data Vault-Entitäten in den Schichten Raw Vault und Business Vault lag. Aufzeichnung ansehen hier umsonst!

Was zu erwarten ist

Sie erhalten einen Überblick über Testansätze, die für die verschiedenen Ebenen Ihrer EDW-Lösung geeignet sind, angefangen bei der Extraktion von Daten aus Quellen bis hin zur Landing Zone/Staging Area (Extract and Load) und endend bei Information Marts, die von Endanwendern in ihren BI-Berichten verwendet werden. Darüber hinaus werden wir die Testautomatisierung und ihre Bedeutung für die kontinuierliche Integration Ihres Data Vault-basierten EDW diskutieren. Der Schwerpunkt dieses Newsletters liegt jedoch auf dem Testen der Data Vault-Entitäten in den Schichten Raw Vault und Business Vault.

Prüfung des Datenextraktionsprozesses

Unabhängig davon, wo die Datenextraktion stattfindet - Datenquelle, dauerhafte Bereitstellung, vorübergehende Bereitstellung - besteht das Hauptziel der Tests in dieser Phase darin, nachzuweisen, dass es beim Transport oder bei der Bereitstellung der Daten keine Lecks gibt. Durch den Vergleich der Eingabedaten mit den Zieldaten wird sichergestellt, dass die Daten nicht versehentlich oder böswillig gelöscht, hinzugefügt oder aufgrund von Problemen im Extraktionsprozess verändert wurden.
Um sicherzustellen, dass die Daten nicht verändert wurden, werden Prüfsummen, Hash-Summen und Datensatzzählungen verwendet:

• Sicherstellen, dass die Prüfsummen über den Quelldatensatz und die Ziel-Staging-Tabelle gleich sind
• Sicherstellen, dass die numerische Summe eines oder mehrerer Felder in einem Quelldatensatz (auch Hashsumme genannt) mit der Summe der entsprechenden Spalten in der Zieltabelle übereinstimmt. Diese Summe kann Daten enthalten, die normalerweise nicht in Berechnungen verwendet werden (z. B. numerische ID-Werte, Kontonummern usw.)
• Stellen Sie sicher, dass die Zeilenzahl zwischen der Quell- und der Ziel-Staging-Tabelle übereinstimmt

Prüfung Data Vault

Das Kernstück Ihrer Data Vault-gestützten EDW-Lösung ist ein Raw Data Vault, das rohe und ungefilterte Daten aus Ihren Quellsystemen enthält, die auf der Grundlage von Geschäftsschlüsseln in Hubs, Links, Satelliten und andere Data Vault-spezifische Entitäten zerlegt und geladen wurden. Dies ist der erste Punkt in der Datenpipeline, an dem die Daten in den Data Vault-modellierten Entitäten landen. Daher sind spezifische Tests erforderlich, um sicherzustellen Konsistenz und Prüfbarkeit der Daten nach der Roh Data Vault aufgefüllt wird. Die folgenden Testansätze sind gültig für Business Vault auch Unternehmen.

Test-Drehkreuze

Hubs speichern Geschäftsschlüssel, indem sie vom Rest des Modells getrennt werden. Für jedes Geschäftsobjekt wird ein Hub erstellt. Er enthält eine eindeutige Liste von Schlüsseln, die ein Geschäftsobjekt repräsentieren und die die gleiche semantische Bedeutung und Granularität haben. Die in einem Hub befindlichen Geschäftsobjekte werden dann von anderen Data Vault-Entitäten über Hash-Schlüssel referenziert, die während der Staging-Phase berechnet werden.

Daher müssen die folgenden Tests an den Knotenpunkten durchgeführt werden, um ihre Konsistenz zu gewährleisten:
Bei einem Hub mit einem einzigen Business Key sollten die Tests sicherstellen, dass:

• Ein Hub enthält eine eindeutige Liste von Geschäftsschlüsseln (Primärschlüssel (PK) Test)
• Eine Geschäftsschlüsselspalte enthält keine NULL- oder Leerwerte (außer wenn der Geschäftsschlüssel zusammengesetzt ist)

Wenn ein Hub einen zusammengesetzten Geschäftsschlüssel hat, stellen Sie sicher, dass:

• Die Kombination der Werte in den Geschäftsschlüsselspalten ist eindeutig (PK-Test)
• Geschäftsschlüsselspalten enthalten nicht auf einmal NULL oder leere Werte

Die Gültigkeit des letztgenannten Punktes hängt auch von der Art der Geschäftsobjekte selbst ab. Es kann auch sein, dass NULLs oder leere Werte in keiner der Geschäftsschlüsselspalten erlaubt sind.

Bei beiden Arten von Naben ist darauf zu achten:

• Hash-Key-Spalte enthält:
  • Eindeutige Liste von Werten (PK-Test)
  • Keine NULLs oder leeren Werte

Links zum Testen

Eine typische Verknüpfung definiert Beziehungen zwischen Geschäftsobjekten durch die Speicherung eindeutiger Kombinationen von Hash-Schlüssel der angeschlossenen Hubs. Der Primärschlüssel des Links oder der Link-Hash-Schlüssel identifiziert eine solche Kombination eindeutig. Daher sollten Link-Tests dies überprüfen:

• Die Kombination der verbundenen Hub-Referenzen (Hub-Hash-Schlüssel) ist eindeutig (PK-Test)
• Jeder Hub-Hash-Schlüsselwert existiert in dem referenzierten Hub
• Hub-Referenzen enthalten keine NULLs oder leeren Werte

Bezüglich des letzten Aufzählungspunktes ist zu beachten, dass die NULLs und leeren Werte in Hub-Referenzen sowie in Hash-Key-Spalten anderer Data Vault-Entitäten durch Null-Schlüssel ersetzt werden.
Bei transaktionalen (nicht historisierten) Daten sollten zusätzlich zu Spalten mit Hash-Schlüsseln auch Spalten mit transaktionalen Schlüsseln in die Eindeutigkeitstests einbezogen werden. Achten Sie darauf, dass auch Transaktionsschlüssel aufgefüllt werden. Solche Transaktionsschlüssel werden normalerweise nicht gehasht, da in der Regel keine Hubs für Transaktionen erstellt werden.
Und, wie bei den Hubs, stellen Sie sicher, dass die Link-Hash-Schlüsselspalte eindeutige Werte enthält und keine NULLs und leeren Werte vorhanden sind.

Satelliten testen

Satellites beschreibende Informationen (Attribute) für Geschäftsobjekte (die sich in Hubs befinden) oder Beziehungen zwischen Geschäftsobjekten (die sich in Links befinden) speichern. Ein Satellit verweist entweder auf einen Hub oder einen Link. Da sich beschreibende Informationen für Geschäftsobjekte und Beziehungen zwischen ihnen im Laufe der Zeit ändern können, wird ein Zeitstempel des Ladedatums eines Satellitendatensatzes zum Primärschlüssel eines Satelliten hinzugefügt.

Vor diesem Hintergrund sollten die Tests für einen Satelliten sicherstellen, dass:

• Die Kombination aus einer Hub/Link-Referenz (Hash Key) und dem Zeitstempel des Ladedatums eines Datensatzes ist eindeutig (PK-Test)
• Jeder Hub- oder Link-Hash-Schlüsselwert existiert in dem referenzierten Hub oder Link
• Hub- oder Link-Referenzen enthalten keine NULL- oder Leerwerte

Multiaktive Satelliten mehrere aktive Datensätze zur gleichen Zeit enthalten. Daher werden zusätzliche Schlüsselspalten (z. B. Typcode, Reihenfolge usw.) zur eindeutigen Identifizierung eines Datensatzes benötigt. Diese zusätzlichen Schlüsselspalten müssen Teil der eindeutigen Prüfung eines multiaktiver Satellit. Außerdem sollten sie auf das Fehlen von NULL und leeren Werten getestet werden.
Der Ansatz für die Prüfung einer nicht-historisierter Satellit unterscheidet sich ebenfalls ein wenig von der Prüfung seines Standardgeschwisters. Ein nicht-historisierter Satellit ist ein spezieller Entitätstyp, der beschreibende Attribute für jeden entsprechenden Datensatz in einer nicht-historisierten Verknüpfung enthält. Der Primärschlüssel eines nicht-historisierten Satelliten ist ein Link-Hash-Schlüssel. Daher ist es nicht erforderlich, einen Zeitstempel des Ladedatums in die Primärschlüsselprüfung einzubeziehen. Für einen nicht-historisierter SatellitStellen Sie außerdem sicher, dass es eine 1:1-Beziehung zu der entsprechenden nicht-historisierten Verbindung gibt. Die Anzahl der Datensätze in beiden Entitäten sollte genau übereinstimmen.

Prüfung anderer Data Vault-Entitäten

Es gibt noch weitere spezielle Entitätstypen in Data Vault, die im Hinblick auf die Prüfung erwähnenswert sind:

• Referenzknotenpunkte und Referenzsatelliten: Die Testansätze sind ähnlich wie die Standard-Hubs und -Satelliten. Der einzige Unterschied besteht darin, dass es keine Hash-Schlüssel gibt und die Geschäftsschlüssel direkt verwendet werden.
• Aufzeichnung von Quellenverfolgungssatelliten: Eine Spalte, die einen statischen Quellennamen darstellt, wird dem Primärschlüsseltest hinzugefügt.
• PIT-Tabelle (Business Vault):
  • PK-Test - Kombination des Hash-Schlüssels des Hubs/Links und der Zeitstempelspalten des Snapshot-Datums ist eindeutig
  • Prüfen Sie für jede Satellitenreferenz, ob das Hash-Schlüsselpaar Hub/Link und der Zeitstempel des Ladedatums im referenzierten Satelliten vorhanden sind
  • Hub/Link-Referenz enthält keine NULL- oder leeren Werte
• Bridge Table (Business Vault):
  • PK-Test - Kombination eines Basis-Link-Hash-Schlüssels und einer Snapshot-Datum-Zeitstempel-Spalte ist eindeutig
  • Prüfen Sie für jede Hub- und Link-Referenz, ob ein Paar von Hub-/Link-Hash-Schlüsseln in dem referenzierten Hub oder Link existiert

Allgemeine Tests für alle Data Vault-Entitäten

Es gibt einige Tests, die für alle Dava Vault-Einheiten gelten.
Stellen Sie sicher, dass alle Data Vault-Einheiten:

• Nullschlüssel anstelle von NULL-Schlüsseln enthalten
• Die Spalten der Datensatzquelle müssen ausgefüllt sein und dem definierten Muster entsprechen (z. B. Regex). Prüfen Sie beispielsweise, ob sie den Dateipfad enthält, wobei der Name des obersten Ordners den Namen des Quellsystems darstellt und der Dateiname den Zeitstempel der Datenextraktion enthält
• keine NULL-Werte in den Zeitstempelspalten des Ladedatums (Snapshot) haben

Testen von Source Marts

Der Source Mart ist eine der Facetten des Information Mart-Konzepts im Data Vault. Es handelt sich dabei um ein virtualisiertes Modell auf dem Raw Data Vault mit dem Ziel, die ursprünglichen Quellstrukturen zu replizieren. Es eignet sich hervorragend für Ad-hoc-Berichte und bietet einen höheren Wert für viele Datenwissenschaftler und Power-User und kann auch zum Testen verwendet werden Konsistenz und Prüfbarkeit des Ladevorgangs in eine mit Data Vault betriebene EDW.

Source-Mart-Objekte sollen so aussehen wie die entsprechenden Quelltabellen (einschließlich der Spaltennamen). Wenn Sie in Ihrem EDW Source Marts implementiert haben, stellen Sie sicher, dass Sie diese nach dem Datenladeprozess mit den entsprechenden Quelltabellen im Staging-Bereich vergleichen. Die Werte und Zeilenzahlen der Quellstrukturen sollten exakt mit den entsprechenden Source-Mart-Objekten übereinstimmen. In der Data Vault-Community wird diese Art von Test auch als "Jedi-Test" bezeichnet.

Es ist relativ einfach, einen solchen Vergleich zu automatisieren und in den Ladeprozess einzubinden.

Testen von Hash Key und Hash-Diff-Berechnungen

Hash-Schlüssel in Data Vault ermöglichen die deterministische Integration von Geschäftsschlüsseln aus mehreren parallelen Quellen. Sie sind der Klebstoff, der die verschiedenen Data Vault-Entitäten miteinander verbindet.

Hash-Diffs hingegen gelten für die Satelliten und helfen bei der Ermittlung von Unterschieden in beschreibenden Attributen während des Datenladevorgangs.

Es ist wichtig, Unit-Tests für Hash-Schlüssel- und Hash-Diff-Berechnungen einzuführen, die in Ihrem EDW verwendet werden, um sicherzustellen, dass die Hash-Werte in Übereinstimmung mit den definierten Hashing-Standards berechnet werden. Lesen Sie hier mehr über Anforderungen und Vorlagen für Hashing. Die Testfälle für solche Unit-Tests sollten möglichst viele Kombinationen verschiedener Datentypen und Werte (z. B. NULL und leere Werte) abdecken, um sicherzustellen, dass sie einheitlich berechnet werden.

Für den Fall, dass Ihr EDW auf verschiedenen DBMS-Plattformen existiert (z. B. während des Migrationsprozesses oder aufgrund von Datensicherheitsbestimmungen), können die oben genannten Testfälle verwendet werden, um sicherzustellen, dass Ihre Hash-Berechnungen plattformunabhängig sind, d. h. dass sie auf verschiedenen Plattformen das gleiche Ergebnis liefern. Es gibt einen häufigen Anwendungsfall, bei dem ein Link in einer On-Premise-DBMS-Plattform auf einen Hub verweist, der bereits auf eine Cloud-Plattform migriert wurde. Solche Unit-Tests können auf beiden Plattformen durchgeführt werden, um die Konsistenz des Hashings während einer Migration sicherzustellen.

Testen von Geschäftsregeln

Im Gegensatz zu den harten Regeln, die den Inhalt der Daten nicht verändern oder unterbrechen und die Prüfbarkeit aufrechterhalten, setzen weiche oder geschäftliche Regeln die von den Geschäftsanwendern angegebenen geschäftlichen Anforderungen durch. Beispiele für Geschäftsregeln können sein:

• Verkettung (Nachname und Vorname)
• Standardisierung von Telefonnummern
• Berechnung des Gesamtumsatzes (Aggregation)
• Koaleszenz, etc.

Neben den oben aufgeführten relativ einfachen Beispielen kann es auch einige komplexere Geschäftsregeln geben, die anspruchsvolle Berechnungen, Datentransformationen und komplexe Verknüpfungen beinhalten. Je nach Anwendungsfall landen die Ergebnisse der Anwendung solcher Regeln in der Regel im Business Vault (d.h. einem Business Satellite) und später in der Information Mart-Schicht, wo sie von den Geschäftsanwendern konsumiert werden. Daher ist das Testen von Geschäftsregeln ein wichtiger Teil des Informationsbereitstellungsprozesses.

Geschäftsregeln sind normalerweise auch Gegenstand von Unit-Tests, die während des Entwicklungs- und CI-Prozesses kontinuierlich durchgeführt werden müssen. Um einen solchen Unit-Test durchzuführen, benötigen wir einige erwartete Werte, die im besten Fall vom Unternehmen bereitgestellt werden, d. h. einen erwarteten Nettoverkaufswert für ein bestimmtes Produkt oder eine Reihe von Produkten in einem bestimmten Geschäft an einem bestimmten Tag auf der Grundlage der realen Daten. Die Nettoumsatzberechnung aus unserem Business Vault wird dann gegen das vorgegebene erwartete Ergebnis getestet.

Testautomatisierung und kontinuierliche Integration

Alle oben beschriebenen Tests sollten so weit wie möglich automatisiert werden und von den EDW-Entwicklern während des Entwicklungsprozesses durchgeführt werden. Erfolgreiche Tests sollten eine obligatorische Bedingung für die Einführung jeder neuen Änderung an Ihrer EDW-Codebasis sein. Dies kann durch die Verwendung von DevOps-Tools und die Aktivierung der kontinuierlichen Integration (CI) in Ihrem DWH-Entwicklungszyklus erreicht werden. Die Durchführung automatisierter Tests bei jeder Überprüfung oder Zusammenführung von Code stellt sicher, dass Probleme mit der Datenkonsistenz oder Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion einfließen. In der Regel wird für die Ausführung automatisierter Tests eine separate Test- (oder CI-) Umgebung erstellt.

Im Folgenden finden Sie einige allgemeine Empfehlungen für die Erstellung und den Betrieb einer Testumgebung:

• Erstellen Sie die CI-Umgebung so ähnlich wie möglich zur Produktionsumgebung
• Erstellen von Testquelldatenbanken und Quelldateien, die von echten Daten abgeleitet sind
• Die Testquelldateien und Quelldatenbanken sollten klein sein, damit die Tests schnell ausgeführt werden können.
• Die Testquelldateien und Quelldatenbanken sollten ebenfalls statisch sein, damit die erwarteten Ergebnisse im Voraus bekannt sind.
• Testen Sie Volllast- und inkrementelle Lastmuster, da die Logik der beiden Muster in den meisten Fällen unterschiedlich ist
• Führen Sie Tests nicht nur für die zusammenzuführenden Änderungen durch, sondern auch für alle nachgelagerten Abhängigkeiten oder sogar für den gesamten Ladeprozess im Allgemeinen, um Regressionen zu vermeiden.

Schlussfolgerung

In this newsletter, we provided an overview of different methods and approaches for the process of technical testing a Data Vault powered EDW.

We covered testing of different stages of the EDW load including extraction of the data from data sources, loading Data Vault entities, and information delivery process, though primary focus was placed upon loading Data Vault entities.

We also covered unit testing hash key & hash diff calculations.

It is important to make sure that your hashing solution is platform/tool agnostic, especially during the migration process.

We also learned that testing business rules is a key part of the information delivery process since they interpret the data and define what business users see in their reports. We highlighted the importance of unit testing the business rules and cooperation with the business in respect to defining test cases and expected results.

Furthermore, we also stressed the significance of test automation during the development phase as well as for enabling continuous integration and provided recommendations for creating and running a test environment.

We go even deeper into this topic in our webinar. Make sure to watch the Aufnahme umsonst!

- Dmytro Polishchuk (Scalefree)

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.