Technische Tests eines Data Vault-gestützten EDW

Data Vault-gestütztes EDW

In diesem Newsletter stellen wir Ihnen verschiedene Methoden und Ansätze zur Durchführung technischer Tests eines Data Vault-gestützten EDW vor und geben Ihnen einen Überblick darüber.

Die unten beschriebenen Testansätze zielen darauf ab, die Integrität, Zuverlässigkeit, Genauigkeit, Konsistenz und Revisionssicherheit (Auditability) der in Ihre Data-Vault-Entitäten geladenen Daten sowie der darauf aufbauenden Information-Marts sicherzustellen. Dies stellt sicher, dass Ihr Unternehmen auf der Grundlage dieser Daten fundierte Entscheidungen treffen kann.

Was Sie erwartet

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

Testen des Datenextraktionsprozesses

Unabhängig davon, wo die Datenextraktion stattfindet – Datenquelle, Persistent Staging oder Transient Staging – besteht das Hauptziel der Tests in dieser Phase darin, nachzuweisen, dass beim Transport oder Staging der Daten kein Datenverlust (Data Leakage) auftritt. Der Vergleich der Eingangsdaten mit den Zieldaten stellt sicher, dass die Daten nicht versehentlich oder unbefugt aufgrund von Problemen im Extraktionsprozess gelöscht, hinzugefügt oder geändert wurden. Prüfsummen (Checksums), Hash-Summen (Hash Totals) und die Anzahl der Datensätze (Record Counts) sollten verwendet werden, um sicherzustellen, dass die Daten unverändert geblieben sind:

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

Testen von Data Vault

Das Herzstück Ihrer Data-Vault-gestützten EDW-Lösung ist der Raw Data Vault. Dieser enthält rohe und ungefilterte Daten aus Ihren Quellsystemen, die aufgeteilt und basierend auf Business-Keys in Hubs, Links, Satelliten und andere Data-Vault-spezifische Entitäten geladen werden. Dies ist der erste Punkt in der Datenpipeline, an dem die Daten in den gemäß Data Vault modellierten Entitäten landen. Daher sind spezifische Tests erforderlich, um die Konsistenz und Revisionssicherheit der Daten nach dem Befüllen des Raw Data Vault sicherzustellen. Die folgenden Testansätze gelten gleichermaßen 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 (Business Object) wird ein Hub erstellt. Er enthält eine eindeutige Liste von Schlüsseln, die ein Geschäftsobjekt repräsentieren und dieselbe semantische Bedeutung sowie Granularität aufweisen. Auf die in einem Hub befindlichen Geschäftsobjekte wird anschließend von anderen Data-Vault-Entitäten über Hash-Keys verwiesen, die während der Staging-Phase berechnet werden.

Daher müssen an Hubs folgende Tests durchgeführt werden, um deren Konsistenz zu gewährleisten. Für einen Hub mit einem einzelnen Business-Key sollten Tests sicherstellen, dass:

• der Hub eine eindeutige Liste von Business-Keys enthält (Primary-Key- (PK-) Test).
• eine Business-Key-Spalte keine NULL- oder leeren Werte enthält (außer wenn der Business-Key zusammengesetzt ist).

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

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

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

Stellen Sie für beide Arten von Hubs sicher, dass:

• die Hash-Key-Spalte eine eindeutige Liste
  • eine eindeutige Liste von Werten enthält (PK-Test)
  • keine NULL- oder leeren Werte vorhanden sind.

Testen von Links

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

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

Beachten Sie bezüglich des letzten Aufzählungspunkts, dass NULL- und leere Werte in Hub-Referenzen sowie in Hash-Key-Spalten anderer Data-Vault-Entitäten durch Zero-Keys ersetzt werden. Für transaktionale (nicht historisierte) Daten sollten transaktionale Schlüsselspalten zusätzlich zu den Spalten mit Hub-Hash-Keys in die Eindeutigkeitstests einbezogen werden. Stellen Sie sicher, dass auch transaktionale Schlüssel befüllt sind. Solche transaktionalen Schlüssel werden in der Regel nicht gehasht, da im Regelfall keine Hubs für Transaktionen erstellt werden.
Zudem sollten Sie, wie bei den Hubs, sicherstellen, dass die Link-Hash-Key-Spalte eindeutige Werte enthält und keine NULL- oder leeren Werte vorhanden sind.

Testen von Satellites

Satelliten speichern beschreibende Informationen (Attribute) für Geschäftsobjekte (die sich in Hubs befinden) oder Beziehungen zwischen Geschäftsobjekten (die sich in Links befinden). Ein Satellit referenziert entweder einen Hub oder einen Link. Da sich beschreibende Informationen für Geschäftsobjekte und deren Beziehungen im Laufe der Zeit ändern können, wird der Primary-Key eines Satelliten um den Load-Date-Timestamp des Satellitendatensatzes ergänzt.

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

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

