Agile DWH Modellierung mit Data Vault. Alexander Blech Matthias Wendt

Transkript

1 Agile DWH Modellierung mit Data Vault Alexander Blech Matthias Wendt

2 Agile DWH Modellierung mit Data Vault Agenda OSP Dresden und die Ottogroup Data Vault Theorie DV im Einsatz für die Hermes Fulfillment Herausforderungen und Erkenntnisse im Betrieb Seite 2

3 OSP Dresden und die Otto-Gruppe Unternehmensvorstellung Der Otto-Konzern 123 Gesellschaften in 20 Ländern 12 Mrd. Umsatz im Geschäftsjahr 13/14 Fokus auf Multichannel-Einzelhandel, Finanzdienstleistungen und Service Ottogroup Solution Provider (OSP) Dresden IT-Dienstleister für die gesamte Otto-Gruppe Gegründet 1991 mit Sitz in Dresden, aktuell 165 Mitarbeiter Schwerpunkte : Logistik und Warenwirtschaft AMOS als eigenständiges Produkt OSP 14 köpfiges BI-Team Teradata und Microsoft SQL Server als Kerntechnologie Hermes Fulfillment und Otto als Hauptkunden Seite 3

4 Data Vault Überblick Herkunft von Data Vault Data Vault ist eine DWH-Methodensammlung Ziel ist der Aufbau eines EDWH (Enterprise Data Warehouse) Entwickelt von Dan Linstedt ab 1990 Import nach Europa ca durch Ronald Damhof Bildung einer ersten User Group in den Niederlanden 2010 Deutsche Initiativen (deutsche DVUG) ab 2012 Seite 4

5 Data Vault Überblick Inhalte von Data Vault Vorschriften / Methoden zur Datenmodellierung Konzeptionelle Modellierungssprache Entwurfsregeln und muster Inkrementeller ( agiler ) Entwicklungsansatz Methoden zur Datenverarbeitung / Bewirtschaftung ETL-Templates Standardisierter Ladeprozess Mögliche Ansätze für ETL-Programm-Generatoren Architekturansätze Trennung von Integrations-/Historisierungslogik und Geschäftslogik Seite 5

6 Data Vault Überblick Gründe für den Einsatz von Data Vault Bewirtschaftungs-Performance Komplexe Lade-Netze mit starker Kopplung Unterstützung agiler BI-Projekte Erweiterbare Datenmodelle ohne komplexe Abhängigkeiten Kurze Releasezyklen Reaktion bei Anpassung von Geschäftslogik Die Abbildung der Geschäftslogik wird in eine weitere Schicht MART verschoben. Teilweise Infragestellung des Single-Point-of-Truth auf Geschäftsprozessebene Steigende Aufwände bei Impact-Analysen Abwärtskompatibilität bei Kontexterweiterungen Neuprojekte Aufbau einer tragfähigen Architektur Seite 6

7 Erläuterung der Kernentitäten Dekomposition Beispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation Seite 7

8 Erläuterung der Kernentitäten Dekomposition Beispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation <<LNK>> <<SAT>> Seite 8

9 Erläuterung der Kernentitäten Kernentitäten (Data Vault 1.0) Hubs Stamm einer Entität, bestehend aus Surrogate Key des DWH (SK) Business Key der Datenquelle (BK) Logging-Informationen (Quelle, Erstelldatum, Erstellprozess) Links Bildet die Beziehung zwischen zwei oder mehr Partnern ab Eigener Surrogate-Key SKs der verbundenen Entitäten Logging-Informationen Link-fähige Partner sind HUBs oder LINKs Satelliten Persistieren von Detaildaten (Kontextinformationen von Hubs oder Links) SK des Hubs oder Links Detailattribute Historisierungs- und Loggingattribute <<LNK>> <<SAT>> Seite 9

10 Erläuterung der Kernentitäten Kernentitäten (Abwandlungen und Sonderformen) Bridges Vorberechnete Sammlung von Beziehungen und Attributen Enthalten weiterführende Geschäftslogik Hauptnutzen: Performance-Optimierung <<BRI>> Referenzen Einfache Referenztabellen Einsprung von Speichervolumen Meist Masterstammdaten ohne Änderungsaufkommen <<REF>> Transaktions-Satelliten Nutzen analog der normalen Satelliten-Logik SK des Hubs oder Links Detailattribute Keine Historisierungs- weniger Loggingattribute <<TSAT>> Seite 10

11 Data Vault im Einsatz Modellierungsbeispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation Seite 11

12 Data Vault im Einsatz Modellierungsbeispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation H_WarehousePlant H_QualityInspection H_Product Seite 12

13 Data Vault im Einsatz Modellierungsbeispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation H_WarehousePlant H_QualityInspection <<LNK>> L_QI_WP <<LNK>> L_QI_Product H_Product Seite 13

14 Data Vault im Einsatz Modellierungsbeispiel PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation H_WarehousePlant H_QualityInspection <<SAT>> S_QualityInspection <<LNK>> L_QI_WP <<LNK>> L_QI_Product H_Product <<SAT>> S_QI_Product Seite 14

