Die DeutschlandCard. Das Multipartnerprogramm für Deutschland

Transkript

1 Die DeutschlandCard Das Multipartnerprogramm für Deutschland 8. Oracle DWH/BI Konferenz "Effizienz in unseren BI/W-Systemen Erreichen wir noch unsere Anwender?" Effiziente All-Nearest-Neighbor Berechnung und weitere Herausforderungen auf Exadata Dr. Jens Oehlschlägel - Senior BI Architect 1

2 Unser Partnerschaftsmodell: Mit einer Karte bei mehr als POS Punkte sammeln und einlösen Durchdringung >12 Mio. Teilnehmer in >8 Mio. Familien Aktivität >1 Mio. Familien nutzen die Karte täglich bei Partnern Wachstum >2 Mio. neue Teilnehmer in den letzten 12 Monaten Frequenz ø 6,5-7 Einsätze pro Monat = 3. Platz im Portemonnaie >300 Prämien Kasse Spenden 2

3 DeutschlandCard ist Teil von Bertelsmann Wir setzen Oracle Exadata X2-2 zusammen mit SAS ein auf Tabellen mit bis zu 10 Milliarden Zeilen Content Services Der europäische Marktführer der Unterhaltungsbranche Die größte Publikumsverlagsgruppe der Welt Europas größtes Magazinhaus Einer der größten Medienund Kommunikationsdienstleister der Welt E L James Mo Yan 3

4 Dr. Jens Oehlschlägel Programmierung seit 1978 Dipl.-Psych. (Forsch.-Meth.) & Dr. hum. biol. (Med.-Stat.) 4 Jahre studienbegleitend einführende Statistik unterrichtet 3 Jahre Projektleiter/Statistiker (Pharma) 5 Jahre Datenmanager/Statistiker (Public Health) 2 Jahre Database Marketing Data Scientist bei McKinsey&Company seit 2011 Senior BI Architect bei der DeutschlandCard Exadata Sizing 7-stellige Kosteneinsparungen DWH-Analyse und ETL-Tuning Optimierung SAS-Exadata Integration Contributor zu R seit 2000 package bit: in-ram Bit-Filter package bit64: integer64 Datentyp package ff: Datenobjekte größer als RAM Algorithmen-Entwicklung Energie-effizientes Sortieren Stream-Sortieren, In-RAM Indizierung, Median-Berechnung Exascale Explorative Data Analysis 4

5 Agenda 1 Effiziente All-Nearest-Neighbor Berechnung 2 Parallelisierung: leider nicht in PL/SQL, nur in OWF 3 Blockade paralleler Ressourcen durch inaktive Abfragen 4 Reverse Engineering von SQL-Statements in OWB 5 Effiziente Median- und Perzentil-Berechnung 6 Hürden für die Verwendung von Oracle Advanced Analytics 5

6 1 Effiziente All-Nearest-Neighbor Berechnung 6

7 Einigen Millionen Teilnehmern aus einigen Tausend POS die jeweils nächste POS zuzuordnen, ist potentiell teuer Quadratische Skalierung O(T x P) = O(N²) 12 Mio Teilnehmer x POS = 120 Milliarden Verbindungen je Teilnehmer ~ 4 SQL Statements ~ 50 Millionen SQLs im täglichen ETL 7

8 Entscheidung gegen Oracle Spatial weil jeden Tag Full-Load erforderlich und Nutzung eines Spatial-Index für full-table scan fragwürdig Oracle s Spatial-Indices sind nicht nativ implementiert, sondern on-top-of-b-trees dauerhaft gesteigerte Lizenzkosten unangemessen für diese eine Aufgabe 8

9 Kosten in CPU Sekunden Tuning der Next-POS Berechung (X2-2 Quarterrack, 2 Instanzen, 12 echte Kerne pro Instanz) Kosten s Neue Lösung: Faktor 77 (einfacher Algorithmus) Techn. Limit: Faktor (Integrierter Algorithmus) Verworfen: Faktor 4 (SQL-Tuning) DOP s s 204 s 25 s 12 s DOP s DOP 6 34 s (1 Core) (1 Core) ANN / 2 50 Mio. SQL Kacheln SQL Sorted PL/SQL Sorted C Optimiert C 9

