1 3

Eingegangen: 28. Januar 2014 / Angenommen: 31. März 2014 / Online publiziert: 3. Mai 2014© Springer Fachmedien Wiesbaden 2014

G. König () · C. GügiYMC AG, Sonnenstr. 4,8280 Kreuzlingen, SwitzerlandE-Mail: gerd.koenig@ymc.ch

Social Media Monitoring mit Big Data Technologien

Gerd König · Christian Gügi

HMD (2014) 51:424–435DOI 10.1365/s40702-014-0041-0

Zusammenfassung Der Artikel beschreibt, wie mit Hilfe der Big Data Techno-logien Hadoop, HBase und Solr eine skalierbare Architektur zur Online Medien-überwachung definiert und realisiert wird. Ausgangspunkt ist das bereits vorhande-ne Medienüberwachungstool eines Kunden. Dessen Analyse und dabei entdeckte Schwachstellen führen zu einem Re-Design des kompletten Systems. Sowohl dieser Design-, als auch der darauf folgende Entwicklungsprozess werden durchgängig er-läutert. Das Hadoop Framework, das den Kern der Lösung bildet, wird zusammen mit weiteren Werkzeugen aus dem Hadoop Ökosystem vorgestellt und die Imple-mentierungen zur Erfüllung der einzelnen Teilanforderungen werden detailliert auf-gezeigt. Die Systemarchitektur, technologische Innovationen, sowie die wichtigsten Softwareprodukte werden genannt. Das abschliessende Kapitel beschreibt die aus diesen Prozessen gewonnenen Learnings.

Schlüsselwörter Big Data · Social Media Monitoring · Hadoop · Map/Reduce · Web Mining · Datenanlyse · HBase · NoSQL

1 Was ist Social Media Monitoring?

1.1 Einleitung

Social Media Monitoring (SMM) ist die möglichst zeitnahe Beobachtung und Aus-wertung von benutzerdefinierten Inhalten (UGC, User Generated Content) aus sozia-len Netzwerken, Diskussionsforen, Weblogs und Bloggingdiensten. Mit SMM lässt

Social Media Monitoring mit Big Data Technologien 425

1 3

sich online in Echtzeit die Stimmung und das Meinungsbild einer grösseren Anzahl von Menschen messen. Im Vergleich zu klassischen Erhebungen ist SMM um ein Vielfaches schneller und kostengünstiger und inzwischen fester Bestandteil jeder professionellen PR und Markenführung.

Organisationen nutzen SMM

● offensiv/ strategisch, um Marktforschung zu betreiben („Welche Produktfeatures werden vermisst? Welche Konkurrenzprodukte sind in der öffentlichen Dis-kussion und warum? Wo sind aktuelle HotSpots im Bereich XY?“) und daran anschliessend das Unternehmensportfolio anzupassen oder neue Marktsegmente zu erschliessen.

● defensiv, um ein Stimmungs-Fremdbild zu erhalten (Was wird über unser Unter-nehmen/ unsere Produkte geschrieben?“) und so Kritikpunkte in der öffentlichen Wahrnehmung schnell zu entdecken und adressieren zu können.

Web-Content ist dynamisch. Online-Diskussionen können sich schnell aufschau-keln und erzeugen dann in kurzer Zeit erhebliche Mengen an Text. Aus technischer Sicht ist die Aktualität, d. h. die Verarbeitung auch grosser Datenmengen möglichst in Echtzeit, somit der wesentliche erfolgskritische Faktor: Die Analyse kann noch so gut aufbereitet sein – sie führt in die Irre, wenn sie auf unvollständigen Rohdaten basiert.

1.2 Der SMM-Prozess

Der SMM-Prozess lässt sich in 4 Schritte unterteilen:

● EinsammelnBeschreibt wie die zu analysierenden Daten eingeholt werden sollen. Im Falle von SMM sind diese Quellen hauptsächlich soziale Netzwerke, Newsfeeds und Blogs. Je mehr Onlinequellen eingebunden werden, umso breiter ist die Daten-basis und somit kann die anschliessende Analyse umso aussagekräftiger/ realisti-scher durchgeführt werden.

