Peter Dikant mgm technology partners GmbH Echtzeitsuche mit Hadoop und Solr
ECHTZEITSUCHE MIT HADOOP UND SOLR PETER DIKANT MGM TECHNOLOGY PARTNERS GMBH
WHOAMI peter.dikant@mgm-tp.com Java Entwickler seit 1996 PL bei mgm technology partners GmbH Schwerpunkt Big Data seit 2009
WAS IST HADOOP?
Open Source Implementierung zweier Whitepaper von Google: The Google File System MapReduce: Simplified Data Processing on Large Clusters
2 HAUPTKOMPONENTEN Hadoop Distributed File System - Ein skaliebares, fehlertolerantes und verteiltes Dateisystem MapReduce - Eine skalierbare, fehlertolerante und verteilte Ausführungsumgebung Zahlreiche Erweiterungen: Hbase, Hive, Pig,...
Es ist deutlich effizienter Programme zu den Daten zu bringen, als Daten zu den Programmen.
HADOOP IM EINSATZ Hadoop wird mittlerweile als ernsthafte Technologie akzeptiert.
2011 waren allein mit der Cloudera Hadoop Distribution 22 Cluster mit jeweils mindestens 1 PB Daten in Betrieb. Omer Trajman (Cloudera)
Durchschnittliche Clustergröße 2010: 60 Knoten Durchschnittliche Clustergröße 2011: 200 Knoten
Insgesamt 42000 Server Bis zu 4000 Server pro Cluster Gesamtkapazität 400 PB
Mehr als 100 Hadoop Cluster Größter Cluster hat über 100 PB Wachstum > 100 TB pro Tag
VORTEILE VON HADOOP Unbegrenzte Kapazität Sehr hoher Datendurchsatz Fehlertoleranz / Ausfallsicherheit Läuft auf Standardhardware
ABER HADOOP IST NICHT ECHTZEITFÄHIG
WAS IST SOLR? Solr ist ein standalone Such-Server mit REST-API basierend auf Lucene.
Indizierung per Volltext und Schema JSON und XML als Datenformat REST Schnittstelle per HTTP Basiert auf etablierter Lucene-Engine
KOMBINATION VON HADOOP UND SOLR
HADOOP CLUSTER
HADOOP CLUSTER MIT SOLR
HDFS ZUR DATENABLAGE Welches Datenformat ist geeignet? Wie Daten organisieren?
MÖGLICHE DATENFORMATE Strukturiert / Unstrukturiert Container: Hadoop Sequence-/Mapfiles, Binary, Text Einschränkungen des HDFS beachten!
STRUKTURIERTE DATENFORMATE CSV, JSON, XML, YAML Protocol Buffers, Thrift, Avro...
UNSTRUKTURIERTE DATENFORMATE Logfiles, PDF, HTML, Text,...
DATENORGANISATION Ein Dokument muss eindeutig adressiert werden können HDFS Blockgröße optimal nutzen Verwandte Daten möglichst nah beieinander speichern /logfiles/appname/2012/11/06/0001#123456 Beispiel: Pfad zur Datei 0001 und Index innerhalb der Datei
ALTERNATIVE HBASE
HBASE Gut geeignet zu Speicherung strukturierter Daten Benötigt allerdings viel Hauptspeicher auf Datanodes
INDIZIERUNG IN SOLR Online während Datenannahme oder Offline
ONLINE-INDIZIERUNG Indizierung in Echtzeit Daten werden sofort gefunden Indizierung per REST-Request
OFFLINE-INDIZIERUNG Nutzung von MapReduce zur Indizierung Parallelisierung der Indizierung Sehr hoher Indizierungsdurchsatz Indizierung per Massendatenimport Lastet den Cluster stark aus
KOMBINATION BEIDER TECHNIKEN Bietet vorteile beider Ansätze Verhindert Diskrepanz zwischen Index und Datenbestand
PROBLEME DER SOLR- INTEGRATION
PROBLEM: SPEICHERBEDARF Solr benötigt viel Hauptspeicher Speicherbedarf abhängig von Dokumentstruktur
OPTIMIERUNG DES INDIZIERUNGSSCHEMAS DURCH... Speicherung von Feldern ohne diese zu indizieren Indizierung von Feldern ohne diese zu speichern Pfad im HDFS als Primärschlüssel kurz halten Reduzierung der Genauigkeit von Zeitstempeln
AUFTEILUNG IN TEILINDIZES Zweitnutzung der Datanodes des Hadoop Clusters Verteilung der Last Kapazität skaliert mit Datanodes Ausfallsicherheit
PROBLEM: MANAGEMENT DER SOLR-INSTANZEN Ausfälle erkennen Gleichmäßige Auslastung sicherstellen Indizes persistieren
HADOOP FUNKTIONALITÄT NUTZEN Cluster-Health mittels Hadoop ermitteln Über Hadoop-Server iterieren und Solr-Daten ermitteln
SOLR INFORMATIONEN Wie viele Indizes sind aktiv? Wie viele Dokumente indiziert? Sind indizes optimiert?
AKTIONEN ABLEITEN Indizes sichern Indizes einspielen Cluster ausbalancieren
BEISPIEL: SERVERAUSFALL 1. Hadop erkennt Ausfall 2. Ausgefallene Indizes werden identifiziert 3. Auswahl von Ersatzservern 4. Einspielen ausgefallener Indizes auf Ersatzservern
PROBLEM: SUCHANFRAGEN PARALLELISIEREN Suchanfragen müssen auf alle Solr Instanzen verteilt werden Konsoldierung der Treffer
VERTEILUNG DER SUCHANFRAGE Timeout-Handling notwendig Wenn möglich Minimierung der Anfragen durch intelligentes Sharding
TREFFERKONSOLIDIERUNG Sortierung der Treffer Treffermenge muss limitiert werden, um Speicherprobleme zu vermeiden
PROBLEM: AUSLESEN DER TREFFER IM HDFS Zugriff auf verteilte Daten im HDFS sehr langsam Auslesen großer Treffermengen in Echtzeit nicht möglich
PAGING DER TREFFER Es wird immer nur eine kleine Treffermenge ausgelesen und ausgeliefert Blätter-Performance kann durch Preloading im Hintergrund verbessert werden
GESAMTARCHITEKTUR
PERFORMANCE 13 Mrd. indizierte Logmeldungen 5 Felder pro Logmeldung indiziert 60 Teilindizes Indexgröße ca. 40 GB pro Teilindex
SOLR Antwortzeit einer Solr-Instanz: 1-2 Sekunden Gesamtzeit aller 60 Instanzen: 4-8 Sekunden Konsolidierung der Treffer: max. 1 Sekunde
HADOOP Auslesen von 50 Treffern aus dem HDFS: 1-2 Sekunden Random Access sehr langsam, daher Caching weiterer Treffer im Hintergrund
GESAMT Zeit zur Darstellung erster 50 Treffer: 6-11 Sekunden
FAZIT Beide Technologien ergänzen sich gut Produktivbetrieb seit 14 Monaten bisher ohne Ausfälle Sehr gute Nutzerakzeptanz
ABER Solr Integration sehr komplex Performance noch ausbaufähig Verfügbarkeit von Open Source Lösungen mit ähnlicher Funktionalität: Elastic Search
VIELEN DANK! Vortragsslides unter http://dikant.de/wjax-2012/ Blog Serie Scalable Log Data Management with Hadoop unter http://blog.mgm-tp.com