Die Verknüpfung von Data Analytics und Supercomputing
Seite 2: Cloud und Big Data
Cloud oder nicht Cloud?
Ob für die genannten Anwendungsfälle auch eine Cloud-Anwendung in Frage kommt, hängt von mehreren Faktoren ab. Zum einen der finanzielle Aspekt, nämlich im Hinblick auf die sogenannte "Utilisation": Wird aufgrund vieler Workloads und Anfragen ein gewisser Auslastungsgrad überschritten, ist eine On-Premise-Anwendung schlicht billiger.
Der zweite Aspekt betrifft das Transferieren von Daten. Ist eine gewisse Datenmenge erreicht, das heißt, bewegt sie sich im Terabyte- oder Petabyte-Bereich, kommen Anwender mit der Cloud nicht mehr weiter. Ein gutes Beispiel hierfür – und somit für die Big-Data-HPC-Konvergenz – ist Petroleum Geo-Services (PGS). Das norwegische Unternehmen ist im Erdöl- und Erdgassektor tätig und bietet weltweit meeresgeophysikalische Dienste zur Entdeckung von Erdölfeldern an. Um seismische Daten zu analysieren und künftig detailliertere Aufnahmen und mehrdimensionale Modelle der geologischen Strukturen am Meeresgrund zu ermöglichen, setzt das Unternehmen nun auch auf Machine-Learning-Algorithmen. Die hierbei generierten Daten bewegen sich aber in der Größenordnung mehrerer Zehner von Petabytes. Das kann keine Cloud-Anwendung.
Zudem spielen in manchen Branchen Geschwindigkeit und Latenzzeit die entscheidende Rolle, beispielsweise im High Frequency Trading, im Bereich Maschinensteuerung oder auch bei der Cyber-Überwachung wie im Fall Telekom.
Drittens sind schließlich regulatorische Aspekte wie Datensicherheit zu nennen: Eine Versicherung etwa wird Daten nur ungern in die Cloud verlagern wollen. Es ist letztlich eine Frage des Anwendungs- und Geschäftsszenarios, ob eine Cloud-Anwendung dazu passt oder nicht. Grundsätzlich lässt sich feststellen, dass die Cloud gegenüber einer Data-Analytics-Plattform auf Hardwarebasis Schwächen bezüglich Latenzzeit und Datenbewegung hat.
Anwender müssen also abwägen, wie schnell sie Ergebnisse zu bestimmten Abfragen brauchen und wie viele Daten sie verarbeiten müssen. Liegt die Auslastung der Analytics-Plattform mit Supercomputing-Techniken unter 50 Prozent, lohnt sich die Investition meist nicht. Dann ist ein Cloud-Service sinnvoller. Wenn ein Anwender jedoch sofort Ergebnisse braucht, die Maschine regelmäßig ausgelastet wird, es auf eine möglichst geringe Latenzzeit sowie einen kurzfristigen Turnaround ankommt und geschäftskritische Anwendungen betroffen sind, sollte über eine lokale Data-Analytics-Anwendung nachgedacht werden.
Dimensionen von Big Data
Unter dem Begriff Big Data ist in den letzten Jahren viel subsumiert worden. Im Endeffekt sind zwei Dimensionen entscheidend: erstens das Data Management, das heißt, wohin man die Daten schiebt. Zweitens: Wie lässt sich Sinnvolles in den Daten finden? Angefangen hat alles mit dem MapReduce-Algorithmus von Google und Hadoop. Auf einmal war verteiltes Rechnen für alle zugänglich. Allerdings kostete die Datenverarbeitung über die auf hohe Verfügbarkeit ausgelegten, dreifach redundanten Server viel Zeit und stellte eher Ballast dar. Um in puncto Geschwindigkeit einen Schritt nach vorne zu machen, entstand dann Apache Spark. Anwender sollten nicht mehr nur Korrelationen zur Verfügung haben, sondern Zusammenhänge innerhalb unstrukturierter Daten aus verschiedensten Quellen erkennen können.
Um große Mengen unstrukturierter Daten analysieren zu können, werden heute überwiegend Graphenanalysen eingesetzt. Sie machen Zusammenhänge erkennbar, die vorher nicht bekannt waren. In der Medizin lassen sich Graphen beispielsweise dazu einsetzen, über die Analyse von Nebenwirkungen und deren Verknüpfung mit anderen Patientendaten Hinweise zu erhalten, also wie existierende Medikamente für andere Krankheiten wiederverwendet werden können.
Graphdatenbanken finden, genauso wie Spark und Hadoop, in zunehmend mehr Industrien Verwendung, sind aber schwer zu parallelisieren. Das liegt daran, dass als Voraussetzung für die sogenannte "Locality", also das parallele Rechnen auf verschiedenen Knoten, die Struktur der Daten bekannt sein muss. Das ist aber bei unstrukturierten Daten eben nicht der Fall. Herkömmliche Cluster haben demnach nicht die nötige Skalierbarkeit, um schnelle Graphenanalysen zu ermöglichen. Auf normalen Rechnern können Graph Analytics deshalb mehrere Stunden oder sogar Tage dauern.
Als Methode im Zentrum der Aufmerksamkeit im Bereich Big Data standen in letzter Zeit Machine Learning beziehungsweise Deep Learning. Hierbei ist zu unterscheiden, ob es sich um rechenintensive Tasks zum Trainieren des neuronalen Netzes oder reine Abfragen handelt. Die Abfragephase ist nicht rechenintensiv. Das können zum Beispiel einfach Kaufvorschläge eines Online-Händlers basierend auf getätigten Käufen sein.
Das Training eines neuronalen Netzes hingegen ist rechenintensiv. Die Fragen sind, wie viele Daten verschoben werden müssen, wie tief das neuronale Netz ist, wie oft Trainings anfallen, wie oft Updates des neuronalen Netzes anstehen et cetera. Auf der NIPS-Konferenz 2016 (Neural Information Processing Systems) in Barcelona wurden kürzlich die Ergebnisse einer Zusammenarbeit zwischen Microsoft, Cray und dem Schweizer Nationalen Hochleistungsrechenzentrum CSCS gezeigt. Dabei wurde das Microsoft Cognitive Toolkit auf die Architektur des schnellsten europäischen Supercomputers "Piz Daint" portiert und demonstriert, wie sich die Dauer rechenintensiver Machine-Learning-Aufgaben von Wochen und Monaten auf Minuten bis Stunden reduzieren ließ.