● VerarbeitenDient der Eliminierung ungültiger Daten und bringt die gesammelte Information auf ein einheitliches Datenformat (z. B. Datumsformatierung), auf welchem die spätere Analyse aufbaut.

● AnalysierenDient der Gewinnung von neuen Erkenntnissen oder Zusammenhängen aus den zugrundeliegenden Daten. Dazu werden verschiedene Techniken, wie z. B. Fil-tern, Gruppieren und Verdichten eingesetzt.

● PräsentierenBeschreibt die Art und Weise, wie die Ergebnisse der Datenanalyse dem Benutzer präsentiert werden. Übliche Darstellungsformen sind Grafiken, Charts und Tabel-len ausserdem wird bei vordefinierten Events oder Erreichen von Schwellenwer-ten per E-Mail alarmiert.

Abbildung 1 fasst die erläuterten Schritte des klassischen SMM zusammen.

426 G. König, C. Gügi

1 3

2 Legacy System

2.1 Architektur

Die ursprüngliche Implementierung des SMM-Tools besteht aus den beiden Haupt-teilen Crawling und Datenverarbeitung. Während das Crawling die Aufgabe hat, Daten aus den vordefinierten Quellen einzusammeln und im zentralen Datenspeicher abzulegen, wird in der Datenverarbeitungsphase auf diesen Datenspeicher zugegrif-fen um nach den vom Benutzer vordefinierten Mustern zu suchen und ggf. Alerts oder Reports zu versenden.

Die eingesetzten Technologien sind:

● Solr:Suchmaschine basierend auf Lucene, zur effizienten Suche in Artikeln/Feeds/Blogs.

● Gearman:Framework zur Verwaltung und Steuerung von Tasks, welche auf verteilten Sys-temen durch sog. Gearman Worker’n ausgeführt werden. Hierüber werden z. B. die Tasks zum Versenden von Reports und Alerts oder auch das Management der Web-Crawler abgedeckt.

● PHP, Javascript:Programmiersprache zur Implementierung der Benutzerschnittstelle (Webinter-face) und der Web-Crawlerlogik.

● MySQL:Zentraler Datenspeicher zur Ablage von Benutzerdaten, Metainformation über gecrawlte Seiten und Jobkoordination von Gearman.

Abbildung 2 zeigt den Technologiestack dieses Systems auf.

2.2 Probleme

Der Betrieb des im vorigen Kapitel beschriebenen Systems offenbarte mit steigender Last und steigendem Datenvolumen diverse Schwachstellen. Diese führten zu Prob-lemen in den Bereichen:

● Wartbarkeit„Organisches“ Wachstum, d. h. gestartet mit einer "single server"-Architektur. Mit steigender Anzahl an Features und somit Tools/Services wurden Teile ad-hoc auf zusätzliche Server ausgelagert.

Abb. 1 Prozesse im klassischen Social Media Monitoring

Social Media Monitoring mit Big Data Technologien 427

1 3

● SkalierbarkeitNach dem Crawlen geht alles durch eine MySQL-Instanz, was sich als Perfor-mance-Engpass herausgestellt hat.Allgemeine Read/Write-Performanz von MySQL bei ca. 1,5 Mio. Schreibvor-gängen pro Tag ist nicht zufriedenstellend.

● Ausfallsicherheit und Web-Crawlerkoordination Fällt ein Server aus, werden die zugeteilten Feeds nicht auf einen der anderen Server übertragen und dort gecrawlt.

● Keine historischen Daten Die Performancekritische Solr Indexgrösse von ca. 400 GB entspricht ungefähr einem Zeitraum von 3 Monaten zur Datenvorhaltung.

● Rohdaten werden verworfen

3 Skalierbare Architektur

Um die in Kap. 2.2 beschriebenen Probleme nicht stets nur punktuell beheben zu müssen, wurde die Architektur und ihre Komponenten grundlegend neu strukturiert und implementiert.

Dieses Kapitel beschreibt die einzelnen Phasen der Neuimplementierung.

3.1 Anforderungen

Die Anforderungen an das neu zu entwickelte System ergaben sich im wesentlichen aus den Problemen des Legacy-Systems. Diese waren:

● Horizontale SkalierbarkeitZusätzliche Server sollen nahtlos den Durchsatz des Systems erhöhen.

