Big Data Architektur

Technologisch gesehen bleibt in diesem Zusammenhang kaum ein anderer Weg als das sogenannte “Massively Parallel Processing” (MPP) – also das Verarbeiten der großen Datenmengen in verteilten Systemen.

Diese Architektur hat mehrere Vorteile gegenüber den klassischen Formen der Datenverarbeitung:

• Scale-Out statt Scale-up (Rechenkapazität durch Hinzufügen von Knoten / Servern erweitern statt dem Ersetzen durch einen größeren Rechner inkl. aufwendigem Migrationsprojekt…)
• Kostenersparnis (Viele kleinere Server sind preiswerter als ein großer – “Commodity Hardware” erlaubt heute einen kleinen Supercomputer im eigenen Rechenzentrum für wenig Geld)
• Aufbrechen der Limitationen in Sachen Hardware (Google, Facebook & Co. wären mit monolithischen Strukturen gar nicht möglich…)
• Riesengroße In-Memory Speicher sind möglich (Durch das Nutzen des gesamten verfügbaren Hauptspeichers in einem Cluster)
• Eingebaute Ausfallsicherheit (Failover und Redundanz sind in einem Rechencluster oftmals implizit)

Allerdings kommen mit diesen neuen Architekturen auch neue Fragen und ein paar Nachteile.

Zuerst einmal bleibt festzuhalten, das Virtualisierung nicht immer sinnvoll ist in Massiv Parallel Rechnenden Clustern. Da viele IT-Abteilungen inzwischen jedoch eine “Alles wird virtualisiert” Strategie fahren, muss hier oftmals zurückgerudert werden – was schon einige Male zu intensiven Diskussionen mit Kunden geführt hat. Ein Hadoop Cluster z.B. verwendet üblicherweise die lokalen Disks der Server. Eine Virtualisierung mit einem gemeinsam genutzten Dateisystem (Shared Filesystem) ist somit eher kontra-produktiv und treibt die Kosten nach oben. Ebenfalls würde man die Sicherheit durch Redundanz und die I/O Performance der lokalen Disks verschenken.

Ein weiteres Schreckgespenst ist der Betrieb eines solchen Clusters – nach meiner Erfahrung allerdings unbegründet. Natürlich ist es aufwändiger einen Cluster zu konfigurieren und zu überwachen als einen einzelnen Server, aber der Aufwand steigt keinesfalls linear mit der Anzahl der Knoten. Oftmals sieht man bei den IT Spezialisten hier eine besondere Motivation sich in die neue Technologie einzuarbeiten und diese zu beherrschen – Das Aufbauen und Betreiben eines Hadoop Clusters löst meist ein funkeln in den Augen der technologisch versierten Mitarbeiter aus. Dass die Basis-Technologie stabil ist zeigen Beispiele wie Google oder Amazon, die diese im großen Stil seit Jahren betreiben.

Einige unserer großen Kunden müssen zudem die Entscheidung treffen wie sich die verschiedenen Anwender und Anwendungen den Cluster teilen. Manchmal macht es Sinn das alle sich einen einzigen großen Rechnerverbund teilen – manchmal ist es sinnvoller diesen in kleinere Sub-Cluster zu unterteilen. Eine “One Size Fits All” Lösung gibt es hier leider nicht.

Ein großer Cluster bringt die größtmögliche CPU-Dichte, erfordert aber eine Strategie zur Sicherstellung der Ressourcenzuteilung. Bei Linux können hier die cgroups (control groups) ganz hilfreich sein. Nach einer Aufteilung in Sub-Cluster stehen den Anwendern natürlich nicht mehr die kompletten Ressourcen zur Verfügung, aber man kommt sich auch nicht mehr in die Quere…

Tricky wird es auch bei den Anwendungen die einen solchen Cluster bedienen sollen. Das reine speichern der Daten ist ja nur der erste Schritt zu Big Data. Weiter geht es dann mit Datenqualität und Berechnungen / Analysen auf Basis Big Data. Diese sollen am Ende zu schnelleren und besseren Entscheidungen führen. Entscheidungen können hier sowohl strategische Unternehmensentscheidungen als auch operationelle “Nahe Echtzeit” Entscheidungen sein. Z.B. ist es so möglich auf Basis aller historischen Daten über einen Kunden und dessen aktuellem Surfverhalten auf der Website optimale Entscheidungen zu Produktplatzierungen zu treffen. Und das noch während er auf der Seite verweilt.

Es gilt weiterhin festzuhalten, dass das Bilden von Summen und Durchschnitten in einer verteilten Umgebung noch relativ simpel ist – beim Rechnen komplexer analytischer Verfahren allerdings, wird die Luft schnell dünner. Ein Neuronales Netzwerk, einen Entscheidungsbaum oder eine Forecast-Analyse verteilt zu rechnen können derzeit nur wenige. Der Rückfall zu klassischen Architekturen erfordert dann wieder Sampling (und damit schlechtere Ergebnisse) oder viel Geduld… Das verzögerte Ergebnis führt u.U. dazu, das man den entscheidenden Schritt langsamer ist als die Mitbewerber oder das man sich mit einem schlechteren Resultat zufrieden gibt und somit Geld verschenkt.

Zusammenfassend sollte man also immer darauf achten, dass die Big Data Architektur sich nicht nur auf das Speichern der Daten beschränkt, sondern auch alle benötigten Verarbeitungsformen zulässt (z.B. prädiktive Modelle, Event Streaming, In-Memory Analysen und Echtzeit-Visualisierungen). Die preiswerte Open-Source Lösung Hadoop ist sicher eine gute Entscheidung für die Massendaten die uns in Zukunft überfluten werden – allerdings ist Hadoop nur der Grundstock, den es mit anderen Lösungen bedarfsgerecht auszubauen gilt.

Spannende Zeiten die da auf uns zukommen!