Jörg Stahnke 11. Oracle Business Analytics und Data Warehouse Konferenz 2016, März 2016

Transkript

1 Data Vault Neue DWH-Anforderungen schnell und kostengünstig umsetzen - Jörg Stahnke

2 Agenda DWH-Landschaften Ausgangssituation & Ziele Vorstellung Data Vault Data Vault 1.0 Kurzer Überblick Data Vault 2.0 Erweiterungen Data Vault 2.0 Vergleich mit herkömmlicher Architektur Data Vault 2.0 Vorteile Universal Datamodeling Generator (UDG) Zusammenfassung 1

3 DWH-Landschaften Ausgangssituation & Ziele Ausgangssituation / Herausforderung DWH als schwerfälliger Dinosaurier mit hoher Komplexität vielfältige Abhängigkeiten: Alles hängt von Allem ab häufig Reengineering erforderlich kontinuierlich steigende Kosten Lange Umsetzungsdauer von Anforderungen Aufwändiger Retest des gesamten Systems bei Änderungen Ziele Kostenreduktion durch extrem effiziente Entwicklung geringe Fehleranfälligkeit Verkürzung der Time-to-Market durch flexibles Datenmodell hoher Automatisierungsgrad Lösung Verwendung von Data Vault 2.0 Implementierung mit Universal Datamodel Generator (UDG) von PPI 2

4 Agenda DWH-Landschaften Ausgangssituation & Ziele Vorstellung Data Vault Data Vault 1.0 Kurzer Überblick Data Vault 2.0 Erweiterungen Data Vault 2.0 Vergleich mit herkömmlicher Architektur Data Vault 2.0 Vorteile Universal Datamodeling Generator (UDG) Zusammenfassung 3

5 Data Vault 1.0 Kurzer Überblick Hubs Geschäftsobjekte Links Beziehungen von Geschäftsobjekten Satellites Eigenschaften von Geschäftsobjekten Ziele: Entkopplung einzelner Komponenten/Fragestellungen für fachliche Analyse Entwicklung/Test Beladung agiles Vorgehen kurze Time- to-market (schnelle Produktivsetzung von Änderungen) 4

6 Data Vault 2.0 Erweiterung durch Architektur und Vorgehensmodell (1/2) Technischer Business Analyst als neue zentrale Rolle verfügt über fundierte fachliche Kenntnisse hat technisches Grundverständnis ist wichtigster Ansprechpartner für Entwickler steuert DWH-Beladung fachlich Architektur Managed Self-Service BI Verantwortung für Daten und Geschäftsregeln (technischer Business Analyst) Write Back: Zurückschreiben neuer Informationen in das DWH (technischer Business Analyst) Fehleranalyse: ständige Rückmeldung Fehler an Quellsysteme vollständige Data-Lineage und Impact-Analyse Automatisierung aller Prozesse 5

7 Data Vault 2.0 Erweiterung durch Architektur und Vorgehensmodell (2/2) Datenmodellierung vollständige Entkopplung der Ladeprozesse durch Nutzung von Hashkeys als Primärschlüssel vereinfachte Deltaerkennung durch Hashkeys zur Differenzanalyse logische Zugriffsschicht simuliert relationales Modell (PPI-Ansatz) Vorgehensmodell agiles Vorgehen Weiterentwicklung von SCRUM 6

8 Staging logische Views Information Mart Data Vault 2.0 Konkrete Architektur Quellen Data Vault Integrationslogik Hard Rules Raw Vault Error Vault 1:1- Übernahme Star Schema Transformation Geschäftsregeln Soft Rules Business Vault Anlieferung Technisches Modell Fachliche Sicht 7

9 Data Vault 2.0 Vergleich mit herkömmlicher Architektur Datenmodell Herkömmliche Architektur Änderung einer Relation wirkt sich in Businessschicht kaskadierend aus Änderung der Granularität einer Beziehung erfordert Reengineering Data Vault Beziehungen zwischen Relationen gehen immer maximal über 2 Stufen Änderung der Granularität einer Beziehung ist ohne Modelländerung möglich Hubs und Links können sich nicht ändern 8

