modellierung agliler data warehouses mit data vault

BASEL BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENEVA HAMBURG COPENHAGEN LAUSANNE MUNICH STUTTGART VIENNA ZURICH

Modellierung agiler Data Warehouses mit Data Vault Dani Schnider, Trivadis AG DOAG Konferenz 2015

Dani Schnider

2

Principal Consultant, Trainer und DWH/BI Lead Architect bei Trivadis in Zürich

  Co-Autor des Buches «Data Warehousing mit Oracle – Business Intelligence in der Praxis»

  Certified Data Vault Data Modeler

19.11.2015 Modellierung agiler Data Warehouses mit Data Vault

Unser Unternehmen.

Modellierung agiler Data Warehouses mit Data Vault 3 19.11.2015

Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution Engineering und der Erbringung von IT-Services mit Fokussierung auf - und -Technologien in der Schweiz, Deutschland, Österreich und Dänemark. Trivadis erbringt ihre Leistungen aus den strategischen Geschäftsfeldern: Trivadis Services übernimmt den korrespondierenden Betrieb Ihrer IT Systeme.

B E T R I E B

KOPENHAGEN

MÜNCHEN

LAUSANNE BERN

ZÜRICH BRUGG

GENF

HAMBURG

DÜSSELDORF

FRANKFURT

STUTTGART

FREIBURG

BASEL

WIEN

Mit über 600 IT- und Fachexperten bei Ihnen vor Ort.


14 Trivadis Niederlassungen mit über 600 Mitarbeitenden.

Über 200 Service Level Agreements.

Mehr als 4'000 Trainingsteilnehmer.

Forschungs- und Entwicklungsbudget: CHF 5.0 Mio.

Finanziell unabhängig und nachhaltig profitabel.

Erfahrung aus mehr als 1'900 Projekten pro Jahr bei über 800 Kunden.


Einleitung

Was ist Data Vault?


  Datenmodellierungsmethode für Data Warehouses in agilen Projektumgebungen

  Entwickelt von Dan Linstedt

  Geeignet für DWH Core Layer bzw. Enterprise DWH

  Optimiert für Agilität, Integration und Historisierung

3NF Model

Dimensional Model

Dimensional Model

3NF Model

Data Vault Model

3NF Model

OLTP Systeme EDWH / Core Data Marts

Motivation und Vorteile


Agilität

•  Einfache Erweiterbar-keit des Data Vault Modells

•  Kein Redesign bestehender Elemente

Integration

•  Integration von Daten aus unterschiedlichen Quellsystemen

•  Verwendung von gemeinsamen fachlichen Schlüsseln

Historisierung

•  Nachvollziehbarkeit von Datenänderungen

•  Vollständige Histori-sierung von Daten aus der Vergangenheit

Grundidee von Data Vault


  Aufteilung der Daten in verschiedene Elemente

Hubs

Links

Satellites

Argumente für und gegen Data Vault


Agiler Ansatz Hohe Komplexität

Einfache Erweiterbarkeit

Vollständige Historisierung

Schwer verständlich

Nur ein Hype-Thema

Hohe Flexibilität

Gute Integration

Zu viele Tabellen

Komplexe ETL-Prozesse


Elemente von Data Vault

Hub


Identifikation von fachlicher Entität

  Fachlicher Schlüssel

Keine beschreibenden Attribute

Keine Fremdschlüssel zu anderen Hubs

  Künstlicher Schlüssel als Primary Key

  Audit-Attribute (Ladezeitpunkt, Quellsystem)

Surrogate Key (PK) Business Key(s) (UK) Load Timestamp Record Source

HUB

Link


Beziehung zwischen zwei oder mehr Hubs

  Fremdschlüssel zu Hubs

Keine beschreibenden Attribute

  Erlaubt n-zu-n Beziehungen zwischen Hubs

  Nur Verbindungen zu Hubs erlaubt

  Künstlicher Schlüssel als Primary Key

  Audit-Attribute (Ladezeitpunkt, Quellsystem)