15 Data Vault im Einsatz Modellierungsbeispiel Agile Erweiterung durch vertikale Partitionierung PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Neuer_Kontext Beziehungen Fachschlüssel Kontextinformation H_WarehousePlant H_QualityInspection <<SAT>> S_QualityInspection <<LNK>> L_QI_WP <<LNK>> L_QI_Product H_Product <<SAT>> S_QI_Product Seite 15

16 Data Vault im Einsatz Modellierungsbeispiel Agile Erweiterung durch vertikale Partitionierung PK Qualitätsprüfung Id Artikel_Id Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Neuer_Kontext <<SAT>> S_QualityInspection Neuer_Kontext H_WarehousePlant H_QualityInspection <<SAT>> S_QualityInspection <<LNK>> L_QI_WP <<LNK>> L_QI_Product H_Product <<SAT>> S_QI_Product Seite 16

17 Data Vault im Einsatz Vorteile durch agile Erweiterung durch vertikale Partitionierung Erweiterung des Modells ohne Anpassung vorhandener Strukturen Kompatibilität der Datenhaltungsschicht zu Strukturanforderungen der aufsetzenden MART-Schicht Analog zu neuen Kontextinformationen können Verbindungen (Links) ohne Anpassung vorhandener Strukturen etabliert werden Schnellere Umsetzung und Verringerung des Testaufkommens, da auf Regressionstests verzichtet werden kann Spätere Konsolidierungsaufwände, um die Ergebnisse aus n Iterationen zusammenzuführen Seite 17

18 DV in der Praxis Ein Praxisbeispiel für DV bei der Hermes Fulfilment (HF) HF ist Fulfillment-Dienstleister in der Ottogroup, teil der Hermes Europe Abwicklung sämtlicher Services rund um die Bestellung vom Wareneingang bis zum Warenausgang Retourenprozess Im Konzern und für externe Kunden Betrieb mehrerer Versandzentren deutschlandweit Haldensleben Löhne, Ohrdruff Paket- und Großstücklogistik, sowie hängende Konfektion Webshop Customer Care Finanzservices Warehousing Distribution Retouren Seite 18

19 Architekturüberblick + Technik Ein Praxisbeispiel für DV bei der Hermes Fulfilment (HF) Aufbau eines Core-DWH nach Data Vault seit 2013 Core als Teile einer 3-Schicht Architektur Basis Microsoft SQL Server (DB + SSIS + SSAS) Start mit SQL Server 2008R2 Für Mart+Olap mittlerweile SQL Server 2012 und 2014 Steuerung über BI-Framework (onelog) Permanentes Entwicklerteam von 3-5 Entwicklern Datenquellen Importschicht Geschäftsmodellschicht Auswertungsschicht Darstellungsebene STAGE CORE Rel. MART / Cube Seite 19

20 Vorgehen bei Neuanforderungen Der Weg von der Anforderung zur Umsetzung Kunde definiert Anforderungen an Mart oder Cube z.b. neue Kennzahlen, Dimensionsausprägungen, Hierarchien Prüfung auf Verfügbarkeit der Daten in Core und Stage Aufwandsindikator Integration der neuen Informationen in Stage und Core Erweiterung Mart um neue Anforderungen Einbindung in bestehende Dimensionen / Fakten Erstellung neuer Objekte Erweiterung der OLAP-Cubes SAT Neuer Objektkontext HUB Geschäftsobjekt SAT Objektkontext Transformation Transformation MART- Objekt (neu) MART- Objekt (kompatibel) Seite 21

21 Fachlichkeit Thematischer Fokus des DWH Logistische Prozesse im Mittelpunkt Lagerprozesse Laufzeiten von Sendungen Reporting über den gesamten Konzernlogistikverbund (HF + Baur + weitere) Keine monetären Auswertungen Prozessketten über mehrere verschiedene Quellsysteme Eindeutigkeit von Entitäten muss sichergestellt sein Schlüsselfindung aufwendig Feine Granularität auf Artikel und Sendungsebene 1 Mio. Artikel je Tag im Warenausgang Entsprechende Anzahl an Sendungen und Retouren Bestandsführung auf Lagerplatzebene bei 3 Mio. SKU (Artikelpositionen) Seite 23

22 Eindrücke aus dem Betrieb Zusammenfassung Entwicklung ist wirklich agiler geworden Mitunter tägliche Roll-outs Schnelle Umsetzungszeiten Aufwendige Regressionstests entfallen Template-gestützte Entwicklung Einarbeitung in Technologie einfacher, dank Standardisierung Konzentration auf Fachlichkeit Übersicht kann schnell verloren gehen Vielzahl von Objekten Leistungsfähigkeit des BI-Frameworks ist wichtiger Bestandteil Änderungsdetektion Abhängigkeitssteuerung Seite 24

23 sagt Danke für Ihre Aufmerksamkeit.