10 Data Vault 2.0 Vergleich mit herkömmlicher Architektur ETL/ELT-Prozess Herkömmliche Architektur fachliche Logik auf mehreren Ebenen Logikänderung beeinflusst großen Teil des DWH Datenquellen ETL mit Logik Datenversorgung ETL mit Logik Integrationsschicht ETL mit Logik (evtl. Datenkopie) Business Schicht ETL mit Logik Data Mart Data Vault fachliche Logik nur in Business Rules Änderung fachliche Logik wirkt sich nur auf Business Vault / Information Mart aus Quellen 1:1 Übernahme Staging EL ohne Logik Raw Vault ETL mit Logik (ergänzend) Business Vault EL ohne Logik Information Mart 9

11 Data Vault 2.0 Vergleich mit herkömmlicher Architektur Standardisierung/Automatisierung Herkömmliche Architektur Datenmodell ist nur teilweise standardisiert fast alle Beladungen enthalten fachliche Logik und sind individuell programmiert sinnvoller Einsatz von Generatoren ist nur selten möglich umfangreiche Generierung führt zu weniger Fehlern geringerem Aufwand vollständig einheitlichem Vorgehen Data Vault es gibt klare Regeln zum Aufbau des Datenmodells alle Hubs und Links sind technisch gleich strukturiert Satelliten haben identische technische Felder alle Beladungsprozesse ohne fachliche Logik werden automatisiert generiert Beladung Staging Beladung Raw Vault Beladung Information Mart nur Geschäftsregeln zur Beladung des Business Vaults werden individuell programmiert 10

12 Data Vault 2.0 Vergleich mit herkömmlicher Architektur Parallelisierung der Ladeprozesse Herkömmliche Architektur enthält technische Abhängigkeiten Parallelisierung muss technische und fachliche Abhängigkeiten berücksichtigen Data Vault Data Vault 2.0 enthält keinerlei technische Abhängigkeiten (durch Nutzung von Hash Keys) Parallelisierung muss nur fachliche Abhängigkeiten berücksichtigen geringer Parallelisierungsgrad sehr hoher Parallelisierungsgrad 11

13 Data Vault 2.0 Vorteile Entkopplung der Abhängigkeiten massiv parallelisierbare Ladeprozesse kein Retest des gesamten Systems erforderlich Reengineering extrem selten hoher Automatisierungsgrad durch standardisierte Beladungsprozesse Reduzierung von Speicherplatz sehr hohe Flexibilität klare Trennung von Geschäftsobjekten, Beziehungen und Eigenschaften inkrementelle Erweiterbarkeit konsequente Transparenz und zeitliche Nachvollziehbarkeit Time-to-Market sehr kurz / Reduzierung der Entwicklungskosten Durch den erweiterten PPI-Ansatz entstehen weitere Vorteile: durch generierte zusätzliche Views wird für fachliche Anwender ein leicht verständliches relationales Modell automatisiert bereitgestellt automatisiert verwaltete Point-in-Time (PIT) Tabellen garantieren zu jedem Zeitpunkt gute Abfrageperformance trotz einer Vielzahl von Joins 12

14 Data Vault 2.0 Vorteile: Kostenkurven im Vergleich Traditionell Data Vault

15 Agenda DWH-Landschaften Ausgangssituation & Ziele Vorstellung Data Vault Data Vault 1.0 Kurzer Überblick Data Vault 2.0 Erweiterungen Data Vault 2.0 Vergleich mit herkömmlicher Architektur Data Vault 2.0 Vorteile Universal Datamodeling Generator (UDG) Zusammenfassung 14

16 UDG Universal Datamodeling Generator Vorstellung Eclipse Plugin zur Datenbankmodellierung intuitive Bedienbarkeit Prüfung der Validierungsregeln, keine (technische) Fehleingabe möglich! Domain Specific Language (DSL) mit Xtext (Open Source) als Basis Erzeugung von SQL-Skripten, fachlicher Datenmodelldokumentation u.a. offene API zum Generieren von beliebigen projektspezifischen Codes in beliebiger Programmiersprache fachlichen Dokumentationen als Word-, HTML- oder Excel-Dateien grafischen Übersichten seit 4 Jahren PPI-Standardwerkzeug bei eigener Produktentwicklung 15

17 UDG Universal Datamodeling Generator PPI-Ansatz zur Implementierung Data-Vault-Regel Reduzierung der Komplexität gilt auch für die Tools herkömmliches Tool deckt Anforderungen verschiedener Kunden ab enthält hohe Komplexität erfordert viel Know-how bietet Möglichkeiten für Fehler Wer nutzt mehr als 5% der Funktionen von Word? PPI-Ansatz statt eines Tools wird eine anpassbare API geliefert ist vorkonfiguriert nutzt eigene Domain Specific Language (DSL) kann nicht alles, aber genau das, was das Projekt braucht 16

