SPRINT aus Sicht der OSP-Teams
Werbung
Agile DWH Modellierung mit Data Vault Alexander Blech Matthias Wendt 2015-04-15 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 OSP Dresden und die Otto-Gruppe Unternehmensvorstellung • Der Otto-Konzern – – – • Ottogroup Solution Provider (OSP) Dresden – – – – • 123 Gesellschaften in 20 Ländern 12 Mrd. Umsatz im Geschäftsjahr 13/14 Fokus auf Multichannel-Einzelhandel, Finanzdienstleistungen und Service 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 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. 2007 durch Ronald Damhof • Bildung einer ersten User Group in den Niederlanden 2010 • Deutsche Initiativen (deutsche DVUG) ab 2012 Seite 4 Data Vault Überblick Inhalte von Data Vault • Vorschriften / Methoden zur Datenmodellierung – – – • Methoden zur Datenverarbeitung / Bewirtschaftung – – – • Konzeptionelle Modellierungssprache Entwurfsregeln und – muster Inkrementeller („agiler“) Entwicklungsansatz ETL-Templates Standardisierter Ladeprozess Mögliche Ansätze für ETL-Programm-Generatoren Architekturansätze – Trennung von Integrations-/Historisierungslogik und Geschäftslogik Seite 5 Data Vault Überblick Gründe für den Einsatz von Data Vault • Bewirtschaftungs-Performance – • Unterstützung agiler BI-Projekte – – • 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 – • Erweiterbare Datenmodelle ohne komplexe Abhängigkeiten Kurze Releasezyklen Reaktion bei Anpassung von Geschäftslogik – – • Komplexe Lade-Netze mit starker Kopplung Abwärtskompatibilität bei Kontexterweiterungen Neuprojekte – Aufbau einer tragfähigen Architektur Seite 6 Erläuterung der Kernentitäten Dekomposition – Beispiel Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation Seite 7 Erläuterung der Kernentitäten Dekomposition – Beispiel Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis <<LNK>> Beziehungen Fachschlüssel <<HUB>> Kontextinformation <<SAT>> Seite 8 Erläuterung der Kernentitäten Kernentitäten (Data Vault 1.0) • Hubs – • <<HUB>> Links – • „Stamm“ einer Entität , bestehend aus • Surrogate Key des DWH (SK) • Business Key der Datenquelle (BK) • Logging-Informationen (Quelle, Erstelldatum, Erstellprozess) 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 <<LNK>> Satelliten – Persistieren von Detaildaten (Kontextinformationen von Hubs oder Links) • SK des Hubs oder Links • Detailattribute • Historisierungs- und Loggingattribute <<SAT>> Seite 9 Erläuterung der Kernentitäten Kernentitäten (Abwandlungen und Sonderformen) • Bridges – • <<BRI>> Referenzen – • Vorberechnete „Sammlung“ von Beziehungen und Attributen • Enthalten weiterführende Geschäftslogik • Hauptnutzen: Performance-Optimierung 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 Data Vault im Einsatz Modellierungsbeispiel Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel Kontextinformation Seite 11 Data Vault im Einsatz Modellierungsbeispiel <<HUB>> H_WarehousePlant Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Beziehungen Fachschlüssel <<HUB>> H_QualityInspection Kontextinformation <<HUB>> H_Product Seite 12 Data Vault im Einsatz Modellierungsbeispiel <<HUB>> H_WarehousePlant Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis <<LNK>> L_QI_WP Beziehungen Fachschlüssel <<HUB>> H_QualityInspection Kontextinformation <<LNK>> L_QI_Product <<HUB>> H_Product Seite 13 Data Vault im Einsatz Modellierungsbeispiel <<HUB>> H_WarehousePlant Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis <<LNK>> L_QI_WP Beziehungen Fachschlüssel Kontextinformation <<HUB>> H_QualityInspection <<SAT>> S_QualityInspection <<HUB>> H_Product <<LNK>> L_QI_Product <<SAT>> S_QI_Product Seite 14 Data Vault im Einsatz Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“ <<HUB>> H_WarehousePlant Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Neuer_Kontext <<LNK>> L_QI_WP Beziehungen Fachschlüssel Kontextinformation <<HUB>> H_QualityInspection <<SAT>> S_QualityInspection <<HUB>> H_Product <<LNK>> L_QI_Product <<SAT>> S_QI_Product Seite 15 Data Vault im Einsatz Modellierungsbeispiel – Agile Erweiterung durch „vertikale Partitionierung“ <<HUB>> H_WarehousePlant Qualitätsprüfung PK Id FK Artikel_Id FK Lagerbetrieb_Id QM_Auftrags_Nummer AuftragsuebergabeDatum PruefungsStatus PruefungsDatum PruefungsErgebnis Neuer_Kontext <<LNK>> L_QI_WP <<SAT>> S_QualityInspection Neuer_Kontext <<HUB>> H_QualityInspection <<SAT>> S_QualityInspection <<HUB>> H_Product <<LNK>> L_QI_Product <<SAT>> S_QI_Product Seite 16 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 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 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 STAGE CORE Rel. MART / Cube Darstellungsebene Seite 19 Vorgehen bei Neuanforderungen Der Weg von der Anforderung zur Umsetzung • Kunde definiert Anforderungen an Mart oder Cube – • Prüfung auf Verfügbarkeit der Daten in Core und Stage – • • z.B. neue Kennzahlen, Dimensionsausprägungen, Hierarchien 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 Transformation MARTObjekt (neu) HUB Geschäftsobjekt SAT Objektkontext MARTObjekt (kompatibel) Transformation Seite 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 Eindrücke aus dem Betrieb Zusammenfassung • Entwicklung ist wirklich agiler geworden – • Schnelle Umsetzungszeiten – – • Konzentration auf Fachlichkeit Übersicht kann schnell verloren gehen – • Aufwendige Regressionstests entfallen Template-gestützte Entwicklung Einarbeitung in Technologie einfacher, dank Standardisierung – • Mitunter tägliche Roll-outs Vielzahl von Objekten Leistungsfähigkeit des BI-Frameworks ist wichtiger Bestandteil – – Änderungsdetektion Abhängigkeitssteuerung Seite 24 sagt Danke für Ihre Aufmerksamkeit.