10 Wenn Teilnehmer und POS sortiert sind, schränkt die nächste POS des vorherigen Teilnehmers den Suchraum des nachfolgenden ein vorheriger Teilnehmer nachfolgender Teilnehmer vorherige POS und nachfolgende Start-POS Teilnehmer sortiert POS sortiert 10

11 Es gibt drei gute Gründe, warum das schnell ist Ab und zu sind die beiden Teilnehmer auch horizontal nahe und schränken den maximalen Suchraum ein Jede gefundene nähere POS schränkt den tatsächlichen Suchraum dynamisch weiter ein Je mehr Teilnehmer und POS, desto kleiner die Suchräume, deshalb nicht O(T x P) ~ O(N²) 11

12 2 Parallelisierung: leider nicht in PL/SQL, nur in OWF 12

13 3 Blockade paralleler Ressourcen durch inaktive Abfragen 13

14 Inaktive Preview-Queries aus SAS blockieren unnötigerweise einen Großteil der Exadata-Ressourcen richtige und wichtige Queries landen in der Warteschlange 2 Queries stehen in der Warteschlange weil 5 User 77 Prozesse mit Ihrer SAS-Preview blockieren 14

15 Da Fehlverhalten einer Vielzahl von Clients schwer zu verhindern ist, wäre eine serverseitige Lösung von Oracle wünschenswert Zu viele Clients! Server-Lösung? inaktive Sessions identifizieren schlafende Sessions wieder aufwecken inaktive Sessions schlafen legen 15

16 4 Reverse Engineering von SQL-Statements in OWB 16

17 Oracle könnte seinen SQL-Parser für Reverse Engineering nutzen Erprobte SQL-Statements in OWB einzupflegen SQL Ausgearbeiteter Prototyp 222 Zeilen SQL-Code Laufzeit: 17 sek ist teuer, OWB 1 PT zum Einpflegen in OWB fehleranfällig und kostet Performance Code Review OWB exportiert 1100 Zeilen SQL-Code der mehrere Fehler beinhaltet und 150% Laufzeit kostet: 26 sek 17

18 5 Effiziente Median- und Perzentil-Berechnung 18

19 Rätsel: Was ist das kürzeste SELECT Statement mit dem man eine Exadata über längere Zeit beschäftigen kann obwohl keine Daten von Platte gebraucht werden obwohl sich das Ergebnis leicht im Kopf ausrechnen lässt ohne user defined functions zu benutzen SELECT MEDIAN(ROWNUM) FROM t; Ergebnis: halbe Zahl der Zeilen 19

20 Die Performance der X2-2 hängt extrem von der angefragten Statistik ab -- table hat 1 Spalte und 1 Milliarde Zeilen SELECT MEDIAN(ROWNUM) FROM table; min DOP 16 SELECT AVG(column) FROM table; sek DOP 16 SELECT MEDIAN(column) FROM table; min DOP 16 (100x) -- in SAS lesend von Oracle; min 1 Connections -- in SAS lesend von Oracle; -- 6 min 3 Connections 20

21 Zumindest Median und Percentilberechnung sollte auf einer DWH-Appliance deutlich schneller sein Zeiten single-threaded 1e9 Elemente in C (R) Aggregation AVG O(N) 1 sek ( 240x) MEDIAN O(N*log(N)) 3 min mittels Sortierung ( 128x) MEDIAN O(N) 1 min mittels Selection ( 384x) APPROXMEDIAN O(N) 3 sek Exascale EDA ( 7680x) Stream-processing CUMSUM O(N) 2 sek CUMMEDIAN O(N²) 500 Jahre extrapoliert mit Selection CUMMEDIAN O(N*log(N)) Google s Interviewfrage: 2 heaps CUMMEDIAN O(N*log(N)) 3 min mittels stream greensort 21

22 6 Hürden für die Verwendung von Oracle Advanced Analytics 22

