Data Vault Zentralisierung von Businesslogik und Data Mart-Anbindung. Dr. Bodo Hüsemann Informationsfabrik GmbH

Transkript

1 Data Vault Zentralisierung von Businesslogik und Data Mart-Anbindung Dr. Bodo Hüsemann Informationsfabrik GmbH

2 Konzeption und Architektur Implementierung [ETL, Reporting, OLAP, Planung] Schulungen für BI und DWH [Tools, Vorgehensmodelle, Projektmanagement] A C B D Projektmanagement [klassisch und agil] Coaching, Beratung, Expertisen 2

3 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

4 Data Warehouse Designziele Klassisch: Data Warehouse als Single Point Of Truth (SPOT) 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 Kritik aus der Praxis: Geringe Agilität bei der Umsetzung von fachlichen Neuanforderungen und Änderungen Keine klare Trennung zwischen integrierter Quellsystemsicht und SPOT 4

5 Data Warehouse Designziele Single Version of Facts (aka ODS mit Historisierung) 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 Point to Point (hohe Kopplung) Hub & Spoke (lose Kopplung) 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) 5

6 Data Vault Architektur: Raw- und Business-Vault Sources Staging Data Vault BI-Layer Single Version of Facts Integrationslogik Raw Vault Analytical BI 1:1 Soft Rules OLAP external Hard Rules Business Vault Standard Reporting Single Point of Truth 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) 6

7 Business Vault genauere Charakterisierung Quellsysteme Data Vault Data Marts Raw Vault Business Vault Conformed Marts Conformed Custom Custom Mart Conformed Business Vault und Marts: Unternehmenssicht (SPOT) Custom Business Vault und Marts: Umsetzung spezifischer/alternativer Businesslogik 7

8 Umsetzung von Änderungsanforderungen Quellsysteme Data Vault Data Marts Raw Vault Business Vault Conformed Custom Conformed Marts Custom Mart 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

9 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 9

10 Business Vault Designpatterns für Fachlogik Ableitung neuer Attribute (Satelliten) Ableitung neuer Relationen (Links) Ableitung neuer Entitäten (Hubs) Validierung Harmonisierung Aggregation Transformation 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) 10

11 Data Vault Designpatterns für Fachlogik Berechnung abgeleiteter Attribute: Beispiel Scoring Ziel: Bestimmung der Popularität eines Künstlers Raw Vault Business Vault 11

12 Data Vault Designpatterns für Fachlogik Berechnung abgeleiteter Relationen: Beispiel Same as Link Ausgangssituation: Hub H_ARTIST in der RAW Vault enthält Duplikate Ziel: Modellierung einer Ähnlichkeitsrelation mit einem Ähnlichkeitsscore Raw Vault Business Vault 12

13 Data Vault Designpatterns für Fachlogik Ableitung neuer fachlicher Entitäten z.b. Fusion von Hubs Ziel: Identityresolution über Zusatzservice Musicbrainz (MBID) LastFM Artist und Spotify Artist auf einen systemübergreifenden Fachschlüssel (MBID) abbilden und Attribute fusionieren. Raw Vault Business Vault 13

14 Data Vault Designpatterns für Fachlogik Validierung Datenqualitätsprüfung und Ergebnis 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 ) Raw Vault Business Vault (Error Vault) h_artist_id valid_from artist_name founded area NULL Im Jahr 1995 Westfalen h_artist_id valid_from artist_name founded area Prodigy NULL Westfalen Prodigy 1995 Nordrhein-Westfalen 14

15 Data Vault Designpatterns für Fachlogik Harmonisierung Ziel: Normierung von Wertebereichen, Formaten, Defaults Raw Vault Business Vault Germany The Prodigy Deutschland Prodigy, The 15

16 Data Vault Designpatterns für Fachlogik Veränderung der Granularität Aggregationskennzahlen Beispiele: Portfolio-Kennzahlen (Riskomanagement) Deckungsbeiträge (Produktkalkulation) FTEs für Mitarbeiter bzw. Stellen (Ressourcenplanung) Media: Musikcharts Pirate Link Raw Vault Business Vault 16

17 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 17

18 Data Vault zu Data Mart Transformation Ausgangssituation und Anforderungen 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 18

19 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