18 Umsetzung mit UDG Basiskomponente 1. Basiskomponente Basis Data Vault Implementierung in UDG mit folgenden Annahmen: tägliche Belieferung im Batch mit Voll-/Deltabeständen Geschäftslogik zentralisiert bei Befüllung Business Vault logisches relationales Datenmodell Steuerung der Anwendung Historisierung / Versionierung von Daten Dokumentation Datenmodell, Data Lineage, Prozessabhängigkeiten (grafisch, Excel und in Word) implementiert zwingend erforderliche Funktionalitäten diesen Code bringt PPI in ein Projekt ein Fundament ist gelegt 17

19 Umsetzung mit UDG spezifische Verwendung im Projekt 1. Basiskomponente 2. Anpassung Projektspezifika Kunde und PPI führen initial einen technischen Architekturworkshop durch, der die gewünschte projektspezifische Architektur festlegt: UDG wird entsprechend diesen Vorgaben angepasst Namenskonventionen weitere projektspezifische Anforderungen Umfang und Layout der Dokumentation u.a. Haus ist errichtet 18

20 Umsetzung mit UDG Ergebnisse 1/2 1. Basiskomponente 2. Anpassung Projektspezifika 3.Generatorverwendung im Projekt UDG erfüllt im laufenden Projektbetrieb folgende Aufgaben: Modellierung Datenmodell Data Vault Source-Schnittstellen/Staging und Information Mart Validierung Datenmodell allgemeine Data-Vault-Regeln eingehalten? projektspezifische Architekturfestlegungen eingehalten? Erstellung DDL zur Erzeugung der Tabellen fachliche Dokumentation Datenmodell, Schnittstellen, Information Mart inklusive Grafik vollständige Code-Erstellung für Befüllung Staging, Befüllung Raw Vault / Error Vault / Information Mart Read/Write API für Geschäftsregeln Haus wird genutzt 19

21 Umsetzung mit UDG Ergebnisse 2/2 1. Basiskomponente 2. Anpassung Projektspezifika 3.Generatorverwendung im Projekt vollständige Code-Erstellung für Zugriffsmechanismen auf Data Vault-Modell Point in Time (PIT) Tabellen logisches relationales Datenmodell zum vereinfachten Zugriff auf Daten fachliche Dokumentation Datenfluss vollständige fachliche Impact-Analyse Abhängigkeitsanalyse zur Steuerung der Beladung mit maximaler Parallelität Skripte zum Vergleichstest Datenmodellmigration Bereitstellung fehlerhafter Daten für Endanwender zur Korrektur im Quellsystem Haus wird genutzt 20

22 Staging logische Views Information Mart Technische Umsetzung Generatorabdeckung Quellen Data Vault Integrationslogik Hard Rules Raw Vault Error Vault 1:1- Übernahme Read API Star Schema Transformation Geschäftsregeln Soft Rules Write API Business Vault individueller Programmcode generiert durch UDG 21

23 Agenda DWH-Landschaften Ausgangssituation & Ziele Vorstellung Data Vault Data Vault 1.0 Kurzer Überblick Data Vault 2.0 Erweiterungen Data Vault 2.0 Vergleich mit herkömmlicher Architektur Data Vault 2.0 Vorteile Universal Datamodeling Generator (UDG) Zusammenfassung 22

24 Zusammenfassung Vorteile eines toolbasierten Data Vault-Ansatzes 1/2 sehr schnelle Umsetzungszyklen automatische Impact-Analyse hoher Anteil Generierung - technisch formaler Code vollständig - Anbindung von Liefersystemen - Aufbereitung als Star Schema individuelle Programmierung nur für fachliche Fragestellungen Entkopplung der Abhängigkeiten durch Data Vault schnelle Beladungen durch maximale Parallelität keine technischen Synchronisationspunkte für Data Vault 2.0 automatische fachliche Abhängigkeitsanalyse 23

