The Realtime Elastic – From Noise To Targeting Signals

Die Otto Gruppe betreibt eine zentrale Business Intelligence Plattform, die helfen soll, Kundenwünsche besser zu verstehen, schnell auf die Marktnachfrage zu reagieren und Echtzeit-Analysen zu tätigen. Dafür wird der Elastic Technologie Stack eingesetzt, wobei bis zu 5000 Dokumente pro Sekunde prozessiert werden.

Jan-Hendrik Lendholt | Elastic{ON}Tour Munich | November 10, 2015

Transcript

1. THE REALTIME ELASTIC
 From Noise To Targeting Signals 09.11.2015 1 München, 10. November 2015
2. INHALT 1. Kurzvorstellung 2. Die OTTO BI-Plattform 3. Elasticsearch im Usecase 4. Clusterstruktur- und Sizing 5. Lessons Learned 6. Fragerunde 09.11.2015 2
3. 3 1. KURZVORSTELLUNG 09.11.2015
4. 4 „GETTING INFORMATION OFF THE INTERNET IS LIKE TAKING A DRINK FROM A FIREHOSE “
 MITCHELL KAPOR
 09.11.2015
5. Persönliche Vorstellung Jan-Hendrik Lendholt, 33 Jahre Software-Architekt bei OTTO GmbH & Co. KG (seit 1. September 2014) + Jan-Hendrik.Lendholt@ottogroup.com ὸ +49 40 6461 - 4538 09.11.2015 5
6. Das Unternehmen OTTO • Besteht aus 123 Konzerngesellschaften • Ca. 54.000 Mitarbeiter • ~ 12 Mrd. Euro Umsatz • Kernmarke OTTO Versand • Weit gestreute Geschäftsmodelle • Starker Effort im Bereich Digitalisierung • Starker Effort im Bereich E-Commerce 09.11.2015 6 Der Konzern • 1.900 Mitarbeiter im Service tätig • ∅ 10s Wartezeit, 24/7 kompetente Berater • 2,1 Mio. Artikel auf otto.de, 3,8 Mio. Kataloge / Jahr à 1.100 Seiten Interessantes
7. 7 2. DIE OTTO BI- PLATTFORM 09.11.2015 “Data really powers everything that we do” Jeff Weiner
8. OTTO baut die BRAIN-Platform 09.11.2015 8 Otto entwickelt eine zentrale BI-Plattform: • Konzernfirmenübergreifend • Mandantenfähig • Entspricht einer angepassten Lambda-Architektur • Classic Data, Big Data, Fast Data Ziel ist es: • Kunden und deren Bedürfnisse besser zu verstehen • Schneller auf neue Anforderungen (am Markt) reagieren zu können • Heterogene Daten aus verschiedenen Konzernbereichen zu konsolidieren • Echtzeit-Analysen durchführen zu können
9. Plattform-Architektur 09.11.2015 9 CLASSIC STACK REAL-TIME STACK BIG DATA STACK ANALYTIC STACK REPORTING STACK AD HOC LOAD BASE BUSINESS DASHBOARDS OLAP LOAD BASE BUSINESS SPEED
 SERVING
 PREPARATION MODEL SCORE STANDARD RT Event Processing (CEP) RT DataStores