23 Es bestehen signifikante Hürden für die Verwendung von R, hier könnte Oracle mit geringem Aufwand Verbesserungen erzielen Problem Fehlender zuverlässiger performanter Zugang von R nach Oracle die Ineffizienz von R macht die Verwendung in Oracle extrem teuer CPU Ineffizienz ( C : PL/SQL : R = 1 : 8 : 50 ) RAM Ineffizienz ( multiple Kopien der Daten in-ram ) Strategische-Risiken durch parasitäre Haltung gegenüber der R-Community mangelnde Unterstützung Lizenzprozesse Lizenzänderungen Abwandern von contributors Vorschlag ROracle Interface mit Binaries pflegen ROracle besser aktualisieren, z.b. 64bit integers unterstützen Keine Lizenzkosten für R, statt CPU- Sekunde nochmals 10% teurer zu machen Mehr RAM in der Exadata (X3-2) Kooperation mit der R-Community und giving-back nützliche Beiträge zum Package- Repository (wie z.b. Revolution Analytics) finanzielle und/oder personelle Unterstützung des kleinen Core- Teams finanzielle und/oder personelle Unterstützung freier IDEs (Eclipse, RStudio) 23

24 Die Big-Data Welle rollt aber wo lohnen sich große Datenmengen wirklich, in-database? Ensembleverfahren Prädiktiv: random forests Segmentierung: truecluster 24

25 Was kommt nach der Big-Data Welle? Kandidat 1: Privacy & Security getrieben von Cloud-Computing z.b. CryptDB: Processing Queries on an Encrypted Database Computer Science and AI Lab, MIT z.b. Privacy-Preserving Data Mining, Models and Algorithms. Charu C. Aggarwal, IBM T. J. Watson Research Center Kandidat 2: Energy Efficiency getrieben von Exascale-Computing z.b. An Effective Coreset Compression Algorithm for Large Scale Sensor Networks Computer Science and AI Lab, MIT z.b. MS Excel Power Pivot MS xvelocity (formerly Vertipaq) z.b. Exascale Explorative Data Analysis using in-ram Lossy Compression, greensort 25

26 Vielen Dank! 26

27 2 Parallelisierung: leider nicht in PL/SQL, nur in OWF 27

28 4-fach Parallelisierung würde idealerweise so erfolgen aber PL/SQL unterstützt keine Concurrency 1. POS sortieren 2. Teilnehmer parallel sortieren 3. Sortierte Teilnehmer in 4 Gruppen aufteilen 4. NN in 4 Gruppen parallel CPU 1 CPU 2 CPU 3 CPU 4 28

29 Seit Jahren werden Programmiersprachen für Concurrency erweitert Quelle: Herb Sutter 2005, The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software 29

30 Alle populären Sprachen unterstützen 2012 Concurrency Quelle: 30

31 Auch R unterstützt inzwischen Concurrency Quelle: 31

32 PL/SQL unterstützt keine Concurrency und fällt zurück Quelle: 32

33 Ausweg: Parallelisierung mit OWF (Hash-Partitioning) Vorgehen Jeder Job sortiert POS Jeder Job filtert ¼ Teilnehmer und sortiert Jeder Job findet NN Nachteile 4-facher RAM und CPU-Bedarf 4 statt 1 Full-Table-Scan ¼ Dichte der Teilnehmer CPU 1 CPU 2 CPU 3 CPU 4 33

34 Alternativ: Parallelisierung mit OWF (Range-Partitioning) Vorgehen Jeder Job sortiert POS Bestimmung Quartile Nord-Süd Jeder Job filtert ¼ Teilnehmer und sortiert Jeder Job findet NN parallel Nachteil Zusätzlich Scan und Sortierung Vorteil Vermeidet ¼ Dichte der Teilnehmer CPU 1 CPU 2 CPU 3 CPU 4 34

35 Ungefähre Perzentile aus Exascale Explorative Data Analysis würden zum Beispiel genügen, für eine Parallelisierung mit Range-Partitioning Vorgehen Bestimmung ungefährer Quartile Nord-Süd Jeder Job sortiert POS Jeder Job filtert ¼ Teilnehmer und sortiert Jeder Job findet NN parallel Vorteil Vermeidet zusätzliche Sortierung zur Quartilbestimmmung CPU 1 CPU 2 CPU 3 CPU 4 35

