Technische Tests eines Data Vault-basierten EDW

Data Vault-basiertes EDW

In diesem Newsletter geben wir einen Überblick über die verschiedenen Methoden und Ansätze bei der Durchführung von technischen Tests für ein Data Vault-basiertes EDW.

Die unten beschriebenen Testansätze zielen darauf ab, die Integrität, Zuverlässigkeit, Genauigkeit, Konsistenz und Nachvollziehbarkeit der in Ihre Data Vault Entitäten geladenen Daten sowie der darauf aufbauenden Information Marts sicherzustellen. All dies, um zu gewährleisten, dass Ihr Unternehmen Entscheidungen sicher auf der Grundlage dieser Daten treffen kann.

Was Sie erwartet

Sie erhalten einen Überblick über Testansätze, die für verschiedene Schichten Ihrer EDW-Lösung geeignet sind, angefangen von der Datenextraktion aus Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu Information Marts, die von Endbenutzern 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 erörtern. Nichtsdestotrotz liegt der Hauptfokus dieses Newsletters auf dem Testen der Data Vault Entitäten in den Schichten Raw Vault und Business Vault.

Testen des Datenextraktionsprozesses

Unabhängig davon, wo die Datenextraktion stattfindet – Datenquelle, persistentes Staging, transientes Staging – ist das Hauptziel des Testens in dieser Phase der Nachweis, dass es beim Transport oder Staging der Daten zu keinem Verlust kommt. Der Vergleich der Eingabedaten und der Zieldaten stellt sicher, dass die Daten aufgrund von Problemen im Extraktionsprozess nicht versehentlich oder böswillig gelöscht, hinzugefügt oder geändert wurden.
Zur Sicherstellung der Datenintegrität sollten Prüfsummen, Hash-Summen und Datensatzanzahlen verwendet werden:

• Stellen Sie sicher, dass die Prüfsummen des Quell-Datasets und der Ziel-Staging-Tabelle übereinstimmen.
• Stellen Sie sicher, dass die numerische Summe eines oder mehrerer Felder in einem Quell-Dataset (auch bekannt als Hash-Summe) mit der Summe der entsprechenden Spalten in der Zieltabelle übereinstimmt. Eine solche Summe kann Daten enthalten, die normalerweise nicht in Berechnungen verwendet werden (z. B. numerische ID-Werte, Kontonummern usw.).
• Stellen Sie sicher, dass die Zeilenanzahl zwischen der Quelle und der Ziel-Staging-Tabelle übereinstimmt.

Testen des Data Vault

Der Kern Ihrer Data Vault-basierten EDW-Lösung ist ein Raw Data Vault, der rohe und ungefilterte Daten aus Ihren Quellsystemen enthält. Diese wurden aufgeteilt und basierend auf Business Keys in Hubs, Links, Satellites und andere Data Vault-spezifische Entitäten geladen. 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 die Konsistenz und Nachvollziehbarkeit der Daten nach der Befüllung des Raw Data Vault zu gewährleisten. Die unten aufgeführten Testansätze gelten auch für Business Vault Entitäten.

Testen von Hubs

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

Daher sind die folgenden Tests erforderlich, um die Konsistenz von Hubs sicherzustellen:
Für einen Hub mit einem einzelnen Business Key sollten Tests Folgendes sicherstellen:

• Ein Hub enthält eine eindeutige Liste von Business Keys (Primärschlüssel (PK)-Test)
• Eine Business-Key-Spalte enthält keine NULL- oder leeren Werte (außer wenn der Business Key zusammengesetzt ist)

Wenn ein Hub einen zusammengesetzten Business Key hat, stellen Sie Folgendes sicher:

• Die Kombination der Werte in den Business-Key-Spalten ist eindeutig (PK-Test)
• Business-Key-Spalten enthalten nicht alle gleichzeitig NULL- oder leere Werte

Die Gültigkeit des letztgenannten Punktes hängt auch von der Natur der Geschäftsobjekte selbst ab. Es kann auch sein, dass NULL- oder leere Werte in keiner der Business-Key-Spalten zulässig sind.

Für beide Arten von Hubs stellen Sie Folgendes sicher:

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

