Michael Olschimke

In der Data-Vault-2.0-Architektur werden Information Marts verwendet, um Endanwendern Informationen bereitzustellen. Konzeptionell folgt ein Information Mart derselben Definition wie ein Data Mart im Legacy-Data-Warehousing. Dort wird ein Data Mart jedoch primär dazu genutzt, aufbereitete, nützliche Informationen statt reiner Rohdaten bereitzustellen. Aus diesem Grund wurde der Begriff Data Mart in Data Vault 2.0 in „Information Mart“ umbenannt, um diesen Anwendungszweck noch präziser widerzuspiegeln.

„Klassische“ Information Marts

Die Definition von Information Marts umfasst jedoch noch weitere Facetten. In dem Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ stellen wir drei grundlegende Arten von Marts vor:

• Information Mart: Dient der Bereitstellung von Informationen für Business-User, typischerweise über Dashboards und Reports.
• Metrics Mart: Wird in Verbindung mit einem Metrics Vault verwendet, der EDW-Logdaten in einem Data-Vault-Modell erfasst. Der Metrics Mart wird aus dem Metrics Vault abgeleitet, um Metriken darzustellen, mit denen Performance-Engpässe oder der Ressourcenverbrauch von Power-Usern und Data Scientists in Managed-Self-Service-BI-Lösungen analysiert werden können.
• Error Mart: Speichert diejenigen Datensätze, die beim Laden der Daten in das Enterprise Data Warehouse eine Hard Rule verletzen.

Zusätzliche Information Marts

Zusätzlich zu diesen „klassischen“ Information Marts setzen wir in unserer Beratungspraxis weitere Typen ein:

• Interface Mart: Dies ist im Grunde ein Information Mart, bei dem die Informationen jedoch nicht an Menschen übermittelt werden (z. B. über ein Dashboard oder einen Report). Stattdessen werden sie an eine nachgelagerte Anwendung oder als Write-Back an das Quellsystem übergeben, beispielsweise wenn das Enterprise Data Warehouse zur Datenbereinigung genutzt wird.
• Quality Mart: Der Quality Mart ist ebenfalls ein Information Mart, dient jedoch nicht der eigentlichen Bereinigung fehlerhafter Daten, sondern dem Reporting über diese. Im Wesentlichen kehrt er die zur Datenbereinigung genutzte Business-Logik um: Nur fehlerhafte Daten auch „Ugly Data“ genannt, werden an den Endanwender, beispielsweise den Data Steward, übermittelt. Dies geschieht häufig in Verbindung mit Frontends zur Datenbereinigung, in denen der Data Steward entweder Quelldaten korrigieren oder Ausnahmen kommentieren und mit Tags versehen kann.
• Source Mart: Ein weiterer Information Mart, der jedoch keines der gängigen Schemata wie Star-Schemata, Snowflake-Schemata oder vollständig denormalisierte Schemata verwendet. Stattdessen nutzt der Source Mart das Datenmodell der Quellanwendung, ähnlich dem Schema eines Operational Data Store (ODS). Er ist jedoch keine physische Datenkopie, sondern ein virtualisiertes Modell auf Basis des Data-Vault-Modells, das die ursprünglichen Strukturen abbildet. Er eignet sich hervorragend für das Ad-hoc-Reporting und bietet sowohl Data Scientists als auch Power-Usern einen erheblichen Mehrwert.

Damit ist unsere Übersicht der Information Marts vollständig. Wir setzen diese Typen seit vielen Jahren erfolgreich in Kundenprojekten ein, um den konkreten Nutzen und Einsatz von Information Marts im Unternehmen greifbar zu machen.

Teilen Sie uns gerne in den Kommentaren mit, ob dieser Überblick auch für Ihre Praxis hilfreich ist!

In der Branche gibt es zwei konkurrierende Ansätze für die Datenanalyse, und die meisten Fachleute tendieren zu einem von beiden: Data Warehousing vs. Data Lake. Dieser Artikel beleuchtet die Unterschiede zwischen den beiden Ansätzen und zeigt auf, wie Data Vault 2.0 eine Best-of-Breed-Lösung bietet, die die Stärken beider Welten in einem einheitlichen Konzept vereint.

Data Warehousing

Data Warehousing ist die traditionelle Unternehmenslösung, um Entscheidungsträgern auf allen Ebenen einer Organisation verlässliche Informationen bereitzustellen. Data-Warehouse-Lösungen basieren auf einem Datenmodell, das traditionell entweder anhand konkreter Informationsanforderungen über einen Bottom-up-Ansatz oder auf Basis eines integrierten Unternehmensdatenmodells über einen Top-down-Ansatz definiert wird.

In beiden Fällen beruht das traditionelle Data Warehouse auf dem „Schema-on-Write“-Prinzip: Das Datenmodell wird bereits beim Laden der Daten festgeschrieben. Dies führt häufig zu einer starren Datenverarbeitung, da jede geschäftliche Veränderung aufwendige Modellanpassungen nach sich zieht.

