Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Realtime Elastic – From Noise To Targeting Signals

Dd9d954997353b37b4c2684f478192d3?s=47 Elastic Co
November 10, 2015

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

Dd9d954997353b37b4c2684f478192d3?s=128

Elastic Co

November 10, 2015
Tweet

More Decks by Elastic Co

Other Decks in Technology

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