● Archivfunktion

Abb. 2 Architektur des Legacy Systems

428 G. König, C. Gügi

1 3

Es sollen keine Daten gelöscht werden, sämtliche heruntergeladenen Daten blei-ben gespeichert.

● Ausfallsicherer BetriebDer Ausfall eines Servers führt zu keinem Datenverlust und keinem Ausfall der Systemfunktionalität.

● Einsatz und Entwicklung von unabhängigen TeilkomponentenVereinfacht die Weiterentwicklung und Wartbarkeit des Gesamtsystems, wie auch der Einzelkomponenten.

● Übernahme und Erweiterung der Features aus dem bisherigen System

3.2 Design

Die im vorigen Kapitel genannten Anforderungen konnten mit den ursprünglich gewählten Technologien nicht abgedeckt werden. Aus diesem Grund wurde für das Redesign auf Technologien aus dem Big Data Umfeld zurückgegriffen, da diese her-vorragend skalieren und der eingebaute Replikationsmechanismus die Gefahr von kompletten Systemausfällen drastisch reduziert.

Beim Design der neuen Architektur standen Aspekte wie Anpassungsfähigkeit, Wartbarkeit und Echtzeitverarbeitung im Vordergrund. Dazu werden die Skalie-rungsfähigkeit von Big Data-Technologien genutzt, um die gecrawlten Daten ohne Einschränkungen zu speichern, durchsuchbar und verarbeitbar zu machen.

Um den optimalen Zeitpunkt für die Aktualisierung einer Quelle zu bestimmen, wurde ein proprietärer Algorithmus (Scheduling) entwickelt. Das Frontend ist vom System komplett entkoppelt und daher jederzeit austauschbar. Um die Ergebnisse übersichtlich darzustellen, steht eine visuelle Benutzerschnittstelle prototypisch zur Verfügung.

3.3 Technologie-Stack

3.3.1 Hadoop-Framework

Die Suche nach einem flexiblen, horizontal skalierbaren System auf Open-Source Basis, welches zudem auf kostengünstiger Hardware zu betreiben ist, führte schnell zum Entschluss, das Hadoop-Framework einzusetzen. Zusätzliche Kriterien, welche diese Entscheidung positiv beeinflusst haben, waren die parallele Datenverarbeitung durch MapReduce und die automatischen Replikationsmechanismen im Dateisystem HDFS.

3.3.2 NoSQL Datastore

Da MySQL Probleme hatte die aufkommende Schreiblast performant zu verarbei-ten und das starre Schema eines RDBMs auf diesen UseCase nicht passend ist, war es schnell klar, dass eine NoSQL Datenbank für die Anforderungen besser geeignet ist. Zum Zeitpunkt der Evaluation waren Cassandra, MongoDB und HBase die aus-sichtsreichsten Kandidaten. Die Entscheidung fiel zugunsten von HBase aufgrund der folgenden Kriterien:

Social Media Monitoring mit Big Data Technologien 429

1 3

● Einfache Integration in das Hadoop-Ökosystem, um die Möglichkeiten/ Leis-tungsfähigkeit von Map/Reduce und HDFS bestmöglich zu nutzen.

● Horizontale Skalierbarkeit, d. h. die Kapazität des Systems soll durch zusätzliche Hardware einfach zu erhöhen sein.

● Schnelle Installation und Setup, um mit möglichst wenig Administrationsauf-wand schnell voran zu kommen.

● HBase war zu dem Zeitpunkt schon bei diversen grossen Unternehmen (z. B. Facebook) mit enormem Datenaufkommen im Einsatz.

3.3.3 Hadoop-Distribution

Cloudera hatte zum Evaluationszeitpunkt mit CDH (Cloudera Distribution for Apache Hadoop) bereits ein komplettes und ausgereiftes Installationspaket für ein Hadoop-System, inklusive zusätzlicher Tools aus dem Hadoop Ökosystem, wie z. B. Zookeeper und HBase, verfügbar. Das vereinfachte zum einen die Inbetriebnahme der Infrastruktur und zum anderen erleichtert dies spätere Versionsupgrades/-updates der installierten Tools. Zudem wurde positiv bewertet, dass einerseits CDH zu 100 % OpenSource Software ist, ohne Vendor Lock-In und andererseits durch die grosse Verbreitung dieser Distribution eine ausgezeichnete, kostenlose Unterstützung durch die Community vorhanden ist. Dies waren die ausschlaggebenden Punkte, warum zum damaligen Zeitpunkt Cloudera gegenüber Hortonworks sowie der kostenlosen MapR-Version bevorzugt wurde.