36 6 Hürden für die Verwendung von Oracle Advanced Analytics 36

37 Qualität: Statistische Modelle auf großen Daten lohnen sich vor allem bei rechenintensiven Verfahren zur Modellierung von Wechselwirkungen z.b. Median ist schon bei kleinen Stichproben robust schätzbar z.b. additive lineare Modelle wie Lineare Regression wie Logistische Regression sind mit moderaten Stichprobengrößen schätzbar auch große Datenmengen lassen sich wenn auch langsamer mit freier opensource Software verarbeiten (z.b. R ff biglm) z.b. Bagging non-additiver Modelle mit komplexen Wechselwirkungen wie Random Forests zur Prädiktion wie Truecluster zur Segmentierung profitiert von möglichst hoher Parallelität profitiert von möglichst großen Stichproben... deren Export aus der DB teuer ist 37

38 Kosten: Der Zugriff auf die kompletten Big-Data lohnt sich nur in bestimmten Phasen eines analytischen Projekts Erste explorative Analysen und prototypische Modellierungen Weitergehende explorative Analysen, Ausreisseranalyse und -bereinigung sind mit Stichproben schätzbar können mittels Exascale Exascale Explorative Data Analysis schneller und weitgehend ohne wiederholte Zugriffe auf den vollen Datenbestand erledigt werden Für 90% Projektvolumen können Appliance- Kosten umgangen werden Finale Modellschätzung, Modellvalidierung, Modellkalibrierung erfordern Zugriff auf den vollen Datenbestand und profitieren von hochparallelen Systemen 38

39 Exascale Explorative Data Analysis beschleunigt bestimmte Abfragen um Größenordnungen bei gleichzeitig minimierten Energiekosten Server Seltene Zugriffe auf Daten auf teurer paralleler Hardware HD/SSD Client Häufige billige schnelle Zugriffe auf lossy compressed Daten in-ram RAM DB-Server 10% Datenhaltung und finaler Modellfit BI-Client 90% Analyseprojekt Exploration und Cleaning lokal in-ram Exadata-Cell-Server Datenhaltung raw & lossy compressed Exadata-DB-Server EEDA-Engine Beliebiger Client EEDA-Anfragen 39

40 Die Logik von Free Open-Source Communities wie R basiert auf Kooperation die GPL Lizenz versucht das zu ermutigen nehmen geben 40

41 Einige Firmen interpretieren FOSS eher kooperativ Packages geben Profite nehmen 41

42 Einige DB-Vendors interpretieren FOSS eher parasitär Patente & Anwälte Profite nehmen 42

43 Für Kunden von Oracle Advanced Analytics birgt es Risiken dass Oracle und andere DB-Player ob juristisch anfechtbar oder nicht die Intention der GPL verletzen. Was wenn die R Foundation sich doch zu einer Klage entschließt? wenn das Core-Team die Lizenz ändert? Autoren von key-packages die Lizenzen ändern? (bit64, ggplot, XML, nlme, lme4, ) die Free Software Foundation die wachsende Popularität von R nutzt um einen Musterprozess um die GPL zu führen? Sie ein Problem haben bei dessen Lösung Sie auf die Mithilfe der Community angewiesen sind, diese Ihnen als kommerziellem Nutzer aber nicht helfen möchte? frustrierte Key-Contributors von R zur neuen Statistiksprache Julia des MIT abwandern? 43

44 Es besteht ein Risiko, dass die Community zerbricht oder abwandert die zwei Gründer von R sind infolge Kommerzialisierung zerstritten Ross Ihaka Robert Gentleman frustrierter Rückzug im Board bei Revolution Analytics 44

45 Dr. Jens Oehlschlägel DeutschlandCard GmbH I Ein Unternehmen von arvato Bertelsmann Neumarkter Strasse 22 I D München Fon +49 (0) & +49 (0) jens.oehlschlaegel@bertelsmann.de 45