Skip to main content
search
0
CartClose Cart
All Posts By

Dmytro Polishchuk

Dmytro Polishchuk is a Principal BI Consultant at Scalefree with six years of experience in business intelligence and cloud architecture. A CDVP2 and Snowflake certified expert, he specializes in large scale migrations and automated CI/CD pipelines for global banking and industrial groups. Dmytro combines finance driven analytical skills with deep expertise in dbt, Azure, and Data Vault 2.0 modeling.

In Anfänger, Datenwerkzeuge

Das Potenzial von Microsoft Fabric für Business Intelligence

Microsoft Fabric

Microsoft Fabric für Business Intelligence

Microsoft Fabric ist eine cloudbasierte All-in-One-Analyseplattform, die eine einheitliche Umgebung für Datenexperten und Geschäftsanwender bietet, um gemeinsam an Datenlösungen zu arbeiten. Diese leistungsstarke Plattform unterstützt Unternehmen dabei, Workflows zu automatisieren, die Produktivität zu steigern und wertvolle Erkenntnisse aus ihren Daten zu gewinnen.

In der heutigen datengesteuerten Welt setzen Unternehmen zunehmend auf Business-Intelligence-Lösungen (BI), um fundierte Erkenntnisse aus ihren Daten zu generieren. BI-Lösungen helfen Unternehmen dabei, ihre Entscheidungsfindung zu verbessern, ihre Abläufe zu optimieren und sich einen nachhaltigen Wettbewerbsvorteil zu verschaffen.

Das Potenzial von Microsoft Fabric für Business Intelligence -Lösungen

Microsoft Fabric ist eine neue, innovative Datenanalyseplattform, welche die Art und Weise, wie Unternehmen Entscheidungen treffen, revolutionieren kann. Mit Fabric können Organisationen all ihre Daten an einem einzigen Ort erfassen, speichern, verarbeiten und analysieren, indem sie ein einheitliches Portfolio an Tools und Diensten nutzen. Dies ermöglicht es, schneller und einfacher als je zuvor Erkenntnisse aus Daten zu gewinnen. In diesem Beitrag untersuchen wir das Potenzial von Microsoft Fabric für Business-Intelligence-Lösungen. Wir erörtern, wie Fabric genutzt werden kann, um die Datenqualität zu verbessern, Analyse-Workflows zu optimieren und Anwendern passgenaue Erkenntnisse bereitzustellen. Dieses Webinar ist für alle interessant, die mehr darüber erfahren möchten, wie sie mit Microsoft Fabric einen maximalen Mehrwert aus ihren Daten ziehen können. Besonders wertvoll ist es für Data Engineers, Analysten, Business-Intelligence-Experten sowie IT-Entscheidungsträger. Registrieren Sie sich jetzt für dieses kostenlose Webinar und erfahren Sie, wie Microsoft Fabric Ihnen helfen kann, Ihre Business-Intelligence-Lösungen auf ein neues Niveau zu heben!

Watch webinar recording

In this article:

Was Sie erwartet

Dieser Newsletter zeigt Ihnen die transformative Kraft von Microsoft Fabric für Business-Intelligence-Lösungen. Sie lernen die verschiedenen Workloads und Experiences kennen, die Microsoft Fabric bietet, und erlangen ein umfassendes Verständnis seiner Funktionen. Zudem entdecken Sie die Vorteile, die Microsoft Fabric für die datengesteuerte Entscheidungsfindung bietet, um fundierte Entscheidungen zu treffen, die Ihr Unternehmen voranbringen. Schließlich tauchen Sie tief in das Potenzial ein, das Microsoft Fabric für die Verbesserung von Business-Intelligence-Lösungen bereithält, und erfahren, wie Sie neue Dimensionen von Erkenntnissen und Entscheidungsprozessen erschließen können.

Um noch tiefer in das Thema einzusteigen, können Sie sich die Webinar-Aufzeichnung kostenlos ansehen. Klicken Sie hier, um sich zu registrieren.

Was ist Microsoft Fabric?

Microsoft Fabric ist eine cloudbasierte All-in-One-Analyseplattform, die eine einheitliche Umgebung für Datenexperten und Geschäftsanwender bietet, um gemeinsam an Datenlösungen zu arbeiten. Fabric bietet eine Suite integrierter Dienste, mit denen Sie Daten auf einer einzigen Plattform erfassen, speichern, verarbeiten und analysieren können, die auf Software-as-a-Service (SaaS) basiert.