Testen von Links

Ein typischer Link definiert Beziehungen zwischen Geschäftsobjekten, indem er eindeutige Kombinationen von Hash Keys der verbundenen Hubs speichert. Der Primärschlüssel des Links oder der Link-Hash-Key identifiziert eine solche Kombination eindeutig. Daher sollten Link-Tests Folgendes überprüfen:

• Die Kombination der verbundenen Hub-Referenzen (Hub-Hash-Keys) ist eindeutig (PK-Test)
• Jeder Hub-Hash-Key-Wert existiert im referenzierten Hub
• Hub-Referenzen enthalten keine NULL- oder leeren Werte

Bezüglich des letzten Punktes ist anzumerken, dass NULL- und leere Werte in Hub-Referenzen sowie in Hash-Key-Spalten anderer Data Vault-Entitäten durch Zero Keys ersetzt werden.
Bei transaktionalen (nicht-historisierten) Daten sollten Spalten mit transaktionalen Schlüsseln zusätzlich zu den Spalten mit Hub-Hash-Keys in die Eindeutigkeitstests einbezogen werden. Stellen Sie sicher, dass auch die transaktionalen Schlüssel befüllt sind. Solche transaktionalen Schlüssel werden in der Regel nicht gehasht, da in der Regel keine Hubs für Transaktionen erstellt werden.
Und wie bei Hubs stellen Sie sicher, dass die Link-Hash-Key-Spalte eindeutige Werte enthält und keine NULL- oder leeren Werte vorhanden sind.

Testen von Satellites

Satellites speichern beschreibende Informationen (Attribute) für Geschäftsobjekte (in Hubs) oder Beziehungen zwischen Geschäftsobjekten (in Links). Ein Satellite referenziert entweder 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 dem Primärschlüssel eines Satelliten ein Load-Date-Zeitstempel des Datensatzes hinzugefügt.

Vor diesem Hintergrund sollten Tests für einen Satellite Folgendes sicherstellen:

• Die Kombination aus einer Hub-/Link-Referenz (dem Hash Key) und dem Load-Date-Zeitstempel eines Datensatzes ist eindeutig (PK-Test)
• Jeder Hub- oder Link-Hash-Key-Wert existiert im referenzierten Hub oder Link
• Hub- oder Link-Referenzen enthalten keine NULL- oder leeren Werte

Multi-aktive Satellites enthalten gleichzeitig mehrere aktive Datensätze. Daher sind zusätzliche Schlüsselspalten (z. B. Typcode, Sequenz usw.) erforderlich, um einen Datensatz eindeutig zu identifizieren. Diese zusätzlichen Schlüsselspalten müssen Teil des Eindeutigkeitstests eines multi-aktiven Satellitensein. Zusätzlich sollte getestet werden, ob sie keine NULL- oder leeren Werte enthalten.
Der Ansatz zum Testen eines nicht-historisierten Satelliten unterscheidet sich ebenfalls etwas vom Testen seines Standard-Pendants. Ein nicht-historisierter Satellite ist ein spezieller Entitätstyp, der beschreibende Attribute für jeden entsprechenden Datensatz in einem nicht-historisierten Link enthält. Der Primärschlüssel eines nicht-historisierten Satelliten ist ein Link-Hash-Key. Daher ist es nicht erforderlich, einen Load-Date-Zeitstempel in die Primärschlüsselprüfung aufzunehmen. Stellen Sie für einen nicht-historisierten Satellitenzusätzlich sicher, dass er eine 1:1-Beziehung zum entsprechenden nicht-historisierten Link hat. Die Anzahl der Datensätze in beiden Entitäten sollte exakt übereinstimmen.

Testen anderer Data Vault-Entitäten

Es gibt weitere spezielle Entitätstypen im Data Vault, die im Hinblick auf das Testen erwähnenswert sind:

• Referenz-Hubs und Referenz-Satellites: Die Testansätze ähneln denen von Standard-Hubs und -Satellites. Der einzige Unterschied besteht darin, dass es keine Hash Keys gibt und Business Keys direkt verwendet werden.
• Record-Source-Tracking-Satellites: Eine Spalte, die einen statischen Quellnamen darstellt, wird zum Primärschlüssel-Test hinzugefügt.
• PIT-Tabelle (Business Vault):
  • PK-Test – die Kombination aus dem Hub-/Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten 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
  • Die Hub-/Link-Referenz enthält keine NULL- oder leeren Werte