20 Batch vs. Realtime vs. Virtual DI Sources Staging Data Vault BI-Layer Batch Integrationslogik Single Version of Facts Raw Vault Analytical BI 1:1 OLAP Soft Rules Virtual DI Layer ESB/CDC Realtime Hard Rules Business Vault Single Point of Truth Standard Reporting Batch: Pull ETL Prozesse (datenmengenorientiert) Realtime: Push ETL Prozesse (einzelsatzorientiert) Virtual DI: NoETL Prozesse (z.b. DBViews oder on demand ETL) 20

21 Business Vault Designpatterns für Data Marts Ansätze und Hilfskonstrukte zur Optimierung der Data Mart Erstellung 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 21

22 Point-in-Time Satellit - PIT PIT ist temporaler Index für schnellen AS-OF Zugriff auf Satelliten Primary Key Raw Vault Business Vault 22

23 PIT Table - Beispiel s_artist bs_artist_norm bs_artist_scoring ID valid_from artist_name ID valid_from ort_name ID valid_from popularity Prodigy Prodigy The Prodigy Prodigy, The ID valid_from s_artist bs_artist_norm bs_artist_scoring NULL NULL Union all LOAD_START dates oder Snapshot Date (z.b. EOM) 23

24 Point in Time Table - Änderungszeitlinien s_artist Prodigy The Prodigy s_artist_norm Prodigy Prodigy, The s_artist_scoring 1 2 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 Zeit T0: Zero-Key Records statt NULL ->Natural Join 24

25 Bridge Table AS-OF Abfragen auf mehrere Hub/Link-Tabellen beschleunigen -> Hilfskonstrukt und keine Data Vault Entität B_Bridge Tabelle H_HUB3 S_1 PK PK B_ID Timestamp Primary Key S_2 S_3 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 Optional L_H2_H3 H_HUB2 L_H1_H2 H_HUB1 S_1 S_1 25

26 Business Vault Designpattern Denormalisierung - Flachklopfen rekursiv definierter Hierarchien Anfrageoptimierung (Strukturänderung) Keine Fachlogik im engeren Sinn -> Performanceoptimierung Raw Vault Business Vault 26

27 Data Vault Designpatterns Data Mart Erstellung Denormalisierung - Flachklopfen rekursiv definierter Hierarchien 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 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

28 Data Vault Data Mart Erstellung Ausgangsmodell Data Vault 28

29 Data Vault Data Mart Erstellung Ausgangsmodell Data Vault Dimension User Fakt MusicRating Dimension Music 29

30 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 S1 A1 K1 SName1 AName1 Artist S2 A1 K1 SName2 AName1 Artist S3 A2 K1 SName3 AName2 Artist1 Hier sind keine LinkIDs in der Bridge, da sie keine Satelliteninfo für die Dimension besitzen Dimension Music 30

31 Beispieldimension Dimension Music: Erstellung über Bridge b_d_music Bridge b_d_music_id valid_from valid_to h_song_id h_album_id h_artist_id song_id album_id artist_id S1 A1 K1 SongID1 AlbumID1 ArtistID S2 A1 K1 SongID2 AlbumID1 ArtistID S3 A2 K1 SongID3 AlbumID2 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 Dimension d_music_id valid_from valid_to song_id song_name album_id album_ name artist_id artist_ name artist_ sortname M SongID1 This That AlbumID1 Future ArtistID1 The Boys Boys, The M SongID2 MyDream AlbumID1 Future ArtistID1 The Boys Boys, The M SongID3 The Place AlbumID2 Past ArtistID1 The Boys Boys, The 31

32 Beispielfakt Erstellung der Fakt MusicRating Join zwischen Hub/Link mit Kennzahl und den zugehörigen Bridges Berechnung abgeleiteter Kennzahlen bereits in der Business Vault Fakt MusicRating d_time d_music_id d_user_id stars stars_delta Bridge b_d_user M1 U M2 U M3 U2 3-1 Bridge b_d_music 32

33 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 33

34 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 Hoher Kopplungsgrad Niedriger Kopplungsgrad 34

35 Designmetrik: Kohäsion Was bedeutet Kohäsion im BI Kontext? 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. Niedrige Kohäsion Hohe Kohäsion 35

36 Single Responsibility Principle (SRP) Low COUPLING - High COHESION 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. Gather together the things that change for the same reasons. Separate those things that change for different reasons. Robert C. Martin (Uncle Bob) 36

37 Bleiben wir in Kontakt Dr. Bodo Hüsemann Informationsfabrik GmbH / bhuesemann@informationsfabrik.de 37