25 Zusammenfassung Vorteile eines toolbasierten Data Vault-Ansatzes 2/2 UDG hat geringe Komplexität kein ETL-Tool mit umfangreichem (nicht genutztem) Funktionsumfang kann genau das, was im Projekt benötigt wird garantiert einheitliches Vorgehen schnelle Einarbeitung neuer Projektmitglieder projektspezifische Anpassung von UDG jederzeit möglich geringe Fehlerrate durch Validierung im UDG keine Verletzung von Architekturvorgaben möglich hoher Generatoranteil weniger Testaufwand vollständiger Vergleichstest mit generierten Skripten möglich Verarbeitung und automatisierter Vergleich des gleichen Datenbestands mit Software-Stand vor und nach der Änderung durch automatisierte vollständige Impact-Analyse nur kleine Teile des DWH zu testen 24

26 Kontakt Kommen Sie an den Stand der PPI AG und erleben Sie die Live-Demonstration des Universal Datamodeling Generators (UDG)! Jörg Stahnke Dipl. Mathematiker Principal Database Engineer Certified Data Vault 2.0 Practitioner PPI Aktiengesellschaft Moorfuhrtweg Hamburg Telefon: Mobil:

27 BACKUP 26

28 Livedemonstration - im Showroom und am Stand Validierung Fehleingaben werden erkannt Code Completion Unterstützung bei der Eingabe Generierung Aufruf per Kontextmenü Ergebnisse Skripte für - Anpassung Datenmodell - Beladung Datenmodell - Ergänzung logisches Modell Steuerung angepasst Dokumentationen aktualisiert - Grafiken / Word / Excel 27

29 Anwendungsszenario Automatisierte Steuerung der Beladung externe Steuerung legt fest, was täglich, monatlich starten soll Start Jobgruppe Scheduler neue Jobs startbar? (Abhängigkeiten erfüllt) Prozesse mit Status soll kann läuft Ergänzung Abhängigkeiten automatische Ergänzung abhängiger Prozesse (Konsistenz) Executoren generierte Abhängigkeiten Signal fertig parallele Ausführung mit dbms_schedule 28

30 Anwendungsszenario Migration Grundidee: in der Data Vault Architektur sind logische relationale Views/Datamarts bereits vorgesehen dies wird in der Migrationsphase genutzt, um auf Data Vault Tabellen das alte Datenmodell mit Hilfe von Views zu simulieren noch nicht umgestellte Teile des DWH greifen auf die logische relationale Sicht von Data Vault zu schrittweise Umstellung daher möglich 29

31 Migration - einzelne Tabelle bisheriges Alt DWH Source Befüllungsregeln neue Umsetzung in Data Vault + Tabelle Beispiel Lesen für Folgeverarbeitungen Hard Rules Business Rules Lesen für Folgeverarbeitungen Source Raw Vault Business Vault View Beispiel 30

32 Migration - Gesamt Ausgangszustand - alle Tabellen im Alt DWH bisheriges Alt DWH Tab 1 Tab 2 Tab 3 Tabelle Tabelle Tabelle noch keine Umsetzung in Data Vault 31

33 Migration - Gesamt erste Tabelle durch View mit Namen Tab1 ersetzt - Data Vault eingeführt bisheriges Alt DWH mit einem View Tab 1 Tab 2 Tab 3 View Tabelle Tabelle Data Vault erstellt 32

34 Migration - Gesamt weitere Tabelle durch View ersetzt - Data Vault erweitert bisheriges Alt DWH mit zweiten View Tab 1 Tab 2 Tab 3 View View Tabelle Data Vault erweitert 33

35 Migration - Gesamt Endzustand - Data Vault vollständig - Alt DWH abgeschaltet bisheriges Alt DWH abgelöst Data Vault vollständig 34

36 Data Vault 2.0 Beispiel für Flexibilität: Referentielle Integrität Szenario bei einzelnen Konten fehlt die Zuordnung zum Kunden Anforderung Reporting über Konten und Kunden muss konsistent sein (gleiche Gesamtsumme) Traditionelle Umsetzung mit Hilfe von Foreign Key Constraints fehlerhafte Sätze werden ausgesteuert (verworfen oder gesondert abgespeichert) Umsetzung mit Data Vault alle Daten im Raw Vault ( all the facts ) Flag setzen für fehlerhafte Daten im Business Vault ( Soft Rule ) gezieltes Bereitstellen für Endanwender (logische Views, Information Marts) Neue Anforderung Nick Leeson hätte keine Chance durch gezielte Fehleingaben Geschäfte dem Monitoring zu entziehen Data Vault hat alle Grunddaten verfügbar und muss nur die Bereitstellung ergänzen traditionelles System benötigt umfangreiche Änderungen und rückwirkende Daten fehlen 35