data vault - modellierungsmethode für agile data warehouse ... · business vault design patterns...

Data VaultZentralisierung von Businesslogik und Data Mart-Anbindung

Dr. Bodo HüsemannInformationsfabrik GmbH

Konzeption und Architektur

Implementierung

[ETL, Reporting, OLAP, Planung]

Schulungen für BI und DWH

[Tools, Vorgehensmodelle, Projektmanagement]

Projektmanagement

[klassisch und agil]

Coaching, Beratung, Expertisen

A B

C D

|2

Agenda

Single Version of Facts <-> Single Point of Truth

Business Vault Design Patterns

Von der Data Vault zum Data Mart

Kopplung und Kohäsion im Data Vault Kontext

|3

Unternehmensweit eindeutige Fachsicht auf Kennzahlen

Zentralisierung von Berechnungen und Fachlogik allgemein

BI Data Governance (Durchsetzung einer Datenqualitätsstrategie)

Kapselung und Wiederverwendung der Implementierung von Fachlogik

Data Integration Business Alignment

Data Warehouse Designziele

Klassisch: Data Warehouse als Single Point Of Truth (SPOT)

Kritik aus der Praxis: • Geringe Agilität bei der Umsetzung von fachlichen Neuanforderungen und Änderungen• Keine klare Trennung zwischen integrierter Quellsystemsicht und SPOT

|4

Data Warehouse Designziele

Integrierte Sicht auf alle operationalen Quellsysteme (Fakten)

Physikalische und logische Integration von Anfrage- und Abnahmeprozessen

Hub and Spoke Zentralisierung von Eingangs- und Ausgangsschnittstellen

Lose Kopplung zwischen Quellsystemen und Anfrage- bzw. Abnehmersystemen

Standardisierte Historisierung von Quellsystemänderungen

Normierung der technischen Historisierungsmethode und -technik

Normierung der fachlichen Quellsystemhistorisierung. Fälle:

Keine Historisierung (z.B. Referenzdaten wie ISO-Codes)

Zeitstempelhistorisierung (z.B. Gültig-ab Attribute, z.B. EFFDT)

Zeitintervallhistorisierung (Gültig-ab + Gültig-bis, z.B. VALID_FROM, VALID_TO)

Single Version of Facts (aka ODS mit Historisierung)

Hub & Spoke

(lose Kopplung)

Point to Point

(hohe Kopplung)

|5

Data Vault Architektur: Raw- und Business-Vault

Zentralisierung der Integrations- und Historisierungslogik in einer Raw Vault

Zentralisierung von Businesslogik in einer Business Vault (oft schon virtuell)

BI Layer greift standardmäßig auf SPOT der Business Vault (virtuell falls möglich)

Spezifische Fachlogik für Data Marts greift auf Raw Vault zu

Integration von Fachinformation aus dem BI-Layer (Managed Self-Service BI)

Data Vault ermöglicht die logische Integration in einem Datenmodell (Hubs)

bei gleichzeitiger Entkopplung der einzelnen Inhalte (Satelliten und Links)

Sources Staging Data Vault BI-Layer

Analytical BI

Standard Reporting

1:1

external

OLAP

Integrationslogik

„Single Version of Facts“

„Hard Rules“

RawVault

BusinessVault

„Single Point of Truth“

„Soft Rules“

|6

Business Vault – genauere Charakterisierung

Quellsysteme Data Vault Data Marts

Raw Vault Business Vault

Conformed

Marts

Custom

Mart

Conformed

Custom

Conformed Business Vault und Marts: Unternehmenssicht (SPOT)

Custom Business Vault und Marts: Umsetzung spezifischer/alternativer Businesslogik

|7

Business Vault

Umsetzung von Änderungsanforderungen

Quellsysteme Data Vault Data Marts

Raw Vault

Conformed

Marts

Custom

Mart

Conformed

Custom

1. Fall: Quellsystemänderung (bestehendes Attribut ändern -> eher selten)

a. Raw Vault ändern, abhängige Conformed BV und Data Mart zu ändern

b. Raw Vault ändern – Conformed BV unverändert aber evtl. Custom BV und Mart anpassen

c. Raw Vault erweitern, evtl. Custom BV zu erweitern und Custom Mart (vgl. SCD3)

2. Fall: Quellsystemerweiterung (neue(s) Quellsystem, Tabelle, Attribut -> regelmäßig)

a. Raw Vault erweitern

b. Raw Vault erweitern, Conformed BV und Data Mart erweitern

c. Raw Vault erweitern, Custom BV und Custom Mart erweitern bzw. erstellen

