Parallelverarbeitung und In-Memory Die passende Infrastruktur für Big Data

Von Big Data können alle profitieren: Unternehmen, öffentliche Einrichtungen und Non-Profit-Organisation. Doch mit herkömmlichen Business-Intelligence-Verfahren und der entsprechenden IT-Infrastruktur lassen sich große, unstrukturierte Datenbestände nicht einfach in Echtzeit auswerten. Erforderlich sind neue Ansätze, wie etwa eine verteilte Parallelverarbeitung und In-Memory-Technologien.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Vogel IT-Medien GmbH

Fivetran Germany GmbH

Unternehmen und Behörden sind daran interessiert, wirtschaftliche und gesellschaftliche Trends besser voraussagen und Projektrisiken schon im Vorfeld exakt quantifizieren und verringern zu können. Dazu bedarf es detaillierter Informationen über das künftige Verhalten von Kunden und die Wünsche der Bürger. Diese sollen Big-Data-Analysen liefern, indem Daten zum Kaufverhalten und zu Anfragen bei den Support-Abteilungen ausgewertet werden, oftmals sogar in Echtzeit.

Diese Analysen erleichtern es, ein Gefühl dafür zu bekommen, welche neuen Produkte Kunden wahrscheinlich kaufen und welche Serviceleistungen sie erwarten werden. Stadtentwickler und Verkehrsplaner sind durch solche Analysen in der Lage, den Bedarf an Straßen, S-Bahn- und Buslinien, Krankenhäusern und Schulen besser abzuschätzen.

Klassische BI reicht nicht aus

Allerdings erfordert Big Data eine andere IT-Infrastruktur als klassische Business-Intelligence-Lösungen (BI). Ein Grund dafür ist zum einen die Menge der Informationen, die im Rahmen von Big Data erfasst und bearbeitet werden muss, und zum anderen die häufige Anforderung, Datenanalysen in Echtzeit durchzuführen. Nach Einschätzung von Fujitsu steigen die Datenbestände in Unternehmen jährlich um 65 Prozent an. Die Marktforschungsgesellschaft IDC geht davon aus, dass die weltweit produzierte Datenmenge von rund 8.600 Exabyte bis 2020 auf mehr als 40.000 Exabyte anschwellen wird.

Hinzu kommt die wachsende Zahl an Datenquellen und Formaten. Neben Daten aus transaktionalen Datenbanken müssen jene aus Blogs, Click-Streams und Social-Media-Plattformen berücksichtigt werden. Hinzu kommen Multimedia-Daten wie Fotos und Videos, Textdateien, E-Mails, Log-Daten, Informationen von Sensoren und Lokationsdaten.

Etwa 80 Prozent dieser Informationen liegen in unstrukturierter Form vor und können mit klassischen BI Tools nur schwer bearbeitet werden. Denn die zugrunde liegenden Data Warehouses basieren auf relationalen Datenbanksystemen. Das heißt, sie sind für die Bearbeitung von strukturierten Daten in festen Tabellenfeldern ausgelegt. Unstrukturierte der semistrukturierte Daten müssten deshalb zunächst in strukturierte Daten überführt werden, wodurch klassische Infrastrukturkonzepte schnell an ihre Grenzen stoßen.

Scale-up und Scale-out helfen nicht weiter

Traditionell stehen als Optionen die vertikale Server-Skalierung (Scale-up) und die horizontale Skalierung (Scale-out) zur Wahl. Allerdings sind beide Ansätze keine nachhaltige Lösung. Denn für die physischen Ressourcen eines Server-Systems gelten Grenzen bezüglich der Anzahl der Prozessorkerne, der Arbeitsspeicherkapazität, dem lokalen Plattenspeicher und der Netzwerkbandbreite. Zwar werden sich die heutigen Grenzwerte in Zukunft nach oben verschieben. Das hilft jedoch nicht weiter, weil jeder Performance-Gewinn durch das Wachstum der Datenmengen, die im Rahmen von Big-Data-Projekten anfallen, kompensiert wird.

Gleiches gilt für den Scale-out-Ansatz, also einer horizontalen Server-Skalierung in Verbindung mit relationalen Datenbanken. In diesem Fall können sich die Speicherverbindungen zum Flaschenhals entwickeln. Zudem steigt der Aufwand für die Koordination der Zugriffe auf gemeinsam genutzte Daten, je mehr Datenbank-Server zum Einsatz kommen. Das wiederum führt laut dem Amdahlschen Gesetz zur Abnahme der Server-Effizienz und zu Beschränkungen bezüglich des Parallelisierungsgrads. Eine Scale-out-Infrastruktur in Verbindung mit relationalen Datenbanken wäre daher höchst aufwendig und würde dennoch nicht die erhofften Performance-Gewinne bringen.

Parallelverarbeitung und Shared-Nothing-Architektur

Der Schlüssel zum Erfolg ist eine Parallelisierung auf der Basis einer Shared-Nothing-Architektur und nicht blockierender Netzwerke. Bei diesem Konzept werden die Daten auf die lokalen Plattenspeicher der Knoten in einem Server-Cluster verteilt. Die Bearbeitung der Daten erfolgt auf denjenigen Server-Knoten, auf denen die Daten liegen.

