Große Datenmengen im Griff: Massiv Parallel Processing versus Hadoop

Inhaltsverzeichnis

Die Datenmengen in Unternehmen nehmen mittlerweile unglaubliche Ausmaße an; sie liegen nicht selten im Petabyte-Bereich. Wesentliche Ursache dieser Datenflut ist die Digitalisierung aller kaufmännischen und technischen Prozesse, beispielsweise in Form von Sensordaten aus Industrieanlagen, Geo- und Telematikdaten von Fahrzeugen oder RFID-Daten aus der Logistikkette. Der fortschreitenden Vernetzung der Systeme im Internet der Dinge geschuldet, wird diese Entwicklung noch weiter voran getrieben. Hinzu kommen nutzergenerierte Daten auf Social-Media-Plattformen, Multimedia-Inhalte, Fotos oder HD-Videos.

Es ist eine Herausforderung für Unternehmen, diese strukturierten und unstrukturierten Daten aus heterogenen Quellen ihrer Relevanz entsprechend zu erfassen, auszuwerten und für Business-Entscheidungen bereitzustellen – am besten noch in Echtzeit. Die Daten aus Webshops, Fahrzeugen, Maschinen oder Smartphones geben dann Auskunft über Konsum, Verhalten und Vorlieben von Kunden, den Status von Maschinen, Orte und Bewegungen und viele andere Dinge. Verknüpft mit kontextbezogenen Informationen wie Kundenhistorie oder Wetter lassen sich daraus Prognosen erschließen.

Doch die gebräuchlichen Data-Warehouse-Systeme sind in die Jahre gekommen und mit Big-Data-Analysen schlichtweg überfordert. Hier helfen Massive Parallel Processing (MPP) und/oder das Framework Hadoop mit seinem umfassenden Ökosystem weiter. Beide Ansätze teilen komplexe und große Datenmengen in kleinere Einheiten auf und verarbeiten sie parallel auf mehreren verteilten Rechnerknoten. Allerdings unterscheiden sie sich in der Natur ihrer Hardware und Software.

Massive Parallel Processing (MPP): Proprietäre Systeme und natives SQL

MPP-Anwendungen sind nur als proprietäre Subsysteme mit eigener Hardware und Software verfügbar. Sie bestehen aus einer Vielzahl parallel arbeitender Serverknoten, die über leistungsfähige Switches miteinander verbunden sind. Jeder Node ist mit Prozessoren, Storage und I/O-Kanälen ausgestattet und bearbeitet mit diesen Ressourcen einen Teil der Gesamtdaten. In dieser so genannten Shared-Nothing-Architektur werden Anfragen mit speziellen Partitionierungsverfahren und Algorithmen an die einzelnen Knoten des Datenbank-Clusters verteilt. Jeder Knoten verarbeitet lokal in seinem Hauptspeicher seinen Datenanteil an der Abfrage; eine Art "Master-Knoten" fasst die einzelnen Ergebnisse am Ende zusammen. Die Daten sind allerdings zunächst vorzubereiten, da MPP-Systeme nicht mit unstrukturierten Daten arbeiten können.

MPP-Systeme zeichnen sich durch die hohe I/O-Leistung aus, mit der die einzelnen Knoten parallel auf die partitionierten Daten zugreifen. Damit können sie auch in kurzer Zeit sehr große Datenmengen verarbeiten. Zudem sind sie weitaus besser skalierbar als klassische Datenbanksysteme, da sich ihre Rechen- und Speicherkapazität durch das Hinzufügen neuer Knoten beziehungsweise Server einfach erweitern lässt. Weiterer Vorteil: Potenziell sind mit MPP-Datenbanken extrem große In-Memory-Speicher möglich, wenn man den gesamten verfügbaren Cluster-Storage nutzt.

MPP-Appliances sind proprietäre Systeme, da jeder Hersteller sein Angebot über Algorithmen und die technische Abstimmung der Komponenten für die speziellen Anforderungen seines Big-Data-Anwendungsfalls optimiert. Für die Nutzer spielt das aber keine Rolle, da MPP-Systeme nach außen über SQL kommunizieren und auch SQL-basierte Business-Intelligence-Tools unterstützen. Zudem entlasten sie den Datenbank-Administrator durch interne Verfahren, automatische Datenverteilung und optimiertes Workload-Management.

Da die Anzahl der CPU-Kerne je System von wenigen Hundert bis zu mehreren Tausend reicht, müssen Unternehmen viel Geld für eine MPP-Produkt in die Hand nehmen. Sie können hier durchaus mit mittleren sechsstelligen Beträgen rechnen. Beispiele auf dem Markt sind IBM Netezza, EMC Greenplum, HPE Vertica, Oracle Exadata, Microsoft Analytics Platform System, Teradata Aster Data nCluster oder auch SAP HANA.