Surrogate Key (PK) Foreign Key Hub 1 Foreign Key Hub 2 ... Load Timestamp Record Source

LINK

Satellite


Kontextinformationen für Hubs oder Links

  Fremdschlüssel zu genau einem Hub oder Link

  Primary Key: Fremdschlüssel + Ladezeitpunkt

  Beschreibende Attribute

Keine Fremdschlüssel zu anderen Hubs/Satellites

  Audit-Attribut (Quellsystem)

  Mehrere Satellites pro Hub/Link erlaubt

Foreign Key to Hub (PK) Load Timestamp (PK) Context Attribute 1 Context Attribute 2 ... Context Attribute n Record Source

SATELLITE

Beispiel


Hubs

Links

Satellites


Design eines Data Vault Modells

Modellierungsprozess


1.  Fachliche Entitäten definieren:

2.  Beziehungen modellieren:

3.  Beschreibende Attribute festlegen:

Hubs

Links

Satellites

Erweiterung des Data Vault Modells


Herausforderung bei Datenmodellerweiterungen:

  Strukturänderungen bestehender Tabellen

  Migration historischer Daten Data Vault Ansatz:

  Bestehende Tabellen nicht verändern

  Nur neue Tabellen hinzufügen

  Keine Datenmigration notwendig

Erweiterung des Data Vault Modells – Beispiel


Zusätzliche Attribute für Online-Shop:

  Login-Name

  E-Mail-Addresse

Integration mehrerer Quellsysteme

19 19.11.2015

Customer Database

(A)

Web Shop Database

(B)

Source Systems

Customer

Online User

✗ ✔ Customer_BK Customer_Name

A-123 Claus Jordan

A-456 Dani Schnider

B-0815 Dani Schnider

B-4711 Peter Welker

A-789 Joachim Wehner

B-9876 Claus Jordan

✗ Customer_BK Customer_Name

23489724 Claus Jordan

90346262 Dani Schnider

98437098 Joachim Wehner

82365405 Peter Welker

✔ Modellierung agiler Data Warehouses mit Data Vault

Historisierung


Nachvollziehbarkeit von Datenänderungen

  Versionierung der Daten in Satellites

  Ladezeitpunkt ist Bestandteil des Satellite PKs

SID TS First_Name Last_Name

77 t1 ANNA BIERI

77 t2 Anna Bieri

77 t6 Anna Hartmann-Bieri

77 t7 Anna Bieri Hartmann

Historisierung – Beispiel


SID TS City

77 t1 ZUERICH

77 t2 Zuerich

77 t4 Zürich

77 t6 Hamburg

77 t8 Basel

SID TS E-Mail

77 t3 [email protected]





SID Customer_No

77 1234-91415


77 t1 ANNA BIERI

77 t2 Anna Bieri



t1 ANNA BIERI, ZUERICH

t2 Anna Bieri, Zuerich

t3 Anna Bieri, Zuerich [email protected]

t4 Anna Bieri, Zürich [email protected]

t5 Anna Bieri, Zürich [email protected]

t6 Anna Hartmann-Bieri, Hamburg [email protected]

t7 Anna Bieri Hartmann, Hamburg [email protected]

t8 Anna Bieri Hartmann, Basel [email protected]

Point In Time (PIT) Table


SID TS City

77 t1 ZUERICH

77 t2 Zuerich

77 t4 Zürich

77 t6 Hamburg

77 t8 Basel

SID TS E-Mail






SID Customer_No

77 1234-91415


77 t1 ANNA BIERI

77 t2 Anna Bieri



SID TS S1 S2 S3

77 t1 t1 t1 -

77 t2 t2 t2 -

77 t3 t2 t2 t3

77 t4 t2 t4 t3

77 t5 t2 t4 t5

77 t6 t6 t6 t6

77 t7 t7 t6 t7

