Konsequentes Erfassen von Informationen und Big-Data-Analyse mit Hadoop

Inhaltsverzeichnis

Wenn Entwickler und Systemadministratoren gleichermaßen Informationen zu den Inhalten ihrer Webprojekte benötigen, gilt die Devise "Log everything". Für eine sinnvolle Big-Data-Analyse müssen sich die Informationen über Plattform- und Systemgrenzen hinweg erfassen lassen, was einheitliche Log Messages und eine spezielle Transporttechnik erfordert. Ein Bericht aus der Praxis.

Log everything! Bei einer solchen "Anforderung" könnte man mit dem Gedanken spielen, die Hände über dem Kopf zusammenzuschlagen, den Rechner auszuschalten und nach Hause zu gehen. Wenn sich der erste Unmut gelegt hat und in Ruhe darüber nachgedacht wird, könnte die Herausforderung nicht nur möglich, sondern auch interessant in der Umsetzung sein: Application Events, sinnvoll abstrahiert, multi-dimensional so zu erfassen, dass man die unterschiedlichen Sichten auf die gesammelten Daten für Anwender, Kunden, Entwickler, Systemadministratoren und C-Level einfach erstellen kann. Immer mit dem Ziel, die jeweilige Arbeit oder Entscheidungen zu vereinfachen oder erst zu ermöglichen.

Eine weitere Herausforderung stellt sich, wenn der Kern des Projektes später als grundlegende Plattform in verschiedenen Webseiten eingesetzt werden soll (wie im konkreten Beispiel der Fall). Das heißt im Allgemeinen, dass der Funktionsumfang der Plattform für jede mit ihr implementierte Website individuell anpassbar und erweiterbar sein muss. Im Besonderen gilt das auch für das Logging. Im vorliegenden Projekt gibt es eine Gemeinsamkeit, die alle Webseiten, die auf der Plattform entstehen, miteinander verbindet: "Content". Content ist ein Synonym für verschiedene Typen von Inhalten. Unter den Begriff fallen beispielsweise Artikel, News, Aufgaben, Bilder, Videos etc. Dabei sind für Bilder und Videos nicht die eigentlichen Assets gemeint, sondern deren Repräsentation in der Anwendung, angereichert mit weiteren Informationen (Meta-Daten) wie Autor, Größe, Qualität oder Länge.

Die Frage ist, wie sich diese Daten über verschiedene Plattformen und Systemgrenzen hinweg so sammeln und filtern lassen, dass sinnvolle Analysen möglich sind. Im Wesentlichen erreicht man das durch eine Vereinheitlichung der Log-Messages und der Transporttechnik, die verschiedene Logs aus diversen Quellen über ganz unterschiedliche Fachdomänen hinweg integrieren kann. Anhand von zwei konkreten Fragen zeigt dieser Artikel, wie das funktioniert:

• Wer schrieb die Artikel, die am häufigsten gelesen wurden?
• Wer sind die Top 10 Autoren mit dem einflussreichsten "Content"?

Um die Fragen beantworten zu können, benötigt man verschiedene Informationen aus dem System:

• Welcher Content wurde von wem erzeugt?
• Welcher Content wurde wann nachgefragt?
• Welcher Content wurde in welchem anderen Content durch Links oder Embeds referenziert?

Datenerzeugung und Transport

Verschiedene Datenproduzenten emittieren die für eine Analyse erforderlichen Daten, die ein "Handler" zum Data Storage transportiert. Zu den Datenproduzenten zählen sowohl Infrastruktursysteme als auch die Applikation selbst. Als Handler kommt ein Flume Node (Agent) zum Einsatz, der die gesammelten Daten an einen anderen Flume Node (Collector) im Netz zur Weiterverarbeitung oder Persistierung weiterleitet.

Mehr Infos

Details zu Flume

Flume stellt die Möglichkeit bereit, Daten aus verschiedenen Quellen verteilt in unterschiedliche Datenspeicher zu transportieren. Das können unter anderem Datenbanken aber auch Indexe von Suchmaschinen wie ElasticSearch sein. Im Beispiel kommt Flume in erster Linie zum Einsatz, um den Datenstrom geordnet im Hadoop-Dateisystem (HDFS) abzulegen. Die dafür notwendige Topologie besteht nicht nur aus den Quellen und Senken, sondern auch aus den Flume-Komponenten, den Flume Nodes und dem Flume Master.

Die von den Flume Nodes übernommenen Aufgaben lassen sich in zwei Schichten illustrieren: der Agentenschicht und der Kollektorenschicht. Innerhalb der Agentenschicht gibt es zu jedem Datenproduzenten einen Flume-Gegenpart: Ein Flume Agent würde beispielsweise die von syslog produzierten Logs erhalten und über einen Flume agentSink an einen Flume Node der Kollektorenschicht weitergeben. Die Nodes der Kollektorenschicht empfangen dann Daten von einer Vielzahl an Agenten, aggregieren und dekorieren die Logdaten und schreiben diese Daten anschließend in den entsprechenden Datenspeicher.

Der Flume Master ist die zentrale Konfigurations- und Steuerinstanz des Systems. Er konfiguriert sämtliche im System vorhandenen Nodes. Das hat allerdings den Nachteil, dass neu hinzukommende Nodes in der zentralen Konfiguration vergessen werden können. Als Vorsichtsmaßnahme kann man auf eine Lösung setzen, bei der sich die einzelnen Flume Nodes beim Start mit dem Master verbinden und sich selbst konfigurieren. Ebenso wird das Anhalten der Nodes berücksichtigt, in diesem Fall entfernt sich ein Node selbst aus der zentralen Konfiguration. Details zu dieser Methode finden sich im Artikel "Dynamically Configuring Flume Agents " von Justin J. Workman.