Building the perfect HolidaySearch for HolidayCheck with Elasticsearch
3 gefällt mir1,554 aufrufe
Das Dokument beschreibt die Implementierung und Optimierung einer Suchanwendung bei Holidaycheck unter Verwendung von Elasticsearch, einschließlich der technischen Architektur und der Herausforderungen bei der Datenverarbeitung. Es betont die Bedeutung von kontinuierlichen Tests und der Aktualisierung von Daten zur Sicherstellung der Suchqualität und Leistungsfähigkeit. Zudem werden spezifische Fallstudien zu Problemlösungen und die Integration von Genauigkeitstests in den Entwicklungsprozess behandelt.
Building the perfect HolidaySearch for HolidayCheck with Elasticsearch
- 1. Building the perfect HolidaySearch for HolidayCheck with Elasticsearch Andreas Neumann : Techlead Search
- 3. Holidaycheck In Einem Satz ▪Die HolidayCheck AG betreibt das größte deutschsprachige Meinungsportal für Reise und Urlaub im Internet. 3
- 6. Elasticsearch Bei Holidaycheck ▪Suche ▪Datenanalyse : ES, Kibana ▪Data store: Microservices ▪Zentralisiertes Logging mit ES, Kibana und Logstash (ELK) 6
- 7. kurz ▪Schweizer Taschenmesser ▪gutes Werkzeug für viele Entwickler-Probleme ▪breite Kenntnis im Unternehmen ▪verschiedene Versionen nebeneinander zu betreiben ist problematisch ▪möglichst früh und kontinuierlich updaten 7 Learnings
- 8. Setup, ES Cluster Kurz erwähnt
- 9. Unser Setup - Search Cluster ▪ CPU: 4 cores ▪ RAM: 16 gigs ▪ 8 gigs of heap ▪ 5 nodes ▪ 3 indices ▪ 2 400 000 documents ▪ 66 GB of data 9
- 14. POIs - Points of Interest ▪Lokale ▪Feste ▪Sehenswürdigkeiten 14
- 15. Software / Search - Service Search-Api
- 16. Search-API ▪ Endpoints für Produkte ▪ Mobile ▪iOS App ▪Android App ▪Web-Site ▪ API um Suchanfragen an Elasticsearch zu senden ▪ Query Preprocessing 16
- 17. Frontend: Embedded Search - Mobile Web App
- 18. Vorgeschichte: Stand Januar 2015 ▪ Team/ Entwickler haben Unternehmen verlassen ▪ lückenhafte Tests ▪ veraltete Dokumentation ▪ alte Elasticsearch Version (0.90) ▪ hardcoded solutions (hurghada) ▪ Deployment-Alptraum ▪ Performance-Probleme (Ø 200 - 400 ms) ▪ gewagte Architektur 18
- 19. Entscheidung: Neuimplementierung ▪ Aufgabe: Neuentwicklung und Austausch der Suchapplikation ▪ Anforderung: ▪Testbarkeit/Nachvollziehbarkeit: Softwarequalität ▪Testbarkeit/Nachvollziehbarkeit: Suchqualität <= selbst gesetzt ▪generelle Lösungsansätze (z.B. Approximative Suche) ▪Geschwindigkeit 19
- 20. Search API: Juni 2015 ▪ Testsuite mit UnitTests / Integration Tests ▪ qualitative (Feature Tests) und Quantitative Tests (Accuracy Tests),Blackbox Tests / Regression Tests: ▪170 Feature-Tests ▪4000+ Accuracy-Tests ▪ Deployment: ▪~ 5 min ▪~ 1 -3 Releases pro Woche 20
- 21. Production Request times: (3 queries per request) 21
- 23. Featureentwicklung : Regeln Search HC ▪ stets auf harten Daten ▪Query Logs ▪User Tracking ▪… ▪ ständige Analysen ▪qualitativ ▪quantitativ 23
- 24. 1.) Paris - textuelle Gleichheit ▪ Query: Paris ▪ Erwartung: ▪Paris in Frankreich ▪Stadt der Liebe ▪ Aber: ▪Paris in USA, Texas ▪??? 24
- 25. Ein Typisches Problem : “Textuelle Gleichheit” ▪ Erklärung: textuelle Gleichheit => gleicher Score ▪ Lösungsansatz: rescoring ▪Idee: Destinationen mit vielen Hotels sind potentiell gute Reiseziele ▪Besonderheit: Rankingveränderungen im vorgegebenen Window 25 naiv: max_score: 9.351926 hits: _id: “3dd…” _score: 9.351926 fields: name: “Paris” hotels: 10 place:”Texas”, "USA" _id: “1f0…” _score: 9.351926 fields: name: ”Paris" hotels:2344 place:"Großraum Paris”, "Frankreich"
- 27. 2.) “San “- Prefix-Suche mit Mehrwortlexemen ▪ Query: “San “ ▪ Feature: Query Suggest Prefix Search ▪ Problem: Whitespace als erlaubtes Zeichen für Mehrwortlexeme ▪ Lösungsansatz: Phrasensuche + Term Suche 27
- 28. 3.) Optimum: Suchstringlänge / Token-Count ▪ Anforderung: Betriebssicherheit ohne Sucherlebnis einzuschränken (Website copy) ▪ Lösung: ▪typische Termlängen / Tokenverteilungen aus Daten bestimmen 28
- 29. zu lange Suchanfrage wird zurückgewiesen http "http://m.holidaycheck.de/svc/search-api/buckets/x x x x x x x x x x x x x x x x x x x x" HTTP/1.1 400 Bad Request Connection: keep-alive Content-Length: 62 Content-Type: application/json; charset=UTF-8 Date: Thu, 22 Oct 2015 12:26:58 GMT X-Trace-Token: fe71180598d3-15723 { "error": "ValidationRejection(search term is too long,None)." }
- 30. 4.) Hotelketten + Ort ▪ Query: ibis münchen ▪ Anforderung: “<Hotellkette> <Ort>” führt zu einem Suchergebnis nur mit Hotels einer bestimmten Kette ▪ Lösung: Query Preprocessing (Keyword Spotting) 30
- 31. Learnings ▪ Features in der Suche beeinflussen sich gegenseitig ▪ Gleiches Verhalten in Feature A kann nach Release von Feature B nicht automatisch angenommen werden ▪ Wie kann man den Funktionalitätsverlust eines Features automatisiert bemerken ? ▪ Wie kann man die Funktionalität eines Features “schützen” ? 31 Fragen
- 33. Was bringen Accuracy Tests ? ▪ Zusätzliche Sicherheit: ▪Deploy nothing that will decrease Quality ▪ Änderungen auf verschiedenen Ebenen fallen frühzeitig auf ▪ Querbeziehung/ Einflüsse von Features auf andere Features frühzeitig erkennen 33
- 34. Was sind Accuracy Tests ? ▪ ähnlich zu Regressionstests ▪ nicht binär, prozentual ▪ quantitative Tests: Testen einer große Datenmenge vs. ein Beispiel ▪ funktionale / inhaltliche Tests ▪ selbst gesetzte SLAs für die Suchergebnisse 34
- 35. Voraussetzungen, Grundlagen ▪ die wichtigsten Daten abdecken ▪ “wichtig” definiert durch harte Kriterien (User Interactions) ▪ Quellen: Suche (innen), Google Analytics (außen) ▪ (ständiger Feedbackloop) 35
- 36. Beispiel: User Interaction: Ergebnis Auswählen {term} => {id/type} : {count} münchen => 5…5b/dest : 4500
- 37. Daten - Beispiel 72632 mallorca/destination 07f5f656-4acc-3230-b7dd-aec3c13af37c 5136 mallorca/destination bc3304c5-a7f0-3cc1-8f3b-7782081d6bf8 691 mallorca/destination 6024bf89-e3bb-374c-8e80-5f527ecc958f
- 38. Definition Eines Accuracy Tests ▪ Für alle Suchen nach Destination sollen bei den am häufigsten gewählten Ergebnissen mindestens 90% einen Hit im View- Window 1-3 erscheinen ▪ X = Queries mit höchster Frequenz ▪ Y = Destination wurden gesucht ▪ Z = View Window 3 ▪ Goal 90% 38
- 39. Debug-Tooling
- 40. Einige Mögliche Testszenarien ▪ Auftrittshäufigkeit ▪ Umsatz (€€€) ▪ Frequenz / €€€ ▪ Stabilität beim Tippen ▪ Beobachtete Usecases ▪ Gruppiert nach Typ (Hotel, Ort …) ▪ Kombinationen aus oben genanntem 40
- 41. Visualisierung mehrere Testläufe ▪ Testergebnisse werden nach ES geschrieben ▪ Visualisierung mit Kibana ▪ Trends und Veränderungen sichtbar machen ▪ für Stakeholder/ PO 41
- 42. Integration in den Development Prozess Accuracy Tests
- 43. Trigger / Anwendung ▪ lokale Entwicklung: Dev Done nur wenn alle Tests “grün” sind ▪Zielzustand im Accuracy Test definieren ▪run and code until green ▪ Update der ES-Indices: Deckt Änderungen in den Daten / Umbenennungen auf (CI) ▪ Teil des Release-Prozesses: Release => test container on CI with Production Data => deployment nur wenn Accuracy Tests erfüllt (CI) 43
- 44. Learnings ▪ Daten aktualisieren ▪ Datenerstellung hat initiale Kosten ▪ Integration in den Development Prozess notwendig ▪ Tests haben meistens Recht : unerwartete Fehler werden aufgedeckt ▪ Tooling / Unterstützung der Entwickler notwendig um Akzeptanz zu erreichen ▪ Visualisierung hilfreich ▪ Gutes Medium um Requirements mit Stakeholdern abzustimmen ▪ => Speedup (PO kommt manchmal mit Stories nicht nach :) 44
- 45. Fazit Takeaways
- 46. Fazit ▪ Elasticsearch ist das perfekte Tool um eine Suchanwendung zu bauen ▪ Elasticsearch ist auch das perfekte Tool um Tools zu bauen, die bei der Entwicklung und Optimierung einer Suchanwendung helfen. ▪ πάντα ῥεῖ ▪ Accuracy Tests and Feature Test: ▪wer nicht checkt, sucht dumm 46
- 47. get in contact Mail : andreas.neumann@holidaycheck.com Twitter handle: @andreas_neumann
- 48. Danke für die Aufmerksamkeit :) - Schon einen Urlaub gebucht ?