Was ist Hadoop und wie fügt sich SQL dort ein?

Hadoop ist ein Open-Source-Framework, das Anfang der 2000er Jahre zur Speicherung und Verarbeitung von Big Data entwickelt wurde. Durch parallele Verarbeitung auf handelsüblicher Hardware werden die Berechnungen auf riesige Rechner-Cluster verteilt.

Hadoop-Jobs werden normalerweise in der Programmiersprache Java geschrieben. Dies kann jedoch kompliziert sein, und Analysten bevorzugen im Allgemeinen noch immer SQL. Daher wurden mehrere Rechner entwickelt, die die Programmierung in SQL mit Ausführung auf einem Hadoop-Cluster ermöglichen.

Die Hauptstärke von Hadoop liegt in seiner Modularität. Traditionelle relationale Datenbankmanagementsysteme (RDBMS) und MPP-Datenzentren bündeln ihre Datenzentren, Rechner und Datenmanagementsysteme in einer Plattform. Bei Hadoop arbeiten all diese Komponenten getrennt und unabhängig voneinander. Als Software-Kategorie ist Hadoop gigantisch, und das gesamte Ökosystem besteht aus Dutzenden von Software-Anbietern, Support-/Service-Anbietern und Anwendungen.

Im Gegensatz zu vielen anderen analytischen Datenzentrumsangeboten ist die Software von Hadoop so konzipiert, dass sie auf handelsüblicher Hardware läuft. Daher arbeitet auch die gesamte Software-Architektur separat und unabhängig von der Hardware.

Diese beiden Eigenschaften zusammengenommen bedeuten, dass ein erfahrenes DBA- oder DevOps-Team jeden einzelnen Teil seiner Datensammlung mit Hadoop individuell anpassen kann. Deshalb sollten Sie, wenn Sie über einen Hadoop-Cluster verfügen, die jeweiligen Vor- und Nachteile der verschiedenen Anbieter kennen.

Welche Vorteile hat die Verwendung von SQL on Hadoop?

Kosteneffizienz und Flexibilität

Einer der Hauptvorteile von Hadoop ist, dass es sich um eine Open-Source-Software handelt, welche für den Betrieb auf handelsüblicher Hardware – also nicht-proprietärer Hardware, die nicht an einen spezifischen Softwareanbieter gebunden ist – entwickelt wurde.

Diese Eigenschaft ist besonders wichtig, da sie es Unternehmen ermöglicht, ihrem Hadoop-Cluster weitere Rechner zu vergleichsweise geringen Kosten hinzuzufügen. Unternehmen können außerdem jederzeit verschiedene Hadoop-Technologien austauschen, um ihre Prozesse zu optimieren, müssen dabei aber nicht ihren gesamten Hardware-Stack ersetzen.

Beispielsweise können Unternehmen, die ihren Hadoop-Cluster als Datenzentrum bereitstellen wollen, eine SQL-Engine wie Hive hinzufügen, um ihre Daten über SQL abzufragen. Sie können anschließend Hive durch eine andere SQL-Engine wie Presto oder Spark ersetzen, ohne ihre Hardware ändern zu müssen. Diese Art von Flexibilität ist aufgrund der Interoperabilität von Hadoop-basierten Systemen viel größer als bei anderen Anbietern von On-Premise-Datenzentren.

Agilität

Hadoop-Benutzer müssen kein Schema deklarieren, wenn sie Daten speichern. Dies macht das verteilte Dateisystem von Hadoop (Hadoop Distributed File System, HDFS) zu einer kostengünstigen Möglichkeit für Unternehmen, riesige Mengen unstrukturierter Daten zu speichern und erst dann ein Schema zu deklarieren, wenn sie die Daten analysieren wollen. Dadurch entfällt die Notwendigkeit, beim Import von Daten in den Cluster im Voraus ein potenziell einschränkendes Schema zu deklarieren.

Die Infrastruktur von Hadoop geht weit über SQL hinaus und ist mit vielen verschiedenen Programmiersprachen kompatibel. Sie wird von vielen Entwicklern bevorzugt, die maschinenlernende Analysen durchführen und mehrere Programmiersprachen parallel auf demselben Cluster ausführen wollen.

