Skip to main content
search
0
CartClose Cart
All Posts By

Marc Winkelmann

Marc Winkelmann is a Senior Managing Consultant and Certified Data Vault 2.1 Trainer at Scalefree with over 8 years of BI experience. A Snowflake SnowPro Advanced Data Engineer and dbt Certified Developer, he specializes in cloud migrations (AWS, Azure, Snowflake) and enterprise data strategy. Marc holds a Master’s in BI & Analytics and is an expert in coaching teams through complex data transformations.

In Agile Daten

Agile Entwicklung im Data Warehousing mit Data Vault 2.0

Agile Entwicklung im Data Warehousing: Ausgangslage

Agile Methoden bringen Flexibilität und Anpassungsfähigkeit ins Data Warehousing und passen daher hervorragend zu modernen Ansätzen wie Data Vault 2.0. Ein häufiges Problem bei Data-Warehouse-Projekten ist das Fehlen eines klar definierten Scopes sowie nicht optimierte Prozesse – etwa beim gesteuerten Zugriff, beim Umgang mit der DSGVO (GDPR), bei der Revisionssicherheit (Auditability), der Dokumentation oder der Infrastruktur. Zudem starten Data-Warehouse-Projekte selbst bei vorhandenem Scope oft ohne echten Fokus auf den geschäftlichen Mehrwert (Business Value). Dies liegt meist daran, dass die Anwendungsfälle (Use Cases) nicht klar kommuniziert werden und Datenarchitekten der konkrete Ansatzpunkt fehlt. In der Folge bleibt der erhoffte Mehrwert für das Unternehmen aus.

In this article:

Data-Vault-2.0-Methodik

Es wird häufig fälschlicherweise angenommen, dass Data Vault 2.0 lediglich eine Modellierungstechnik sei. Data Vault 2.0 umfasst jedoch weit mehr: eine Modellierungstechnik, eine Referenzarchitektur und eine eigene Methodik. Diese Methodik integriert etablierte Projektmanagement-Werkzeuge wie CMMI, Six Sigma und Scrum, um die beschriebenen Herausforderungen zu lösen. Während CMMI und Six Sigma übergeordnete Projektmanagement-Themen abdecken, kommt Scrum vor allem im Entwicklungsteam zum Einsatz und bildet den Rahmen für einen kontinuierlichen Verbesserungsprozess. Der Einsatz agiler Entwicklung in Data-Vault-2.0-Projekten wird im Folgenden näher erläutert.

Der Scope eines Sprints

Der erste Schritt beim agilen Aufsetzen eines Data-Warehouse-Projekts besteht darin, das Projektziel prägnant auf ein bis zwei Seiten zu definieren. Im Gegensatz zu klassischen Wasserfall-Projekten ist es das Ziel, in kontinuierlichen Iterationen (Sprints) funktionierende und nutzbare Teilergebnisse – wie Berichte oder Dashboards – zu erzeugen. Das bedeutet, dass nicht das gesamte Projekt vorab im Detail geplant werden muss. Stattdessen lässt sich das Data Warehouse rund um ein zentrales Zielbild aufbauen, bevor die ersten Sprints konkret geplant werden. Um den genannten Problemen entgegenzuwirken, muss der Schwerpunkt der Sprints konsequent auf dem geschäftlichen Mehrwert liegen. Dafür ist es entscheidend, im Sinne eines kontinuierlichen Verbesserungsprozesses fortlaufend Feedback von den Fachanwendern (Business Usern) einzuholen.

Definition des Projekts

Sowohl der Scope eines Sprints als auch die Architektur folgen einem Business-Value-getriebenen Ansatz, der vertikal statt horizontal aufgebaut ist. Das bedeutet, dass die Entwicklung nicht Schicht für Schicht, sondern Feature für Feature erfolgt. Eine bewährte Vorgehensweise ist hierbei der Tracer-Bullet-Ansatz: Ausgehend vom geschäftlichen Mehrwert, der durch einen Bericht, ein Dashboard oder einen Information Mart definiert wird, werden die benötigten Quelldaten identifiziert, durch alle Schichten modelliert und geladen.

Wie in Abbildung 1 dargestellt, wird nicht von Anfang an die gesamte Staging-Area-Schicht aufgebaut, sondern nur der Teil, der für die Daten im aktuellen Scope benötigt wird – in diesem Fall für den SalesReport.

Agile Entwicklung

Bevor eine neue Funktionalität in einem Sprint implementiert werden kann, muss sie klar definiert werden.
Diese Aufgabe liegt beim Product Owner, der für das Verfassen und Priorisieren der User Stories verantwortlich ist.
Wie bereits erläutert, besteht das Ziel eines Sprints darin, funktionierende und nutzbare Teilergebnisse (Features) bereitzustellen.
Darüber hinaus müssen technische Themen (Tech Topics) berücksichtigt werden. Zur Unterstützung der Sprint-Planung existieren verschiedene Methoden wie Planning Poker oder die Function-Point-Analyse, auf die in einem separaten Artikel näher eingegangen wird.

Ein wichtiger Indikator für den Projektverlauf ist die Evaluierung des laufenden Sprints. Gelingt es dem Entwicklungsteam nicht, ein Feature innerhalb eines Sprints umzusetzen, deutet dies häufig darauf hin, dass der Scope zu groß gewählt wurde.

Um dem vorzubeugen, sollten alle Arbeitspakete entfernt werden, die für das jeweilige Feature nicht zwingend erforderlich sind. Aus Sorge vor Verlust zögern Fachanwender jedoch oft, diese Arbeitspakete zu streichen.

Um dieser Sorge zu begegnen, sollte den Fachanwendern verdeutlicht werden, dass diese Arbeitspakete nicht verworfen, sondern lediglich in spätere Sprints verschoben und vorübergehend im Backlog geführt werden.

Agile - Data Warehousing Sprint
Figure1 : Data Vault 2.0 Architecture

Dank des flexiblen und skalierbaren Data-Vault-Modells lassen sich die Schichten beim nächsten Feature mit minimalem bis gar keinem Re-Engineering erweitern. Dies ist möglich, da Data Vault aus einem Raw-Data-Vault- und einem Business-Vault-Modell besteht. Es kombiniert somit die logische Architektur mit der Perspektive der Datenmodellierung. Der Raw Data Vault wird datengetrieben modelliert, indem die Daten über Business Keys integriert werden. Hierbei werden ausschließlich Hard Business Rules wie Datentypkonvertierungen oder Hash-Key-Berechnungen angewendet. Sämtliche Soft Business Rules kommen erst im Business Vault zum Tragen.

Hier werden Daten in wertvolle Informationen verwandelt. Aus diesem Grund erfordert der Raw Data Vault kaum Refactoring und lässt sich unbegrenzt erweitern.

Review in der agilen Entwicklung

Ein wesentlicher Erfolgsfaktor agiler Projekte ist die regelmäßige Überprüfung und Optimierung. Vor dem Start des nächsten Sprints stehen für das Team folgende Meetings an:

  • Das Sprint-Review-Meeting: Hier werden die gelieferten Features überprüft. In der Regel nehmen das Entwicklungsteam, der Product Owner, der Scrum Master und die Endanwender daran teil
  • Das Retrospektive-Meeting: Dieses Meeting schließt meist direkt an das Review-Meeting an und dient dazu, Verbesserungspotenziale im Arbeitsprozess zu identifizieren.
  • Das Backlog Refinement: Zur Priorisierung der User Stories und zur Klärung der anstehenden Aufgaben für das Team.
  • Das Sprint Planning: Um auf Basis von Aufwandsschätzungen festzulegen, welche User Stories im kommenden Sprint umgesetzt werden.

Die konsequente Durchführung dieser Meetings ist essenziell, um Fehlerquellen frühzeitig zu erkennen. So lassen sich die Projektergebnisse kontinuierlich verbessern und die Entwicklungsprozesse iterativ optimieren.

Fazit

Data Vault 2.0 ist nicht nur eine skalierbare und flexible Modellierungstechnik, sondern eine ganzheitliche Methodik zur Umsetzung der Unternehmensvision im Data Warehousing und der Informationsbereitstellung (Information Delivery). Durch die Verbindung agiler Prinzipien mit einem klaren Fokus auf den geschäftlichen Mehrwert (Business Value) stellt Data Vault 2.0 sicher, dass Data-Warehouse-Projekte verlässliche, nutzbringende und hochwertige Ergebnisse für das Unternehmen liefern.

In Data Vault

Green-Bond-Reporting in Rekordzeit bei Grenke AG

Green-Bond-Reporting

Nachhaltigkeit und Transparenz sind längst mehr als nur Buzzwords – heutzutage gehören sie zum Selbstverständnis moderner Unternehmen. Green Bonds gewinnen zunehmend an Bedeutung, da sie gezielte Investitionen in nachhaltige Projekte ermöglichen. Ein professionelles und prüfungssicheres Reporting ist entscheidend, um Vertrauen bei Investoren, Wirtschaftsprüfern und anderen Stakeholdern zu schaffen.

Unser Kunde Grenke vertraute bereits auf unsere Expertise und hatte ein Data Warehouse auf Basis von Data Vault 2.0 implementiert. Die Prozesse wurden weitgehend automatisiert, sodass Datenquellen effizient integriert und verarbeitet werden konnten. Als eine neue Anforderung für das Green-Bond-Reporting entstand, konnten wir diese dank des bereits bestehenden, skalierbaren Setups in nur einem Monat umsetzen.

In this article:

Ausgangslage: Ein bestehendes, automatisiertes Data Warehouse

  • Data-Vault-2.0-Architektur als Fundament:
    Grenke nutzte bereits eine robuste Data-Vault-2.0-Architektur, die dank ihrer klaren Strukturen (Hubs, Links und Satellites) eine flexible und erweiterbare Datenspeicherung ermöglicht.
  • Automatische Modellgenerierung:
    Durch den Einsatz von Templates und metadatengesteuerten Ansätzen können Data-Vault-Modelle automatisch generiert werden. Dies reduziert den manuellen Aufwand, erhöht die Standardisierung und verbessert die Datenqualität.
  • Qualitätsprüfungen und Revisionssicherheit:
    Plausibilitätsprüfungen, Historisierung und metadatenunterstützte Prozesse sorgten bereits für eine hohe Datenqualität und Nachvollziehbarkeit – essenziell für Audits und Reporting.

Diese Voraussetzungen bildeten das perfekte Sprungbrett, um das neue Green-Bond-Reporting schnell und zuverlässig in das bestehende System zu integrieren.

Neue Anforderung: Green-Bond-Reporting

Mit dieser neuen Anforderung stand Grenke vor der Herausforderung, spezifische ESG-Kennzahlen sowie Green-Bond-spezifische Daten zu erfassen, aufzubereiten und in einem nachvollziehbaren Bericht darzustellen.

Ziel war es, das Reporting so zu gestalten, dass:

Externe Prüfer und Auditoren schnell und einfach Einblick erhalten können.

Investoren und andere Stakeholder transparente Informationen über die nachhaltigen Projekte erhalten.

Regulatorische Anforderungen und interne Standards jederzeit erfüllt und nachvollziehbar dokumentiert werden.

Dank der bestehenden Data-Vault-2.0-Infrastruktur und des hohen Automatisierungsgrads konnten diese neuen Anforderungen in kurzer Zeit umgesetzt werden.

Unser Ansatz: Erweiterung statt Neubau

  1. Anforderungsanalyse:
    Gemeinsam mit Grenke haben wir die relevanten Green-Bond-Kennzahlen und Reporting-Anforderungen definiert. Dazu gehörten Klassifizierungen nach ESG-Kriterien, die Zuordnung von Projekttypen sowie regionale und finanzielle Attribute.
  2. Integration in das bestehende Data Warehouse:
    Anstatt ein neues System aufzubauen, haben wir die erforderlichen Felder zu den bestehenden Hubs, Links und Satellites hinzugefügt. Dank der agilen Data-Vault-2.0-Methodik war dies ohne großen Zusatzaufwand möglich.
  3. Automatisierte Prozesse und Qualitätsprüfungen:
    Dank der bestehenden ETL/ELT-Strecken konnten wir die Daten schnell und sicher in das System laden. Neue Validierungsregeln für das Green-Bond-Reporting wurden ergänzt, um sicherzustellen, dass alle relevanten Daten vollständig und korrekt erfasst werden.
  4. Reporting & Dashboards:
    Auf Basis der verarbeiteten Daten haben wir interaktive Dashboards und Berichte entwickelt, die den Projektstatus, das Finanzierungsvolumen und weitere ESG-Kennzahlen übersichtlich darstellen. Bei Bedarf kann externen Prüfern auch über Exportfunktionen Zugriff gewährt werden.
  5. Schnelle Freigabe durch externe Prüfungen:
    Da die Data-Vault-2.0-Struktur eine vollständige Historisierung und Nachvollziehbarkeit der Daten gewährleistet, verliefen die externen Prüfungen reibungslos. Die Auditoren konnten alle Schritte und Datenänderungen lückenlos nachvollziehen – ein entscheidender Vorteil für Nachhaltigkeitsberichte.

Ergebnis: Green-Bond-Reporting in nur einem Monat

Die Kombination aus einem skalierbaren Data-Vault-2.0-Ansatz, einem hohen Automatisierungsgrad und einer bereits etablierten Dateninfrastruktur ermöglichte es uns, das Green-Bond-Reporting in nur einem Monat erfolgreich bereitzustellen.

Das bedeutet:

  • Schnelle Time-to-Market: Grenke konnte den Bericht schnell veröffentlichen und direkt mit der Kommunikation und dem Marketing beginnen.
  • Vertrauenswürdige Datenbasis: Dank integrierter Qualitätsprüfungen und Nachvollziehbarkeit ist das Reporting prüfungssicher – eine entscheidende Voraussetzung für externe Audits.
  • Zukunftssichere Lösung: Neue Kennzahlen, erweiterte ESG-Kriterien oder regulatorische Anforderungen können flexibel integriert werden, ohne das System grundlegend neu aufbauen zu müssen.

Das sagt Grenke

„Die Partnerschaft mit Scalefree war entscheidend für unsere Data-Vault-2.0-Reise. Ihre tiefe Expertise in Data-Vault-Prinzipien und das praktische dbt-Know-how haben unsere Implementierung maßgeblich unterstützt und für einen reibungslosen sowie strukturierten Prozess gesorgt. Dank ihrer Begleitung konnten wir unsere Fähigkeiten zur Integration und Analyse von Unternehmensdaten bereits verbessern und gleichzeitig ein skalierbares und zukunftssicheres Data Warehouse aufbauen.“

Oliwia Borecka,
Chief Data & Analytics Officer bei grenke digital GmbH

grenke Logo

Fazit: Agil und nachhaltig in die Zukunft

Das Projekt zeigt, wie Scalefree Kunden dabei unterstützt, neue Anforderungen schnell und effizient in bestehende Datenökosysteme zu integrieren. Der Data-Vault-2.0-Ansatz bietet dafür die ideale Basis: Skalierbarkeit, Flexibilität und Revisionssicherheit stellen sicher, dass Unternehmen ihre Reporting-Anforderungen nicht nur heute, sondern auch morgen erfüllen können.

Möchten Sie mehr darüber erfahren, wie Sie Ihr Data Warehouse oder ESG-Reporting zukunftssicher aufstellen können?
Kontaktieren Sie uns bei Scalefree – gemeinsam entwickeln wir eine maßgeschneiderte Lösung, die Ihren Anforderungen entspricht und Sie in puncto Nachhaltigkeit und Transparenz optimal aufstellt. Wir freuen uns darauf, Ihr Projekt zum Erfolg zu führen!

In Data Vault, Fortgeschrittene

Data Vault & Data Mesh in einer Data Fabric: Ein moderner Architekturleitfaden

Best Practices für die Data-Mesh-Implementierung

Unternehmen stehen häufig vor der Herausforderung, ihre Daten effizient zu verwalten. Daten sind meist über viele getrennte Systeme verteilt, wachsen kontinuierlich an Umfang sowie Komplexität und werden für eine zunehmende Anzahl von Anwendungsfällen benötigt. Selbst erfahrene Fachleute stoßen hierbei an Grenzen. Um dem zu begegnen, haben sich Ansätze wie Data Fabric, Data Vault und Data Mesh als wesentliche Grundlagen für den Aufbau robuster, flexibler Datenplattformen und effizienter Prozesse etabliert.

Gleichzeitig bringen diese modernen Ansätze zusätzliche Komplexität für das Management von Datenplattformen mit sich. Dieser Artikel beleuchtet, wie sich die drei Konzepte optimal kombinieren lassen, um eine leistungsfähige und zukunftssichere Datenarchitektur zu schaffen, die Datenarchitekten als fundierter Leitfaden dient.

Data Vault & Data Mesh in einer Data Fabric: Ein moderner Architekturleitfaden

Dieses Webinar bietet einen kompakten Überblick über Data Fabric, Data Vault sowie Data Mesh und vertieft anschließend die konkreten Vorteile aus der Kombination dieser Ansätze. Melden Sie sich jetzt für unser kostenloses Webinar am 13. Mai 2025 an!

Watch Webinar Recording

In this article:

Die Data Fabric: Vereinheitlichung verteilter Datenökosysteme

Um der Herausforderung verteilter, heterogener Datenlandschaften zu begegnen, hat sich die Data Fabric als architektonischer Ansatz etabliert. Sie nutzt metadatengetriebene Automatisierung und intelligente Funktionen, um eine einheitliche und konsistente Datenmanagementschicht zu schaffen. Dieses Framework ermöglicht einen nahtlosen Datenzugriff sowie eine reibungslose Datenbereitstellung und steigert so nachhaltig die Agilität des gesamten Unternehmens.

Zu den Hauptmerkmalen einer Data Fabric gehören:

  • Einheitlicher Datenzugriff: Bereitstellung eines integrierten Zugriffs für unterschiedlichste Benutzeranforderungen.
  • Zentralisierte Metadaten: Nutzung eines KI-gestützten Datenkatalogs für effiziente Data Discovery und ein besseres Datenverständnis.
  • Erweiterte, metadatengetriebene Automatisierung: Steigerung von Effizienz und Skalierbarkeit durch automatisierte Prozesse auf Basis eines umfassenden Metadatenmanagements.
  • Verstärkte Governance und Sicherheit: Standardisierung von Verfahren zur unternehmensweiten Verbesserung von Governance und Datensicherheit.

Eine moderne Data-Fabric-Plattform integriert eine Vielzahl von Systemen und Prozessen, um das Datenmanagement zu optimieren. Dieser Ablauf beginnt mit der Einbindung von Daten aus verschiedenen Quellsystemen wie ERP, CRM, HR und MDM. Anschließend wird ein Data Lakehouse angebunden, das als Staging Area für die Datenaufbereitung dient.

Data Fabric Architecture EDW

Die Architektur umfasst darüber hinaus ein Enterprise Data Warehouse für die zentrale Datenspeicherung, gefolgt von der Implementierung von Information Marts, AI Marts und User Marts für eine zielgerichtete Informationsbereitstellung. Schließlich unterstützt die Plattform verschiedene Formen der Datennutzung, darunter Applikationen, Dashboards und OLAP-Cubes.

Das Data Lakehouse bildet zudem die drei Medallion-Schichten ab: Rohdaten (Bronze Layer), integrierte Datenschicht (Silver Layer) und Informationsbereitstellungsschicht (Gold Layer) mit ihren einsatzbereiten Datenprodukten.

Entscheidend für diese Architektur sind ein robustes Metadatenmanagement und ein KI-gestützter Datenkatalog, die gemeinsam die Automatisierung vorantreiben und Data Discovery erleichtern.

Data Vault: Aufbau einer Single Source of Facts

Data Vault ist eine Datenmodellierungsmethodik, die speziell für den Aufbau und die Wartung von Enterprise Data Warehouses konzipiert wurde. Bekannt für Flexibilität, Skalierbarkeit und die lückenlose Historisierung von Daten, fügt sich Data Vault nahtlos in das Ziel einer einheitlichen Datenmanagementschicht sowie in den Automatisierungsfokus einer Data Fabric ein.

Zu den Hauptvorteilen von Data Vault gehören:

  • Skalierbarkeit: Mühelose Anpassung an wachsende Datenmengen und steigende Komplexität.
  • Flexibilität: Schnelle Reaktion auf sich verändernde Geschäftsanforderungen.
  • Konsistenz: Sicherstellung der Datenintegrität über das gesamte Unternehmen hinweg.
  • Musterbasierte Modellierung (Pattern-based Modeling): Ideale Grundlage für eine durchgehende Datenautomatisierung.
  • Auditierbarkeit: Bereitstellung einer klaren, revisionssicheren Datenhistorie.
  • Agilität: Schnellere Bereitstellung neuer Datenstrukturen und Funktionen.

Innerhalb einer modernen Data-Fabric-Plattform wird das Data-Vault-Modell im Enterprise Data Warehouse implementiert. Der Raw Data Vault integriert alle Quellsysteme in Form von Business Objects und deren Beziehungen. Der schlank und bedarfsgerecht aufgebaute Business Vault auf Basis des Raw Data Vault ergänzt erweiterte Data-Vault-Entitäten, beispielsweise für Query Assistants, um die Erstellung zu erleichtern und die Performance der Informationsbereitstellungsschicht zu optimieren.

Data Fabric Architecture with Data Vault

Dieser Ansatz liefert alle genannten Vorteile und ermöglicht dank seiner musterorientierten Modellierungsmethode einen außergewöhnlich hohen Automatisierungsgrad.