Microsoft Fabric bietet Tools für Anwender aller Erfahrungsstufen im Datenbereich und lässt sich nahtlos mit den Tools verbinden, die Unternehmen für ihre Entscheidungsfindung nutzen.
Fabric selbst fungiert als Dach für die folgenden cloudbasierten Microsoft-Dienste, die das Microsoft-Analytics-Portfolio bilden:

  • Azure Data Factory
  • Azure Event Hubs
  • Azure Data Explorer
  • Azure Artificial Intelligence
  • Azure Databricks
  • Azure Synapse Spark Pools
  • Azure Synapse Analytics
  • and Microsoft Power BI

Die oben genannten Komponenten wurden innerhalb von Microsoft Fabric vollständig überarbeitet und auf ein neues Niveau gehoben.

Workloads of Microsoft Fabric

Fabric umfasst die folgenden Workloads und Experiences:

  • Datenintegration
  • Data Engineering
  • Data Warehousing
  • Data Science
  • Real-Time Analytics
  • Business Intelligence
  • Insight to Action

Das Fundament dieser Experiences in Fabric ist der Data Lake, der als OneLake bezeichnet wird. Die folgende Abbildung veranschaulicht das Konzept von Microsoft Fabric.

Microsoft Fabric

Betrachten wir die einzelnen Komponenten von Fabric im Detail.

Datenintegration

Die Workload für Datenintegration in Microsoft Fabric, genannt Data Factory, bringt Datenbewegungsfunktionen sowohl in Dataflows als auch in Data Pipelines.

  • Dataflows bieten flexible und benutzerfreundliche Möglichkeiten zur Transformation von Daten mit über 300 Transformationsoptionen. Sie basieren auf der vertrauten Power-Query-Experience, die in verschiedenen Microsoft-Produkten und -Diensten wie Excel, Power BI, Power Platform und anderen verfügbar ist.
  • Data Pipelines ermöglichen es Ihnen, flexible Daten-Workflows zu erstellen, um Ihre organisatorischen Ziele zu erreichen. Sie können die integrierten Datenorchestrierungsfunktionen nutzen, um Ihre Dataflows zu aktualisieren, große Datensätze zu verarbeiten und komplexe Kontrollfluss-Pipelines zu definieren.

Data Engineering

Die Data-Engineering-Experience oder Synapse Data Engineering bietet eine erstklassige Spark-Plattform mit umfassenden Entwicklungsumgebungen. Dies ermöglicht es Data Engineers, umfangreiche Datentransformationen durchzuführen, und erleichtert den breiten Zugriff auf Daten über das Lakehouse.

Microsoft Fabric bietet verschiedene Data-Engineering-Funktionen, um sicherzustellen, dass Ihre Daten leicht zugänglich, gut organisiert und von hoher Qualität sind. Auf der Data-Engineering-Startseite haben Sie die folgenden Optionen:

  • Lakehouse
    Erstellen und Verwalten von Lakehouses. Ein Lakehouse ist ein logischer Speicherort in OneLake, an dem Sie strukturierte und unstrukturierte Daten mithilfe verschiedener Tools und Frameworks speichern und verwalten. Mit der Shortcut-Funktion können Sie sogar ein externes Speicherkonto in Ihr Lakehouse einbinden. Sie können den SQL-Endpunkt verwenden, um Lakehouse-Tabellen abzufragen, wobei dieser jedoch nur schreibgeschützte Abfragen unterstützt.
  • Notebook
    Schreiben und Ausführen von Code in gängigen Programmiersprachen wie Python, R und Scala. Nutzen Sie Notebooks für die Datenerfassung, -transformation, -analyse und andere Datenverarbeitungsaufgaben.
  • Environment
    Innerhalb eines Environments haben Sie die Flexibilität, aus einer Vielzahl von Spark-Runtimes zu wählen, Ihre Rechenressourcen zu konfigurieren und Bibliotheken zu integrieren, entweder aus öffentlichen Repositories oder durch das Hochladen lokal erstellter, benutzerdefinierter Bibliotheken. Die Zuweisung dieser Umgebungen (Environments) zu Ihren Notebooks und Spark-Jobdefinitionen ist ein nahtloser Prozess.
  • Spark-Jobdefinition
    Definieren, planen und verwalten Sie Spark-Jobs, um Big Data in Ihrem Lakehouse zu verarbeiten, Transformationslogik auf die Daten anzuwenden und vieles mehr.
  • Data Pipeline
    Entwerfen und orchestrieren Sie Pipelines, um Daten in Ihr Lakehouse zu kopieren, Spark-Jobs und Notebooks zur Verarbeitung großer Datenmengen zu planen und Daten-Workflows durch die Integration mit Data Factory zu automatisieren.