Vor der Entwicklung von SQL-Engines erforderte das Schreiben von Code zur Ausführung auf Hadoop spezielle Kenntnisse. Dank des Einzugs von SQL-Engines in Hadoop konnten Unternehmen jedoch ANSI-konforme SQL auf ihren Hadoop-Clustern ausführen. Die Einführung dieser Technologien ermöglicht es Geschäftsanwendern, beliebige SQL-basierte Berichtstools mit ihrem Hadoop-Cluster zu verbinden.

Zuverlässigkeit und Leistungsfähigkeit

Hadoop, und speziell das Hadoop Distributed File System (HDFS), wird aus zwei Gründen häufig in Unternehmensdaten-Stapelspeichern eingesetzt. Zum einen ist HDFS so konzipiert, dass es erstaunlich fehlertolerant ist (auch bei Ausfall von Rechnern im Cluster kann weiterhin auf Daten im Cluster zugegriffen werden). Zum anderen können Entwickler dank des MapReduce Frameworks von Hadoop extrem große Datenmengen verarbeiten.

Beliebte SQL-auf-Hadoop-Engines

Hadoop-Architektur

„Als man noch Ochsen für schwere Zugarbeiten einsetzte, versuchte man nicht, einen größeren Ochsen zu züchten, nur weil ein Ochse einen Stamm nicht vom Fleck bewegen konnte. Wir sollten also nicht größere Computer, sondern vielmehr größere Computersysteme bauen.“– Grace Hopper

Die Schöpfer von Hadoop leisteten Pionierarbeit bei mehreren Konzepten, welche seither die Innovation im Big-Data-Umfeld vorangetrieben haben.

Horizontale Skalierung

Das Konzept von Hadoop beruht auf der Nutzung der linearen horizontalen Skalierung. Das bedeutet, dass dem Datenbanksystem weitere Rechner derselben Größe hinzugefügt werden, anstatt jeden einzelnen Knoten zu vergrößern.

Dieses Prinzip gewährleistet nicht nur eine einfache und effektive Skalierung des Hadoop-Clusters durch seine Nutzer, sondern auch dessen kontinuierliche Leistungsfähigkeit, auch und gerade wenn er vergrößert wird.

Zugriff ohne Datenbewegung

Hadoop war ursprünglich als unstrukturierter Datenpool konzipiert, in dem Rohdaten vor der Weiterleitung in ein RDBMS gespeichert werden konnten. Dies war ein Segen für mit Java vertraute Entwickler, da sie direkt auf die unstrukturierten Daten zugreifen und Analysen durchführen konnten, ohne die Daten in eine relationale Datenbank importieren zu müssen. Geschäftsanwender mussten jedoch darauf warten, dass die Daten bereinigt und in eine relationale Datenbank verschoben wurden. Erst dann konnten sie mit SQL darauf zugreifen und die Daten verwenden.

Dank der Einführung von leistungsstarken SQL-Engines für Hadoop können Analysten und Geschäftsanwender nun direkt auf Daten aus dem Cluster zugreifen und müssen nicht mehr darauf warten, dass die Daten verschoben werden. Die Analyse kann hier näher an Echtzeit durchgeführt werden, was die Notwendigkeit eines dedizierten Datenzentrums für Analysten reduziert und die Datenarchitektur eines Unternehmens vereinfachen kann.

Schema-on-Read

In älteren Systemen musste vor dem Import der Daten in die Datenbank ein Schema deklariert werden, das angab, wie die Daten in der Datenbank strukturiert werden sollten. Die Erstellung eines Schemas war ein entscheidender Teil der Extraktions-, Transformations- und Lade-Prozesse (Extract, Transform, Load – ETL). Diese waren erforderlich, um Daten korrekt in eine Datenbank zu importieren.