3. Fall: Änderung der Businesslogik (eher häufig und zeitnahe Umsetzung benötigt)

a. Conformed BV und Data Mart ändern

b. Custom BV und Custom Mart erweitern bzw. erstellen -> evtl. technische Schuld

|8

Agenda





|9

Business Vault – Designpatterns für Fachlogik

Ableitung neuer Attribute (Satelliten)

Ableitung neuer Relationen (Links)

Ableitung neuer Entitäten (Hubs)

Validierung

Harmonisierung

Aggregation

Transformation

|10

Mit den Eigenschaften und Nebenbedingungen

Änderung/ Erweiterung der Businesslogik ist entkoppelt zur Raw Vault

Quellsystemerweiterungen sind entkoppelt zur bestehenden Businesslogik

Fachlogik kann oft durch Virtualisierung umgesetzt werden (NoETL)

Data Vault – Designpatterns für Fachlogik

Ziel: Bestimmung der Popularität eines Künstlers

Berechnung abgeleiteter Attribute: Beispiel Scoring


|11


Ausgangssituation: Hub H_ARTIST in der RAW Vault enthält Duplikate

Ziel: Modellierung einer Ähnlichkeitsrelation mit einem Ähnlichkeitsscore

Berechnung abgeleiteter Relationen: Beispiel Same – as Link


|12


Ziel: Identityresolution über Zusatzservice Musicbrainz (MBID)

LastFM Artist und Spotify Artist auf einen systemübergreifenden

Fachschlüssel (MBID) abbilden und Attribute fusionieren.

Ableitung neuer fachlicher Entitäten – z.B. Fusion von Hubs


|13


Ziel: Prüfung von Validierungsregeln (z.B. Formate, Wertebereiche)

1. Fall: Erkennung von Datenqualitätsmängeln (keine Raw Vault Veränderung -> „area“)

2. Fall: Erkennung und Behandlung von technischen Integrationsfehlern (Default in Raw Vault -> „founded“)

Validierung – Datenqualitätsprüfung und Ergebnis

h_artist_id valid_from artist_name founded area

1 01.01.2015 NULL Im Jahr

1995

Westfalen

h_artist_id valid_from artist_name founded area

1 01.01.2015 Prodigy NULL Westfalen

1 15.01.2015 Prodigy 1995 Nordrhein-Westfalen

Raw Vault Business Vault (Error Vault)

|14


Ziel: Normierung von Wertebereichen, Formaten, Defaults

Harmonisierung

„Prodigy, The“„The Prodigy“

„Deutschland“


„Germany“

|15


Beispiele:

Portfolio-Kennzahlen (Riskomanagement)

Deckungsbeiträge (Produktkalkulation)

FTEs für Mitarbeiter bzw. Stellen (Ressourcenplanung)

Media: Musikcharts

Veränderung der Granularität – Aggregationskennzahlen


Pirate Link

|16

Agenda





|17

Data Vault zu Data Mart Transformation

Fakten der Quellsysteme: Raw Vault

Fachlogik : Business Vault

Conformed Business Vault (SPOT)

Custom Business Vault

Spezifische Fachlogik eines Data Mart?

Alternative 1: Implementierung ebenfalls in der Business Vault

Alternative 2: Implementierung innerhalb der Data Mart Schicht

Vorteile der Alternative 1:

Hoher Automatisierungsgrad bei der Data Mart Erstellung

Keine zusätzliche Historisierungsschicht im Data Mart

Nutzung von Virtualisierungstechnologie falls möglich

Data Mart als anfrageoptimierte Sicht auf die Daten der Data Vault

Ausgangssituation und Anforderungen

|18

Virtualisierung von Business Logik

Ziele

Schnellere Anpassung an fachliche Anforderungen

Fachbereich pflegt Business Rules (Managed Selfservice BI)

Vermeidung von Datenbank Migrationsaufwänden

Aktuell: technische (Not)-Lösung mit NoETL (Not Only ETL)

Datenintegration zur Zeit der Anfrage (on demand ETL)

Virtualisierte ETL Technologie (z.B. Informatica Data Services)

Als Webservice ausführbare ETL-Prozesse

Alternativ realisiert durch Datenbanktechnologie

DB SQL-Views

View gekapselte Stored Procedures (z.B. SAP Hana Analytic Views)

Zukünftig: realtime processing engines

Apache Spark (nextgen Hadoop batch processing)

Apache Storm (stream/ CEP processing)

|19

Batch vs. Realtime vs. Virtual DI

Sources Staging Data Vault BI-Layer

Analytical BI

Standard Reporting

1:1 OLAP

Integrationslogik