3.4 Umsetzung

In den folgenden Abschnitten werden sowohl die Gesamtarchitektur als auch wich-tige Komponenten des Systems getrennt voneinander betrachtet.

3.4.1 Architekturübersicht

Wie aus Abb. 3 ersichtlich, besteht das System aus verschiedenen Komponenten, die im folgenden erklärt werden.

Um den Datendurchsatz zu erhöhen, werden die Web-Crawler über mehrere Maschinen verteilt. Dies wird durch eine Aufteilung des URL-Raums erreicht, so dass jeder Web-Crawler für eine bestimmte Teilmenge der URLs verantwortlich ist. Die Web-Crawler parsen den HTTP-Body und extrahieren den Haupttext.

Die Daten werden dann in HBase gespeichert sowie in ein Messaging-System geschrieben. Als verteiltes Messaging-System wird Apache Kafka1 eingesetzt, mit der persistente Queues mit hohem Durchsatz bereitgestellt werden. Auf der anderen Seite der Queue lauschen spezielle Prozesse, sogenannte Consumer, die diese Daten in einen schnellen, temporären In-Memory Index indexieren. Mit einer sogenannten Prospective Search (Wikipedia: Prospective Search) werden Dokumente erkannt, die auf gewisse Suchterme passen. Eine Übereinstimmung löst eine sofortige Benach-richtigung (Realtime Alert) an den Kunden aus.

1 http://kafka.apache.org.

430 G. König, C. Gügi

1 3

Damit die Daten sofort durchsuchbar sind, werden sie parallel auf Apache Solr indiziert (near real time). Für ausführliche Datenanalysen wird das Map/Reduce (M/R) Framework eingesetzt. Koordiniert werden die verschiedenen M/R Jobs mit Azkaban – einem Tool für das Workflow Management.

Das Frontend ist entkoppelt und greift über standardisierte Schnittstellen auf HBase (REST) respektive Apache Solr (HTTP) zu.

3.4.2 Verteilte Webcrawler

Wie in Abb. 3 gezeigt, laufen die Web-Crawler (auch Spider oder Web-Roboter genannt) auf mehreren Servern verteilt. Durch diese Parallelisierung wird eine effi-zientere Nutzung der Ressourcen CPU und Netzwerk beim Downloaden und Parsen der Dokumente erreicht. Die Web-Crawler versuchen erst die Datei robots.txt (Wiki-pedia: Robots Exclusion Standard) aufzurufen und haben eine adaptive Politeness-Strategie, um Webserver nicht zu überlasten (Lui 2011).

Je nach Quellenart (Webseite, Forum, Twitter, Facebook, Google +, etc.) werden unterschiedliche Mechanismen für das Extrahieren der Hauptinformationen sowie der Metadaten verwendet. So werden bei Webseiten, Feeds und Foren klassische Crawlermechanismen (Wikipedia: Webcrawler) eingesetzt, bei Twitter, Facebook und Google+ hingegen deren öffentliche API.

Abb. 3 Systemarchitektur

Social Media Monitoring mit Big Data Technologien 431

1 3

Koordination der Parallelisierung. Der URL-Raum wird vorab aufgeteilt, indem die invertierte URL einem bestimmten Bereich zugeordnet wird. Jeder dieser Bereiche wird wiederum einem Web-Crawler zugewiesen. Damit ist sichergestellt, dass eine Domain nur von einem bestimmten Web-Crawler bearbeitet wird. Als Beispiel zeigt Abb. 4 eine Aufteilung in 8 Bereiche. Bereich 2 beinhaltet zum Beispiel Domains von com.wordpress bis de.spiegel (reversed domains). Die Aufteilung in 8 Bereiche anhand der Anfangsbuchstaben der reversed domains ist stark vereinfacht und exemp-larisch zu verstehen. In Wirklichkeit werden viel mehr Bereiche (z. B. 64) verwendet.