Data Warehousing

Das Data Warehouse oder Synapse Data Warehouse ist ein Lake-zentriertes Repository zur Speicherung und Analyse strukturierter Daten, das auf einer verteilten Verarbeitungs-Engine basiert. Die Data-Warehousing-Workload profitiert von den umfassenden Funktionen der SQL-Engine über ein offenes Delta-Lake-Format. Dabei handelt es sich um Parquet-Dateien, die als Delta-Lake-Logs veröffentlicht und in OneLake gespeichert werden. Delta-Lake-Logs ermöglichen ACID-Transaktionen. Ein Warehouse kann nur strukturierte Daten enthalten. Hier können Sie Daten mit SQL nicht nur lesen, sondern auch Schreib- und Aktualisierungsvorgänge (Inserts und Updates) ausführen.

Data Science

Die Data-Science-Experience oder Synapse Data Science ermöglicht die Erstellung, Bereitstellung und Operationalisierung von Machine-Learning-Modellen. Data Scientists werden in die Lage versetzt, Unternehmensdaten mit Vorhersagen anzureichern, und Business-Analysten können diese Vorhersagen direkt in ihre BI-Berichte integrieren. Data Science in Fabric bietet Ihnen die folgenden Optionen:

  • ML-Modell
    Nutzen Sie Machine-Learning-Modelle, um Ergebnisse vorherzusagen und Unregelmäßigkeiten in Datensätzen zu identifizieren.
  • Experiment
    Steigen Sie in die Experimentierphase ein, indem Sie verschiedene Modelle erstellen, ausführen und deren Entwicklung überwachen, um Hypothesen zu validieren.
  • Notebook
    Nutzen Sie die Notebook-Funktion, um in die Datenexploration einzutauchen und Machine-Learning-Lösungen über Apache-Spark-Anwendungen zu erstellen.
  • Environment
    Diese Option dient demselben Zweck wie in der Data-Engineering-Experience.

Real-Time Analytics

Real-Time Analytics in Fabric oder Synapse Real-Time Analytics ist eine vollständig verwaltete Big-Data-Analyseplattform, die für Streaming- und Zeitreihendaten optimiert ist. Sie nutzt die Kusto Query Language (KQL), eine Engine mit außergewöhnlicher Performance für die Suche in strukturierten, semistrukturierten und unstrukturierten Daten. Real-Time Analytics ist vollständig in die gesamte Palette der Fabric-Produkte für Datenlade-, Datentransformations- und erweiterte Visualisierungsszenarien integriert. Es gibt drei Komponenten von Real-Time Analytics in Fabric:

  • KQL-Datenbank
    Der Ort zum Speichern von Streaming-Daten. Sie nutzt OneLake als zugrunde liegendes Speichersystem.
  • KQL-Queryset
    Führen Sie Abfragen auf Ihren Daten aus, um teilbare Tabellen und Visualisierungen zu erstellen. Speichern, verwalten, exportieren und teilen Sie KQL-Abfragen. Ein KQL-Queryset ist das Pendant zu SSMS für eine SQL-Datenbank.
  • Eventstream
    Erfassen, transformieren und leiten Sie Echtzeit-Event-Streams im gewünschten Format an verschiedene Ziele weiter, ganz ohne Programmieraufwand (No-Code). Es ist eine zentrale Drehscheibe für Streaming-Daten, an der mehrere Quellen (einschließlich Event Hub) und verschiedene Ziele (einschließlich KQL-Datenbank) eingerichtet werden können.

Business Intelligence

