Abfragegeschwindigkeit von Hive und Impala messen
Schneller, höher und breiter
Wer Big-Data-Bestände mit dem Tempo eines Data Warehouse analysieren will, muss einigen Aufwand treiben. Richtig konfigurierte Benchmarks ermitteln das geeignete Analysetool.
Daten aus Big-Data-Systemen genauso schnell zu ermitteln wie aus relationalen Datenbanken, ist immer noch der Heilige Gral der Datenanalyse. Systeme wie Hive und Impala mussten hier nachziehen, um die gestiegenen Anforderungen moderner Business-Intelligence- (BI) und -Analyse-Software wie Tableau, Qlik oder Microsoft Power BI zu erfüllen. Einfache Batch-Verarbeitung, wie sie vor 13 Jahren mit dem MapReduce-Verfahren zuerst bei Google und später in der Open-Source-Community mit Apache Hadoop Einzug hielt, lockt keinen Analysten mehr hinter dem Ofen hervor. In Zeiten von Streaming Data und Real Time Analysis ist das stunden- oder gar tagelange Warten auf Analyseergebnisse inakzeptabel.
Als moderner Anwender möchte man Daten jeglicher Art – egal ob kleine oder große Mengen – schnell, einfach und vor allem explorativ verarbeiten. Dabei helfen Visualisierungstools wie die schon erwähnten Power BI, Qlik und Tableau. Über definierte Konnektoren gelangt man zur Datenquelle und bekommt anschließend eine Übersicht über die verfügbaren und nutzbaren Tabellen. Diese BI-Tools abstrahieren die Komplexität und die Abfragesprache der jeweiligen Datenbank. Basierend auf dem verwendeten Datenbankkonnektor werden die Abfragen für den jeweiligen SQL-Dialekt generiert. Im Extremfall ist die Modellierung einer einfachen Operation im BI-Frontend auch nicht mit nur einer Abfrage möglich, sondern muss mit mehreren Querys dargestellt werden. Wie sich diese Abfragen für eigene Benchmark-Tests nutzen lassen, zeigt der Artikel.
Schnelle Antworten gewünscht
Ähnlich verhält es sich mit dem gleichzeitigen Zugriff verschiedener Nutzer. Setzen ganze Abteilungen so ein System ein, stellt sich die Frage nach einem Abfrage- und Datencaching und danach, wie viele Nutzer noch performant auf das Zielsystem zugreifen können.
Relationale Datenbank- oder Data-Warehouse-Systeme verfügen vielfach über verschiedene technische Optimierungsmethoden für Abfragen auf die unterschiedlichen Datenbestände. In der Regel werden Indexe auf Schlüsselfelder von Tabellen generiert und im Hauptspeicher hintergelegt, um einen schnelleren Zugriff auf die eigentlichen Daten zu ermöglichen. Noch schneller wird es, wenn sich nicht nur ein Zeiger auf die Daten, sondern gleich ganze Teile der Daten im Hauptspeicher befinden.
Hadoop ist bekanntlich keine Datenbank, sondern ein verteiltes Dateisystem (HDFS) und ein Ressourcenmanager, der Berechnungen und Datenanalysen verteilt ausführt (YARN). Damit innerhalb dieses Rahmens SQL-artige Abfragen auf Tabellen mit mehreren Milliarden Zeilen effizient ablaufen können, gehen die Hersteller teilweise recht unterschiedliche Wege.
Die Data-Warehouse-Software Hive war der erste Versuch von Facebook, die manuelle Erstellung von MapReduce-Code durch SQL-artige Abfragen abzulösen – SQL-artig, weil die Sprache HiveQL sich auch nach fünf Jahren nicht strikt an den SQL-92-Standard hält, wohl aber daran orientiert. Nachdem Hadoop mit YARN ein Fundament für Nicht-MapReduce-Anwendungen bekommen hatte, konnte Hive (mittlerweile als Teil der Apache Foundation) sich dieser moderneren Ausführungsmethoden bemächtigen.
Hive: Von MapReduce zu LLAP
Mit der Stinger-Initiative versuchen Microsoft und Hortonworks seit 2013, die Geschwindigkeit des Hive-Systems zu steigern. Entwickelt wurden im Zuge dessen die Tez Execution Engine, das neue Dateiformat Optimized Row Columnar und zahlreiche Analysefunktionen wie die Möglichkeit, Teilabfragen (Subqueries) auszuführen (siehe ix.de/ix1802124).
Apache Tez erschien 2014 als Incubator-Projekt. Ziel dieser Execution Engine ist es, Datenanalyse in Form von DAGs (gerichteten azyklischen Graphen) zu modellieren und dadurch Abfragen, die mit MapReduce vormals mehrere Durchläufe (Stages) benötigten, in einem Durchgang auszuführen. Darüber hinaus erlaubt Tez das Speichern von Zwischenergebnissen einer Abfrage, zum Beispiel für die Aggregation oder Filterung von Daten, direkt im Hauptspeicher und spart so das Erstellen zeitkritischer Zwischenergebnisse auf der Festplatte. Beim sogenannten Vectoring werden dabei nicht nur einzelne Zeilen einer (Teil-)Ergebnismenge im Hauptspeicher vorgehalten, sondern ganze Bündel von Zeilen. Abfragezeiten ließen sich mit Tez in vielen Fällen von Stunden auf Minuten reduzieren.
Doch die (IT-)Welt hört nicht auf sich weiterzudrehen und je schneller man die Antworten auf seine (Ab-)Fragen bekommt, desto schneller lassen sich neue Fragen stellen. Das Apache-Spark-Projekt hatte es vorgemacht: Wenn die Daten intelligent im Hauptspeicher gecacht werden, lässt sich noch mehr Geschwindigkeit bei der Abfrage auf großen Datenmengen erzielen. Der Verfall der Hauptspeicherpreise, der Preiskampf der Cloud-Anbieter und die Hoffnungen in Daten als das „neue Öl“ wirken dabei als Katalysator.
Ebenso wie die Stringer-Initiative startete Cloudera 2012 mit Impala eine eigene Version einer massiv parallelen Datenverarbeitungs-Engine. Wie bei Tez war das Ziel, die Verarbeitung vieler Daten zu beschleunigen und das alte MapReduce-Paradigma im Hadoop-Kontext abzulösen. Kernidee war es, die Übersetzung von SQL in Java-Code und seine Ausführung in verteilten JVMs durch C++-Code zu ersetzen. Wichtigste Technik bei diesem Übergang war das LLVM-Framework (Low-Level Virtual Machine) von Chris Lattner und Vikram Adve. Damit generiert man Datenbankabfragen als C++-Code für die LLVM, in der sich Code weiter optimieren lässt, sodass die Impala-Query-Engine den JIT-kompilierten Code direkt ausführen kann. Impala nutzt für das Bereitstellen ein verteiltes System von Daemon-Prozessen.