Die Konfiguration wird auf Apache ZooKeeper gehalten und beim Start der Web-Crawler eingelesen. Das System ist so konzipiert, dass die Bereiche gleich-mässig unter den verfügbaren Web-Crawlern aufgeteilt werden. Kommt ein neuer Web-Crawler hinzu, werden alle anderen darüber benachrichtigt, dass das System ausbalanciert werden soll. Die Web-Crawler geben dann automatisch Bereiche ab, die anschliessend dem neuen Web-Crawler zugewiesen werden. Dabei wird das Ver-fahren Consistent Hashing angewendet (Wikipedia: Amazon Dynamo Consistent Hashing).

Im optimalen Zustand bearbeiten alle Web-Crawler die gleiche Anzahl an Berei-chen – das System ist dann ausbalanciert. Das selbe Prinzip wird auch beim Stoppen eines Web-Crawlers angewendet – die frei gewordenen Bereiche werden wieder auf die laufenden Web-Crawler aufgeteilt.

Revisit-Strategie. Im Kontext von Medienmonitoring ist Aktualität fundamental. Entsprechend ist die Festlegung der Crawl-Reihenfolge beziehungsweise das Wie-derbesuchen einer Webseite entscheidend. Ziel hierbei ist, das gespeicherte Abbild einer sich kontinuierlich verändernden Seite aktuell zu halten.

Um den optimalen Wiederbesuchszeitpunkt zu finden, wurde ein Scheduling Algorithmus entwickelt. Als Basis zur Ermittlung des Zeitpunktes verwendet der Algorithmus die Publikationshistorie der vergangenen 5 Wochen einer Webseite. Die Publikationshistorie ist eine Liste aus Publikationdaten, die bereits früher geladen wurde. Desweiteren wird der nächste geplante Wiederbesuchszeitpunkt einer Seite durch ihre Priorität beeinflusst. Die Wichtigkeit einer Webseite wird mittels verschie-dener Signale berechnet.

3.4.3 HBase Design

Im vorhergehenden Abschnitt wurde beschrieben, wie Information aus dem Internet beschafft werden. Mit diesen Methoden sammelt sich in kürzester Zeit eine grosse Menge an Daten und Netzwerkinformationen an. Für die Speicherung dieser hete-rogenen Daten wird HBase eingesetzt. Dabei wurde viel Aufwand in das Schema-Design investiert, um im Betrieb die bestmögliche Performance zu erzielen. HBase speichert die Daten in so genannten HFile’s auf HDFS. Werte einer Zelle auf der Platte sind durch die drei Koordinaten

● RowKey ● ColumnName, Kombination aus ColumnFamily (CF) und ColumnQualifier (CQ) ● Zeitstempel

432 G. König, C. Gügi

1 3

eindeutig identifiziert.Der RowKey ist die invertierte URL eines Artikels – zum Beispiel org.apache.

blogs/hbase. In der ColumnFamily (CF) „cnt“ wird der Artikelinhalt im Avroformat sowie die verwendete Avro-Version gespeichert. Das gesamte HTTP Protokoll wird in der ColumnFamily „l“ geloggt. Die ColumnFamily „mis“ enthält Metadaten wie Sprache, Autor, usw.

Die Verwendung mehrerer Versionen für die „cnt“ ColumnFamily ermöglicht es, ältere Kopien zu speichern. Das ist unter anderem hilfreich, um die Frage zu beantworten, wie oft eine Seite sich im Laufe der Zeit verändert hat. Der verwendete Zeitstempel ist die tatsächliche Zeit, wenn die Webseite vom Web-Crawler herunter-geladen wurde.

Beim Design ist besonders auf folgende Punkte zu achten:

1. Kurze Bezeichner für RowKey und ColumnNames Um direkten Zugriff auf einen Datenwert zu ermöglichen bietet ein HFile einen Block-Index an (George 2011, S. 329–333). Sind die Bezeichner für RowKey und ColumnName entsprechend gross, alloziert HBase den Grossteil des ihm zu-gewiesenen RAM nur für diesen Index.

