Einleitung
In diesem Newsletter geben wir Ihnen einen Überblick über die Möglichkeiten zur Überwachung Ihrer Lösung innerhalb eines Enterprise Data Warehouse (EDW), das auf Data Vault 2.0 basiert.
Die vorgestellten Monitoring-Ansätze zeigen Ihnen verschiedene Wege auf, um fundierte Einblicke in die Performance Ihrer Data-Warehouse-Lösung zu gewinnen. Das Ziel besteht darin, nützliche Informationen über die technischen Daten Ihres EDW zu gewinnen und diese gezielt zu nutzen: zur Fehlernachverfolgung, zur Identifikation von Engpässen in Lade- und Transformationsprozessen sowie zur Steigerung der Gesamtperformance Ihres Data Warehouse.
In unserer Webinar-Session sind wir tiefer in das Thema technischer Test- und Monitoring-Methoden für ein Data Vault-basiertes EDW eingetaucht. Dabei wurden alle EDW-Schichten abgedeckt und Performance-Einblicke mit Schwerpunkt auf der Modellierung von Metrics Vaults und Marts unter Berücksichtigung der Quelldaten vermittelt.
Sehen Sie sich die Aufzeichnung hier kostenlos an!
Was Sie erwartet
Sie erhalten einen Überblick über verschiedene Metriken und Metadatenarten zur Überwachung Ihrer Lösung. Im nächsten Schritt wird der Modellierungsansatz zur Erfassung und späteren Analyse der Daten für die verschiedenen Schichten Ihres EDW behandelt vom klassischen Metrics Vault bis hin zu den Metrics Marts. Darüber hinaus werden relevante Monitoring-Bereiche mit Fokus auf potenzielle Herausforderungen innerhalb Ihrer Architektur thematisiert. Der Schwerpunkt dieses Newsletters liegt darauf, wie Metadaten bereitgestellt und für wertvolle Erkenntnisse nutzbar gemacht werden können.
Modellierung von Metadaten
Im Folgenden werden vier Instanzen behandelt, die nützliche technische Daten enthalten: der Metrics Vault und der darauf aufbauende Metrics Mart, der Meta Mart sowie der Error Mart. Jede dieser Komponenten erfüllt ihren eigenen Zweck, auch wenn sich Modellierung und Datenquellen ähneln können. Die Gemeinsamkeiten und Unterschiede zwischen den Modellierungsansätzen dieser überwiegend technischen Tabellen und ihren Datenquellen werden in den folgenden Abschnitten erläutert.
Metrics Vault
Der Metrics Vault wird verwendet, um definierte Metriken zu erfassen, die aus ETL/ELT-Datenflüssen stammen. Er ist keine obligatorische Komponente von Data Vault. Wird er jedoch implementiert, profitiert Ihre Lösung von verschiedenen Vorteilen und technischen Funktionen, wie zum Beispiel:
- Fehlerprüfung (Error Inspection)
- Ursachenanalyse (Root Cause Analysis)
- Performance-Metriken
Im Hinblick auf Datenflüsse liegt der Fokus auf der Identifizierung von Fehlern sowie auf Ursachenanalysen von Systemausfällen, um gezielte Maßnahmen zur künftigen Fehlervermeidung abzuleiten.
Die Metriken selbst können aus unterschiedlichen Quellen stammen – etwa der Datenplattform, der ETL/ELT-Pipeline oder dem von Ihnen verwendeten EDW-Job-Orchestrierungs-Tool. Aus diesem Grund empfehlen wir, diese Datenquellen nach denselben Mustern und Standards zu modellieren, die Sie auch für die Erstellung des Raw Data Vault nutzen. Dies gewährleistet eine skalierbare Lösung zur Erfassung und Verarbeitung Ihrer Metriken.
Metrics Mart
Im Metrics Vault werden die Daten im Hinblick auf Speicherung, Skalierbarkeit und Flexibilität modelliert und optimiert. Um die gesammelten Daten auswerten zu können, muss das Modell den Anforderungen der Endbenutzer entsprechen. Aus diesem Grund ist der Metrics Mart Teil des Information Delivery Layer. Da der Metrics Vault ausschließlich dafür aufgebaut ist, Daten für den Metrics Mart bereitzustellen, werden mit diesem Ansatz die Standards der Data Vault 2.0-Architektur konsequent eingehalten. Der Metrics Mart ist ein zweckgebundener Information Mart, der primär aus dem Metrics Vault gespeist wird. Für die Umsetzung kommen sowohl die Materialisierung als physische Tabellen als auch die Virtualisierung über Views in Betracht. Der Virtualisierungsansatz ist hierbei häufig vorzuziehen, da die Bereitstellungsgeschwindigkeit (Deployment Speed) von dieser Entscheidung profitiert.
Wie oben erwähnt, bildet der Metrics Vault die Hauptdatenquelle für den Metrics Mart, wenngleich er nicht darauf beschränkt ist. In bestimmten Fällen kann sich der Fachbereich dazu entscheiden, Business Objects mit Metriken zu verknüpfen, um die Performance konkreter Geschäftsobjekte nachzuverfolgen. Dies trägt ebenfalls dazu bei, die Performance weiter zu optimieren.
Das Datenmodell des Metrics Mart ist nicht starr vorgegeben und variiert je nach Anforderung der Endbenutzer. Daher kann ein dimensionales Modell die passende Lösung sein, ist jedoch nicht zwingend erforderlich. Stammen Daten direkt aus Quellwerkzeugen, kann mitunter deren Ursprungsstruktur beibehalten werden, um eine effizientere Datenanalyse zu ermöglichen.
Meta Mart
Metadaten werden direkt im Meta Mart gespeichert. Diese Marts speisen sich nicht aus dem Raw Data Vault; daher existiert kein Meta Vault als Quelle für eine Virtualisierung. Folglich wird der Meta Mart in Form von Tabellen materialisiert. Der Aufbau ähnelt dem anderer Information Marts: Die fachlichen Anforderungen bestimmen das exakte Modell des Meta Marts, da dessen Kernfunktion darin besteht, Daten für den maximalen geschäftlichen Nutzen bereitzustellen. Je nach Anwendungsfall wird dies als dimensionales Modell oder in der dritten Normalform umgesetzt.
Error Mart
Der Error Mart ist ein weiterer Information Mart. Auch hier hängt die genaue Implementierung des Modells vom jeweiligen Fachbereich ab, wenngleich in der Praxis meist ein dimensionales Modell gewählt wird. Das Ziel des Error Marts ist es, fehlerhafte Datensätze, sogenannte „Ugly Data“ abzufangen. Dabei handelt es sich um Daten, die von Ihren Transformationswerkzeugen abgewiesen wurden, beispielsweise aufgrund definierter Soft Rules. Da sich Soft Rules im Zeitverlauf verändern können, passen sich auch Ihre Error Marts entsprechend an. Diese Fehlerdaten stammen nicht aus dem Raw Data Vault, weshalb es keinen Error Vault gibt. Die Daten für die Error Marts speisen sich aus verschiedenen Quellen, überwiegend jedoch direkt aus der ETL/ELT-Engine.
Verwaltung von Metadaten
Nachdem im vorherigen Abschnitt beschrieben wurde, wie ausgewählte Information Marts modelliert werden und welchem Zweck sie dienen, widmet sich dieser Abschnitt den Details der Datenbeladung. Dazu betrachten wir die zugrunde liegenden Daten, deren Ursprung sowie die jeweiligen Anwendungsfälle genauer.
Business Metadata
Business Metadata sind definiert als Metadaten mit direkter Relevanz für den Fachbereich. Obwohl die fachliche Verantwortung je nach Unternehmensstruktur variieren kann, liegt die technische Datenverwaltung beim Data-Warehouse-Team. Der Meta Mart deckt diesen Bereich der Metadaten ab.
Zu den Metadaten, die Sie erfassen sollten, gehören unter anderem:
- Fachliche Spaltennamen
Entscheidet sich der Fachbereich für Abkürzungen in Präfixen oder Suffixen, müssen diese dokumentiert werden, um eine einheitliche und verständliche Begrifflichkeit im Business zu gewährleisten. - Fachliche Definitionen
Sie bilden das Fundament für alle nachfolgenden Datenanalysen. Eine lückenlose fachliche Beschreibung der Attribute und Tabellen belegt zudem deren Notwendigkeit. Kann der Fachbereich keine Definition für eine Spalte oder Tabelle liefern, sollte geprüft werden, ob das Element im Information Mart benötigt wird oder fachlich neu definiert werden muss. - Ontologien und Taxonomien
Sie liefern Kontext zum Business Object hinter den Quelldaten – etwa Klassifizierungen, Hierarchien sowie Beziehungen zu anderen Objekten. - Physische Tabellen- und Spaltennamen
Sie stellen die Verknüpfung zwischen den fachlichen Namen der Business Objects und den Bezeichnungen der physischen Tabellen und Spalten her. - Record Source
Sie beschreibt die Datenquellen in fachlicher Sprache. Das Ziel besteht nicht im rein technischen Verweis auf Datenbanken, sondern in der Vermittlung der geschäftlichen Bedeutung der jeweiligen Quellen. - Tabellenspezifikation
Sie dokumentiert den Zweck der Quelltabelle und der Daten sowie die relevanten Spaltennamen und Schlüssel. - Exception-Handling Rules
Sie erfassen potenzielle Fehler sowie Datenqualitätsprobleme und legen fest, wie der ETL/ELT-Prozess bei Ausnahmen verfährt. - Fachliche Definitionen der Quellsysteme
Sie erläutern die fachliche Bedeutung der Attribute aus den Quellsystemen. - Business Rules
Sie erzeugen neue Daten auf Basis von Geschäftslogiken. Entwickler benötigen ein klares Verständnis dieser Regeln und Transformationen, um fachliche Anforderungen exakt umzusetzen. Als Business Metadata werden Geschäftsregeln fachlich verständlich formuliert, wobei stets sauber zwischen Hard Rules und Soft Rules unterschieden werden sollte.
Technical Metadata
Während Business Metadata in erster Linie dem Fachbereich dienen, profitiert vor allem das Data-Warehouse-Team von den Technical Metadata, die ebenfalls im Meta Mart hinterlegt werden. Diese Metadaten stammen überwiegend direkt aus den beteiligten Systemkomponenten, wie die folgenden Beispiele zeigen:
- Quellsysteme
Sie liefern eine technische Spezifikation der Quellsysteme, beispielsweise Datenbanknamen, Schnittstellen oder Speicherpfade von Flat Files. - Datenmodelle
Sie stellen eine essenzielle technische Referenz dar, veranschaulichen die Beziehungen zwischen den genutzten Tabellen und können grafisch aufbereitet werden. - Datendefinitionen
Sie beschreiben die Daten auf technischer Ebene und umfassen Details zu Tabellen- und Spaltennamen, Datentypen, Constraints sowie Standardwerten. - Business Rules
Geschäftsregeln sind ebenso Teil der Technical Metadata. Hier liegt der Fokus auf der technischen Ausgestaltung der Logiken, die in den ETL/ELT-Tools implementiert werden. Hard Rules und Soft Rules müssen hierbei analog zu den Business Metadata klar getrennt werden. - Volumetrie
Sie dokumentiert Ladeprozesse, Tabellengrößen und Datenwachstum, um die Auslastung und Skalierung des Data Warehouse präzise zu steuern. - Ontologien und Taxonomien
Technische Metadaten konkretisieren Begriffskürzel, Attributstrukturen, Business-Key-Konventionen, Hierarchien sowie Neudefinitionen (Re-defines). - Datenqualität
Diese Metadaten erfassen Qualitätsmetriken und Regeln zur technischen Standardisierung der Quelldaten.
Process Execution Metadata
Process Execution Metadata werden im Gegensatz zu Business und Technical Metadata nicht vom Fachbereich oder von Quellanwendungen geliefert, sondern automatisiert vom Data-Warehouse-Team bzw. der Infrastruktur generiert, um Transparenz über die ETL/ELT-Pipelines zu schaffen. Das Hauptziel besteht darin, die Performance des Data Warehouse messbar zu machen und gezielt zu optimieren. Die Daten stammen primär aus dem eingesetzten ETL/ELT-Tool und umfassen folgende Bereiche:
- Control-Flow-Metadaten
Da ein Control Flow mindestens einen Data Flow ausführt, liefert er Statusdaten über Abläufe und die Data Lineage sämtlicher EDW-Komponenten. - Data-Flow-Metadaten
Sie dokumentieren die Datenflüsse selbst, einschließlich übertragener Datenvolumina sowie abgewiesener Zeilen innerhalb von Lade- und Transformationsschritten. - Package-Metadaten
Sie fassen die Ausführungsinformationen eines Packages zusammen, welches in der Regel einen übergeordneten Control Flow abbildet. - Prozess-Metadaten
Da die meisten Packages automatisiert über Scheduling-Lösungen laufen, protokollieren diese Metadaten Details zum auslösenden Gesamtprozess.
Process Execution Metadata sollten im Metrics Vault abgelegt und getrennt von den Business und Technical Metadata verwaltet werden.
Fazit
In diesem Newsletter haben wir Ihnen die zentralen Monitoring-Optionen für Ihr Data Vault-basiertes EDW vorgestellt. Wir haben erläutert, wie spezialisierte Information Marts modelliert werden, aus welchen Quellen sie gespeist werden und wie Fachbereich und Data-Warehouse-Team davon profitieren. Zudem haben wir die verschiedenen Metadatenarten und ihre Einsatzbereiche strukturiert: von Business Metadata für den Fachbereich über Technical Metadata für die technische Administration bis hin zu Process Execution Metadata für die Überwachung Ihrer ETL/ELT-Pipelines. Damit verfügen Sie über eine verlässliche Grundlage, um Ihr EDW nach den Best Practices von Data Vault 2.0 professionell zu überwachen.
In unserem Webinar gehen wir noch weiter ins Detail. Nutzen Sie die Gelegenheit und sehen Sie sich die Aufzeichnung kostenlos an! Wir freuen uns darauf, Sie dort begrüßen zu dürfen.