• Bridge Tabelle (Business Vault):
  • PK-Test – die Kombination aus einem Basis-Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig
  • Für jede Hub- und Link-Referenz prüfen Sie, ob ein Paar aus Hub-/Link-Hash-Key im referenzierten Hub oder Link vorhanden ist

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

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

• Anstelle von NULL-Schlüsseln Zero Keys enthalten
• Record-Source-Spalten haben, die befüllt sind und dem definierten Muster (z. B. Regex) entsprechen. Überprüfen Sie beispielsweise, ob sie den Dateipfad enthält, wobei der Name des obersten Ordners den Namen des Quellsystems und der Dateiname den Zeitstempel der Datenextraktion enthält
• Keine NULL-Werte in ihren Ladezeitstempel- (Snapshot-) Spalten haben

Testen von Source Marts

Der Source Mart ist eine der Facetten des Information Mart Konzepts im Data Vault. Es handelt sich um ein virtualisiertes Modell, das auf dem Raw Data Vault aufbaut und das Ziel verfolgt, die ursprünglichen Quellstrukturen zu replizieren. Er eignet sich hervorragend für Ad-hoc-Berichte und bietet vielen Data Scientists und Power-Usern einen höheren Mehrwert. Zudem kann er verwendet werden, um die Konsistenz und Nachvollziehbarkeit des Ladeprozesses in ein Data Vault-basiertes EDW zu testen.

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

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

Testen von Hash Key und Hash-Diff-Berechnungen

Hash Keys im Data Vault ermöglichen die deterministische Integration von Business Keys aus mehreren Quellen parallel. Sie sind das Bindeglied, das verschiedene Data Vault-Entitäten miteinander verbindet.

Hash Diffs hingegen werden auf die Satellites angewendet und helfen, Unterschiede in beschreibenden Attributen während des Datenladeprozesses zu identifizieren.

Es ist wichtig, Unit-Tests für die in Ihrem EDW verwendeten Hash-Key- und Hash-Diff-Berechnungen einzuführen, um sicherzustellen, dass die gehashten Werte gemäß den definierten Hashing-Standards berechnet werden. Weitere Informationen zu Anforderungen und Vorlagen für das Hashing finden Sie hier. Testfälle für solche Unit-Tests sollten so viele Kombinationen verschiedener Datentypen und Werte (z. B. NULL- und leere Werte) wie möglich abdecken, um sicherzustellen, dass sie konsistent berechnet werden.