2. Die Anzahl CF’s sollte gering gehalten werden Pro ColumnFamily legt HBase ein HFile an. Darum wird bei vielen HFiles der Compaction-, und Flushing-Prozess (George 2011, S. 326–329) sehr I/O intensiv und führt zu Performanceeinbussen.

3.4.4 Realtime Suche und Indexierung

Zum Entwicklungszeitpunkt war Solr Cloud für den Produktiveinsatz noch nicht aus-gereift genug. Da profundes Solr-KnowHow intern vorhanden war, hat man sich für eine eigene Lösung entschieden. Die grösste Herausforderung war die Wahrung der Performanz mit Blick auf die Indexgrösse. Es sollten keine Indexkürzungen mehr durchgeführt werden.

Abb. 4 Aufteilung der URLs in 8 Bereiche

Social Media Monitoring mit Big Data Technologien 433

1 3

Es wurde dafür ein Sharding-Konzept entwickelt, bei dem die Shards (Solr-Index) nach Monaten aufgeteilt sind. Sharding bedeutet, dass der Index auf mehrere Server verteilt wird. Die Solr-Shards werden automatisch erstellt und die durchschnittliche Indexgrösse liegt bei 80 GB.

Das Frontend kann über einen Parameter steuern, wie viele Shards abgefragt werden. In der Standardeinstellung wird der aktuelle Monats-Shard verwendet. Bei einem Monatsübergang wird der aktuelle Monat plus aktueller Monat-1 durchsucht.

3.4.5 Layout des Clusters

Die in den vorigen Kapiteln beschriebene Softwarearchitektur wird auf einer Infra-struktur bestehend aus physikalischen und virtuellen Servern betrieben. Die insge-samt 10 physikalischen Server dienen als

● Hadoop Worker (HDFS Datanodes, Tasktracker und HBase Regionserver) ● Solr Suchserver (repliziert) ● KVM Virtualisierungshosts

Als virtuelle Server werden auf den Virtualisierungshosts die Orchestrationsdienste wie z. B. Namenode, Jobtracker, HMaster betrieben, da diese Dienste überwiegend Hauptspeicher basiert arbeiten und geringe Anforderung an den Festplattendurchsatz haben.

Zum Einsatz kommen Server des Herstellers Supermicro mit der folgenden Ausstattung

● CPU: Intel Xeon Quadcore ● RAM: 32 GB ● HDD: 6 × 1 TB Festplatten ● Netzwerk: 3 NICs, jeweils 1 GBit

Diese Konfiguration ist bewusst aus dem commodity hardware-Segment gewählt, da für den Betrieb eines Hadoop-Clusters nicht unbedingt High-End Hardware benötigt wird. Vielmehr ist ein hoher Grad an Parallelität (also viele Hadoop Worker Knoten) ein entscheidender Faktor für die Performance der Datenverarbeitung. Der Ausfall eines Servers wird von Hadoop abgefangen (Apache Software Foundation: HDFS Architecture) und führt zu keinem Ausfall der Verfügbarkeit des Clusters.

4 Fazit und Fakten

Das beschriebene System zur Online-Medienbeobachtung wurde in einem Team von 5 Softwareentwicklern, unter Anwendung agiler Methoden nach Scrum, innerhalb von 9 Monaten entwickelt. In dieser Zeit hat sich das Team ein umfangreiches Wis-sen über die einzelnen Komponenten des Hadoop Ökosystems (HDFS, HBase, Map/Reduce usw.) aufgebaut. Für die Entwicklung von Applikationen, die auf Hadoop aufsetzen, ist es unerlässlich sich im Umgang mit verschiedenen Komponenten aus dem vielfältigen Ökosystem vertraut zu machen. Entwicklungsarbeit beinhaltet im

434 G. König, C. Gügi

1 3

Hadoop Umfeld neben der Implementierung auch die Konfiguration des Zusammen-spiels dieser Komponenten.

Das beschriebene System überwacht momentan 303’392 Online-Quellen. Das Datenaufkommen wächst dabei monatlich um ~ 600 GB.