Eine verteilte Parallelverarbeitung hat mehrere Vorteile:

• Hohe Performance: Bearbeiten viele Knoten eine Abfrage, sinkt die Bearbeitungszeit und Analyseresultate stehen schneller zur Verfügung.

• Hohe Skalierbarkeit: Der Anwender kann mit wenigen Knoten starten und bei Bedarf weitere hinzufügen. Eine solche Infrastruktur lässt sich linear und ohne Obergrenze horizontal erweitern.

• Fehlertoleranz: Daten werden auf mehrere Knoten repliziert. Fällt ein System aus, übernimmt ein Server mit einer Datenreplik dessen Aufgabe – und das im laufenden Betrieb.

• Kosteneffizienz: Eine Serverfarm lässt sich aus handelsüblichen Zwei-Prozessor-Systemen mit einigen Terabyte lokalem Speicher aufbauen.

Apache Hadoop als Big-Data-Standard

Der De-facto-Standard für die verteilte Parallelverarbeitung ist das Open-Source-Ecosystem Apache Hadoop. Hadoop lässt sich horizontal auf mehrere tausend Knoten skalieren, ist fehlertolerant und erlaubt stabile Speicher- und Analyseprozesse. Ein Bestandteil von Hadoop ist das Hadoop Distributed File System (HDFS), das die verteilte Speicherung sehr großer Datenmengen auf mehreren Knoten erlaubt. Dazu wird das Netzwerk in Master- und Slave-Knoten unterteilt.

Auf dem Master Server liegt der sogenannte NameNode. Dieser spaltet die Daten in Blöcke auf, verteilt sie auf die Server und speichert die Metadaten. Zum Zwecke der Fehlertoleranz werden identische Blöcke auf mehreren Servern vorgehalten. Außerdem ist der NameNode für die Verwaltung der Metadaten zuständig; er weiß also genau, wo die Datenblöcke liegen und wo Speicherkapazitäten frei sind. HDFS sieht zwei NameNodes für den Fall vor, dass ein System ausfällt.

Der zweite zentrale Bestandteil von Hadoop ist das MapReduce Framework beziehungsweise dessen Weiterentwicklung YARN (Yet Another Resource Negotiator). Es ist für die Verwaltung der Ressourcen und die parallelisierte Anwendungssteuerung zuständig. MapReduce beziehungsweise YARN teilen eine Analyseaufgabe in viele kleinere „Jobs“ auf und verteilen diese inklusive der Daten auf die Server-Knoten.

Bei YARN ist ein „schlanker“ Ressourcen-Manager für die zentrale Verwaltung der Ressourcen zuständig. Hinzu kommt ein ApplicationMaster. Er wird auf den Slave-Knoten im Server-Cluster für die jeweiligen Jobs generiert und steuert das Abarbeiten der betreffenden Teilaufgabe. Am Ende werden die Ergebnisse der Jobs zu einem Ganzen zusammengefügt.

Schnellere Analysen mit In-Memory-Datenbanken

Eine zentrale Anforderung an Big Data ist, dass Analyseergebnisse möglichst schnell, am besten in Echtzeit, zur Verfügung stehen. Daher müssen auch die Daten schnell verfügbar sein. Plattenspeichersysteme und selbst All-Flash-Arrays (AFA) sind in diesem Punkt In-Memory-Datenbanken (IMDB) wie etwa SAP HANA unterlegen. Denn In-Memory-Datenbanken nutzen den Arbeitsspeicher von Server-Systemen, um Daten zu speichern. Nach Erfahrungswerten von Fujitsu erfolgen Datenanalysen bei Einsatz einer IMDB etwa um den Faktor 1.000 bis 10.000 schneller als bei Verwendung konventioneller Datenbanktechniken und Storage-Technologien.

Bei einer In-Memory-Datenbank befindet sich das gesamte Datenvolumen zusammen mit den Datenbankanwendungen im Hauptspeicher eines Servers oder mehrerer Server. Festplatten dienen nur zum Ablegen von regelmäßigen Sicherungskopien und zur Protokollierung von Datenänderungen. Da bei einer In-Memory-Datenbank das Einlesen der Daten von einem relativ langsamen Plattenspeicher entfällt, lassen sich die Informationen extrem schnell speichern, abrufen und sortieren. Die Analyse von Geschäftsdaten ist somit in Echtzeit möglich. Herkömmliche Lösungen, die relationale Datenbanken und Festplattenspeicher nutzen, benötigen dafür unter Umständen mehrere Tage.

Verteilte Parallelverarbeitung und In-Memory im Zusammenspiel

Über die verteilte Parallelverarbeitung können Daten, die aus unterschiedlichen Quellen stammen, vorverarbeitet und in eine für die anstehenden Analyseaufgaben optimale Form gebracht werden. Anschließend erfolgt der Export der Daten in die In-Memory-Datenbank. Die folgenden Analyseschritte erfolgen im Hauptspeicher eines oder mehrerer Server.