77 t8 t7 t8 t8

PIT Table


ETL-Prozesse für Data Vault

Laden von Data Vault Tabellen


  Hubs:

–  Einfügen neuer Business Keys

  Links:

–  Key Lookups auf Hubs

–  Einfügen neuer Beziehungen

  Satellites:

–  Key Lookup auf Hub

–  Deltaermittlung neue Daten / aktuelle Version

–  Einfügen von neuer Version

INSERT

INSERT

INSERT

Laden von dimensionalen Data Marts aus Data Vault


  Data Vault unterscheidet nicht zwischen Stammdaten (Dimensionen) und Ereignisdaten (Fakten)

  Fakten und Dimensionen können Daten aus mehreren Entitäten enthalten

  Join aller benötigten Hubs, Links und Satellites

  SCD1 Dimensionen:

–  Aktuelle Version aller Satellites

  SCD2 Dimensionen:

–  Point In Time (PIT) Tables

–  ev. History View Layer

Ladeschritte


1.  Paralleles Laden aller Stage-Tabellen

2.  Paralleles Laden aller Hubs

3.  Paralleles Laden

–  aller Links

–  aller Hub Satellites

4.  Paralleles Laden aller Link Satellites

5.  Paralleles Laden aller Dimensionen

6.  Paralleles Laden aller Faktentabellen

Point In Time (PIT) Table – Beispiel


Ausführliches Beispiel dazu siehe Blog danischnider.wordpress.com


Data Vault &

DWH Architektur

ETL Pipeline


  Verschiedene Arten von Transformationen zwischen Extraktion und Laden

Load

Reco

rd

Calc

ulat

e

D/T

Sta

mp

Tran

sfor

m

Clea

nse

Valid

ate

Inte

grat

e

Extr

act

  Was wird in welcher DWH-Schicht ausgeführt?

Source: Hans Hultgren, Modeling the Agile Data Warehouse with Data Vault, page 172

Data Warehouse Marts Cleansing Area Core Staging Area

Metadata

Data Vault

Auswirkungen auf DWH-Architektur


Source Systems

ETL

BI Plattform

Data Warehouse Cleansing Area Staging Area

Metadata

Data Vault

Core Marts

Data Warehouse Staging Area

Metadata

Raw Data Vault

Core Marts

Business Data Vault

Tran

sfor

m

Load

D/T

Sta

mp

ETL Pipeline für erweiterte Data Vault Architektur


Load

Calc

ulat

e

Clea

nse

Valid

ate

Inte

grat

e

Extr

act

Source: Hans Hultgren, Modeling the Agile Data Warehouse with Data Vault, page 173

Inte

grat

e

Tran

sfor

m

Calc

ulat

e

Clea

nse

Valid

ate

Extr

act

Staging Area Data Marts Raw Data Vault Business Data Vault

Common Business Rules

Mart Specific Rules


Fazit

Data Vault – Chancen und Herausforderungen


+  Einfache und einheitliche ETL-Regeln

+  Leichte Erweiterbarkeit

+  Integration mehrerer Quellsysteme

+  Vollständige Historisierung

-  Hohe Anzahl Tabellen in Data Vault

-  Konsequente Einhaltung der Regeln

-  Korrekte Wahl der Business Keys

Data Vault – Einsatzgebiete


  Projekte mit hoher Agilität

–  Häufige Modellerweiterungen

–  Laufend ändernde Anforderungen

  Data Warehouses mit mehreren Quellen

–  Wichtig: Fachliche Schlüssel zwingend

Grosse DWH-Projekte

–  Keine manuelle ETL-Entwicklung

–  Einsatz von DWH-Generatoren


Trivadis an der DOAG 2015

Ebene 3 - gleich neben der Rolltreppe

Wir freuen uns auf Ihren Besuch.

Denn mit Trivadis gewinnen Sie immer.

modellierung agliler data warehouses mit data vault

Presentations & Public Speaking