10. 10 3. ELASTICSEARCH IM USECASE 09.11.2015
11. R2D2 – Retargeting Data Driven (1) 09.11.2015 11
12. R2D2 – Retargeting Data Driven (2) 09.11.2015 12 AdServer / DMP Click-Event Storage Wait Transfer Retarget ~1 SEK. ~5 Min. 1x pro Tag 24h-36h < 20s
13. Speed Layer im Fokus 09.11.2015 13 Clickstream Webshop Sonstige Events Business Reporting AdServer • Ca. 1500 – 5000 Events pro Sekunde • Ein Logging-Event pro Prozessschritt ➢ Bis zu 30k Logging-Events / Sek. Elasticsearch
14. Scoring im Detail 09.11.2015 14 Elasticsearch { "query": { "knn": { "custScore": { "sessionId": "abc123" } } } } Modell [1, …, 10] Event1 Event2 Event3 Event4 Event5 Event6 { "query": { "term": { "sessionId": "abc123" } } }
15. R2D2 – Retargeting Data Driven (2) 09.11.2015 15 • R2D2 stellt Informationen zum Retargeting binnen weniger Sekunden bereit, idR < 50ms • Echtzeit-Scoring durch statistisches Modell • Modellbildung auf Hadoop, Scoring auf Elasticsearch (∅ <5 ms) • Zwischenspeicherung der User-Sessions in Elasticsearch • Datenanreicherung aus Logfiles via Logstash • Bereitstellung der Nutzerdaten zum aktuellen Scoring in Echtzeit im „Stream Processing“ Prozess unter konstanten zeitlichen Bedingungen • Persistierung der (Zwischen-)Ergebnisse in Elasticsearch • AdHoc-Abfragen durch Analysten
16. 16 4. CLUSTERSTRUKTUR- UND SIZING 09.11.2015
17. Cluster Layout (1) 09.11.2015 17 Host (VM) Docker Container Elasticsearch (Process) Index-Benennung: • raas_{usecase}_20151110_1400 • raas_{usecase}_20151110_1300 • raas_{usecase}_20151110_1200 • raas_{usecase}_20151110_1100
18. Cluster Layout (2) 09.11.2015 18 Master Nodes Data Nodes Client Nodes Tribe
19. Cluster-Sizing 09.11.2015 19 Master-Nodes (3x): • 4-Core-CPU @ 2,4 GHz • 16 GB RAM • 1 TB Storage Client-Nodes (2x): • 6-Core-CPU @ 2,4 GHz • 32 GB RAM • 1 TB Storage Data-Nodes (29x): • 8-Core-CPU @ 2,4 GHz • 64 GB RAM • 6 TB Storage
20. Index Setup 09.11.2015 20 • Ein Index pro Usecase und Stunde • Benennung nach dem Schema raas_{usecase}_{yyyymmdd_hh} • TTL pro Dokument = 72h ➢ Max. 72 Indizes pro Usecase im Cluster • Pro Index 9 Shards • Pro Shard 2 Replica • Index Templates • Flush Period ca. alle 30 Sekunden
21. Cluster- und Index-Statistiken (WiP) 09.11.2015 21 • Cluster • Indices: 139 • Shards: 983 (~ 33 Shards / Node) • Dokumente: ~220.000.000 Dokumente • Size Primary Shards: ~3.2 TB • Index: • Peak: ca. 1.800 Dokumente / Sekunde, ∅ ca. 250 Dokumente / Sekunde • ~ 16 KB / Dokument • Pro Index ca. 900.000 Dokumente und 14 GB Daten • ∅ 7ms pro Request, max. 10ms Sekunden • Ca. 550 Suchanfragen / Sekunde, Peak 2.400
22. 22 5. LESSONS LEARNED 09.11.2015
23. Lessons learned 09.11.2015 23 • Leichter Start, lehrreiche Skalierung • Trial & Error • Starke DSL, auch für „SQL-Junkies“ gute Lernkurve • Konzept Index vs. Datenbank eröffnet neue Möglichkeiten für Analysten • Performance: Zeitlich konstant bei gleichbleibender Komplexität der Abfragen • Plugin-System sehr ausgereift • Eigenentwicklungen für bestimmte Abfragetypen gehen leicht von der Hand • Elasticsearch in einer Multihost-Docker-Umgebung nicht ganz unkompliziert • Weaveworks to rescue • Docker 1.9 bringt eigene Networking-Komponenten • I/O bottleneck auf Spinning Disks • Flush vs. Realtime-Search • Shard-Allocation im Betrieb
24. 24 5. FRAGERUNDE 09.11.2015