Dieser als Schema-on-Write bekannte Prozess war die einzige Methode für den Import von Daten in eine Datenbank. Zu den Vorteilen eines Schema-on-Write-Frameworks gehörte, dass die Daten in der Datenbank robust (alles, was importiert wurde, galt als nützlich für Analysten), konsistent (alle Daten waren auf die gleiche Weise strukturiert) und sauber (für Endbenutzer zugänglich) waren.

Das Schema-on-Write-Konzept hat jedoch einige bedeutende Nachteile. Die für den ETL-Prozess verantwortliche Person muss wissen, wie die Daten verwendet und analysiert werden sollen, bevor sie importiert werden. Das führt in der Regel zu einer eingeschränkten Verfügbarkeit der Datensätze. Es kann vorkommen, dass Daten gelöscht oder nicht erfasst werden, weil es dafür noch keinen eindeutigen Anwendungsfall gibt, was eine historische Analyse verhindert.

Hadoop und andere moderne Datenpools stellen dieses Konzept auf den Kopf. Anstatt zu erklären, wie genau die Daten in der Datenbank erscheinen sollen, werden Daten aus externen Quellen in einen Datenpool eingebracht und erst dann transformiert, wenn sie gelesen werden sollen. Dieses neue Framework wird Schema-on-Read genannt, da die Analysten das Schema dann definieren, wenn die Daten zur Analyse aus der Datenbank ausgelesen werden.

Das Schema-on-Read-Framework erfordert zwar mehr Vorarbeit von Analysten, um die Daten zu verstehen, bevor sie ein Schema für die Analyse deklarieren. Aber es ermöglicht mehr Vielseitigkeit und Flexibilität bei der Analyse und stellt sicher, dass keine Daten zurückgewiesen werden, weil sie nicht sofort schematisiert werden können. Mit dem Schema-on-Read-Konzept haben Analysten außerdem die Möglichkeit, das Schema zu wählen, das für die Art der durchgeführten Analyse am sinnvollsten ist. Sie müssen die Analyse nicht an das Schema anpassen, sondern können stattdessen das Schema auf die Analyse zuschneiden.

Die drei Hauptkomponenten der Hadoop-Architektur

Die Hadoop-Architektur kann sehr schnell sehr komplex werden. Dennoch besteht jedes moderne Hadoop-Deployment aus drei Hauptkomponenten:

  • Hadoop Distributed File System (Speicherung)
  • MapReduce (Verarbeitung)
  • Apache Hadoop YARN (Ressourcenallokation)

Das verteilte Dateisystem von Hadoop (Hadoop Distributed File System, HDFS)

Eine der größten Herausforderungen, die zur Einführung von HDFS führte, war die Notwendigkeit, riesige Datenmengen so zu speichern, dass die Leistung bei der Skalierung der Speicherung nicht beeinträchtigt wird.

Laden von Daten in das HDFS

HDFS wurde als Lösung geschaffen, um einzelne Daten auf viele einzelne Maschinen zu verteilen und sie zu indizieren, damit sie schnell abgerufen und verarbeitet werden können.

Aus verschiedenen Datenformaten bestehende Rohdaten werden in HDFS geladen und in bitgroße Dateien partitioniert, die als Blöcke bezeichnet werden. Diese Blöcke werden dann gleichmäßig über den gesamten Cluster hinweg auf einzelne, als Datenknoten bezeichnete Speichergeräte verteilt. Die Position jedes einzelnen Blocks wird anschließend einem spezialisierten Knoten namens NameNode zugeordnet. Der NameNode kennzeichnet die Positionen der Blöcke innerhalb des Clusters und verwaltet zugleich den Zugriff auf diese Datenknoten.

Dreifache Replikation

HDFS repliziert jeden Block dreimal und speichert Kopien von jedem Block auf separaten Datenknoten. Dieses Replikationsmuster macht HDFS erstaunlich fehlertolerant, denn bei Ausfall eines Geräts (was im großen Maßstab fast unvermeidlich ist) sind die Daten im gesamten Cluster weiterhin verfügbar. Das Replikationsmuster garantiert, dass HDFS bei Verlust einer Kopie diese Kopie automatisch an einem anderen Ort im Cluster repliziert, wodurch eine gleichbleibend hohe Verfügbarkeit der Daten gewährleistet wird.