Auf der BI-Seite bietet Fabric mit Power BI eine der weltweit führenden Business-Intelligence-Plattformen. Power BI vereint eine Reihe von Diensten, Tools und Konnektoren, die Ihre Daten in interaktive visuelle Berichte und Dashboards verwandeln. In Fabric gibt es einige neue Funktionen und Erweiterungen für die Arbeit mit Fabric-Objekten und -Experiences. Dazu gehören:

  • Der Direct-Lake-Modus, eine Verbindung, die auf dem direkten Laden von Dateien im Parquet-Format aus einem Data Lake basiert, ohne dass die Daten in ein Dataset importiert werden müssen.
  • Die Integration mit Synapse Real-Time Analytics zur Erstellung von Berichten nahezu in Echtzeit.
  • Semantic Link, der das Laden von Daten aus Power-BI-Datasets in die Data-Science-Experience und andere Umgebungen ermöglicht..

Insight to Action

Insight to Action in Fabric bietet den Data Activator, eine Experience zur automatischen Auslösung von Aktionen, sobald bestimmte Bedingungen in den eingehenden Daten erfüllt sind. Der Data Activator arbeitet mit Eventstreams für Echtzeitdaten und mit Power BI für Batch-Daten. Es gibt drei mögliche Aktionen, die nach dem Erkennen der Bedingungen konfiguriert werden können:

  • E-Mail: Lassen Sie sich per E-Mail benachrichtigen.
  • Teams-Nachricht: Senden Sie eine Benachrichtigung an eine Person oder einen Kanal in Teams.
  • Benutzerdefinierte Aktion: Führen Sie eine benutzerdefinierte Aktion aus, um einen Power-Automate-Workflow aufzurufen.

Data Lake

OneLake ist die zentrale Komponente aller Fabric-Dienste. Es ist ein integrierter, einheitlicher Data Lake, der alle Organisationsdaten speichert und von allen Fabric-Experiences genutzt wird. OneLake verwendet ADLS Gen2 als zugrunde liegenden Speicher.

Um die Verwaltung im gesamten Unternehmen zu vereinfachen, ist OneLake hierarchisch organisiert. Jeder Tenant besitzt genau eine OneLake-Instanz, die einen einzigen Namensraum bereitstellt, der sich über Benutzer, Regionen und sogar Clouds erstreckt. Zur einfachen Handhabung sind die Daten in OneLake in überschaubare Container unterteilt.

Ähnlich wie bei Microsoft OneDrive kann jeder Entwickler oder jede Geschäftseinheit innerhalb des Tenants eigene Arbeitsbereiche (Workspaces) in OneLake erstellen. Sie können Daten in ihre eigenen Lakehouses laden und mit der Verarbeitung, Analyse und gemeinsamen Bearbeitung der Daten beginnen. Alle Fabric-Experiences sind an OneLake gebunden und arbeiten darauf aufbauend.

Welche Potenziale bietet Microsoft Fabric also?

Microsoft Fabric hat das Potenzial, die Art und Weise, wie Unternehmen Business-Intelligence-Lösungen entwickeln und bereitstellen, grundlegend zu verändern. Hier sind einige der wichtigsten Aspekte:

  • Einheitliche Datenplattform: Microsoft Fabric bietet eine einheitliche Datenplattform für die Speicherung und Analyse aller Datentypen, einschließlich strukturierter, semistrukturierter und unstrukturierter Daten. Dies bedeutet, dass Unternehmen ein einziges Toolset nutzen können, um alle Aspekte ihrer Datenpipeline zu verwalten – von der Datenerfassung und -aufbereitung bis hin zur Datenanalyse und -visualisierung. Dies trägt maßgeblich dazu bei, die Komplexität zu reduzieren und die Effizienz zu steigern.
  • End-to-End-Analysen: Microsoft Fabric bietet ein vollständiges Spektrum an Funktionen für die Erstellung und Bereitstellung von End-to-End-Analyselösungen. Dies umfasst Data Engineering, Data Science, Data Warehousing und Business Intelligence. Dies vereinfacht die Entwicklung sowie Bereitstellung von Analyselösungen und reduziert den Bedarf an spezialisiertem Fachwissen.
  • KI-gestützte Erkenntnisse: Microsoft Fabric integriert KI- und Machine-Learning-Funktionen auf der gesamten Plattform. Diese können genutzt werden, um Aufgaben zu automatisieren, Erkenntnisse zu generieren und die Genauigkeit von Vorhersagen zu verbessern. So können Unternehmen schneller fundierte Entscheidungen treffen.
  • Eine einheitliche Plattform für unterschiedliche Fachbereiche: Datenexperten mit verschiedenen Hintergründen können ihre Fähigkeiten einbringen, um gemeinsam an einer einzigen Datenlösung zu arbeiten. Diese integrative Umgebung ermöglicht es Personen aus unterschiedlichen Disziplinen und mit verschiedenen Qualifikationsstufen, ihr Fachwissen in ein gemeinsames Datenprojekt einzubringen.
  • Reduzierung von Datensilos: Da Daten nicht mehr zwischen verschiedenen Systemen verschoben werden müssen, wird eine ganzheitliche Sicht auf das Unternehmen erheblich erleichtert.
  • Kostensenkung: Microsoft Fabric hilft Unternehmen dabei, die mit der Entwicklung und Bereitstellung von Business-Intelligence-Lösungen verbundenen Kosten zu senken. Da die Anschaffung und Wartung mehrerer Einzelsysteme entfällt, wird eine Reihe von Funktionen bereitgestellt, die Aufgaben automatisieren und die Effizienz steigern können.

