Data Vault Reine Lehre vs. Real-World Requirements Dr.-Ing. Holger Friedrich
Agenda Introduction Data Vault Diskussionsstoff Schlussfolgerungen 2
500+ Technsche Experten Helfen Kollegen Weltweit 3 Membership Tiers Oracle ACE Director Oracle ACE Oracle ACE Associate bit.ly/oracleaceprogram Connect: oracle-ace_ww@oracle.com Facebook.com/oracleaces @oracleace Nominiert euch selbst oder Kollegen: acenomination.oracle.com
sumit AG Beratung, Projekte, Implementierung Experten für Data Warehousing, Business Intelligence/Analytics, und Big Data Fokussiert auf Oracle-Technologie BI Foundation specialised -Partner Data Warehousing specialised -Partner Unser Motto: Get Value From Data Besuchen sie: www.sumit.ch 4
Holger Friedrich Diplom Informatiker des Karlsruhe Institute of Technology (KIT) Promotion in Robotik und Machine Learning Mehr als 18 Jahre Expertise mit Oracle-Technologie Experte für Data Integration Data Warehousing, Analytics Technischer Direktor von sumit AG Oracle ACE for Data Warehousing/Business Intelligence 5
Agenda Introduction Data Vault Diskussionsstoff Schlussfolgerungen 6
Inmon - Enterprise Data Warehouse Selfless Model modelliert die Welt wie sie ist üblicherweise 3-NF Vorteile flexibel mächtig Nachteile schwer verständlich komplexe Abfragen viele Joins nur begrenzt automatisierbar Abhängigkeiten im Ladeprozess Schwerfällig, lange Entwicklungszeiten, Performanceprobleme 7
Kimball - Dimensionale Modellierung Selfish Model modelliere Aspekte zweckgerichtet üblicherweise Star - oder Snowflake Vorteile einfach zu verstehen performant Nachteile begrenzt aussagefähig change schwierig zu managen komplex zu erstellen nur begrenzt automatisierbar Nur für Analyseschicht verwendbar, keine Alternative für Foundation 8
Linstedt - Data Vault Selfless Model modelliert die Welt wie sie ist verteilt Semantik auf spezifische Komponenten Vorteile flexibel & mächtig automatisierbar/agil (theoretisch) insert-only Nachteile pur recht schwer verständlich viele Joins Ideal für schnelle Quellsystemanbindung & DWH Foundation 9
Data Vault - Hubs Header-Tabelle für jede relevante Entity Enthält Business Key(s) DWH Surrogate Key Enthält nicht Historie (fachliche) Nutzattribute zeitliche Gültigkeitsinformation etc. Fragen Surrogate-Key-Repräsentation? relevante Entity? Behandlung von DQ-Problemen? DV2.0 - Hash-Wert 10
Data Vault - Links Header-Tabelle für jeden Foreign-Key Enthält DWH Surrogate Key Hub Primary- & Src-Sys-Keys Enthält nicht Historie (fachliche) Nutzattribute zeitliche Gültigkeitsinformation etc. Fragen Surrogate-Key-Repräsentation? Behandlung von DQ-Problemen? Gültigkeit von (1:n)-Beziehungen? DV2.0 - Quellsystem Business-Key- Values DV2.0 - Hash-Keys 11
Data Vault - Satelliten Tabelle für Nutzinformation von Objekte & Links Enthält Business Key(s) & DWH Surrogate Key CDC-Hash-Value Nutzattribute Ladedatum Historie Enthält nicht Fremdschlüssel Valid-To-Information Fragen Surrogate-Key- & CDC-Wert- Repräsentation? Zeitliche Auswertungen? DV2.0 - Hash-Wert für Change Data DV2.0 - Hash-Key 12
Data Vault - Herausforderungen Verständnis Tabellenzahl Temporale Queries Abfragekomplexität Performance Infrastruktur Integraton mehrerer Quellsysteme Neue Objekttypen im sogenannten Business Vault 13
Business Vault Point-In-Time Satelliten Bridge Tabellen Vordefinierte Aggregationen oder KPIs Same-As & Hierarchical Links 14
Agenda Introduction Data Vault Diskussionsstoff Schlussfolgerungen 15
Diskussionsstoff Hash-Keys Referentielle Integrität Abfragefreundlichkeit Löschungen Zeitreihen Change Management Performance & Lizenzen 16
Hash-Keys - Beworbene Vorteile Unabhängig voneinander in mehreren Systemen generierbar Vollständige Parallelisierung des Loads Effizientes Change Data Capturing Einfache Automatisierung 17
Hash-Keys - Aber die Idee ist nicht neu und hatte sich Jahrzehnte nicht durchgesetzt Was ist jetzt anders? Big Data! 18
Hash-Keys - Handling Change in Schlüsseln Quellsysteme werden heute agil entwickelt Folge: viele Änderungen, auch an Schlüsseln Datentypwechsel Erweiterung Klassische Sequenzschlüssel Anpassung der CDC-Logik Anpassung der Lookup-Logik Hash-Keys Rehashing aller Hubs, Links und Satelliten in allen Systemen 19
Hash-Keys - Change in Nutzattributen Neue Attribute (auch nullable) in bestehenden Satelliten Folgen Erweiterung von Satelliten Datenänderungen beim seeden/releasen oder beim ersten Load Neue Links falls notwendig Klassische Sequenzschlüssel Anpassung der CDC-Logik Hash-Keys Rehashing aller CDC-Hashes im betroffenen Satelliten oder Massenupdate beim ersten Load post Release Alternativ ein neuer Satellit 20
Herausforderung Software Engineering: gleiche Hash-Berechnung Cross-Plattform Hash-Keys - Hash-Berechnung Kollisionswahrscheinlichkeit: sehr gering, aber grösser Null Grenzen von Technologie/Implementierung: berechnen auf vielen Attributen und grossen Objekten (LOBs) - ORA_HASH: deprecated, hohe Kollisionswahrscheinlichkeit - DBMS_OBFUSCATION_TOOLKIT: deprecated, PL/SQL - DBMS_CRYPTO.HASH: PL/SQL - STANDARD_HASH: SQL-Function, aber keine LOBs 21
Sinnvolle Partitionierung auf Hash-Werten schwierig In-Memory Performance schlechter mit Hash-Keys keine Vector-By-Transformation auf VC2(32) Hash-Keys (siehe Blog-Post Dani Schnider https:// danischnider.wordpress.com/ 2017/10/25/oracle-database-inmemory-and-hash-keys/) Hash-Keys - Technische Gotchas in Oracle 22
Referentielle Integrität Technische Standardheader: Key(s), Load TS, Record Source Viele Quellsysteme/-daten verletzen referentielle Integrität Wie kann bzw. soll dieser Tatsache in Data Vault Rechnung getragen werden? Data Vault enthält keinen Standard zur Behandlung von Datenqualitätsproblemen bezüglich referentieller Integrität Alternativen Sicherstellung nach dem Raw Vault Load http://roelantvos.com/blog/?p=1072 Handling während des Loads 23
Löschungen Technische Standardheader: Key(s), Load TS, Record Source Löschen und wieder anlegen in Quellen sind üblich Wie kann bzw. soll dieser Tatsache in Data Vault Rechnung getragen werden? Data Vault enthält keinen Standard zur Behandlung von Löschungen und Wiederanlage von Quelldaten Alternativen einfügen von Deleted'-Records zeitliches abschliessen von Datensätzen (Abkehr vom Insert-Only-Prinzip) 24
Zeitreihen Technische Standardheader: Key(s), Load TS, Record Source Keine Zeitintervalle im Raw Vault Keine Zeitintervalle im Business Vault Abfragen müssen immer zeitliche Gültigkeit berechnen Jeder Select erfordert je Tabelle analytische Funktionen Alternativen View Layer zeitliches abschliessen von Datensätzen beim Load (Abkehr vom Insert-Only-Prinzip) 25
Auch hier immer analytische Funktionen notwendig Dani Schnider Immer vollständiger Neuaufbau Performance-Albtraum Roelant Vos Alternative Wherescape Abgeschlossene Zeitreihen Watermark-Dokumentation Temporale Filterung CDC für Bridge Tabellen PITs & BTs - Performance 26
Korrekte Link-Repräsentation Fachliches Problem: Switch von 1:n-Beziehungen Beispiel: Mitarbeiter wechselt Abteilung Folge Bisheriger Link-Eintrag gelöscht Neuer Link-Eintrag erstellt Herausforderung Zwei Ziele mit einem Datensatz manipulieren zeitlichen Anschluss' sicherstellen Lösungsmöglichkeit komplexere ETL-Logik vollständige Zeitintervalle (Abkehr vom Insert-Only-Prinzip) 27
Satelliten-Proliferation Agile Quellsystementwicklung fordert DWH-Entwicklung Quellobjekte werden gesplittet, Attribute hinzugefügt etc. Wie ist beim DWH-Design zu reagieren? Alternativen Traditionell Bestehende(n) Satelliten & Ladelogik anpassen Eventuell Seeding-Skripte & Historienupdate Auswertungen anpassen Modern Neue Satelliten & Ladelogik erzeugen PIT-Satelliten & Ladelogik anpassen Auswertungen anpassen 28
Ladeperformance Data Vault (2.0) erreicht bislang unerreichte Parallelisierung Folgen kurze Ladezeiten des Raw Vaults hohe Leistungsanforderung Viele PIT-Satelliten und Bridge-Tabellen sind zu rechnen Folgen zusätzliche Ladezeiten für Business Vault hohe Leistungsanforderung Temporale Abfragen erfordern analytische Funktionen Folgen hohe Fähigkeitsanforderung an Analysten hohe Leistungsanforderung Lizenzbedarf nimmt nicht ab 29
Agenda Introduction Data Vault Diskussionsstoff Schlussfolgerungen 30
Schlussfolgerungen I Data-Vault-Standard ist fokussiert auf Ladeperformance (Insert-Only-Prinzip) Verteilte Datenhaltung Weniger beachtet wird Abfragefreundlichkeit/-performance Datenqualitätssicherung Situation beim Kunden Wenig verteilte Datenhaltung Hohe Abfragefreundlichkeit gebraucht Hohe Datenqualität verlangt Begrenzte Rechenpower vorhanden Grosser Datenanteil mit Löschungen, geringer Anteil Insert-Only 31
Schlussfolgerungen II Data Vault ist ein hervorragendes Modellierungsparadigma für Foundation Layer Business Vault erlaubt hochautomatisierte Aufbereitung von Business-Objekten Aber Data Vault is keine Silver Bullet Ohne Automatisierung bedeutet Data Vault Mehrarbeit für Integratoren und Analysten Spezialwissen über Modellierung und Technologie bleibt weiterhin absolut entscheidend Manche Innovation in DV2.0 ist jenseits von Big Data Anwendungen zweifelhaft Fazit: DV umsetzen, aber nicht sklavisch den Standard einhalten 32