MapReduce

MapReduce ist das Framework, welches die über viele verschiedene Knoten im HDFS verteilten Daten verarbeitet. MapReduce ist, wie der Name schon sagt, eine Kombination aus zwei Phasen:

  • Map-Phase, welche die Operation auf den einzelnen, in HDFS gespeicherten Blockdateien ausführt, und
  • Reduce-Phase, welche die Ergebnisse kombiniert.

Datenvorbereitung vor dem MapReduce-Prozess

Bevor MapReduce ausgeführt werden kann, müssen die für die MapReduce-Phasen benötigten Daten lokalisiert und für die Verarbeitung vorbereitet werden. Bei der Ausführung einer MapReduce-Aufgabe werden die im HDFS in Blöcken gespeicherten Daten lokalisiert und deren Format bestimmt. Auf diese Weise kann MapReduce eine Vielzahl von in HDFS gespeicherten Dateiformaten verarbeiten.

Da die Daten aus einer einzelnen Datei auf Blöcke aufgeteilt sind, wird eine andere Funktion namens InputSplit aufgerufen. Diese teilt die Daten in kleinere, definierte Blöcke zur Verarbeitung auf. Eingabe-Splits enthalten selbst keine Daten, sondern verwenden einen sogenannten Byte-Offset. Damit kann MapReduce ein logisches Muster für die Aufteilung der Dateien festlegen.

Map-Phase

Nachdem die Eingaben lokalisiert und aufbereitet wurden, sind die Daten für die Map-Phase bereit. Während der Map-Phase werden die Eingaben auf den einzelnen Knoten im Hadoop-Cluster alle gleichzeitig verarbeitet. Dieser Prozess wird als Map bezeichnet. All diese Maps werden anschließend gemischt, d. h., die Maps werden sortiert und auf den richtigen Knoten für die Reduce-Phase platziert.

Reduce-Phase

Nachdem die Daten entsprechend auf die richtigen Knoten partitioniert wurden, aggregiert die Reduce-Phase alle Einzelergebnisse einer Map-Phase zu einer einzigen Ausgabe. Es handelt sich dabei im Wesentlichen um eine zusammenfassende Operation, die alle Ergebnisse dieser Daten in einer Antwort kombiniert.

Beispiel für eine MapReduce-Operation

Nehmen wir zum Beispiel an, dass dieser Artikel über Hadoop als Datei in HDFS eingelesen wurde und Sie eine MapReduce-Aufgabe ausführen wollten, um herauszufinden, wie oft das Wort „Hadoop“ darin vorkam. Zuerst würde die Datei in HDFS eingelesen und in einzelne Blockdateien zerlegt werden. Diese Blöcke werden dann in einzelne Eingabe-Splits aufgeteilt. Dadurch wird sichergestellt, dass die Wörter in diesem Artikel nicht zertrennt werden (würde z. B. eine Instanz von Hadoop zwischen zwei Blockdateien in „Ha“ und „doop“ aufgeteilt, würde diese Instanz nicht mitgezählt werden).

Nachdem die Eingabe-Splits gezählt wurden, wird jedem Knoten auf dem Cluster ein Eingabe-Split zugewiesen. Dieser zählt unabhängig die Instanzen von „Hadoop“ innerhalb des ihm zugewiesenen Eingabe-Splits. Die Ergebnisse dieser einzelnen Map-Phasen in Form von Zählwerten werden dann gemischt und während der Reduce-Phase der Operation aggregiert. So wird die Anzahl aller Fälle ermittelt, in denen Hadoop in diesem Artikel erscheint.

IBM verwendet ein großartiges Beispiel vom Zensus im Römischen Reich. Dabei reisten Zensus-Beauftragte in alle Städte des Römischen Reiches, zählten die Personen in dieser Stadt und kehrten dann in die Hauptstadt zurück. Dort wurden die Ergebnisse anschließend zu einer Gesamtzahl der Bevölkerung im Römischen Reich aggregiert.