Data Mesh: Dezentralisierung von Data Ownership und Datenzugriff

Data Mesh ist ein dezentraler Ansatz für das Datenmanagement, der Domain Ownership, Data as a Product, Self-Service-Datenplattformen und Federated Governance in den Mittelpunkt stellt. Dieses Konzept verlagert die fachliche Verantwortung für das Datenmanagement auf domänenspezifische Teams und fördert so eine höhere Eigenverantwortung und Agilität.

Zu den Kernprinzipien gehören:

  • Domain Ownership: Dezentrale Verantwortung für analytische und operative Daten.
  • Data as a Product: Behandlung analytischer Daten als hochwertige, gemanagte Produkte.
  • Self-Service-Datenplattform: Bereitstellung von Tools für die autonome Erstellung und Verwaltung von Daten.
  • Federated Governance: Etablierung einer domänenübergreifenden, kollaborativen Governance.
  • Dezentrale Datendomänen: Jede Domäne verantwortet und betreibt ihre eigenen Datenprodukte.

Die Implementierung eines Data Mesh auf einer Data-Fabric-Plattform erfordert grundlegende Komponenten wie standardisierte DevOps-Prozesse, klare Modellierungsrichtlinien und einen umfassenden Datenkatalog.

Obwohl eine vollständige Dezentralisierung der Datenpipelines über ein reines Data Mesh theoretische Vorteile verspricht, zeigt die Praxis, dass eine selektive Integration zentraler Data-Mesh-Prinzipien in eine Data-Fabric-Architektur deutlich wirksamer ist. So lässt sich eine dezentrale Ownership nutzen, während gleichzeitig die Stärken eines automatisierten, zentralen Datenkerns auf Basis von Data Vault erhalten bleiben.

Best Practices für die Data-Mesh-Implementierung

  • Zentralisiertes Staging und Raw Vault: Schafft die Basis für einen maximalen Automatisierungsgrad.
  • Dezentraler Business Vault und nachgelagerte Schichten: Erleichtert die Einbindung von Fachbereichswissen und den produktiven Einsatz cross-funktionaler Teams.
Best Practices für die Data-Mesh-Implementierung

Für eine optimale Umsetzung sorgt ein Ansatz mit zentralem Staging und Raw Vault für einen hohen Automatisierungsgrad und garantiert, dass sich alle Datenprodukte auf eine verlässliche Single Source of Facts beziehen. Im Gegensatz dazu ermöglicht eine Strategie mit dezentralem Business Vault und nachgelagerten Bereichen die nötige Integration von Fachwissen, eine klare Verantwortung für Datenprodukte (Data Product Ownership) sowie eine effiziente Skalierung. Dieser Grad an Dezentralisierung ist der Schlüssel für eine erfolgreiche Data-Mesh-Implementierung unter Einbindung cross-funktionaler Domänenteams.

Empfohlene Architektursynthese

Die empfohlene Architektur vereint Data Fabric, Data Mesh und Data Vault zu einem harmonischen Gesamtbild und schöpft die individuellen Stärken jedes Ansatzes optimal aus. Diese Synthese führt zu einer metadatengetriebenen, flexiblen, hochgradig automatisierten, transparenten und sicher gesteuerten (governed) Datenumgebung.

Anwendungsfälle und Einsatzbereiche

Diese moderne Datenarchitektur unterstützt ein breites Spektrum an Anwendungsfällen, darunter:

  • Effizientes und vertrauenswürdiges Reporting sowie Advanced Analytics
  • Regulatorische Compliance durch einen vollständig auditierbaren Kern
  • Vielfältige KI- und Machine-Learning-Anwendungen

Fazit

Die Integration von Data Fabric, Data Vault und Data Mesh ermöglicht es Unternehmen, eine zukunftsfähige Datenarchitektur aufzubauen, die durch Flexibilität, Skalierbarkeit und Effizienz überzeugt. Dieser ganzheitliche Ansatz optimiert das Datenmanagement, verbessert den Datenzugriff und beschleunigt die Bereitstellung von Datenprodukten – was bei einem Höchstmaß an Automatisierung, Governance und Transparenz zu messbar besseren Geschäftsergebnissen führt.

In Anfänger, Data Warehouse

Echtzeit-Data-Warehousing & BI mit Data Vault 2.0 und AWS

real time data aws

Daten sind der Treibstoff der digitalen Wirtschaft. Ihr wahrer Wert entfaltet sich jedoch erst, wenn sie schnell, zuverlässig und strukturiert für Analysen und Berichte aufbereitet werden. Real-Time-Data-Streaming ermöglicht es Unternehmen, datenbasierte Entscheidungen in Echtzeit zu treffen. Data Vault 2.0 in Kombination mit AWS Kinesis bietet eine zukunftssichere Lösung für die effiziente Verarbeitung und Speicherung großer Datenmengen in modernen Data-Warehousing- und BI-Umgebungen.

Echtzeit auf AWS mit Data Vault 2.0

Nehmen Sie am 18. März 2025 um 11:00 Uhr MEZ an unserem Webinar teil und erfahren Sie, wie Sie eine skalierbare Echtzeit-Datenarchitektur auf AWS aufbauen. Wir behandeln die AWS-Infrastruktur für Echtzeitdaten, den Einsatz von Data Vault 2.0 in Echtzeitszenarien und präsentieren eine Live-Demo anhand eines praxisnahen Anwendungsfalls.

Watch Webinar Recording

In this article:

Warum Real-Time-Data-Streaming für Data Warehousing und BI?

In der heutigen dynamischen Geschäftswelt ist der unmittelbare Zugriff auf präzise Daten unerlässlich, um fundierte Entscheidungen zu treffen. Traditionelle Batch-Processing-Methoden können mit dem Bedarf an Echtzeit-Insights nicht mehr Schritt halten, was häufig zu veralteten Berichten und verzögerten Reaktionszeiten führt. Real-Time-Data-Streaming löst dieses Problem durch eine kontinuierliche Datenintegration: Unternehmen können aktuelle Daten direkt beim Eintreffen analysieren und sofort darauf reagieren. Dieser Wandel steigert nicht nur die operative Effizienz, sondern stärkt auch ganzheitliche Business-Intelligence-Strategien, da stets die aktuellsten Informationen bereitstehen.

Data Vault 2.0 als Fundament für Echtzeit-Data-Warehousing

Da Unternehmen mit wachsenden Datenmengen aus verschiedensten Quellen konfrontiert sind, benötigen sie einen flexiblen und skalierbaren Ansatz für die Datenmodellierung. Data Vault 2.0 bildet die ideale Grundlage für Echtzeit-Data-Warehousing, da es eine strukturierte und zugleich anpassungsfähige Methodik bietet. Im Gegensatz zu traditionellen Datenmodellen, die oft starr und schwer zu modifizieren sind, lässt sich Data Vault 2.0 zügig an neue Anforderungen anpassen. Durch den Einsatz von Data Vault 2.0 bauen Unternehmen ein robustes, zukunftssicheres Data Warehouse auf, das Echtzeit-Datenströme mühelos verarbeitet.

AWS Kinesis: Echtzeitdaten für Ihr Data Warehouse

Die skalierbare Verarbeitung von Echtzeitdaten erfordert eine leistungsfähige Infrastruktur – genau dafür wurde AWS Kinesis entwickelt. Der Dienst ermöglicht es Unternehmen, Echtzeit-Datenströme zuverlässig zu erfassen, zu verarbeiten und zu analysieren, sodass Data Warehouses kontinuierlich auf dem neuesten Stand bleiben. Durch die Eliminierung von Datenlatenzen gewinnen Unternehmen Erkenntnisse in Echtzeit, was zu schnelleren Entscheidungen und einer höheren operativen Leistungsfähigkeit führt. Darüber hinaus lässt sich AWS Kinesis nahtlos in führende Cloud-Data-Warehouse- und BI-Lösungen wie Amazon Redshift und Snowflake integrieren. Die dynamische Skalierung gewährleistet Kosteneffizienz, indem der Ressourcenverbrauch automatisch an den tatsächlichen Bedarf angepasst wird. Fortschrittliche Sicherheitsfunktionen stellen zudem sicher, dass sensible Daten geschützt bleiben und alle regulatorischen Branchenstandards eingehalten werden.

Fazit: Zukunftssichere BI und modernes Data Warehousing mit Real-Time-Streaming

Unternehmen, die auf Echtzeit-Datenverarbeitung setzen, profitieren von schnelleren BI-Analysen, reduzierten Betriebskosten und einer höheren Skalierbarkeit. Data Vault 2.0 in Kombination mit AWS Kinesis bietet eine leistungsstarke Basis für moderne Data-Warehousing-Architekturen. Durch die nahtlose Integration von Echtzeitdaten können Unternehmen unmittelbar auf Marktveränderungen reagieren, interne Abläufe optimieren und ihre Marktposition stärken.

Die Investition in Real-Time-Data-Streaming bedeutet nicht nur mehr Geschwindigkeit, sie schafft eine widerstandsfähige und adaptive Dateninfrastruktur, die mit Ihrem Unternehmen wächst. Wer diese Technologien bereits heute nutzt, sichert sich einen entscheidenden Wettbewerbsvorteil sowie langfristigen Erfolg in einer zunehmend datengetriebenen Welt. Nutzen Sie Real-Time-Streaming für BI und schöpfen Sie das volle Potenzial Ihrer Daten aus!

In Data Vault Friday

Snapshot-basierte Bridge Table für Link und Effectivity Satellite

Watch the Video

Snapshot-basierte Bridge Table für Link und Effectivity Satellite

Willkommen zu einer weiteren Ausgabe von Data Vault Friday! Heute widmen wir uns dem Konzept einer snapshot-basierten Bridge Table und konzentrieren uns dabei insbesondere auf deren Einsatz in Szenarien mit Links und Effectivity Satellites. Dieser Ansatz hilft uns, komplexe Beziehungen zwischen Business Objects im Zeitverlauf zu verwalten, Beziehungsänderungen nachzuvollziehen und eine lückenlose historische Sicht zu bewahren. In diesem Artikel untersuchen wir Lösungen für drei zentrale Fragen:

  • Wie mit einer Beziehung umzugehen ist, die an Tag 2 im Vergleich zu Tag 1 entfällt
  • Wie geänderte Beziehungen zwischen Tag 1 und Tag 2 für denselben Key verwaltet werden
  • Wie sich ein Business Object (A3) an Tag 2 einbinden lässt, wenn keine Beziehung zu einem Objekt in B besteht

In this article:



Das Data-Vault-Modellierungsbeispiel verstehen

In unserem Beispiel nutzen wir zwei Quellen, die jeweils ein anderes Business Object (A und B) repräsentieren. Business Object A liegt als statischer Datensatz vor, während Business Object B über drei Tage hinweg dynamische Beziehungen zu A aufweist. Jeder Tag bringt Änderungen in diesen Beziehungen mit sich, wobei einzelne Einträge wegfallen oder sich verschieben. Unsere Aufgabe besteht darin, diese Änderungen effizient in einer snapshot-basierten Bridge Table abzubilden.

