Agile DWH Modellierung mit Data Vault - htw-dresden.de · Agile DWH Modellierung mit Data Vault • OSP Dresden und die Ottogroup • Data Vault Theorie • DV im Einsatz für die

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


• 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


• 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


Seite 8

Dekomposition – Beispiel

Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Fachschlüssel

Beziehungen

Kontextinformation

<<HUB>>

<<LNK>>

<<SAT>>


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


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


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Fachschlüssel

Beziehungen

Kontextinformation


Seite 12


Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Fachschlüssel

Beziehungen

Kontextinformation

<<HUB>>H_QualityInspection

<<HUB>>H_WarehousePlant

<<HUB>>H_Product


Seite 13


Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Fachschlüssel

Beziehungen

Kontextinformation


<<LNK>>L_QI_WP


<<HUB>>H_Product

<<LNK>>L_QI_Product


Seite 14


Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Fachschlüssel

Beziehungen

Kontextinformation


<<LNK>>L_QI_WP

<<SAT>>S_QualityInspection


<<HUB>>H_Product

<<LNK>>L_QI_Product

<<SAT>>S_QI_Product


Seite 15

Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“

Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Neuer_Kontext

Fachschlüssel

Beziehungen

Kontextinformation


<<LNK>>L_QI_WP



<<HUB>>H_Product

<<LNK>>L_QI_Product

<<SAT>>S_QI_Product


Seite 16

Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“

Qualitätsprüfung

PK Id

FK Artikel_Id

FK Lagerbetrieb_Id

QM_Auftrags_Nummer


PruefungsStatus

PruefungsDatum

PruefungsErgebnis

Neuer_Kontext


<<LNK>>L_QI_WP



<<HUB>>H_Product

<<LNK>>L_QI_Product

<<SAT>>S_QI_Product


Neuer_Kontext


• 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.

Documents

Agile DWH Modellierung mit Data Vault - htw-dresden.de · Agile DWH Modellierung mit Data Vault • OSP Dresden und die Ottogroup • Data Vault Theorie • DV im Einsatz für die