Datenbanken für Big Data

Sind die Analysen nicht extrem zeitkritisch, können die vorverarbeiteten Daten auch in herkömmliche SQL-Datenbanken exportiert werden, sofern das Volumen überschaubar bleibt. Für Big-Data-Szenarien mit einem steigenden Volumen an zu exportierenden Daten eignen sich NoSQL-Datenbanken besonders gut. Diese Datenbanken setzen auf keinem festen Schema auf und kommen daher mit jedem Datentyp zurecht. Außerdem erlauben sie es, Datenformate anzupassen, ohne dadurch die Anwendung zu beeinträchtigen.

Vor allem aber können sie auf beliebig viele Server verteilt werden, was dem steigenden Datenvolumen sehr entgegenkommt. Die geläufigste Variante ist die spaltenorientierte NoSQL-Datenbank. Sie kommt vor allem bei der Verarbeitung großer strukturierter Datenmengen zum Zuge, bei denen man mit zeilenorientierten relationalen Datenbanken nicht die gewünschten Antwortzeiten erreicht.

Weitere Varianten von NoSQL-Datenbanken sind Key-Value Stores, dokumentenorientierte Datenbanken (Document Stores) und Graphen-Datenbanken. Im Gegensatz zu relationalen Datenbanken, die universell verwendet werden können, sind NoSQL-Datenbanken auf spezielle Anwendungsfälle zugeschnitten.

Complex Event Processing zur Echtzeitanalyse

Sind im Rahmen von Big-Data-Analysen überwiegend Daten wie Clickstreams oder Sensordaten in Echtzeit zu verarbeiten, ist ein sogenanntes Complex Event Processing (CEP) erforderlich. Dieses ermöglicht die Echtzeitanalyse der Datenströme nach vorab definierten Regeln, welche Bedingungen und Aktionen enthalten. Sind gewisse Bedingungen erfüllt, werden eine oder mehrere damit verknüpfte Aktionen angestoßen.

Typischerweise muss eine CEP-Engine Hunderttausende oder Millionen von Ereignissen pro Sekunde bewältigen. Die Latenzwerte (Zeit zwischen der Entstehung eines Ereignisses und der anzustoßenden Aktion) liegen typischerweise im Bereich von Millisekunden oder manchmal sogar darunter. Um zeitraubende Festplattenzugriffe einzusparen, werden Ereignisströme im Hauptspeicher verarbeitet. Nur Protokolldaten landen auf der Festplatte. Zur Vermeidung von Datenverlusten und um die Last zu verteilen, lassen sich die Daten auf mehrere Server-Knoten replizieren.

Big-Data-Infrastrukturen entstehen nicht von alleine

Die Bereitstellung einer Big-Data-Infrastruktur ist alles andere als einfach. Server- und Speichersysteme, Netzkomponenten und Software müssen ausgewählt, beschafft, kombiniert und getestet werden. Das erfordert Spezialwissen, über das nicht jede IT-Abteilung verfügt. Und selbst wenn das Know-how vorhanden ist, steht dabei immer das Risiko im Raum, dass die Gesamtkonfiguration doch nicht so funktioniert, wie man es erwartet hat.

Lange Projektzeiten, hohe Kosten, Frustration und die Vernachlässigung von anderen wichtigen Aufgaben sind oftmals die Folge. Daher hat Fujitsu für die wesentlichen Techniken, die in einer Big-Data-Infrastruktur eine Rolle spielen, integrierte Systeme bestehend aus Server-, Storage und Netzkomponenten wie auch Software entwickelt. Das Ergebnis sind reduzierte Vorlaufzeiten bis zum Produktiveinsatz, ein minimiertes Projektrisiko und geringere Kosten.

Die integrierten Systeme kommen entweder bereits vorinstalliert aus dem Fujitsu-Werk in Augsburg zum Kunden oder aber Fujitsu stellt sogenannte Referenzarchitekturen zur Verfügung, die flexibel an spezielle Kundenbedürfnisse anpassbar sind. Für die verteilte Parallelverarbeitung bietet Fujitsu zum Beispiel das integrierte System Primeflex for Hadoop an, welches ebenso für den Einsatz von NoSQL-Datenbanken genutzt werden kann.

Zum Einsatz der In-Memory-Datenbank SAP HANA wurde das Integrierte System Primeflex for SAP HANA entwickelt, welches sowohl als Single-Node-Konfiguration wie auch als Multi-Node-Konfiguration angeboten wird.

Wer sich für den Einsatz integrierter Systeme entscheidet, hat somit die Möglichkeit, mit einem sehr überschaubaren Aufwand eine funktionierende Big-Data-Lösung zu bekommen. Gerade für mittelständische Unternehmen ist dieser Weg eine richtungsweisende Alternative zum traditionellen „Do-it-yourself“-Ansatz.

* Gernot Fels ist Head of Integrated Systems, Global Marketing bei Fujitsu

(ID:43522373)