„Single Version of Facts“

„Hard Rules“

RawVault

BusinessVault

„Single Point of Truth“

„Soft Rules“

Batch

ESB/CDC

Realtime

Virtual

DI Layer

Batch: Pull ETL Prozesse (datenmengenorientiert)

Realtime: Push ETL Prozesse (einzelsatzorientiert)

Virtual DI: NoETL Prozesse (z.B. DBViews oder on demand ETL)

|20

Business Vault Designpatterns für Data Marts

Dimensionsebenen

Einsatz von Point-in-Time (PIT) Satelliten

Vielzahl von Satelliten verknüpft mit Hub oder Link

Optimierung von AS-OF Abfragen (Vorberechnung von Filtern)

Abgefragte Datenmenge wird reduziert (Snapshot)

Dimensionshierarchien

Einsatz von Bridge Tabellen

Hierarchie schließt eine Vielzahl von Hubs & Links ein (Bridge)

Datenlieferung in Real-Time (Pufferung von konsistenten Snapshots)

Pattern: Denormalisierung rekursiver Hierarchien

Faktentabellen

Verwendung von PIT und Bridge Tabellen gleichzeitig

Ansätze und Hilfskonstrukte zur Optimierung der Data Mart Erstellung

|21

Point-in-Time Satellit - PIT

PIT ist temporaler Index für schnellen AS-OF Zugriff auf Satelliten

Primary Key

Raw Vault Business Vault|22

PIT Table - Beispiel

s_artist bs_artist_norm bs_artist_scoring

Union all LOAD_START dates oder Snapshot Date (z.B. EOM)

ID valid_from s_artist bs_artist_norm bs_artist_scoring

1 01.08.2000 NULL NULL 01.08.2000

1 14.10.2000 14.10.2000 14.10.2000 01.08.2000

1 01.11.2000 01.11.2000 01.11.2000 01.08.2000

1 17.12.2000 01.11.2000 01.11.2000 17.12.2000

1 01.01.2001 01.11.2000 01.11.2000 01.01.2001

ID valid_from artist_name

1 14.10.2000 Prodigy

1 01.11.2000 The Prodigy

ID valid_from ort_name

1 14.10.2000 Prodigy

1 01.11.2000 Prodigy, The

ID valid_from popularity

1 01.08.2000 100

1 17.12.2000 150

1 01.01.2001 130

|23

Point in Time Table - Änderungszeitlinien

Prodigy The Prodigy

Prodigy

2

s_artist

s_artist_norm

s_artist_scoring 1

t1 t2 t3 t4 t5

VALID_FROM

s_artist T1 T1 T3 T3 T3

s_artist_nom T0 T2 T3 T3 T3

s_artist_scoring T0 T0 T0 T4 T5

T0: Zero-Key Records statt NULL ->Natural Join

Zeit

Prodigy, The

|24

Bridge Table

AS-OF Abfragen auf mehrere Hub/Link-Tabellen beschleunigen

-> Hilfskonstrukt und keine Data Vault Entität

Primary Key

Optional

H_HUB3

L_H2_H3

S_1

S_2

S_3

H_HUB1

H_HUB2

S_1

L_H1_H2 S_1

B_Bridge Tabelle

PK B_IDPK Timestamp

Hub 1 ID Hub 2 ID Hub 3 ID Link 1 ID Link 2 ID ... Link N ID Hub 1 Business Key Hub 2 Business Key ... Hub N Business Key

|25

Business Vault Designpattern

Anfrageoptimierung (Strukturänderung)

Keine Fachlogik im engeren Sinn -> Performanceoptimierung

Denormalisierung - Flachklopfen rekursiv definierter Hierarchien

Raw Vault Business Vault |26

Data Vault – Designpatterns Data Mart Erstellung

Unbalancierte Hierarchien

Pfadlänge von Blatt bis Wurzel ist unterschiedlich

Elementzuordnung auf jeder Ebene möglich

Hier: Normalisierung zu einer balancierten Hierarchie

Alternative: Zuordnung von „NA“-Dummies

Denormalisierung - Flachklopfen rekursiv definierter Hierarchien

ID leaf level genre_1 genre_2 genre_3

1 n 1 Rock Rock Rock

2 n 2 Rock Heavy Metal Heavy Metal

3 y 3 Rock Heavy Metal Progressive Metal

4 n 1 Electronic Electronic Electronic

5 n 2 Electronic Pop Pop

6 y 3 Electronic Pop Hip Hop

|27

Data Vault – Data Mart Erstellung

Ausgangsmodell Data Vault

|28

Data Vault – Data Mart Erstellung