Falls Ihr EDW auf verschiedenen DBMS-Plattformen existiert (z. B. während eines 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. auf verschiedenen Plattformen dasselbe Ergebnis liefern. Ein häufiger Anwendungsfall ist, wenn ein Link auf einer On-Premise-DBMS-Plattform einen Hub referenziert, der bereits auf eine Cloud-Plattform migriert wurde. Solche Unit-Tests können auf beiden Plattformen ausgeführt werden, um die Konsistenz des Hashings während einer Migration sicherzustellen.

Testen von Geschäftsregeln

Im Gegensatz zu den Hard Rules, die den Inhalt der Daten nicht verändern oder unterbrechen und die Nachvollziehbarkeit gewährleisten, setzen Soft Rules oder Geschäftsregeln die von den Fachanwendern formulierten Geschäftsanforderungen durch. Beispiele für Geschäftsregeln können sein:

• Verkettung (Nachname und Vorname)
• Standardisierung von Telefonnummern
• Berechnung des Gesamtumsatzes (Aggregation)
• Coalescing usw.

Neben den oben genannten relativ einfachen Beispielen kann es auch komplexere Geschäftsregeln geben, die anspruchsvolle Berechnungen, Datentransformationen und komplexe Joins 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 Fachanwendern genutzt werden. Daher ist das Testen von Geschäftsregeln ein wichtiger Bestandteil des Informationsbereitstellungsprozesses.

Geschäftsregeln sind in der Regel auch Gegenstand von Unit-Tests, die während der Entwicklung und des CI-Prozesses kontinuierlich durchgeführt werden müssen. Um einen solchen Unit-Test durchzuführen, benötigen wir einige erwartete Werte, idealerweise vom Fachbereich bereitgestellt, d. h. einen erwarteten Nettoumsatzwert für ein definiertes Produkt oder eine Reihe von Produkten in einem bestimmten Geschäft an einem bestimmten Tag auf Basis der realen Daten. Die Nettoumsatzberechnung aus unserem Business Vault wird dann mit dem vorgegebenen erwarteten Ergebnis verglichen.

Testautomatisierung und kontinuierliche Integration

Alle oben beschriebenen Tests sollten so weit wie möglich automatisiert und von EDW-Entwicklern während des Entwicklungsprozesses ausgeführt werden. Erfolgreiche Tests sollten eine obligatorische Bedingung für die Einführung jeglicher neuer Änderung an Ihrer EDW-Codebasis sein. Dies ist durch den Einsatz von DevOps-Tools und die Aktivierung der kontinuierlichen Integration (CI) in Ihrem DWH-Entwicklungszyklus erreichbar. Die Ausführung automatisierter Tests bei jedem Check-in oder Merge von Code stellt sicher, dass Datenkonsistenzprobleme oder Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion gelangen. In der Regel wird für die Durchführung automatisierter Tests eine separate Test- (oder CI-) Umgebung eingerichtet.

Hier sind einige allgemeine Empfehlungen für die Erstellung und Ausführung einer Testumgebung:

• Erstellen Sie die CI-Umgebung so ähnlich wie möglich der Produktionsumgebung
• Erstellen Sie Testquelldatenbanken und Quelldateien, die von realen Daten abgeleitet sind
• Die Testquelldateien und Quelldatenbanken sollten klein sein, damit Tests schnell ausgeführt werden können
• Die Testquelldateien und Quelldatenbanken sollten auch statisch sein, sodass die erwarteten Ergebnisse im Voraus bekannt sind
• Testen Sie sowohl Full-Load- als auch Incremental-Load-Muster, da die Logik beider Muster in den meisten Fällen unterschiedlich ist
• Führen Sie Tests nicht nur gegen die zu mergenden Änderungen durch, sondern auch gegen alle nachgelagerten Abhängigkeiten oder sogar den gesamten Ladeprozess im Allgemeinen, um Regressionen zu vermeiden

Fazit

In diesem Newsletter haben wir einen Überblick über verschiedene Methoden und Ansätze für den Prozess des technischen Testens eines Data Vault-basierten EDW gegeben.

Wir haben das Testen verschiedener Phasen des EDW-Ladevorgangs behandelt, einschließlich der Datenextraktion aus Datenquellen, des Ladens von Data Vault-Entitäten und des Informationsbereitstellungsprozesses, wobei der Hauptfokus auf dem Laden von Data Vault-Entitäten lag.

Wir haben auch das Unit-Testing von Hash-Key- und Hash-Diff-Berechnungen behandelt.

Es ist wichtig sicherzustellen, dass Ihre Hashing-Lösung plattform- und toolunabhängig ist, insbesondere während des Migrationsprozesses.

Wir haben auch erfahren, dass das Testen von Geschäftsregeln ein wichtiger Bestandteil des Informationsbereitstellungsprozesses ist, da sie die Daten interpretieren und definieren, was Fachanwender in ihren Berichten sehen. Wir haben die Bedeutung des Unit-Testings der Geschäftsregeln und der Zusammenarbeit mit dem Fachbereich hinsichtlich der Definition von Testfällen und erwarteten Ergebnissen hervorgehoben.

Darüber hinaus haben wir die Bedeutung der Testautomatisierung während der Entwicklungsphase sowie für die Ermöglichung der kontinuierlichen Integration betont und Empfehlungen für die Erstellung und Ausführung einer Testumgebung gegeben.

In unserem Webinar gehen wir noch tiefer in dieses Thema ein. Sehen Sie sich die Aufzeichnung kostenlos an!

- Dmytro Polishchuk (Scalefree)