Untersuchung der Beziehungsänderungen

Gehen wir die über drei Tage hinweg beobachteten Änderungen im Detail durch:

  • Tag 1: B1 steht in Beziehung zu A1, B2 zu A2 und B3 zu A3.
  • Tag 2: Die Beziehungen ändern sich. B1 steht nun in Beziehung zu A2, B2 zu A1 und B3 entfällt.
  • Tag 3: Im Vergleich zu Tag 2 treten keine weiteren Änderungen auf.

Unser Ziel ist es, diese Beziehungen mithilfe eines Effectivity Satellites und einer Bridge Table so zu dokumentieren, dass wir ihren exakten Zustand für jeden einzelnen Stichtag historisch korrekt abfragen können.

Erstellung des Links und des Effectivity Satellites

Der erste Schritt zur Erfassung dieser Beziehungen besteht darin, eine Link-Tabelle zu erstellen, die eine eindeutige (distinct) Liste aller Beziehungen zwischen den Business Objects enthält. Links sollten keine zusätzlichen Metadaten wie etwa Gültigkeitszeiträume enthalten, da dies spätere Abfragen unnötig verkompliziert und die Abfrage-Performance beeinträchtigen kann. In unserem Beispiel erfasst die Link-Tabelle jede eindeutige Kombination von A- und B-Keys, speichert jedoch weder Start- noch Enddaten.

Als Nächstes erstellen wir einen Effectivity Satellite. Diese Tabelle erweitert den Link, indem sie Beginn und Ende jeder Beziehung über Zeitstempel sowie ein „is_active“-Flag speichert, um den jeweiligen Status jeder Beziehung anzuzeigen. Mithilfe dieser Tabelle lässt sich lückenlos nachvollziehen, wann eine Beziehung beginnt, sich ändert oder endet. In der Praxis stellt sich das wie folgt dar:

  • Einträge an Tag 1: Alle Beziehungen (B1-A1, B2-A2, B3-A3) sind als aktiv gekennzeichnet.
  • Einträge an Tag 2: Neue Beziehungen (B1-A2 und B2-A1) kommen hinzu und werden als aktiv markiert, während vorherige Beziehungen (B1-A1 und B2-A2) auf inaktiv gesetzt werden. B3-A3 entfällt vollständig.

Aufbau der snapshot-basierten Bridge Table

Sobald der Effectivity Satellite eingerichtet ist, können wir eine Bridge Table aufbauen, die die aktiven Beziehungen für jeden Tag in Form eines Snapshots festhält. Diese Tabelle liefert eine Point-in-Time-Sicht auf die Beziehungen genau so, wie sie an einem bestimmten Tag bestanden haben. Sehen wir uns den Aufbau der Bridge Table an:

Snapshot für Tag 1

Der Snapshot für Tag 1 spiegelt die Ausgangsbeziehungen wider und übernimmt alle zu diesem Zeitpunkt aktiven Datensätze aus dem Effectivity Satellite. An Tag 1 sind B1-A1, B2-A2 und B3-A3 durchgängig aktiv.

Snapshot für Tag 2

Im Snapshot für Tag 2 verbleiben lediglich die Beziehungen B1-A2 und B2-A1 als aktiv, während B3-A3 nicht mehr berücksichtigt wird. Durch die Filterung auf ausschließlich aktive Einträge bildet der Snapshot den Zustand an Tag 2 exakt ab.

Snapshot für Tag 3

Der Snapshot für Tag 3 ist identisch mit dem von Tag 2, da keine weiteren Änderungen erfolgt sind. Die aktiven Beziehungen B1-A2 und B2-A1 bleiben unverändert bestehen.

Dieses Vorgehen gewährleistet einen transparenten Audit-Trail über sämtliche Beziehungsänderungen und -löschungen. Der tägliche Snapshot gibt den jeweiligen Status quo präzise wieder, ohne redundante Daten zu erzeugen.

Umgang mit fehlenden Daten und Wiederherstellung von Beziehungen

Eine zentrale Stärke des Effectivity Satellites liegt in der Fähigkeit, reaktivierte Beziehungen sauber abzubilden. Wird beispielsweise die Beziehung B1-A1 an Tag 4 wiederhergestellt, fügen wir im Effectivity Satellite neue Zeilen hinzu, markieren die zuvor aktive Kombination (B1-A2) als inaktiv und aktivieren B1-A1 erneut. Diese dynamische Struktur federt das Entstehen, Wegfallen und Wiederauftreten von Beziehungen im Zeitverlauf flexibel ab.

Einbindung von A3 in die Bridge Table an Tag 2

Eine typische Herausforderung besteht darin, Business Objects wie A3 an Tag 2 einzubinden, obwohl an diesem Tag keine Beziehung zu einem Objekt in B vorliegt. Im Data-Vault-Umfeld wird dies üblicherweise in nachgelagerten Abfragen oder Joins auf Reporting-Ebene gelöst – und nicht direkt in der Bridge Table.

Wenn Sie von Objekt A ausgehen und einen Left Join auf die Bridge Table durchführen, beziehen Sie sämtliche Datensätze aus A ein – selbst diejenigen ohne Entsprechung in B. Dadurch ist sichergestellt, dass nicht verknüpfte Objekte in den Ergebnissen erscheinen, wobei die zugehörigen B-Attribute als NULL oder optional über einen definierten Platzhalter abgebildet werden.

Vermeidung kartesischer Produkte und weitere Best Practices

Beim Einsatz einer Bridge Table gilt es unbedingt zu verhindern, dass unerwünschte kartesische Produkte entstehen, da diese das Datenvolumen bei Aggregationen massiv aufblähen können. Prüfen Sie daher stets die Kardinalität der Beziehungen (z. B. 1:1 oder n:m), um sicherzustellen, dass Joins ausschließlich über die erforderlichen Keys ausgeführt werden. Der Driving Key, der die Beziehungen in der Link-Tabelle verankert, muss dabei im Mittelpunkt stehen – insbesondere bei n:m-Beziehungen.

Diese Best Practice garantiert höchste Präzision sowie optimale Performance bei der Datenaggregation und schützt vor verfälschten Reporting-Ergebnissen.

Fazit

Snapshot-basierte Bridge Tables sind in der Data-Vault-Modellierung ein leistungsfähiges Instrument, um veränderliche Beziehungen zu steuern und historische Snapshots nachvollziehbar festzuhalten. Durch das strukturierte Zusammenspiel von Links, Effectivity Satellites und Bridge Tables schaffen wir einen verlässlichen, auditierbaren Pfad für alle Datenänderungen im Zeitverlauf. Wie gezeigt, ermöglicht uns dieser Ansatz, Datenlücken zu überbrücken, Beziehungen zu reaktivieren und eine künstliche Datenaufblähung zu verhindern. Das Ergebnis sind performante und stabile Datenmodelle.

Wenn Sie Unterstützung bei Vorlagen für Bridge Tables oder Effectivity Satellites wünschen, können Sie sich jederzeit gerne an mich wenden. Ich hoffe, dass diese Erläuterung wertvolle Klarheit über den Einsatz von Bridge Tables in Data Vault geschaffen hat. Seien Sie auch beim nächsten Mal wieder dabei, wenn wir neue Einblicke teilen, und reichen Sie Ihre Fragen gerne vorab ein!

In Data Warehouse, Fortgeschrittene

Data Vault im Data-Mesh-Ansatz

Solutions

Data Vault & Data Mesh

Tauchen Sie ein in die Integration von Data Vault im Kontext von Data Mesh. Beginnen Sie die Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen mit unserem Data Vault 2.Go-Newsletter – Ihrer zentralen Anlaufstelle für (fast) alles rund um die zukunftsweisende Welt der Daten.

In dieser Ausgabe befassen wir uns eingehend mit der Integration von Data Vault 2.0 im Kontext eines Data-Mesh-Ansatzes. Begleiten Sie uns auf dieser Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Data Vault im Data-Mesh-Ansatz

Dieses Webinar untersucht die Integration von Data Vault in einen Data-Mesh-Ansatz und beleuchtet die Synergie zwischen den Data-Mesh-Prinzipien und der Skalierbarkeit, Flexibilität, Resilienz sowie Interoperabilität von Data Vault. Wir betrachten die Integration von Data Vault im Kontext eines Data-Mesh-Ansatzes im Detail – eine Reise in die Zukunft skalierbarer und dezentraler Datenarchitekturen.

Watch webinar recording

In this article:

Data Mesh verstehen: Eine kurze Zusammenfassung

Bevor wir uns mit der Rolle von Data Vault befassen, lassen Sie uns kurz rekapitulieren, was ein Data Mesh ist. Der von Zhamak Dehghani geprägte Begriff Data Mesh beschreibt ein Architekturparadigma, das darauf abzielt, die Herausforderungen bei der Skalierung von Daten in großen Unternehmen zu bewältigen. Es fördert einen dezentralen Ansatz für das Dateneigentum (Data Ownership) und den Datenzugriff, indem es Daten als Produkt behandelt und eine domänenorientierte Self-Service-Dateninfrastruktur etabliert.

Data Vault im Mesh: Eine synergetische Allianz

Lassen Sie uns nun über Data Vault sprechen. Data Vault ist seit Langem als robuste Methodik für den Aufbau von Enterprise Data Warehouses anerkannt und hat seinen Wert bei der Erstellung skalierbarer, flexibler und resilienter Datenarchitekturen unter Beweis gestellt. Seine Integration in einen Data-Mesh-Ansatz fügt jedoch eine neue Ebene der Agilität und Effizienz hinzu.

Skalierbarkeit

Data Mesh betont die Notwendigkeit eines dezentralen Dateneigentums, was eine horizontale Skalierung der Dateninfrastruktur entscheidend macht. Data Vault fügt sich mit seiner modularen und skalierbaren Architektur nahtlos in diese Anforderung ein. Durch die Aufteilung des Data Warehouses in kleinere, überschaubare Komponenten stellt Data Vault sicher, dass das System mühelos mit steigendem Datenvolumen und zunehmender Komplexität skalieren kann.

Flexibilität

In einem Data Mesh ist jede Domäne oder Geschäftseinheit für ihre eigenen Datenprodukte verantwortlich. Hier glänzt die Anpassungsfähigkeit von Data Vault, da verschiedene Teams ihre Daten unabhängig voneinander modellieren und verwalten können. Diese Flexibilität ermöglicht schnellere Entwicklungszyklen, reduziert die Abhängigkeiten von einem zentralen Datenteam und befähigt die Domänenteams, in ihrem eigenen Tempo Innovationen voranzutreiben und zu iterieren.

Resilienz