Im Wesentlichen verspricht Microsoft Fabric, die Entwicklung und Bereitstellung robuster Business-Intelligence-Lösungen zu vereinfachen und sie für Unternehmen jeder Größenordnung zugänglicher und kostengünstiger zu machen.

Fazit

Microsoft Fabric stellt einen Paradigmenwechsel im Bereich der Business-Intelligence-Lösungen dar. Mit seiner einheitlichen Datenplattform, den End-to-End-Analysefunktionen und den KI-gestützten Erkenntnissen optimiert Fabric das Datenmanagement von der Erfassung bis zur Visualisierung. Die Fähigkeit der Plattform, verschiedene Fachbereiche und Kompetenzen zusammenzuführen, Datensilos zu reduzieren und Aufgaben zu automatisieren, verdeutlicht das bemerkenswerte Potenzial, die Branche nachhaltig zu revolutionieren.

Durch seine Komponenten wie Data Factory, Data Engineering, Data Warehousing, Data Science, Real-Time Analytics, Power BI, Data Activator und das solide Fundament von OneLake verspricht Microsoft Fabric eine Zukunft, in der Unternehmen die Macht der Daten effizient nutzen können, um fundierte Entscheidungen zu treffen und Innovationen voranzutreiben. Letztendlich hat es das Potenzial, leistungsstarke Business-Intelligence-Lösungen zu demokratisieren und sie für Unternehmen aller Größenordnungen zugänglicher und wirtschaftlicher zu machen.

In Data Warehouse, Fortgeschrittene

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.

Technische Tests und Monitoring eines Data Vault-gestützten EDW

In diesem Webinar geben Ihnen unsere Experten einen Überblick über verschiedene Methoden und Ansätze für technische Tests und das Monitoring eines Data Vault-gestützten EDW. Die vorgestellten Testansätze eignen sich für verschiedene Schichten (Layers) Ihrer EDW-Lösung – von der Extraktion der Daten aus den Quellen in die Landing Zone/Staging Area (Extract and Load) bis hin zu den Information-Marts, die von den Endanwendern in ihren BI-Berichten genutzt werden. Der Hauptfokus unseres Webinars liegt jedoch auf dem Testen der Data-Vault-2.0-Entitäten in den Raw-Vault- und Business-Vault-Schichten. Das Monitoring konzentriert sich darauf, Einblicke in die Performance Ihres EDW zu geben. Ausgehend vom Modellierungsansatz des Metrics-Vault und der Metrics-Marts werden die Quelldatenbereiche dieser Entitäten abgedeckt. Diese erfassten Daten liefern Informationen über die Prozessausführung Ihrer ELT-Prozesse sowie Fehlerinformationen. Durch die Analyse der Error-Marts können Sie Fehler nachverfolgen, deren Ursachen ermitteln und die Performance durch die Berücksichtigung von Performance-Metriken steigern.

Watch Webinar Part 1Watch Webinar Part 2

In this article:

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!

Close Menu