Während der Entwicklung mussten Hürden wie bspw. die Qualität oder Stabili-tät (v. a. HBase) der verwendeten Open Source Produkte gemeistert werden. Beim Einsatz von „Bleeding-Edge“-Technologie ist dies jedoch nicht sonderlich über-raschend. In der Rückschau erwies sich Scrum als die richtige Methode, um sehr schnell auf Probleme reagieren zu können. Naturgemäss haben verschiedene, anwen-dungsbezoge, zusammengesetzte Open-Source-Produkte keine einheitliche Qualität und Stabilität, was zu diversen Issues diesbezüglich führte. Deren Lösung lies sich aber laufend in die Sprints integrieren und führte zu keinem Zeitpunkt zu Entwick-lungssackgassen oder anderen erheblichen Verzögerungen. Auch existierte für Setup und Konfiguration des Produktionsclusters keine Best Practice, so dass der Aufwand, vor allem in der Schlussphase, für das Feintuning hoch war. Auch aufgrund der kon-tinuierlich in der Entwicklung mitgeführten Unit- und Integrationstests erwies sich die Architektur als robust. Sie benötigte nur einen einzigen Totalreset in den ersten Wochen nach Beginn des Testbetriebs, mit Verwerfen der bis dahin gecrawlten Daten.

Durch die fehlenden Überwachungswerkzeuge war der Betrieb anfangs eine müh-same Angelegenheit. Oft wurde zu spät entdeckt, dass z. B. ein RegionServer ein Pro-blem hatte und dadurch die Stabilität des gesamten Clusters gefährdet war. Deshalb ist der Einsatz eines Monitoringsystems, wie z. B. Nagios oder Ganglia, unbedingt zu empfehlen. Kennzahlen zum Status des Hadoop-Clusters können entweder über HTTP-Anfragen an die einzelnen Dienste oder über das Auswerten von Java JMX-Daten eingeholt werden. Dazu existieren bereits eine Reihe vorgefertigter Plugins. Ein weiterer positiver Aspekt des Monitorings ist das Überwachen der Gesamtauslas-tung des Clusters, so kann proaktiv und ohne Downtime durch Hinzufügen weiterer Ressourcen problemlos horizontal skaliert werden.

Jedoch bietet HBase ein paar wichtige Grössen über interne Vorgänge, wie z. B. Compactions, das Umstrukturieren der physikalischen Speichereinheiten (George 2011, S. 326–329), nicht über die vorhin beschriebenen Schnittstellen an. Aus die-sem Grund und dem Wunsch nach mehr Einsicht in die Interna von HBase wurde im Anschluss an die Inbetriebnahme des SMM-Systems das Tool „Hannibal“ ent-wickelt und als Open Source Software lanciert. Hannibal bietet eine grafische Über-sicht sowohl über aktuelle Zustandsgrössen, wie auch über historische Daten und Vorgänge (Diverse).

Im Vergleich zum abgelösten System konnte in den Bereichen Stabilität, Perfor-mance, Wartbarkeit und Skalierbarkeit durch den Einsatz von Big Data Technologien eine deutliche Verbesserung erreicht und somit die in Kap. 2.2 beschriebenen Proble-matiken des Legacy-Systems behoben werden.

Literatur

Apache Software Foundation: HDFS Architecture. http://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html#Hardware_Failure. Zugegriffen: 24. Jan. 2014

Social Media Monitoring mit Big Data Technologien 435

1 3

Lui B (2011) Web Data Mining Second Edition. Springer, HeidelbergDiverse: Hannibal, a tool to help monitor and maintain HBase-Clusters. https://github.com/sentric/hannibal/

wiki. Zugegriffen: 09. Jan. 2014George L. (2011) HBase: The Definitive Guide. O’Reilly, SebastopolWikipedia: Amazon Dynamo Consistent Hashing. http://de.wikipedia.org/wiki/Amazon_Dynamo#Consistent_

Hashing. Zugegriffen: 23. Jan. 2014Wikipedia: Prospective Search. http://en.wikipedia.org/wiki/Prospective_search. Zugegriffen: 09. Jan.

2014Wikipedia: Robots Exclusion Standard. http://de.wikipedia.org/wiki/Robots_Exclusion_Standard. Zuge-

griffen: 09. Jan. 2014Wikipedia: Webcrawler. http://de.wikipedia.org/wiki/Webcrawler. Zugegriffen: 09. Jan. 2014