Hamburg, im August 2016

Transkript

1 Hamburg, im August 2016

2 AGILE DATA-VAULT- ENTWICKLUNG IM ONLINE- VERSANDHANDEL. Eine Fallstudie bei Otto

3 INHALT 1. Zahlen & Fakten: Vorhang auf für OTTO 2. Architektur: Das BRAIN 3. Data Vault I: Der Weg rein 4. Data Vault II: Der Weg raus 3

4 1. ZAHLEN UND FAKTEN Vorhang auf für OTTO 4

5 Zahlen & Fakten Firmensitz: Hamburg (Hauptsitz) Mitarbeiter: (standortunabhängig) Umsatz 2015/2016: 2,561 Milliarden Euro Der OTTO-Campus in Hamburg 5

6 Über 65 Jahre OTTO: Vom Schuhversand zum Pionier im E-Commerce 1949: Gründung 1950: Der erste, handgebundene OTTO-Katalog wird verschickt: Er präsentiert auf 14 Seiten 28 Paar Schuhe Ab 1960: Aufbau zum führenden Versandhändler für Mode und Einrichten Der Hauptkatalog wird zum Markenzeichen Ab 1995: Verstärkter Ausbau zum Multichannel-Händler otto.de geht online Heute: OTTO ist Treiber im Onlinehandel, das Unternehmen nutzt neueste Technologien und gestaltet den Markt aktiv mit 6

7 20 Jahre Erfahrung im E-Commerce 2000: Bestellung per Handy wird erstmals möglich über mobil.otto.de 1995: OTTO präsentiert sein Angebot erstmals im Internet unter Heute: Über 2,1 Millionen Artikelpositionen und rund Marken auf otto.de. Komfortables Shopping über alle Endgeräte. 7

8 Vom Katalogversender zum E-Commerce-Profi Schuhe Multimedia Bademoden Haushalt Herrenmode Küche Möbel Damenmode Heimtextilien Baumarkt Sport Spielzeug Wäsche Große Bandbreite an Produkten und Marken 8

9 Großer und treuer Kundenbestand 20 Millionen Bestellungen pro Jahr rund 6 Millionen aktive Kunden über 1 Million Visits pro Tag 9

10 Rund 90% Onlineanteil am Gesamtumsatz Unternehmenspräsentation

11 International erfolgreich Die Otto Group ist eine weltweit agierende Handels- und Dienstleistungsgruppe mit 123 wesentlichen Unternehmen in mehr als 20 Ländern. 11

12 Geschäftsfeld Multichannel-Einzelhandel der Otto Group Nordamerika Deutschland Russland Südamerika Europa Asien Mehrheitsbeteiligungen der Otto Group Minderheitsbeteiligungen der Otto Group 12

13 2. ARCHITEKTUR Das BRAIN 13

14 Positionierung der BI-Plattform in die Gesamt-IT Customer Touchpoints Closed Loop Onlineshop Real-time BI BI Middleware / EAI Interne Systeme NOA Mercado SEO Tool Externe Quellen Google Adwords Load Once BRIN (BI Plattform) 14

15 COMMON Zusammensetzung von BRAIN aus vertikalen Stacks und horizontalen Layern REAL-TIME STACK SPEED ANALYTIC STACK SERVING REPORTING STACK STANDARD PREPARATION MODEL SCORING BIG DATA STACK INFORM. STACK LOAD BASE HUB 1 CLASSIC STACK HUB LOAD BASE HUB n OLAP DASH- BOARDS AD HOC 15

16 Strukturierung über Daten Domänen 16

17 QUELLEN STAGING ( LOAD ) DATA VAULT ( BASE ) INFORMATION MARTS ( BUSINESS ) Strukturierung über Daten Domänen 17

18 Zentrales DM Tool

19 Zentrales DI Tool

20 3. DATA VAULT I Der Weg rein 20

21 Data Vault 2.0 Modell Das (relationale) Datenmodell steht im Vordergrund MD5 Hashes Hashing auf dem Weg nach Staging CSV 1 : 1 Staging Hard Rules Data Vault XML 21

22 Abweichungen vom Standard Keine explizite RecordSource Kein expliziter LDTS Abgedeckt über techn. Felder die auch den Talend Job identifizieren 22

23 Bewirtschaftung Data Vault CLASSIC STACK CSV XML Generisches Job parsen CSV Code Generator für Load Statements SQL Code Generator für DV spezifische Load Statements LOAD Layer (Staging Area) BASE Layer (Core Warehouse)

24 Metadaten Model enthält Struktur und Beladelogik der Modelle Data Definition Data Logistics Model Relationship Entity Entity Mapping Entity Key Relationship Attribute Entity Key Attribute Attribute Entity Attribute Mapping

25 Quelle nach Staging XML Preload Job CSV Load Job Xpath parsing SK erzeugen Staging CSV Load Job 25

26 Quelle nach Staging Im 2 Wochen Sprint bei neuer Quelle machbar Automatisierung recht einfach SKs auf den Weg in die Staging sehr vorteilhaft Generik auf den Weg in den DV nicht immer deterministisch / abbildbar Von Anfang an Geschäftsanforderung betrachten Datenbeschaffung ist essentiell XML ohne XSD schwer zu modellieren Großes Testdatenset ist wertvoll Schnittstelle selber definieren, wenn möglich Daten direkt von RDMS abziehen Früh auf den Weg bringen 26

27 Staging nach Base optional Staging gen. Job Mappings aus PD Data Vault 27

28 Physikalische Modellierung und Datenfluss 28

29 PowerDesigner als fundamentales Tool für die Modellierung SAP PowerDesigner DDL Metadaten Bewirtschaftung (ETL) 29

30 Daten Domäne BaseDelivery 30

31 Lessons Learned Im 2 Wochen Sprint bei neuem Modell machbar Scope gut definieren (agil) Klein anfangen, man kommt iterativ zur allumfänglichen Lösung Nicht zu viel (allein) vorausdenken, es ist kein Reengineering nötig Kenne deinen Fachbereich und das Geschäft Konkret nachfragen nicht versuchen selber zu interpretieren Timestamps: an fachliches Datum gehalten (letzte Änderung in Quelle) Probleme durch Nachläufer-Problematik KISS (vor allem die Beladelogik) 31

32 4. DATA VAULT II Der Weg raus 32

33 Base nach Business (End-) User greifen nur auf die Marts zu (über ded. Access-Schicht) Analytic User dürfen auf alle Ebenen Data Vault Soft Rules Common Mart Soft Rules Trafo Mart n Mart Bus. Rules Mart 1 33

34 Pains Nichts generisches / automatisiertes Kein BusinessVault Common Mart soll kompletter DV in 3NF persistiert sein Marts sollen auf Exasol, aber Architektur soll so bleiben 34

35 Lessons Learned Geschäftslogik bleibt trotzdem bestehen und komplex View-Schicht ohne BusinessVault (Stern aus DV direkt ) kann inperformant werden Kenne Dein DMBS Investitionen sind zu schützen, keine Grüne Wiese 35

36 VIELEN DANK FRAGEN? 36

37 Jan Sandte Information Architect IT-BI-CA Otto (GmbH & Co. KG) 37