Multi-Active-Satelliten enthalten mehrere aktive Datensätze zur gleichen Zeit. Daher sind zusätzliche Schlüsselspalten (z. B. Type Code, Sequence usw.) erforderlich, um einen Datensatz eindeutig zu identifizieren. Diese zusätzlichen Schlüsselspalten müssen Teil des Eindeutigkeitstests eines Multi-Active-Satelliten sein. Darüber hinaus sollten sie auf das Fehlen von NULL- und leeren Werten getestet werden. Der Ansatz zum Testen eines Non-Historized-Satelliten unterscheidet sich ebenfalls geringfügig vom Testen seines Standard-Pendants. Ein Non-Historized-Satellit ist ein spezieller Entitätstyp, der beschreibende Attribute für jeden entsprechenden Datensatz in einem Non-Historized-Link enthält. Der Primary-Key eines Non-Historized-Satelliten ist ein Link-Hash-Key. Daher ist es nicht erforderlich, einen Load-Date-Timestamp in die Prüfung des Primary-Keys einzubeziehen. Stellen Sie bei einem Non-Historized-Satelliten zusätzlich sicher, dass er eine 1:1-Beziehung mit dem entsprechenden Non-Historized-Link aufweist. Die Anzahl der Datensätze (Record Counts) in beiden Entitäten sollte exakt übereinstimmen.

Testen anderer Data Vault-Entitäten

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

• Reference-Hubs und Reference-Satelliten: Die Testansätze ähneln denen von Standard-Hubs und -Satelliten. Der einzige Unterschied besteht darin, dass keine Hash-Keys vorhanden sind und Business-Keys direkt verwendet werden.
• Record-Source-Tracking-Satelliten: Dem Primary-Key-Test wird eine Spalte hinzugefügt, die einen statischen Quellnamen repräsentiert.
• PIT-Table (Business Vault)
  • PK-Test – die Kombination aus dem Hub-/Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
  • Überprüfen Sie für jede Satelliten-Referenz, ob das Paar aus Hub-/Link-Hash-Keys und dem Load-Date-Timestamp im referenzierten Satelliten existiert.
  • Die Hub-/Link-Referenz enthält keine NULL- oder leeren Werte.
• Bridge-Table (Business Vault):
  • PK-Test – die Kombination aus einem Basis-Link-Hash-Key und den Snapshot-Date-Timestamp-Spalten ist eindeutig.
  • Überprüfen Sie für jede Hub- und Link-Referenz, ob das Hub-/Link-Hash-Key-Paar im referenzierten Hub oder Link existiert.

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

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

• Zero-Keys anstelle von NULL-Schlüsseln enthalten.
• Record-Source-Spalten haben, die befüllt sind und dem definierten Muster (z. B. Regex) entsprechen. Prüfen Sie beispielsweise, ob sie den Dateipfad enthalten, bei dem der Name des Ordners auf oberster Ebene den Namen des Quellsystems darstellt und der Dateiname den Zeitstempel der Datenextraktion enthält.
• Keine NULL-Werte in ihren Load- (bzw. Snapshot-) Date-Timestamp-Spalten aufweisen

Testen von Source Marts

Der Source-Mart ist eine der Facetten des Information-Mart-Konzepts in Data Vault. Es handelt sich um ein virtualisiertes Modell auf dem Raw Data Vault mit dem Ziel, die ursprünglichen Quellstrukturen zu replizieren. Er eignet sich hervorragend für Ad-hoc-Berichte, bietet vielen Data Scientists und Power-Usern einen hohen Mehrwert und kann auch verwendet werden, um die Konsistenz und Revisionssicherheit des Ladeprozesses in ein Data-Vault-gestütztes EDW zu testen.

Source-Mart-Objekte sollen genauso aussehen wie die jeweiligen 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 jeweiligen Quelltabellen in der Staging Area vergleichen. Werte und Zeilenanzahlen (Row Counts) der Quellstrukturen sollten exakt mit den jeweiligen 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 in Data Vault ermöglichen es, Business-Keys auf deterministische Weise aus mehreren Quellen parallel zu integrieren. Sie sind das Bindeglied, das verschiedene Data-Vault-Entitäten miteinander verbindet.

Hash-Diffs hingegen werden auf die Satelliten angewendet und helfen dabei, 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. Lesen Sie hier mehr über Anforderungen und Vorlagen für das Hashing. 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 eine konsistente Berechnung zu gewährleisten.

Falls Ihr EDW auf verschiedenen DBMS-Plattformen existiert (z. B. während eines Migrationsprozesses oder aufgrund von Datensicherheitsvorschriften), können die oben genannten Testfälle verwendet werden, um sicherzustellen, dass Ihre Hash-Berechnungen plattformunabhängig (platform-agnostic) sind – was bedeutet, dass sie auf verschiedenen Plattformen das gleiche Ergebnis liefern. Ein typischer Anwendungsfall ist, wenn ein Link auf einer On-Premises-DBMS-Plattform auf einen Hub verweist, 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 Business Rules

