View
224
Download
0
Category
Preview:
Citation preview
Agile DWH Modellierung mit Data Vault
Alexander Blech
Matthias Wendt
2015-04-15
Agile DWH Modellierung mit Data Vault
• OSP Dresden und die Ottogroup
• Data Vault Theorie
• DV im Einsatz für die Hermes Fulfillment
• Herausforderungen und Erkenntnisse im Betrieb
Seite 2
Agenda
OSP Dresden und die Otto-Gruppe
• 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
• BI @ OSP– 14 köpfiges BI-Team
– Teradata und Microsoft SQL Server als Kerntechnologie
– Hermes Fulfillment und Otto als Hauptkunden
Seite 3
Unternehmensvorstellung
Data Vault Überblick
• 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. 2007 durch Ronald Damhof
• Bildung einer ersten User Group in den Niederlanden 2010
• Deutsche Initiativen (deutsche DVUG) ab 2012
Seite 4
Herkunft von Data Vault
Data Vault Überblick
• 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
Inhalte von Data Vault
Data Vault Überblick
• 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
Gründe für den Einsatz von Data Vault
Erläuterung der Kernentitäten
Seite 7
Dekomposition – Beispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
Erläuterung der Kernentitäten
Seite 8
Dekomposition – Beispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
<<HUB>>
<<LNK>>
<<SAT>>
Erläuterung der Kernentitäten
Seite 9
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
<<HUB>>
<<LNK>>
<<SAT>>
Erläuterung der Kernentitäten
Seite 10
Kernentitäten (Abwandlungen und Sonderformen)
• Bridges– Vorberechnete „Sammlung“ von Beziehungen und Attributen
• Enthalten weiterführende Geschäftslogik
• Hauptnutzen: Performance-Optimierung
• Referenzen– Einfache Referenztabellen
• Einsprung von Speichervolumen
• Meist Masterstammdaten ohne Änderungsaufkommen
• Transaktions-Satelliten– Nutzen analog der normalen Satelliten-Logik
• SK des Hubs oder Links
• Detailattribute
• Keine Historisierungs- weniger Loggingattribute
<<BRI>>
<<TSAT>>
<<REF>>
Data Vault im Einsatz
Seite 11
Modellierungsbeispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
Data Vault im Einsatz
Seite 12
Modellierungsbeispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
<<HUB>>H_QualityInspection
<<HUB>>H_WarehousePlant
<<HUB>>H_Product
Data Vault im Einsatz
Seite 13
Modellierungsbeispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
<<HUB>>H_QualityInspection
<<LNK>>L_QI_WP
<<HUB>>H_WarehousePlant
<<HUB>>H_Product
<<LNK>>L_QI_Product
Data Vault im Einsatz
Seite 14
Modellierungsbeispiel
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Fachschlüssel
Beziehungen
Kontextinformation
<<HUB>>H_QualityInspection
<<LNK>>L_QI_WP
<<SAT>>S_QualityInspection
<<HUB>>H_WarehousePlant
<<HUB>>H_Product
<<LNK>>L_QI_Product
<<SAT>>S_QI_Product
Data Vault im Einsatz
Seite 15
Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Neuer_Kontext
Fachschlüssel
Beziehungen
Kontextinformation
<<HUB>>H_QualityInspection
<<LNK>>L_QI_WP
<<SAT>>S_QualityInspection
<<HUB>>H_WarehousePlant
<<HUB>>H_Product
<<LNK>>L_QI_Product
<<SAT>>S_QI_Product
Data Vault im Einsatz
Seite 16
Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“
Qualitätsprüfung
PK Id
FK Artikel_Id
FK Lagerbetrieb_Id
QM_Auftrags_Nummer
AuftragsuebergabeDatum
PruefungsStatus
PruefungsDatum
PruefungsErgebnis
Neuer_Kontext
<<HUB>>H_QualityInspection
<<LNK>>L_QI_WP
<<SAT>>S_QualityInspection
<<HUB>>H_WarehousePlant
<<HUB>>H_Product
<<LNK>>L_QI_Product
<<SAT>>S_QI_Product
<<SAT>>S_QualityInspection
Neuer_Kontext
Data Vault im Einsatz
• Erweiterung des Modells ohneAnpassung vorhandener Strukturen
• Kompatibilität der Datenhaltungsschichtzu Strukturanforderungen der auf-setzenden MART-Schicht
• Analog zu neuen Kontextinformationen könnenVerbindungen (Links) ohne Anpassungvorhandener Strukturen etabliertwerden
• 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
Vorteile durch agile Erweiterung durch „vertikale Partitionierung“
DV in der Praxis
• 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
Seite 18
Ein Praxisbeispiel für DV bei der Hermes Fulfilment (HF)
WebshopCustomer
CareFinanzservices Warehousing Distribution Retouren
Architekturüberblick + Technik
• 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
Seite 19
Ein Praxisbeispiel für DV bei der Hermes Fulfilment (HF)
Datenquellen Geschäftsmodellschicht Auswertungsschicht Darstellungsebene
STAGE CORE Rel. MART / Cube
Importschicht
Vorgehen bei Neuanforderungen
• 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
Seite 21
Der Weg von der Anforderung zur Umsetzung
HUBGeschäftsobjekt
SATObjektkontext
Transformation
MART-Objekt
(kompatibel)
SATNeuer
Objektkontext
MART-Objekt(neu)
Transformation
Fachlichkeit
• 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
Thematischer Fokus des DWH
Eindrücke aus dem Betrieb
• 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
Zusammenfassung
sagt Danke für Ihre Aufmerksamkeit.
Recommended