Ausgangsmodell Data Vault

Fakt MusicRating

Dimension User

Dimension Music|29

Beispiel Bridge

Bridge Dimension: b_d_music

b_d_music_id valid_from valid_to h_song_id h_album_id h_artist_id song_id album_id artist_id

1 01.01.2015 31.01.2015 S1 A1 K1 SName1 AName1 Artist1



Hier sind keine LinkIDs in der Bridge, da sie keine Satelliteninfo für die Dimension besitzen

Dimension Music|30

Beispieldimension

Dimension Music: Erstellung über Bridge b_d_music

b_d_music_id valid_from valid_to h_song_id h_album_id h_artist_id song_id album_id artist_id

1 01.01.2015 31.01.2015 S1 A1 K1 SongID1 AlbumID1 ArtistID1



Join der Bridge mit den Satelliten ergibt STAR-Dimension (Nutzung PIT falls vorhanden)

Künstlicher Schlüssel der Bridge ist Teilschlüssel der Faktentabelle (für historisierte Dim.)

Künstliche Schlüssel der Data Vault sind nicht Teil des Data Marts

d_music_id valid_from valid_to song_id song_name album_idalbum_name

artist_idartist_name

artist_sortname

M1 01.01.2015 31.01.2015 SongID1 This That AlbumID1 Future ArtistID1 The Boys Boys, The

M2 01.01.2015 31.01.2015 SongID2 My Dream AlbumID1 Future ArtistID1 The Boys Boys, The

M3 01.01.2015 31.01.2015 SongID3 The Place AlbumID2 Past ArtistID1 The Boys Boys, The

Bridge

Dimension

|31

Beispielfakt

Erstellung der Fakt MusicRating

Fakt MusicRating

d_time d_music_id d_user_id stars stars_delta

01.01.2015 M1 U1 5 +1

01.01.2015 M2 U1 4 0

01.01.2015 M3 U2 3 -1

Bridge b_d_music

Bridge b_d_user

Join zwischen Hub/Link mit Kennzahl und den zugehörigen Bridges

Berechnung abgeleiteter Kennzahlen bereits in der Business Vault

|32

Agenda





|33

Designmetrik: Kopplung

Was bedeutet Kopplung im BI Kontext?

Kopplung ist eine Strukturmetrik: Änderungsabhängigkeit zwischen Entitäten

Änderungsabhängigkeiten im BI Kontext:1. Datenmodell 2. Datenflussabhängigkeit (ETL Prozesse)

Data Vault entkoppelt Änderungen auf Datenmodellebene durch Separierung von Schlüssel-, Relations-, Kontextinformation

Niedriger KopplungsgradHoher Kopplungsgrad

|34

Designmetrik: Kohäsion

Was bedeutet Kohäsion im BI Kontext?

Niedrige Kohäsion

Kohäsion ist ein Inhaltsmetrik: Maß inhaltlicher/fachlicher Nähe der Daten (Attribute) und Funktionen (Logik) einer Entität.

Kennzeichen hoher Kohäsion:1. Datenmodell:

• Attribute einer Tabelle werden oft gemeinsam angefragt (strukturell)• Attributwerte einer Tabelle ändern sich häufig gemeinsam (Unit of Work)

2. Datenfluss/ Fachlogik:• Datenfluss erfüllt *einen* klar definierten fachlichen und technischen Zweck

Data Vault bündelt fachlich zusammengehörige Attribute in separierte Satelliten.Data Vault entkoppelt auf Architekturebene die Integrations-, Historisierungs- und Fachlogik und erhöht damit die Kohäsion der jeweiligen Datenflussprozesse innerhalb einer Schicht.

Hohe Kohäsion

|35

Single Responsibility Principle (SRP)

Low COUPLING - High COHESION

Gather together the things that change for the same reasons.

Separate those things that change for different reasons.

Jede Verantwortung einer Entität ist eine potentielle Änderungsquelle.

Gibt es mehrere unabhängige Änderungsquellen pro Entität, dann existieren möglicherweise auch mehrere Verantwortlichkeiten.

Das SRP wird durch niedrige Kopplung und hohe Kohäsion umgesetzt und so sind die Gesamtkosten einer Änderung am niedrigsten.

Dieses Prinzip ist durch Data Vault im BI Kontext umsetzbar.

Robert C. Martin (Uncle Bob)

|36

Bleiben wir in Kontakt

Dr. Bodo HüsemannInformationsfabrik GmbH

02 51 / 91 99 79 - [email protected]

|37

data vault - modellierungsmethode für agile data warehouse ... · business vault design patterns...

Documents