Im Gegensatz zu Hard-Rules, welche die Inhalte der Daten nicht verändern oder unterbrechen und so die Revisionssicherheit wahren, setzen Soft-Rules oder Business-Rules die von den Geschäftsanwendern (Business Users) definierten geschäftlichen Anforderungen um. Beispiele für Business-Rules sind:

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

Neben den oben aufgeführten, relativ einfachen Beispielen kann es auch komplexere Business-Rules geben, die anspruchsvolle Berechnungen, Datentransformationen und komplexe Joins beinhalten. Je nach Anwendungsfall landen die Ergebnisse dieser Regeln im Business Vault (z. B. in einem Business-Satelliten) und später in der Information-Mart-Schicht, wo sie von den Geschäftsanwendern konsumiert werden. Daher ist das Testen von Business-Rules ein wichtiger Teil des Informationsbereitstellungsprozesses (Information Delivery Process).

Business-Rules sind in der Regel auch Gegenstand von Unit-Tests, die kontinuierlich während des Entwicklungs- und CI-Prozesses durchgeführt werden müssen. Um einen solchen Unit-Test durchzuführen, werden bestimmte Erwartungswerte benötigt, die im besten Fall vom Fachbereich (Business) bereitgestellt werden – beispielsweise ein erwarteter Nettoumsatzwert für ein bestimmtes Produkt oder eine Reihe von Produkten in einer bestimmten Filiale an einem bestimmten Tag auf der Grundlage realer Daten. Die Nettoumsatzberechnung aus dem Business Vault wird dann gegen das vorgegebene erwartete Ergebnis getestet.

Testautomatisierung und Continuous Integration

Alle oben beschriebenen Tests sollten so weit wie möglich automatisiert und von den EDW-Entwicklern während des Entwicklungsprozesses ausgeführt werden. Erfolgreiche Tests sollten eine zwingende Voraussetzung für die Integration neuer Änderungen in Ihre EDW-Codebasis sein. Dies lässt sich durch den Einsatz von DevOps-Tools und die Aktivierung von Continuous Integration (CI) in Ihrem EDW-Entwicklungslebenszyklus erreichen. Die Ausführung automatisierter Tests bei jedem Einchecken oder Zusammenführen (Mergen) von Code stellt sicher, dass Probleme mit der Datenkonsistenz oder Fehler frühzeitig erkannt und behoben werden, bevor sie in die Produktion übergeben werden. In der Regel wird für die Durchführung automatisierter Tests eine separate Test- (oder CI-) Umgebung erstellt.

Hier sind einige allgemeine Empfehlungen für das Erstellen und Betreiben einer Testumgebung:

• Gestalten Sie die CI-Umgebung so ähnlich wie möglich zur Produktionsumgebung.
• Erstellen Sie Test-Quelldatenbanken und Quelldateien, die von realen Daten abgeleitet sind.
• Die Test-Quelldateien und -Quelldatenbanken sollten klein sein, damit die Tests schnell ausgeführt werden können.
• Die Test-Quelldateien und -Quelldatenbanken sollten zudem statisch sein, damit die erwarteten Ergebnisse im Voraus bekannt sind.
• Testen Sie Full-Load- und Incremental-Load-Muster, da sich die Logik beider Muster in den meisten Fällen unterscheidet.
• Führen Sie Tests nicht nur für die zusammenzuführenden Änderungen aus, sondern auch für alle nachgelagerten Abhängigkeiten (Downstream Dependencies) oder sogar für den gesamten Ladeprozess im Allgemeinen, um Regressionen zu vermeiden.

Fazit

In diesem Newsletter haben wir Ihnen einen Überblick über verschiedene Methoden und Ansätze für das technische Testen eines Data-Vault-gestützten EDW gegeben.

Wir haben das Testen verschiedener Phasen des EDW-Ladeprozesses behandelt, einschließlich der Extraktion von Daten aus Datenquellen, dem Laden von Data-Vault-Entitäten und dem Informationsbereitstellungsprozess (Information Delivery Process), 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 werkzeugunabhängig (platform-/tool-agnostisch) ist, insbesondere während des Migrationsprozesses.

Wir haben auch gelernt, dass das Testen von Business-Rules ein wesentlicher Bestandteil des Informationsbereitstellungsprozesses ist, da diese die Daten interpretieren und definieren, was Geschäftsanwender in ihren Berichten sehen. Wir haben die Bedeutung von Unit-Tests für die Business-Rules und die Zusammenarbeit mit dem Fachbereich (Business) bei 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 von Continuous Integration betont und Empfehlungen für die Erstellung und den Betrieb einer Testumgebung gegeben.

In unserem Webinar gehen wir noch tiefer auf dieses Thema ein. Nutzen Sie die Gelegenheit und sehen Sie sich die Aufzeichnung kostenlos an!