Getrennt marschieren

Google hat gezeigt, dass sich extrem große Datenmengen in einem verteilten Dateisystem effizient verarbeiten lassen, wenn man die Verarbeitungsroutinen selbst verteilt. Der Internetkonzern stellte dieses Vorgehen für sein Dateisystem (siehe „Alle Links“) und die Verarbeitung mit Map-Reduce bereits 2003 vor. Doug Cutting und andere nutzten dieselben Prinzipien bei der Suchmaschine Nutch, die ins Hadoop-Framework der Apache Foundation mündete.

Hadoop hat seit 2008 überall dort Erfolg, wo große, unstrukturierte Datenberge zu bewegen sind. Kostenlos und über Rechnergrenzen hinweg skalierend, ist es auch für Firmen interessant, die zwar viele Daten sammeln und verarbeiten, sich ein großes, kommerzielles Produkt aber nicht leisten können oder wollen. Damit dringt Hadoop in die Domänen klassischer ETL-Software (Extract Transform Load) und des Data Warehousing ein.

Facebook versah Hadoop mit Hive, einer SQL-ähnlichen Abfragesprache, die das mühsame Schreiben geeigneter Map- und Reduce-Jobs automatisierte. Dadurch konnten Datenanalysten in nahezu gewohnter SQL-Manier Abfragen formulieren. Dieses Vorgehen eignet sich für Auswertungen, die zwischen wenigen Minuten und einigen Stunden dauern. Systembedingt sind Antwortzeiten im Millisekundenbereich, wie man sie von konventionellen relationalen Datenbanksystemen kennt, mit Hive und Hadoop nicht zu erreichen.

Inspiriert von Googles Vorschlägen

Immer weniger Anwender und IT-Abteilungen möchten diese Einschränkung akzeptieren: Sie wollen auch für interaktive Abfragen dasselbe System nutzen und nicht auf den zeitintensiven Import in Datenbanken warten. „Real-Time-Analyse für Big Data“ lautet das immer häufiger zu vernehmende Buzzword für Abfragen mit einer Antwortzeit von bis zu 20 Minuten.

Googles 2010 veröffentlichter Vorschlag „Dremel: Interactive Analysis of Web-Scale Datasets“ von Sergey Melnik und anderen stellte einen ersten Ansatz für ein hybrides System aus Map-Reduce und SQL vor. Neben der verteilten Ausführung von SQL-Queries beschreibt er ein komprimierbares, spaltenorientiertes Datenformat. Heute verwendet Google Dremel nicht nur intern, sondern bietet es auch als eigenständiges Produkt mit dem Namen BigQuery für Kunden seiner App Engine kommerziell an.

Im selben Jahr wie Google stellte Daniel Abadi seine Version einer verteilten Datenbank im Geiste von Dremel vor. Er griff dessen Kernidee auf und kombinierte Hadoops skalierbares Dateisystem mit der Datenlokalität verteilter PostgreSQL-Instanzen (siehe Abb. 1). Ein Prototyp entstand als HadoopDB [a], der sowohl von der Skalierbarkeit des Map-Reduce-Verfahrens als auch von der Abfragemächtigkeit einer modernen SQL-Datenbank profitierte.

Kurz nach seiner Promotion gründete Abadi mit anderen die Firma Hadapt. Ihr zentrales Produkt ist die Adaptive Analytical Platform mit der 2010 präsentierten SQL-Engine für interaktive Abfragen auf Hadoop-Basis.

Auch andere Firmen haben die Chancen eines solchen Hybrid-Produkts erkannt. Besonders jene, die sich früh mit Hadoop-Consulting einen Namen gemacht hatten, sprangen auf den Zug auf. So präsentierte Cloudera im Dezember 2012 seine Version einer hybriden Ad-hoc-Abfrage-Engine mit Hadoop-Anbindung als „Impala“ [b]. Es nutzt den bereits von Hive eingeführten Metastore für die Schema-Verwaltung und den SQL-Dialekt HiveQL.

Eigene SQL-Engines statt PostgreSQL

Impalas Quellcode ist unter der Apache-Lizenz bei GitHub verfügbar und gehört zu Clouderas kommerziellem Produkt „Enterprise Real Time Query“. Die Impala-Architektur stammt von Marcel Kornacker, der bereits Googles F1 Query Engine maßgeblich entwickelte. Das derzeit verfügbare Impala 1.0 ist vollständig in Clouderas Manager und die Hadoop-Distribution CDH integriert. Es wird parallel zu Hive installiert und zeigt für Abfragen mit kleinen Ergebnismengen deutliche Geschwindigkeitsvorteile (siehe Abb. 2). Anders als bei HadoopDB und Hadapt laufen in Impala keine PostgreSQL-Instanzen auf den DataNodes, sondern eigene Query-Planner und -Execution-Engines (siehe Kasten „Impala testen“).