Data Lakes

Data Lakes hingegen basieren auf dem „Schema-on-Read“-Konzept. Anstatt vorab ein Zielmodell zu entwerfen und Datenstrukturen anzupassen, werden die Daten zunächst unverändert so im Data Lake gespeichert, wie sie aus den Quellsystemen angeliefert werden – ohne vorherige Modellierung.

Während traditionelles Data Warehousing häufig zu einer Übermodellierung und trägen Prozessen führt, birgt der Data-Lake-Ansatz das gegenteilige Risiko: unkontrollierten Datenwuchs und inkonsistente Analyseergebnisse.

Der Best-of-Breed-Ansatz

Beide Ansätze bilden die extremen Enden des Spektrums der Datenanalyse und haben in der Praxis jeweils eigene Herausforderungen offenbart. Mit dem Data Vault 2.0-Standard steht Datenexperten eine moderne dritte Option für den Aufbau von Datenanalyseplattformen zur Verfügung.

Data Vault 2.0 verbindet als Best-of-Breed-Lösung das Beste aus Data Warehousing und Data Lakes: Einerseits nutzt es ein klares Datenmodell zur Strukturierung von Daten und Geschäftslogik wie beim klassischen Data Warehouse, andererseits ermöglicht es bei der Bereitstellung die Flexibilität eines Schema-on-Read-Ansatzes wie bei Data Lakes.

Die Data Vault 2.0-Architektur gliedert sich in mehrere Schichten:

Die erste Schicht ist die Staging Area: Sie dient der reinen Extraktion der Daten aus den Quellsystemen. Die nächste Schicht ist der Raw Data Vault. Diese Schicht bleibt wie die Staging Area funktional an den Quellen orientiert, führt die Daten jedoch historisiert und integriert zusammen. Dazu wird das eingehende Quelldatenmodell in modulare Komponenten zerlegt: fachliche Schlüssel (gespeichert in Hubs), Beziehungen zwischen diesen Schlüsseln (gespeichert in Links) und beschreibende Kontextdaten (gespeichert in Satellites).

Der Business Vault bildet die darauf aufbauende Schicht, wird jedoch gezielt und sparsam modelliert: Nur dort, wo Geschäftslogik zwingend erforderlich ist, um verwertbare Informationen zu erzeugen, wird eine Business-Vault-Entität implementiert. Der Business Vault schließt die Lücke zwischen den Rohdaten und dem finalen Informationsmodell. Entsprechen Rohdaten hinsichtlich Datenqualität, Vollständigkeit oder Formatierung noch nicht den Anforderungen der Fachbereiche, wird hier die entsprechende Berechnungs- und Transformationslogik angewendet.

Die letzte Schicht bildet der Information Mart. Hier wird das eigentliche Zielmodell erzeugt, um die Daten im gewünschten Format bereitzustellen, beispielsweise als dimensionales Star-Schema. Fachanwender greifen auf diese Schicht entweder direkt über Ad-hoc-Abfragen oder über Business-Intelligence-Tools wie Dashboarding- und Reporting-Software zu.

Die Schichten bis hin zum Raw Data Vault bleiben quellsystemnah, da sich das Modell entweder direkt aus den Quellsystemen ableitet oder durch die Normalisierung in Hubs, Links und Satellites entsteht. Das fachliche Zielschema greift erst auf der Ebene des Information Marts. Da diese Schicht häufig über SQL-Views virtualisiert wird, erfolgt die Transformation zur Laufzeit der Abfrage. Abfragen auf die Views greifen direkt auf die materialisierten Daten im Raw Data Vault zu. Somit setzt Data Vault 2.0 das Schema-on-Read-Prinzip optimal in die Praxis um.

Data Vault 2.0 gewährleistet maximale Agilität: Das Konzept hat sich in zahlreichen Projekten bewährt und lässt sich flexibel erweitern, ganz gleich, ob sich Quellsystemstrukturen ändern, Geschäftsregeln angepasst werden müssen oder neue Informationsanforderungen entstehen. Zusätzliche Datenquellen und Geschäftsregeln können jederzeit ohne Ausfallzeiten integriert werden.

Zudem lässt sich das Data Vault 2.0-Modell nahtlos mit einem Data Lake kombinieren: Ein Data Lake kann für Staging-Zwecke genutzt werden, was der empfohlenen hybriden Architektur für moderne Projekte bei Scalefree entspricht. Ebenso eignet sich der Data Lake, um semi-strukturierte oder unstrukturierte Daten für das Enterprise Data Warehouse aufzunehmen oder spezielle Information Marts zu speisen.

Dadurch vereint Data Vault 2.0 als Best-of-Breed-Ansatz die Stärken des traditionellen Data Warehouse mit der Agilität des Data Lake. Unternehmen jeder Größenordnung profitieren so von einer skalierbaren und zukunftssicheren Datenanalyseplattform.