Data Mesh führt das Konzept von Datenprodukten und -services ein und betont die Notwendigkeit von Resilienz in Datenarchitekturen. Data Vault spielt mit seinem Fokus auf die Erfassung und Verwaltung historischer Datenänderungen eine entscheidende Rolle bei der Gewährleistung der Zuverlässigkeit und Integrität von Datenprodukten. Diese historische Datenhaltung erweist sich als unschätzbar wertvoll für Audits, Compliance und das Verständnis der Datenentwicklung im Laufe der Zeit.

Interoperabilität

Ein Data Mesh befürwortet eine föderierte Datenarchitektur, in der Datenprodukte nahtlos miteinander interagieren können. Die standardisierten Modellierungstechniken und klar definierten Schnittstellen von Data Vault erleichtern es verschiedenen Domänen, zusammenzuarbeiten und Daten auszutauschen, während gleichzeitig Konsistenz und Kohärenz im gesamten Ökosystem gewahrt bleiben.

Data Mesh & Data Vault

Fazit

Die Verbindung von Data Vault und Data Mesh stellt einen großen Fortschritt in der Evolution von Datenarchitekturen dar. Sie kombiniert die bewährte Zuverlässigkeit von Data Vault mit der Agilität und Skalierbarkeit eines dezentralen Data Mesh und bietet Unternehmen eine leistungsstarke Lösung für die Verwaltung ihrer stetig wachsenden und vielfältigen Datenlandschaft.

Obwohl die Integration von Data Vault in einen Data-Mesh-Ansatz zahlreiche Vorteile mit sich bringt, ist es wichtig, auch potenzielle Herausforderungen zu berücksichtigen. Die Steuerung des dezentralen Dateneigentums, die Gewährleistung einheitlicher Standards über Domänen hinweg und die Bereitstellung einer angemessenen Governance sind entscheidende Aspekte, die sorgfältig bedacht werden müssen.

Sehen Sie sich unbedingt die Webinar-Aufzeichnung zu „Data Mesh in einem Data-Vault-2.0-Ansatz“ an, um noch tiefer in das Thema einzusteigen.

In Datenwerkzeuge, Fortgeschrittene

Data Vault 2.0 mit Hadoop und Hive/Spark

Hadoop und Hive/Spark in Data Vault 2.0

In diesem Artikel erhalten Sie einen Überblick darüber, was Hadoop und Hive sind und warum sie als Alternative zu traditionellen Datenbanken eingesetzt werden können.

Data Vault 2.0 mit Hadoop und Hive/Spark

Dieses Webinar befasst sich eingehend mit den Details von Hadoop und Hive, einschließlich ihrer Funktionsweise und ihrer Kommunikation untereinander. Der zweite Teil der Präsentation konzentriert sich auf eine Data Vault 2.0-Beispielarchitektur unter Verwendung von Batch-Loading und bietet den Teilnehmern Einblicke, wie ein solches Szenario in der Praxis aussehen kann, um in realen Projekten einen echten Mehrwert zu schaffen. Unabhängig davon, ob Sie ein erfahrener Datenprofi sind oder gerade erst am Anfang stehen, ist dieses Webinar eine wertvolle Ressource für jeden, der mehr über Hadoop erfahren möchte. Wenn Sie also Ihr Wissen über diese Technologien erweitern und deren Potenzial in der Welt der Datenanalyse erkunden möchten, sollten Sie dieses Webinar nicht verpassen.

Watch webinar recording

In this article:

Hadoop

Hadoop wird verwendet, um große Datenmengen effizient zu verarbeiten und zu analysieren, indem die Arbeitslast auf einen Cluster aus Standardhardware (Commodity Hardware) verteilt wird. Dies ermöglicht eine parallele Verarbeitung und bietet Fehlertoleranz durch ein verteiltes Dateisystem und ein flexibles Ressourcenmanagement-Framework.

HDFS – Hadoop Distributed File System

HDFS ist ein verteiltes Dateisystem, das zuverlässigen und skalierbaren Speicher für Big Data bietet. Es zerlegt große Dateien in Blöcke und verteilt diese über einen Cluster aus Standardhardware. HDFS stellt die Zuverlässigkeit und Verfügbarkeit von Daten durch kontinuierliche Datenreplikation sicher.

Yet Another Resource Negotiator – YARN

YARN bietet ein flexibles, skalierbares Ressourcenmanagement-Framework für Hadoop, das es einer Vielzahl von Anwendungen und Workloads ermöglicht, nebeneinander zu existieren und die Ressourcen des Clusters effizient zu nutzen. Es abstrahiert die zugrunde liegende Infrastruktur und ermöglicht die dynamische Zuweisung von Ressourcen basierend auf den Anforderungen der jeweiligen Anwendung.

MapReduce – MR

MapReduce ist ein Programmiermodell und Verarbeitungs-Framework für die verteilte Datenverarbeitung in Hadoop. Es ermöglicht die parallele Verarbeitung großer Datensätze, indem es die Arbeitslast in Map- und Reduce-Aufgaben aufteilt. Map-Aufgaben verarbeiten die Daten parallel, woraufhin die Ausgabe kombiniert und reduziert wird, um das Endergebnis zu erzielen.

Hadoop Common

Hadoop Common stellt Bibliotheken, Hilfsprogramme und die nötige Infrastruktur für die anderen Komponenten von Hadoop bereit. Es umfasst allgemeine Dienstprogramme, Authentifizierungsmechanismen und Schnittstellen, die von verschiedenen Hadoop-Modulen genutzt werden.

Welche Vorteile bietet Hadoop?

Skalierbarkeit
Hadoop ermöglicht die Speicherung und Verarbeitung riesiger Datenmengen durch horizontale Skalierung über einen Cluster von Standardhardware. Es kann Petabytes an Daten verarbeiten, ohne dass die Leistung beeinträchtigt wird.

Verteiltes Rechnen (Distributed Computing)
Hadoop verteilt Daten und Verarbeitungsaufgaben auf mehrere Knoten in einem Cluster, was eine parallele Verarbeitung und eine schnellere Datenanalyse ermöglicht. Dieses verteilte Rechenmodell sorgt für eine effiziente Ressourcennutzung und eine hochperformante Datenverarbeitung.

Fehlertoleranz
Hadoop bietet eine hohe Fehlertoleranz, indem Daten über mehrere Knoten im Cluster hinweg repliziert werden. Wenn ein Knoten ausfällt, kann weiterhin auf die Daten von anderen Replikaten zugegriffen werden, was die Zuverlässigkeit und Verfügbarkeit der Daten garantiert.

Kosteneffizienz
Hadoop ist für den Betrieb auf kostengünstiger Standardhardware ausgelegt, was es zu einer wirtschaftlichen Lösung für die Speicherung und Verarbeitung großer Datenmengen macht. Dadurch erübrigt sich der Einsatz teurer Spezialhardware.

Flexibilität und Erweiterbarkeit
Die modulare Architektur von Hadoop ermöglicht die nahtlose Integration verschiedener Tools und Frameworks innerhalb des Hadoop-Ökosystems. Sie unterstützt eine Vielzahl von Datenverarbeitungsaufgaben, einschließlich Batch-Verarbeitung, Echtzeitverarbeitung, maschinellen Lernens und vielem mehr.

Datenlokalität (Data Locality)
Das verteilte Dateisystem von Hadoop, HDFS, zielt darauf ab, die Berechnung so nah wie möglich an die Daten zu bringen. Durch die Verarbeitung der Daten direkt an ihrem Speicherort minimiert Hadoop die Datenbewegung über das Netzwerk, was die Latenz verringert und die Gesamtleistung verbessert.

Ökosystem und Community
Hadoop verfügt über ein reichhaltiges Ökosystem mit einer Vielzahl von Tools, Bibliotheken und Frameworks, die seine Funktionalität für verschiedene Anwendungsfälle erweitern. Zudem gibt es eine große und aktive Community von Nutzern, Entwicklern und Mitwirkenden, die kontinuierliche Verbesserungen und Support bereitstellen.

Diese Vorteile machen Hadoop zu einer leistungsstarken und bewährten Lösung für den Umgang mit Big Data, die es Unternehmen ermöglicht, riesige Mengen strukturierter und unstrukturierter Daten effizient zu speichern, zu verarbeiten und wertvolle Erkenntnisse daraus zu gewinnen. Das gesamte Ökosystem kann auch lokal (On-Premises) betrieben werden, was es zu einer hervorragenden Alternative macht, wenn die Cloud keine Option darstellt.

HIVE

Hive ist eine Data-Warehouse-Infrastruktur, die auf Hadoop aufbaut und eine höhere, SQL-ähnliche Abfragesprache namens HiveQL für die Abfrage und Analyse großer Datensätze bereitstellt.

Was sind die Komponenten?

Datenspeicherung
Hive nutzt das Hadoop Distributed File System (HDFS) als zugrunde liegendes Speichersystem. Es speichert Daten im HDFS auf verteilte und fehlertolerante Weise, was eine skalierbare und zuverlässige Datenspeicherung ermöglicht.

Schemadefinition
Hive ermöglicht es Benutzern, ein Schema für ihre Daten mithilfe einer Sprache namens Hive Data Definition Language (DDL) zu definieren. Dies erlaubt es den Anwendern, Tabellen, Partitionen, Spalten, Datentypen und andere mit den Daten verknüpfte Metadaten festzulegen.

Abfrageoptimierung
Hive optimiert Abfragen durch moderne Abfrageplanung und Optimierungstechniken. Ziel ist es, effiziente Ausführungspläne zu erstellen, um Datenbewegungen zu minimieren, die Ressourcennutzung zu optimieren und die Abfrageleistung zu maximieren.

Hive Metastore
Hive unterhält ein Metadaten-Repository namens Hive Metastore. Es speichert Informationen über Tabellen, Partitionen, Schemata und andere Metadaten, die mit den im HDFS gespeicherten Daten verknüpft sind. Der Metastore ermöglicht eine effiziente Verwaltung und den schnellen Abruf von Metadaten während der Abfrageverarbeitung.

Erweiterbarkeit:
Hive bietet eine hohe Flexibilität durch benutzerdefinierte Funktionen wie User-Defined Functions (UDFs), User-Defined Aggregations (UDAs) und User-Defined Table Functions (UDTFs). Diese ermöglichen es Entwicklern, eigene Logiken und Operationen in Programmiersprachen wie Java, Python oder anderen unterstützten Sprachen zu implementieren

Integration mit anderen Tools
Hive lässt sich nahtlos in verschiedene andere Tools und Frameworks im Hadoop-Ökosystem integrieren. Beispielsweise kann es zusammen mit Apache Spark, Apache Pig, Apache HBase und anderen Komponenten eingesetzt werden, um eine vollständige Datenverarbeitungs- und Analyselösung bereitzustellen.

