Innovative Lösungen setzen die alteingesessenen Datenbankhersteller unter Druck, Hadoop mit ihren relationalen Datenbanksystemen zu verknüpfen. Klassische relationale Datenbanksysteme stoßen im Umfeld von Big Data vielfach an ihre Grenzen, denn große Datenbanken im Multi-Terabyte-Bereich erfordern schnellen Storage, leistungsstarke Server und damit meist auch viele CPU-Lizenzen. Als Ergänzung setzen Unternehmen deshalb inzwischen immer häufiger das Open-Source-Framework Hadoop ein. Apache Hadoop besteht im Kern aus zwei Komponenten:
dem verteilten und hochverfügbaren Hadoop File System (HDFS) und
MapReduce, einer Programmbibliothek für die parallele Verarbeitung der im HDFS abgelegten Dateien.
Foto: Apache.org
Stärken und Schwächen von Hadoop
Hinter MapReduce verbirgt sich grundsätzlich das Programmierparadigma, Rechenaufträge stark parallelisiert auf einer Vielzahl von Rechnerknoten abzuarbeiten. MapReduce basiert dabei im Kern auf Ideen von Google, das den Algorithmus ursprünglich dazu entwickelt hat, um einen eigenen Such-Index aus den Web-Inhalten zu erstellen. Ein wesentliches Ziel des Verfahrens ist die parallele Verarbeitung von Jobs auf einer Low-Cost-Hardware-Infrastruktur bestehend aus Standard-Servern. Neben der Skalierungsfähigkeit liegt der große Vorteil eines solchen Gesamtsystems in seiner Fehlertoleranz: Ausfälle einzelner Maschinen lassen sich jederzeit tolerieren und durch die anderen Rechner auffangen.
Allerdings werden bei der Hadoop-Implementierung für jeden Prozessschritt eigene Betriebssystemprozesse gestartet, so dass das Verfahren grundsätzlich etliche Sekunden Overhead benötigt. Sofern wie bei Google oder Yahoo viele Dateien im Batch gelesen und verarbeitet werden müssen, fällt dieser Overhead nicht ins Gewicht. Interaktive Analysen auf relationalen Datenbanken sind damit aber nicht möglich. Hadoop eignet sich daher zunächst nur für die Speicherung und Vorverarbeitung von Big Data. Für Business Intelligence auf polystrukturierten Daten im HDFS ist das Framework nicht ohne weiteres einsetzbar.
Im Kern sind MapReduce-Jobs Java-Programme. Allerdings bietet Hadoop mit der Zusatzsoftware "Hive" einen relationalen Wrapper. Hive übersetzt klassische SQL-Anfragen in MapReduce-Code und führt ihn aus. Ein Zugriff auf Hadoop via Open Database Connectivity (ODBC) und Java Database Connectivity (JDBC), den herkömmlichen Verbindungswegen in eine relationale Datenbank, ist damit prinzipiell möglich. Allerdings unterstützt Hive nur SQL-Basisfunktionen und arbeitet aufgrund der Verwendung des MapReduce-Frameworks ebenso Batch-orientiert.
Auch wenn Lizenz- und Hardware-Kosten für Hadoop auf den ersten Blick gering erscheinen, gilt es für Anwender, einige weitere Kostenfaktoren zu beachten. Sowohl beim Betrieb als auch für den Zugriff auf die Daten ist Spezialwissen erforderlich, das häufig extern eingekauft werden muss. Zudem fehlen in der Apache-Basisversion für den geschäftskritischen Betrieb notwendige Überwachungs- und Sicherheitsfunktionen. Kommerzielle Distributionen von Cloudera, Hortonworks oder IBM schaffen hier zwar Abhilfe, verursachen allerdings im Gegenzug Lizenz- und Wartungsgebühren, die den Kostenvorteil schrumpfen lassen.
Relationale Datenbanken und Hadoop verknüpfen
Trotz dieser Beschränkungen lassen sich echte Big-Data-Anwendungen (mehrere Terabyte und polystrukturierte Daten) ohne Hadoop kaum wirtschaftlich realisieren. Von daher ist es nicht verwunderlich, dass praktisch alle namhaften Anbieter im Datenbankmarkt das quelloffene Framework auf die eine oder andere Weise in ihr Produktportfolio einbinden. Ein Import-Export-Konnektor für den direkten Datenimport aus Hadoop kann heute bereits als Standard angesehen werden. Basis hierfür ist in der Regel die zu Hadoop gehörende Anwendung "Sqoop" oder eine entsprechende hersteller-spezifische Adaption.
Viele Datenbanksysteme bieten über sogenannte External Tables alternativ die Möglichkeit, über SQL auf Dateien zuzugreifen. Die Daten, die zum Beispiel in Form von Text-Dateien abgelegt sind, werden dabei nicht in die relationale Datenbank geladen. Stattdessen werden die Dateien als "External Tables" deklariert. Man nennt dieses Verfahren auch "Schema-on-Read", da dabei das relationale Schema lediglich als virtuelle Struktur über die Dateien gelegt wird und somit auch unterschiedliche Schemata für ein und dieselbe Text-Datei möglich sind. Diesen Mechanismus haben beispielsweise Oracle, Teradata Aster, EMC Greenplum und Microsoft implementiert.
Eher Import als Interaktion
Da auch beim SQL-Zugriff auf Daten im HDFS über External Tables die Dateien immer komplett gelesen werden, eignet sich das Verfahren hauptsächlich für den Import in die relationalen Systeme und weniger für interaktive Datenzugriffe. Letzteren Aspekt adressieren einige neuentwickelte SQL-Datenbanken wie "Cloudera Impala", "EMC Pivotal HD/HAWQ", "Rainstor" oder "IBM BigSQL". Diese Systeme basieren nicht wie bislang üblich auf einem Unix- oder Windows-File-System, sondern auf dem Hadoop File System (HDFS). Ziel dabei ist es, eine kostengünstige, hochverfügbare, skalierbare Big-Data-Plattform bereitzustellen, die interaktive Abfragen mit SQL ermöglicht. Performance-Gewinne lassen sich dadurch erreichen, dass statt oder zumindest alternativ zum Hadoop-MapReduce-Verfahren eigene SQL-Engines eingesetzt werden, die für kurze Antwortzeiten statt für Batch-Verarbeitung optimiert sind.
Neben der Hadoop-Schnittstelle bieten einige Datenbankhersteller über eigene Implementierungen von MapReduce die Möglichkeit, Datenzugriffe durch spezielle User-Defined Functions innerhalb der relationalen Datenbank zu parallelisieren (In-Database MapReduce). So unterstützt beispielsweise "Teradata Aster" auf MapReduce basierende Built-In und User-Defined Table Functions, die sehr eng auf die eigene ohnehin parallel arbeitende Architektur abgestimmt sind. Auch Oracle bietet seit der Version 11 seines Datenbanksystems die Möglichkeit, mit Hilfe von Pipelined Table Functions das MapReduce-Paradigma zu nutzen. Darüber hinaus hat der US-amerikanische Softwarekonzern eine zu Hadoop Code-kompatible Neuimplementierung angekündigt.
Neben diesen klassischen relationalen Datenbanksystemen verfügen insbesondere NoSQL-Datenbanken, die ebenso wie Hadoop für die Skalierung auf kostengünstiger Hardware konzipiert wurden, über eigene MapReduce-Implementierungen. Beispiele sind "CouchDB", "MongoDB" oder "Riak".
Als richtungsweisend könnten sich hybride Systeme erweisen, welche über intelligente Mechanismen sowohl die klassische relationale Speicherung als auch die Datenablage in Hadoop unterstützen. Das erste System mit einem hybriden Ansatz war "Hadapt", das strukturierte Daten relational, unstrukturierte Daten hingegen im HDFS verwaltet. Für die relationale Verarbeitung wird auf jedem Knoten des Hadoop-Clusters eine Instanz von "PostgreSQL" betrieben. Ebenfalls in die Klasse der hybriden Systeme einzuordnen ist Microsofts "Polybase". Polybase ermöglicht die Integration von Hadoop in das "SQL Server Parallel Data Warehouse" (PDW). Einige Funktionalitäten, die sich effizienter auf der relationalen Seite als in Hadoop abbilden lassen, übernimmt dabei schon heute das PDW. Für die Zukunft ist eine Erweiterung des kostenbasierten Optimierers geplant, um dynamisch den Datenzugriff zu optimieren.
Wie reif ist Hadoop?
Hadoop ist längst den Kinderschuhen entwachsen und stellt eine sinnvolle Ergänzung der vorhandenen Datenhaltungssysteme für Big-Data-Anwendungen dar. Insbesondere bei Anwendungsfällen, in denen es um große Mengen unstrukturierter Daten geht, führt kaum ein Weg an dem Open-Source-Framework beziehungsweise einer der kommerziellen Distributionen vorbei.
Auch eine Integration mit vorhandenen relationalen Datenbanksystemen ist bereits heute meist problemlos möglich. Darüber hinaus werden Hadoop-basierte Systeme auch für die Ablage strukturierter Massendaten immer interessanter. Ähnlich wie beim hierarchischen Speicher-Management auf Ebene der Datenträger könnte die relationale Datenhaltung im Big-Data-Umfeld bald durch Hadoop-Komponenten kosten- und leistungsmäßig optimiert werden. (ba/sh)