Ein ähnliches Konzept wie Clouderas Impala verfolgt die Firma MapR aus San José, die 2012 das Drill-Projekt [c] bei der Apache Foundation eingereicht hat. Als Unterstützer konnten unter anderem Ted Dunning (MapR-Angestellter und Initiator von Apache Mahout) und Chris Wensel (CEO von Concurrent und Autor der Cascading API) gewonnen werden. Ziel des Projekts ist eine Open-Source-Version von Googles Dremel. Neben einer Query Engine, die ANSI-SQL nach dem Standard 2003 versteht, soll Drill die für HadoopDB formulierten hybriden Anwendungsfälle unterstützen. Architektonisch setzt es auf das erst vor Kurzem in Hadoop eingeführte YARN-Interface. MapR möchte Drill durch vollständige ODBC- und JDBC-Treiber stärker mit bestehenden Softwaresystemen verzahnen. Bislang gibt es noch keine lauffähige Version. Ein erster Prototyp findet sich bei GitHub, ein Beta-Release soll im dritten Quartal 2013 erscheinen.

Mit der Stinger-Initiative [d] versucht das aus Yahoo ausgegründete Hortonworks, Hive um Komponenten für Ad-hoc-Abfragen zu erweitern. Das Projekt möchte mit der Community und Firmen wie Microsoft und SAP viel erreichen: Das Hive-Typensystem soll sich stärker an SQL orientieren, Stinger soll einzelne Abfragen optimieren, mit dem ORC-Dateiformat Daten spaltenorientiert speichern und mit Tez ein neues Framework für die optimierte Job-Ausführung einbringen, das YARN weiterentwickelt. All dies soll Hive selbst fit machen für eine hybride Zukunft. Aktuelle Patches für die kommenden Hive-Releases zeigen bereits erste Erfolge dieser Bemühungen.

Ausgangspunkt YARN und Pig

Tajo [e] ist der jüngste Vertreter eines von Dremel inspirierten Hybrid-Analyse-Systems, dessen Core-Entwickler aus Südkorea kommen. Das als Apache Incubator eingereichte Projekt nutzt nicht Hive wie Impala oder Stinger, sondern möchte eine Alternative schaffen. Es verwendet das YARN-Framework von Hadoop und ist bei GitHub im Quellcode erhältlich. Sein Funktionsumfang umfasst zurzeit einfache CREATE TABLE- und SELECT-Statements.

Einen ähnlichen Weg wie Hadapt geht die junge Firma Citus Data [f], die von Absolventen der Stanford University gegründet wurde. Mit der rein kommerziellen CitusDB stellen sie ein System vor, das der HadoopDB-Architektur in weiten Teilen ähnelt. Sie nutzt die von PostgreSQL 9.1 eingeführten externen Tabellenreferenzen (foreign data wrapper). Dabei verteilt man die Tabellen in einem Cluster, der CitusDB-Master fragt sie ab. Ähnlich wie bei Drill gibt es bei CitusDB die Möglichkeit, Daten aus einer MongoDB-Instanz abzufragen, indem man die erwähnten externen Tabellenreferenzen nutzt.

Mit HStreaming [g] betritt ein deutsches Gründerteam die kalifornische Start-up-Szene rund um die Echtezeitverarbeitung von Big Data. Das gleichnamige Produkt läuft auf den Hadoop-Distributionen von Cloudera, Hortonworks, IBM, MapR und EMC Greenplum. Neben einer zu bezahlenden Cloud- und Enterprise-Edition bietet HStreaming eine kostenlose Community-Ausgabe an. Anders als Stinger, Impala, Drill, Tajo und CitusDB konzentriert es sich auf Ad-hoc-Abfragen mit dem Pig-Framework der Apache Foundation. Es nutzt also nicht SQL als Sprache, sondern Pig Latin. Die Community-Edition von HStreaming lässt sich nach Registrierung anhand der Installationsanleitung mit wenigen Handgriffen einrichten.

Fazit

Im Moment schießen neue Entwicklungen wie Pilze aus dem Boden. Einige davon preisen Zukünftiges an, als handele es sich um bereits vorhandene Funktionen. Doch noch steht die Entwicklung im Bereich der verteilten, SQL und Map-Reduce kombinierenden Analysesysteme am Anfang. Neue Frameworks wie YARN ergänzen das auf Batch-Verarbeitung ausgelegte Map-Reduce von Hadoop. Der Konkurrenzdruck zwingt die Anbieter, verstärkt freie Produkte zu entwickeln. Interessierte erhalten so bereits heute Einblicke in die Technik von morgen.

Ramon Wartala

ist Diplom-Informatiker und arbeitet als Director Technology für die Performance Media Deutschland GmbH. Anfang 2012 erschien sein Buch „Hadoop – Zuverlässige, verteilte und skalierbare Big-Data-Anwendungen“.

Alle Links: www.ix.de/ix130810

time hive -e 'select count(*) 
  from zipcode_incomes 
    where zip="59101";' 

time impala-shell --impalad=127.0.0.1:21000
  --query="select count(*) from zipcode_incomes
    where zip='59101'" 

(ck)