Data Vault 2 - Oracle Data Warehouse Community Seite · Data Vault 2.0 - Neue DWH-Anforderungen schnell und kostengünstig umsetzen - Jörg Stahnke 11. Oracle Business Analytics und

Data Vault 2.0- Neue DWH-Anforderungen schnell und kostengünstig umsetzen -

Jörg Stahnke

11. Oracle Business Analytics und Data Warehouse Konferenz 2016, März 2016

1

Agenda

11. Oracle Business Analytics und Data Warehouse Konferenz 2016, März 2016© PPI AG

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

Zusammenfassung

Universal Datamodeling Generator (UDG)

2



Ausgangs-

situation /

Heraus-

forderung

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

3

Agenda








Zusammenfassung




Ziele:

Entkopplung einzelner Komponenten/Fragestellungen für

fachliche Analyse

Entwicklung/Test

Beladung

agiles Vorgehen

kurze Time- to-Market (schnelle Produktivsetzung von Änderungen)

HubsGeschäftsobjekte

LinksBeziehungen von

Geschäftsobjekten

SatellitesEigenschaften von

Geschäftsobjekten

5

Data Vault 2.0 –

Erweiterung durch Architektur und Vorgehensmodell (1/2)


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

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

6

Data Vault 2.0 –

Erweiterung durch Architektur und Vorgehensmodell (2/2)


Vorgehensmodell

agiles Vorgehen

Weiterentwicklung von SCRUM

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)

7

Geschäftsregeln

Soft Rules


Data Vault 2.0 –

Konkrete Architektur

Quellen Data Vault

Sta

gin

gRaw Vault

+

++

+

+

++

Star Schema

Transformation

Info

rmation M

art

Business Vault

Error Vault

logis

che V

iew

s

Anlieferung Technisches Modell Fachliche Sicht

© PPI AG

1:1-

Übernahme

Integrationslogik

Hard Rules

8© PPI AG


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




ETL/ELT-Prozess


fachliche Logik auf mehreren Ebenen

Logikänderung beeinflusst großen

Teil des DWH

Data Vault

fachliche Logik nur in Business Rules

Änderung fachliche Logik wirkt sich nur

auf Business Vault / Information Mart aus

Staging

Quellen

Raw Vault

Information Mart

EL ohne Logik

1:1 Übernahme

EL ohne Logik

Business Vault

ETL mit Logik (ergänzend)

Datenversorgung

Datenquellen

Integrationsschicht

Data Mart

ETL mit Logik

ETL mit Logik

ETL mit Logik

Business Schicht

ETL mit Logik (evtl. Datenkopie)



Standardisierung/Automatisierung


Datenmodell ist nur teilweise

standardisiert

fast alle Beladungen enthalten

fachliche Logik und sind individuell

programmiert

sinnvoller Einsatz von Generatoren

ist nur selten möglich

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

umfangreiche Generierung führt zu

weniger Fehlern

geringerem Aufwand

vollständig einheitlichem Vorgehen



Parallelisierung der Ladeprozesse


enthält technische Abhängigkeiten

Parallelisierung muss technische

und fachliche Abhängigkeiten

berücksichtigen

geringer Parallelisierungsgrad

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

sehr hoher Parallelisierungsgrad


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

13© PPI AG

Data Vault 2.0 –

Vorteile: Kostenkurven im Vergleich

Traditionell

Data Vault 2.0


14

Agenda








Zusammenfassung



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


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

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

Wer nutzt mehr als

5% der Funktionen

von Word?

17

Umsetzung mit UDG – 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

1. Basiskomponente


Fundament ist gelegt


Umsetzung mit UDG – spezifische Verwendung im Projekt

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.

1. Basiskomponente2. Anpassung

Projektspezifika

Haus ist errichtet

19

Umsetzung mit UDG – Ergebnisse 1/2

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

3.Generator-

verwendung

im Projekt


Haus wird genutzt


Projektspezifika

vollständige Code-Erstellung für

Befüllung Staging, Befüllung Raw Vault / Error Vault / Information Mart

Read/Write API für Geschäftsregeln

20

Umsetzung mit UDG – Ergebnisse 2/2

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

3.Generator-

verwendung

im Projekt


Haus wird genutzt


Projektspezifika

21

Technische Umsetzung – Generatorabdeckung


Quellen Data Vault

Sta

gin

g

Integrationslogik

Hard Rules

Raw Vault

+

++

+

+

++

Star Schema

Transformation

Info

rmation M

art

Business Vault

Error Vault

Read API

logis

che V

iew

s1:1-

Übernahme

Geschäftsregeln

Soft Rules

Write API

generiert durch UDGindividueller Programmcode

22

Agenda








Zusammenfassung



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


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

25

Kontakt

© PPI AG

Jörg StahnkeDipl. Mathematiker | Principal Database Engineer

Certified Data Vault 2.0 Practitioner

PPI Aktiengesellschaft

Moorfuhrtweg 13

22301 Hamburg

Telefon: +49 40 227433-1329

Mobil: +49 1603841771

[email protected]


Kommen Sie an den Stand der PPI AG und

erleben Sie die Live-Demonstration

des Universal Datamodeling Generators (UDG)!

26

BACKUP



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


Anwendungsszenario

Automatisierte Steuerung der Beladung

AbhängigkeitenProzesse

mit StatusStart Jobgruppe

externe Steuerung legt fest, was

täglich, monatlich … starten soll

Ergänzungautomatische

Ergänzung abhängiger

Prozesse (Konsistenz)Scheduler

Executoren

parallele Ausführung

mit dbms_schedule

neue Jobs startbar?

(Abhängigkeiten erfüllt)

soll

kann

läuft

fertigSignal

generierte

Abhängigkeiten


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


Migration - einzelne Tabelle

bisheriges Alt DWH

neue Umsetzung in Data Vault

Raw Vault

Business

Rules

Business Vault

Befüllungsregeln

+

++

+

Source

Hard Rules

View

„Beispiel“

Lesen für Folge-

verarbeitungen

Lesen für Folge-

verarbeitungenTabelle

„Beispiel“

Source


Migration - Gesamt

bisheriges Alt DWH

Tab 1 Tab 3Tab 2

noch keine Umsetzung in Data Vault

Ausgangszustand - alle Tabellen im Alt DWH

Tabelle Tabelle Tabelle


Migration - Gesamt

bisheriges Alt DWH mit einem View

Tab 1

Data Vault erstellt

erste Tabelle durch View mit Namen Tab1 ersetzt - Data Vault eingeführt

Tab 3Tab 2

View Tabelle Tabelle

33

Tab 2


Migration - Gesamt

bisheriges Alt DWH mit zweiten View

Data Vault erweitert

weitere Tabelle durch View ersetzt - Data Vault erweitert

Tab 1 Tab 3

View View Tabelle


Migration - Gesamt

bisheriges Alt DWH abgelöst

Data Vault vollständig

Endzustand - Data Vault vollständig - Alt DWH abgeschaltet


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

Documents

Data Vault 2 - Oracle Data Warehouse Community Seite · Data Vault 2.0 - Neue DWH-Anforderungen schnell und kostengünstig umsetzen - Jörg Stahnke 11. Oracle Business Analytics und