Partitionierung und Bucketing
Hive unterstützt Datenpartitionierung und Bucketing, was eine strukturierte Organisation und Speicherung der Daten ermöglicht. Die Partitionierung teilt Daten basierend auf bestimmten Kriterien in logische Partitionen auf, während Bucketing die Daten anhand von Hash-Werten in gleich große Buckets unterteilt.

SerDe
Hive verwendet ein Serialisierungs- und Deserialisierungs-Framework namens SerDe (Serializer/Deserializer), um Daten in verschiedenen Formaten wie CSV, JSON, Avro und anderen zu lesen und zu schreiben. Benutzer können das passende SerDe für ihr jeweiliges Datenformat angeben, um eine reibungslose Datenverarbeitung zu gewährleisten

Insgesamt vereinfacht Hive die Abfrage und Analyse von Daten in Hadoop durch die Bereitstellung einer vertrauten, SQL-ähnlichen Schnittstelle. Es abstrahiert die Komplexität des Schreibens von Low-Level-MapReduce- oder Tez-Jobs und bietet einen deklarativen und benutzerfreundlichen Ansatz für die Interaktion mit großen Datenmengen.

Fazit

Hadoop ist eine robuste und funktionsreiche Umgebung, deren Verwaltung und Administration durchaus eine Herausforderung darstellen kann. Seine zahlreichen Vorteile machen es jedoch zu einer äußerst attraktiven Wahl, je nach den individuellen Anforderungen und dem im Unternehmen vorhandenen Fachwissen. Wenn Sie mehr darüber erfahren möchten, sehen Sie sich gerne die folgende Aufzeichnung an.

In Anfänger, Data Vault

Kurzanleitung für eine Data Vault 2.0-Implementierung

Data Vault 2.0 Architecture

Data Vault 2.0-Implementierung

Es wird oft angenommen, dass Data Vault 2.0 lediglich eine Modellierungstechnik ist. Doch der Ansatz umfasst weit mehr als das: Er ist eine vollständige BI-Lösung, die sich aus agiler Methodik, Architektur, Implementierung und Modellierung zusammensetzt.

Warum also sollten Sie Data Vault nutzen?

  • Data Vault 2.0 ermöglicht es Ihnen, automatisierte Ladeprozesse und -muster zu erstellen und Modelle auf einfache Weise zu generieren
  • Plattformunabhängigkeit
  • Auditierbarkeit (Revisionssicherheit)
  • Skalierbarkeit
  • Unterstützung von ELT- anstelle von ETL-Prozessen

Nachdem wir das „Warum“ beantwortet haben, fragen Sie sich vielleicht, welche Schritte erforderlich sind, um Data Vault 2.0 in Ihrem Projekt zu implementieren.

Dies hängt von vielen Faktoren ab, wie beispielsweise Ihrem Business Case, der gewünschten Architektur, der Lademethode Ihrer Datenquellen oder dem Sprint-Plan Ihres Projekts.

Schritt-für-Schritt-Anleitung für eine Data Vault 2.0-Implementierung

Für Einsteiger kann es zunächst überwältigend sein, mit der Nutzung von Data Vault 2.0 zu beginnen und zu verstehen, wie und wo die Implementierung ansetzen soll. Dieses Webinar bietet eine grundlegende Anleitung, die die erforderlichen Schritte zeigt, um eine Data Vault 2.0-Implementierung auf Basis einer Geschäftsanforderung von Grund auf zu realisieren. Dies wird anhand eines praktischen Beispiels demonstriert, das von der Erfassung der ersten Anforderungen bis hin zum fertigen, bereitgestellten Produkt reicht.

Watch Webinar Part 1Watch Webinar Part 2

In this article:

Feature-by-Feature-Architektur in Data Vault 2.0

Eines ist sicher: Die Architektur sollte vertikal und nicht horizontal aufgebaut werden. Das bedeutet nicht Schicht für Schicht, sondern Feature für Feature.

Ein gängiger Ansatz hierbei ist der Tracer-Bullet-Ansatz. Auf Basis des geschäftlichen Nutzens (Business Value), der durch einen Bericht, ein Dashboard oder einen Information Mart definiert wird, müssen die Quelldaten identifiziert, modelliert und durch alle Schichten der Architektur geladen werden.

Nehmen wir beispielsweise an, die geschäftliche Anforderung bestünde darin, ein Dashboard zur Analyse der Umsätze des Unternehmens zu erstellen:

1. Extract

Zuerst müssen wir die Daten aus den Quellsystemen extrahieren und diese im Originalzustand laden. In diesem Beispiel legen wir sie in einer transienten Staging Area ab, Sie können jedoch ebenso eine persistente Staging Area in einem Data Lake wählen.

2. Transform

Als Nächstes sollten Sie, falls erforderlich, mithilfe eines Transformationstools grundlegende Transformationsregeln (Hard Rules) anwenden. Seien Sie hierbei vorsichtig, da an dieser Stelle noch keine fachlichen Berechnungen (Business Rules) durchgeführt werden sollten. Es gibt viele verschiedene Data-Warehouse-Automatisierungstools, aus denen Sie wählen können: dbt, Coalesce, WhereScape etc.

Data Vault 2.0 Architecture

3. Load

Laden Sie Ihre Daten aus der Staging Area (Raw Stage) in den Raw Vault.

4. Geschäftsanforderungen modellieren

Modellieren Sie die Data Vault-Entitäten, die zur Erfüllung der Geschäftsanforderung benötigt werden. Liegen beispielsweise Verkaufstransaktionen und Kundendaten vor, modellieren wir einen Non-historized Link (auch bekannt als Transactional Link) und einen Customer Hub sowie alle zusätzlichen Satelliten zur Speicherung der beschreibenden Kundendaten, die letztendlich im Sales-Dashboard dargestellt werden sollen.

5. Business Logic anwenden

Als Nächstes müssen einige Berechnungen und Aggregationen durchgeführt werden. Daher erstellen wir die Business Logic auf Basis der Raw-Vault-Entitäten und laden diese in den Business Vault.

6. Einen Information Mart aufbauen

Nun könnten wir die im Raw Vault und Business Vault gespeicherten Daten direkt für Diagramme und Dashboards nutzen. Wir möchten die Daten jedoch so strukturieren, dass sie von den Fachanwendern leicht gelesen und abgerufen werden können. Daher erstellen wir einen Information Mart auf Basis eines Sternschemas (Star Schema) mit einer Faktentabelle (Fact Table) und Dimensionen.

7. Daten visualisieren

Um das Sales-Dashboard in einem BI-Visualisierungstool wie Power BI oder Tableau zu erstellen, rufen wir die Daten direkt aus dem Sternschema im Information Mart ab. Dieser ist über das Data Warehouse angebunden und enthält alle benötigten Informationen.

Data Vault 2.0 bietet einen agilen, skalierbaren und flexiblen Ansatz für die Data-Warehouse-Automatisierung. Wie im Beispiel gezeigt, haben wir nur die Data Vault-Tabellen modelliert, die für die Bewältigung der gestellten Aufgabe – der Erstellung eines Sales-Dashboards – erforderlich waren. Auf diese Weise können Sie Ihre Datenlandschaft bedarfsgerecht skalieren, ohne das gesamte Unternehmen auf einmal abbilden zu müssen

Die Antwort auf die Frage, wie Data Vault 2.0 implementiert werden soll, lässt sich in einer einfachen Phrase zusammenfassen: Fokussieren Sie sich auf den Business Value!

Wenn Sie eine detaillierte Erklärung dieser schrittweisen Implementierung inklusive einer Demonstration mit realen Daten und dbt als Transformationstool sehen möchten, schauen Sie sich gerne unsere Webinar-Aufzeichnung an.

Fazit

Die Implementierung von Data Vault 2.0 folgt einem strukturierten Ansatz, der mit der Extraktion von Daten aus Quellsystemen in eine Staging Area beginnt, gefolgt von den minimal erforderlichen Transformationen und dem Laden in den Raw Vault. Anschließend bestimmen die Geschäftsanforderungen die Modellierung der Data Vault-Entitäten, die Anwendung der Business Logic, den Aufbau von Information Marts und die Datenvisualisierung. Diese Feature-by-Feature-Methodik gewährleistet Skalierbarkeit sowie Flexibilität und ermöglicht es Unternehmen, sich auf die schrittweise Bereitstellung von Business Value zu konzentrieren. Durch die Ausrichtung der Entwicklungsaktivitäten an konkreten geschäftlichen Anforderungen lassen sich Data-Warehouse-Lösungen effizient aufbauen und kontinuierlich erweitern.

In Datenwerkzeuge, Fortgeschrittene

Beschleunigen Sie Ihr Data Vault 2.0 mit TurboVault4dbt

TurboVault4dbt Logo

TurboVault4dbt

Scalefree hat TurboVault4dbt veröffentlicht – ein Open-Source-Paket zur automatisierten Modellgenerierung auf Basis der Metadaten Ihrer Quellen unter Verwendung von DataVault4dbt-kompatiblen Templates.

TurboVault4dbt unterstützt derzeit die Metadateneingabe aus Excel, Google Sheets, BigQuery sowie Snowflake und hilft Ihrem Unternehmen bei:

  • der Beschleunigung des Entwicklungsprozesses, der Reduzierung von Entwicklungskosten und der Erzielung schnellerer Ergebnisse
  • der Motivation von Nutzern, ihre Quelldaten zu analysieren und zu verstehen

Beschleunigen Sie Ihre Data Vault 2.0-Implementierung – mit TurboVault4dbt

Dieses Webinar befasst sich eingehend mit TurboVault4dbt, einem Open-Source-Tool von Scalefree, das die Implementierung von Data Vault 2.0 beschleunigt. Es automatisiert die Erstellung von dbt-Modellen mithilfe Ihrer Quellmetadaten, was Zeit und Kosten spart und gleichzeitig eine bessere Datenanalyse fördert.

TurboVault4dbt arbeitet mit Metadateneingaben aus Excel, Google Sheets, BigQuery und Snowflake und generiert automatisch Modelle für Hubs, Links und Satellites. Richten Sie einfach Ihre Metadatentabellen ein, verbinden Sie das Tool und sehen Sie selbst, wie es die schwere Arbeit für Sie erledigt!

Watch webinar recording

In this article:

„Ist nicht jedes Modell irgendwie gleich?“

DataVault4dbt ist das Ergebnis jahrelanger Erfahrung in der Entwicklung und dem Laden von Data Vault 2.0-Lösungen, geschmiedet zu einer vollständig auditierbaren Lösung für Ihr dbt-basiertes Data Vault 2.0 Data Warehouse.

Aber jeder Entwickler, der bereits mit dem Paket gearbeitet oder dbt-Modelle für den Raw Vault erstellt hat, kennt folgendes Ärgernis:

Das Erstellen eines neuen dbt-Modells für eine Tabelle bedeutet, das vorhandene Template zu kopieren und mit den spezifischen Metadaten dieser Tabelle zu befüllen. Diese ständige Wiederholung ist eine mühsame Aufgabe. Aus diesem Grund haben wir TurboVault4dbt entwickelt, um diesen Prozess zu automatisieren und zu beschleunigen.

Von STRG+C und STRG+V zu einem einfachen Mausklick

Wie oft haben Sie schon STRG+C und dann STRG+V gedrückt und einige Zeilen Code angepasst, um neue dbt-Modelle für den Raw Vault zu erstellen?

Anstatt mühsam herauszufinden, wie die Namen Ihrer Tabellen und Business Keys lauten oder in welcher Reihenfolge Ihr Hash-Key generiert werden soll, erledigt TurboVault4dbt all das für Sie. Alles, was TurboVault4dbt benötigt, sind die Metadaten, in denen Sie die Struktur Ihres Data Warehouse erfassen.

TurboVault4dbt

TurboVault4dbt erfordert derzeit eine Struktur aus fünf Metadatentabellen:

  • Hub Entities: Diese Tabelle speichert Metadaten zu Ihren Hubs, z. B. Hub-Name, Business Keys, Spaltensortierung für das Hashing usw.
  • Link Entities: Diese Tabelle speichert Metadaten zu Ihren Links, z. B. Link-Name, referenzierte Hubs, Pre-Join-Spalten usw.
  • Hub Satellites: Diese Tabelle speichert Metadaten zu Ihren Hub Satellites, z. B. Satellite-Name, referenzierter Hub, Spaltendefinition usw.
  • Link Satellites: Diese Tabelle speichert Metadaten zu Ihren Link Satellites, z. B. Satellite-Name, referenzierter Link, Spaltendefinition usw
  • Source Data: Diese Tabelle speichert Metadaten zu Ihren Quellen, z. B. Quellsystem, Quellobjekt, Quellschema usw.

Durch die Erfassung der Metadaten in diesen fünf Tabellen kann TurboVault4dbt die benötigten Informationen extrahieren und jedes auf einer ausgewählten Quelle basierende Modell automatisch generieren. Gleichzeitig werden Sie als Nutzer dazu angeregt, Ihre Daten besser zu analysieren und zu verstehen.

Fazit: Lehnen Sie sich zurück, entspannen Sie sich und lassen Sie TurboVault4dbt die Arbeit erledigen!

Erstellen und befüllen Sie Ihre Metadatentabellen, verbinden Sie sie mit TurboVault4dbt und nutzen Sie die gewonnene Zeit für eine entspannte Tasse Kaffee. Probieren Sie es aus und geben Sie uns Feedback, indem Sie TurboVault4dbt auf GitHub besuchen!

Bleiben Sie über unsere Kanäle auf dem Laufenden, denn es stehen bereits großartige neue Features für TurboVault4dbt in den Startlöchern!

In Data Vault, Fortgeschrittene

Was gibt es Neues in Data Vault?

Data Vault 2.0

Teilnehmer unserer Data Vault 2.0-Schulungen fragen uns häufig, worin der Unterschied zwischen dem Buch „Building a Scalable Data Warehouse with Data Vault 2.0“ und unserer aktuellen Beratungspraxis besteht. Um zumindest vorerst eine eindeutige Antwort zu geben, haben wir diesen Artikel verfasst.

Was gibt es Neues in Data Vault?

Dieser Artikel behandelt aktuelle Updates in den Data Vault 2.0-Praktiken seit der Veröffentlichung des Buches „Building a Scalable Data Warehouse with Data Vault 2.0“. Zu den wesentlichen Änderungen gehören die Virtualisierung des Load End Date mithilfe von Window Functions zur Steigerung der Effizienz, die Einführung hybrider Architekturen, die Data Lakes für Staging-Zwecke integrieren, sowie die Verlagerung von Business Timelines in das dimensionale Modell für eine höhere Flexibilität. Darüber hinaus liegt ein Schwerpunkt auf der Verwendung von Snapshot-Date-Zeitstempeln in Business-Vault-Satelliten, um die Entwicklung von Business-Regeln zu vereinfachen. Der Artikel stellt klar, dass diese Updates als Erweiterungen innerhalb des bestehenden Data Vault 2.0-Frameworks betrachtet werden – bezeichnet als „Data Vault 2.0.1“ –, anstatt eine neue Version wie Data Vault 3.0 darzustellen.

Watch webinar recording

In this article:

Data Vault 3.0?

Vorab: Es gibt kein Data Vault 3.0. Wir bezeichnen die Version von Data Vault, die wir unterrichten und in unserer Beratungspraxis anwenden, gerne als „Data Vault 2.0.1“. Daher gibt es nur geringfügige Unterschiede zu der Version, die wir im Buch verwendet haben. Einige dieser Änderungen wirken groß, ändern jedoch nicht das zugrundeliegende Konzept – und das ist es, worauf es bei Versionsänderungen ankommt. Auf Konzept-Ebene sehen wir also nur geringfügige Anpassungen oder Erweiterungen. Diese können allerdings größere Auswirkungen auf die praktische Implementierung haben, was wiederum rein auf technologische Veränderungen zurückzuführen ist.

Wie man Data Vault 2.0 zwischen zwei Buchdeckeln unterbringt

Neben den geringfügigen Änderungen am Konzept spielt hier noch ein weiterer Faktor eine Rolle: Beim Schreiben des Buches mussten wir den Umfang begrenzen, damit es zwischen die Buchdeckel passte, da der Verlag eine Seitenbegrenzung hatte (die wir tatsächlich leicht überschritten haben). Daher haben wir im Buch nicht alle Data Vault 2.0-Konzepte angewendet: Echtzeit-Konzepte (Real-Time) werden beispielsweise im Buch nicht behandelt, und wir haben in unseren Beispielen weder einen Data Lake noch Cloud Computing verwendet. Stattdessen haben wir diese Konzepte der Vollständigkeit halber nur kurz angeschnitten und uns auf On-Premise-Technologien konzentriert, die damals in realen Projekten häufiger eingesetzt wurden. Im Jahr 2012 war Cloud Computing zwar bereits verfügbar und weit verbreitet, aber es war einfacher, das Buch durch die Verwendung von On-Premise-Technologien auf eine breitere Leserschaft zuzuschneiden.

Was hat sich vor diesem Hintergrund seit dem Erscheinen des Buches verändert?

Entfernung des Load End Date

Die offensichtlichste Änderung ist die Entfernung des Load End Date. In unseren Praxisprojekten entfernen wir es jedoch nicht vollständig aus dem Data Vault 2.0-Modell, sondern virtualisieren es lediglich: Wir entfernen das Load End Date aus der zugrundeliegenden Satellite-Tabelle und berechnen es virtuell in einer View oberhalb der Satellite-Tabelle mithilfe einer Window Function (typischerweise LEAD, aber auch LAG ist möglich). Auf diese Weise können wir auf das Update-Verfahren zur Pflege des Load End Date (den sogenannten End-Dating-Prozess) verzichten, während die Abfragemuster (Query Patterns) nachgelagert erhalten bleiben. Bedenken Sie, dass es beim Laden von PIT-Tabellen oder Satelliten auch effizienter sein kann, die Window Function zu verwenden; daher ist der Query Layer eigentlich nur für Power User gedacht, wenn diese das Data Vault-Modell direkt abfragen.

Das ist eigentlich kein Update: Bereits 2012 (und davor) haben wir diese Ansätze genutzt, aber sie funktionierten nicht unter SQL Server 2014, der im Buch verwendet wurde, da die für diesen Ansatz erforderliche analytische Window Function viel zu langsam war. Dies verbesserte sich jedoch 2016. Um das Load End Date in Szenarien loszuwerden, in denen die Window Function zu langsam ist oder schlicht nicht existiert, hat sich eine neue Lösung etabliert: die Verwendung einer Snapshot-Partition in der PIT-Tabelle. Das „Ende aller Zeiten“ wird in der PIT-Tabelle verwendet, um für den Delta-Check auf das neueste Delta in jedem Satelliten zu verweisen. Sobald die PIT-Tabelle verfügbar ist, kann sie auch zur Erzeugung von SCD Type 1-Dimensionen (ohne Historie) verwendet werden, wodurch der Bedarf an dem Load End Date (oder einem schnellen Ersatz wie oben beschrieben) nur noch beim Laden besteht.

Hybride Architektur

Die nächste offensichtliche Änderung ist die Nutzung einer hybriden Architektur, bei der ein Data Lake für Staging-Zwecke verwendet wird. Im Buch haben wir uns auf den On-Premise Microsoft-SQL-Server-Stack konzentriert, der kein verteiltes Dateisystem enthielt. Wir haben Kunden bereits damals empfohlen, einen Data Lake für Staging-Zwecke zu nutzen – in einer Architektur, die wir als „hybride Architektur“ bezeichneten. Damals folgten nur wenige diesem Rat, aber heute nutzen die meisten Kunden die hybride Architektur für ihr Data Warehouse. Wir betrachten eine relationale Staging-Area mittlerweile als Anti-Pattern und empfehlen sie unseren Kunden (mit wenigen Ausnahmen) nicht mehr.

Multi-Temporal Data Vault 2.0

Das Buch beschreibt einen Temporal PIT (TPIT) für den Aufbau multi-temporaler Lösungen. Während das Pattern nach wie vor gültig und im Vergleich zu anderen Lösungen relativ flexibel ist, verlagern wir heute für maximale Flexibilität die Business Timelines in der Regel in das dimensionale Modell. Dies wird im Kurs „Multi-Temporal Data Vault 2.0“ detaillierter behandelt. TPITs sind weniger flexibel, bieten aber eine höhere Performance.

Snapshot Date

Satelliten im Business Vault verwenden möglicherweise einen Snapshot-Date-Zeitstempel anstelle eines Load-Date-Zeitstempels. Die Idee dahinter ist, dass eine Business-Vault-Entität als allgemeine Praxis immer eine bestehende Granularität wiederverwenden sollte. Dadurch wird die Entwicklung von Business-Vault-Lösungen deutlich einfacher. Mit dem Snapshot Date im Primärschlüssel des Satelliten wird dies für Business-Regeln auf der ausgehenden Informationsgranularität wesentlich einfacher. Dies wird im Kurs „Data Vault 2.0 Information Delivery“ detaillierter behandelt.

Fazit

Und schließlich haben wir auch einige Fehler gemacht. Wir sind bereit (wenn auch nicht begeistert), diese auf unserer Errata-Seite für das Buch zuzugeben – dieser Link stammt direkt aus unserem internen Wiki und wir versprechen, ihn auf dem neuesten Stand zu halten (allerdings haben wir in letzter Zeit keine weiteren Meldungen erhalten).

In Data Vault, Experte

Multitemporalität in Data Vault 2.0 – Teil 2

An abstract illustration features a large clock in the center with connected circuitry-like lines. Icons of a calendar and a smaller clock are in the background. Two large arrows pointing outward appear on both sides, and the backdrop has splashes of blue and gray.