Apache Hadoop YARN – Yet Another Resource Negotiator

Vor dem Start von Hadoop 2.0 und der Einführung von YARN wurde MapReduce auch zur Verwaltung von elementaren Workload-Management- und Job-Planungs-Aufgaben verwendet. Das machte die Ausführung von analytischen Anwendungen, die nicht von MapReduce stammten, auf denselben Knoten sehr kompliziert. Tatsächlich mussten Architekturen, die auch analytische Anwendungen beinhalteten, außerhalb von Hadoop ausgeführt werden. Dazu mussten die Daten aus Hadoop auf externe Knoten außerhalb der Hadoop-Infrastruktur verschoben werden.

Die Einführung von YARN war von besonderer Bedeutung, weil nun analytische Anwendungen, die nicht von MapReduce stammen, direkt auf dem Hadoop-Cluster ausgeführt werden können. YARN ist dazu in der Lage, indem es die Ressourcen auf den einzelnen Knoten auf intelligente Weise zwischen MapReduce-Aufgaben und analytischen Anwendungen ausgleicht.

Nachteile von Hadoop

Viele sehr kleine Dateien

Einer der bekannteren Nachteile von Hadoop ist, dass es Probleme bei mit Speicherung und Verarbeitung von wirklich kleinen Dateien hat, also von Dateien, die kleiner als eine HDFS-Blockgröße (etwa 64 MB) sind. Hadoop ist so optimiert, dass es einige wenige extrem große Dateien sehr effizient verarbeiten kann. Dagegen gibt es Probleme sowohl bezüglich der Lagerung als auch der Verarbeitung von kleineren Dateien.

Clouderas Blog enthält ein sehr gutes Beispiel. Dort wird eine einzelne 1-GB-Datei, die in 16 64-MB-Blöcke aufgeteilt ist, mit 10,000 Dateien von jeweils 100 KB verglichen. Im ersten Fall werden 16 individuelle Map-Aufgaben erstellt. Im zweiten Fall werden 10,[#2]} Map-Aufgaben erstellt, was die Leistung dramatisch verringert, obwohl die benötigte physische Speicherkapazität dieser Dateien die gleiche ist.

Cloudera bietet dann zwei Lösungen für das Problem der kleinen Dateien in Hadoop. Eine beinhaltet die Erstellung einer HAR-Datei und die andere die Erstellung einer Sequenzdatei.

Hadoop-Optimierung

Hadoop kann entweder als unstrukturierter Datensee und für die Aufbereitung der Daten, die in ein dediziertes Datenzentrum verschoben werden sollen, oder als selbständiges, dediziertes Datenzentrum unter Nutzung von In-Cluster-Analysen eingesetzt werden.

Hadoop und ein Datenzentrum

Viele Unternehmen implementieren Hadoop als unstrukturierten Datensee für Entwickler und nutzen das Hadoop-Verarbeitungs-Framework als kostengünstigen ETL-Mechanismus, um Daten in ein dediziertes Datenzentrum für Analysten, Geschäftsanwender und analytische Anwendungen zu leiten.

Hadoop als Datenzentrum

Hadoop 2.0, YARN und die stetig wachsende Menge an ANSI-kompatibler SQL-on-Hadoop-Engines ermöglichen die direkte Ausführung von In-Cluster-Analysen auf Hadoop. Bei einer solchen Implementierung müssen Unternehmen die Daten nie verschieben und können die Berechnungen und Analysen stattdessen auf Hadoop ausführen.

Der Hauptvorteil von SQL-on-Hadoop-Engines besteht darin, dass Geschäftsanwender und Analysten SQL-on-Hadoop-Datenspeichern ausführen können. Dadurch wird eine Datenverschiebung im großen Maßstab komplett überflüssig.

Entdecken Sie Ihre Liebe zur Analytik.

Business Intelligence, Big-Data-Analyse oder eine 360°-Ansicht Ihrer Kunden.
Was auch immer Sie benötigen, Looker steht Ihnen zur Seite. Sprechen Sie einfach mit unseren Datenexperten.

Demo anfordern