Multitemporalität

Dieser Artikel befasst sich mit dem Management von Multitemporalität in Data Vault 2.0 anhand eines Szenarios aus der Reisebranche. Er beleuchtet, wie operative Systeme und Business-Intelligence-Systeme unterschiedlich mit Daten umgehen, und zeigt auf, wie Data Vault 2.0 eine umfassende historische Nachverfolgung sowie multitemporale Analysen unterstützt.

Multitemporalität in Data Vault 2.0

Vielleicht haben Sie bereits von bitemporalen Daten gehört. Meistens gibt es jedoch mehr als nur zwei Zeitachsen in Ihren Daten, die Ihre Arbeit erschweren. In der Regel finden Sie in Ihren Datensätzen mehrere Zeitstempel und Datumsangaben aus unterschiedlichen Perspektiven. Das eröffnet verschiedene Möglichkeiten, wie Sie Ihre Daten aus zeitlicher Sicht betrachten können. Allerdings sollten Sie auch in der Lage sein, dieses Biest einer Zeitmaschine zu beherrschen. Wussten Sie, dass Data Vault 2.0 in der Lage ist, multitemporale Daten zu verarbeiten? Wie beeinflusst dies Ihre Arbeit und wie können Sie davon profitieren? Nehmen Sie an diesem Webinar teil und erfahren Sie, wie Data Vault 2.0 Ihnen dabei helfen kann, Multitemporalität zu meistern.

Watch webinar recording

In this article:

Multitemporales Beispiel aus der Reisebranche

In einem unserer vorherigen Blogbeiträge haben wir Ihnen einen Einblick in die Grundlagen der Multitemporalität in Data Vault 2.0 gegeben. Dieser Artikel liefert Ihnen ein kurzes Praxisbeispiel zu diesem Thema. Wenn Sie Ihren Urlaub buchen, ändern Sie nach der ursprünglichen Buchung möglicherweise noch etwas: die Dauer, den Abflugort, das Hotel, das Start- oder Enddatum Ihrer Reise oder Sie buchen einfach noch ein paar Extras hinzu. Aus operativer Sicht stellen diese Änderungen kein Problem dar und die Anforderungen sind überschaubar. Der Datensatz für Ihre Reise wird in der Datenbank des Quellsystems aktualisiert und in der Benutzeroberfläche werden nur die aktuellsten Daten angezeigt. Die Mitarbeitenden sehen möglicherweise einige Protokolle im Historienbereich, sofern vorhanden. Das reicht in der Regel aus, um den operativen Betrieb aufrechtzuerhalten. In der Welt der Business Intelligence ist der Umgang mit Daten etwas anders. Dort wollen wir alles sehen. Jedes Mal, wenn ein Datensatz im Quellsystem aktualisiert wird, erfassen wir alle Änderungen und speichern sie in einer separaten Datenbank. Das bedeutet, dass wir eine neue Zeitachse einführen, die uns neue Möglichkeiten bietet, aber auch neue Herausforderungen mit sich bringt. Werfen wir einen Blick auf einige Beispiel-Datensätze eines Quellsystems im Zeitverlauf:

Tag 1: Erstbuchung einer Urlaubsreise

This Image shows the initial booking data of a holiday trip - multi-temporality example

Tag 2: Korrektur des Start- und Enddatums sowie eine kleine Preisanpassung

Day 2 - multi-temporality example

Tag 3: Korrektur des Start- und Enddatums sowie eine kleine Preisanpassung

The employee in the tourist office promised the early bird price. To apply for it, the booking date needs to be adjusted. But the old booking needs to be cancelled first as the booking date can only be set on the initial creation (operational business rule). Multi-temporality example

Wenn Sie heute einen Blick in das Quellsystem werfen, werden Sie sehen, dass Buchung B4711 storniert wurde oder vielleicht komplett verschwunden ist und B4712 die aktive Buchung ist (ID = 2, erstellt an Tag 3). Aus analytischer Perspektive haben Sie möglicherweise noch weitere Fragen, die Sie beantworten möchten.
Zum Beispiel:

  • Wie hoch war der geschätzte Umsatz für Juli aus der Perspektive des Februars?
  • Wie hoch war der geschätzte Umsatz für Juli aus der Perspektive des März?
  • Welche Datumsangaben muss ich verwenden, um die beiden obigen Fragen zu beantworten?
  • In welchem Monat verzeichnen wir die meisten Buchungen für die nächste Sommersaison?
  • Können wir einen Bericht reproduzieren, den wir vor einigen Monaten erstellt haben?
  • Was passiert, wenn sich einige fachliche Datumsangaben ändern? Was beeinflusst meine Berichte in der Vergangenheit?
  • Wo können wir die Daten aufbereiten, um all diese Fragen zu beantworten? Im Data Warehouse? Im Frontend-BI-Tool? Oder woanders?

In unserem Webinar „Multi-Temporality in Data Vault 2.0“ geben wir Ihnen Antworten auf all diese Fragen unter Verwendung von Data-Vault-Entitäten.

Wenn Sie daran interessiert sind, weitere Anwendungsfälle zum Thema Multitemporalität zu sehen: Wir bieten einen 2-tägigen Kurs speziell zu diesem Thema an: „Multi-Temporal Data Vault 2.0 Class“.

Fazit

Die Einbindung von Multitemporalität in Data Vault 2.0, wie am Beispiel der Reisebranche gezeigt, ermöglicht es Unternehmen, Datenänderungen über mehrere Zeitachsen hinweg effektiv zu erfassen und zu analysieren. Dieser Ansatz bewahrt nicht nur die historische Genauigkeit, sondern ermöglicht auch umfassende Einblicke in Geschäftsprozesse. Durch die Nutzung der Funktionen von Data Vault 2.0 können Unternehmen komplexe zeitliche Fragestellungen beantworten, wie etwa die Erstellung von Umsatzprognosen aus unterschiedlichen Blickwinkeln im Zeitverlauf und die präzise Reproduktion vergangener Berichte. Diese Methodik gewährleistet ein robustes Framework für die Verwaltung sich verändernder Datenlandschaften und unterstützt fundierte Entscheidungen.

In Data Vault

Warum Sie Data Vault 2.0 nutzen sollten?

Data Lineage with Data Vault 2.0

Warum Data Vault 2.0?

Dieser Blogartikel befasst sich mit den Stärken von Data Vault 2.0 und zeigt auf, warum Sie diese Methode für Ihr Data Warehouse nutzen sollten. Als Datenbankentwickler, -administrator oder -anwender haben Sie wahrscheinlich schon von Data Vault gehört. Wenn Sie bereits eine Datenbanklösung im Einsatz haben, stellen Sie sich jedoch vielleicht die Frage, warum Sie Data Vault in Ihrem Enterprise Data Warehouse implementieren sollten.

In this article:

Grund 1: Unterstützung mehrerer Quellsysteme und sich häufig ändernder Beziehungen

Data Vault 2.0 bietet die größten Vorteile, wenn Ihre Daten aus vielen verschiedenen Quellsystemen stammen oder sich ständig ändernde Beziehungen aufweisen.

Data Vault 2.0 eignet sich hervorragend für Umgebungen mit mehreren Quellsystemen oder für Datenstrukturen mit sich kontinuierlich ändernden Beziehungen.

Dies funktioniert in solchen Systemen deshalb so gut, weil sich neue Attribute ganz einfach hinzufügen lassen. Wenn sich ein Quellsystem ändert, muss diese Änderung nicht mühsam in allen anderen Quellsystemen abgebildet werden. Zudem lässt sich die Anzahl der anzupassenden Stellen minimieren, da Attribute getrennt von den Strukturdaten in Satellites gespeichert werden.

Darüber hinaus lassen sich neue und veränderte Beziehungen einfacher abbilden, indem ein Link geschlossen und ein neuer erstellt wird. Sie müssen weder historische Daten anpassen, um eine neue Beziehung zu berücksichtigen, noch ein bestehendes Schema aktualisieren. Sie müssen lediglich zukünftige Änderungen erfassen. Dies verleiht Ihrem Enterprise Data Warehouse eine enorme Flexibilität und Skalierbarkeit.

Grund 2: Einfache Nachverfolgung und Auditierung Ihrer Daten mit Data Vault 2.0

In einer modernen Datenumgebung durchlaufen Daten verschiedene Stationen. Um dennoch eine kontinuierliche Datenqualität zu gewährleisten, muss immer klar nachvollziehbar sein, woher die Daten stammen.

Data Lineage with Data Vault 2.0

Abbildung 1: Data Lineage

Da die lückenlose Nachverfolgbarkeit und Auditierung von Daten heute unerlässlich sind, bietet Data Vault hierfür eine optimale Unterstützung. Dies gelingt durch die standardmäßige Auditierbarkeit, da für jede Zeile Ladezeiten (Load Times) und Datenquellen (Record Sources) zwingend erforderlich sind. Zudem werden alle historischen Änderungen in Satellites erfasst, wobei die Load Time Teil des Primary Keys ist.
Bei der Aktualisierung eines Attributs wird einfach ein neuer Datensatz angelegt.
Diese Auditierungsfunktionen ermöglichen es Ihnen, die Revisionssicherheit, sowohl für regulatorische Vorgaben als auch für die Data Governance mühelos zu gewährleisten. Da die gesamte Historie gespeichert bleibt können Sie jederzeit auf den Datenbestand zu einem beliebigen historischen Zeitpunkt zugreifen.

Grund 3: Schnelleres Laden von Daten aus mehreren Quellsystemen mit Data Vault 2.0

Data Vault ermöglicht ein schnelleres Laden von Daten, da eine Vielzahl von Tabellen parallel und unabhängig voneinander geladen werden kann. Das Modell reduziert die Abhängigkeiten zwischen den Tabellen während des Ladeprozesses und vereinfacht die Datenintegration (Ingestion), indem es ausschließlich auf Inserts setzt. Diese lassen sich deutlich schneller ausführen als Upserts oder Merges. Dies verringert zudem die Gesamtkomplexität des Systems.

Fazit

Data Vault 2.0 ist speziell für die Integration von Daten aus mehreren Quellsystemen konzipiert und bietet in komplexen Szenarien herausragende Vorteile.

Zusammenfassend lässt sich sagen: Wenn Sie nur geringe bis mittlere Anforderungen an Ihre Analytics-Plattform stellen und ein kleines Team aus Architekten, Designern und Entwicklern eine Lösung mit Daten aus nur wenigen Systemen bereitstellt, ist Data Vault für Ihre Anforderungen eventuell überdimensioniert.

Wenn Sie jedoch ein großes Projekt mit vielen Quellsystemen umsetzen, das hohe Anforderungen an die Datenintegration stellt, kann Data Vault Ihrem Projekt einen entscheidenden Mehrwert bieten.

Close Menu