HDFS – Hadoop Distributed Filesystem – Konzepte einfach erläutert

Zu jedem Betriebssystem gehören ein Filesystem, eine Assemblersprache und letztendlich ein Ökosystem von Tools, Frameworks und Programmen.  Für Big-Data-Anwendungen ist das Hadoop-Ökosystem eine gute Wahl. Die Konzepte sind wiedererkennbar: HDFS als Filesystem, YARN als Betriebssystem, MapReduce als Assembler. Dieser Blog Post erläutert die Grundlagen des HDFS und YARN und des Programmierkonzepts MapReduce für Big-Data-Analysen.

Vereinte Kräfte im Big Data Cluster

Big Data Systeme skalieren horizontal. Dazu werden mehrere Rechner zu einem Cluster vernetzt. Zusätzliche Nodes im Cluster erlauben höhere Systemlast.

Die Grundausstattung: Betriebssystem – Filesystem – Java JRE

Linux ist das Betriebssystem der Wahl für die Server im Hadoop-Cluster. Für Linux wird wird Ext4 gern als Filesystem verwendet.

Das Hadoop Ökosystem benötigt auf jedem Node auch die Java Runtime Umgebung (JRE).

Jetzt kann das Cluster seine geballte Rechenkraft entfalten.

Hadoop – das Open Source Big Data Filesystem

Das HDFS Hadoop Distributed Filesystem, ist eigentlich ein Pseudo-Filesystem. Es  speichert riesige Dateien. Dateien mit Größen bis zum Petabyte-Bereich, mehr als eine Festplatte fassen kann.

Die Idee dazu entstand bei Google. Suchmaschinen-Indexe werden rasch sehr groß und wer das ganze Web durchsuchbar machen will, hat unweigerlich mit gigantischen Dateien zu kämpfen. Das ist der Background der Entwicklung. Google veröffentlichte in 2002 ein Paper über die Konzepte des Google Filesystem GFS. Doug Cutting und Joe Cafarella arbeiteten damals bei Yahoo!, griffen die Idee auf und entwickelten Hadoop.

Yahoo! stiftete Hadoop der Apache Software Foundation und gab damit die Initialzündung für Big-Data-Technologien außerhalb der Internet-Riesen.

Einsatzmöglichkeiten von HDFS

Solch große Files gibt es auch in anderem Kontext. Hier einige Beispiele:

• Log-Files
• Data Warehouses
• Suchmaschinen-Indexe
• Social Media Plattformen
• Große E-Commerce-Systeme
• IoT Streams – Sensordaten aus dem Internet of Things

Das HDFS als verteiltes System hat die Eigenschaften eines File-Systems. Auch die Befehle zur Bedienung ab Command-Line gleichen den Linux Befehlen.

Beispiel: Statt

mkdir meinVerzeichnis

schreibt man

hdfs dsf -mkdir meinVerzeichnis

Auch die Verzeichnisstruktur und die Pfadstruktur wurde bei Linux abgeschaut. So fühlt man sich als Anwender fast schon wie zu Hause.

Blöcke und Blockgröße

Wenn Linux Ext4 die Files in Blöcken von 4KB abspeichert, dann speichert HDFS Blöcke von 128MB oder auch mehr.

Die Philosophie ist dieselbe: Ein File wird aufgeteilt in Blöcke und die Daten werden immer in ganzen Blöcken geschrieben und gelesen.

Die effektive Blockgröße ist Konfigurationssache. Sie wird mit Bedacht gewählt: eine ungünstige Blockgröße kann die Performance des Gesamtsystems bremsen.

Ist die typische Blockgröße 128MB, dann müssen die Files auf HDFS auch entsprechend groß sein. Wer viele kleine Files verwalten muss, ist mit HDFS nicht gut bedient.

HDFS – Eine Art Filesystem geschrieben in Java

Eigentlich ist HDFS  eine verteilte Anwendung, mit den wichtigsten Eigenschaften eines typischen Filesystems.

Dazu verteilt HDFS die einzelnen Datenblöcke auf die Nodes im Cluster. Man spricht in dem Zusammenhang von einem DataNode.

Java Daemons: DataNodes und NameNode

Ein DataNode ist eigentlich ein Java-Daemon, der auf jedem Node im Hadoop-Cluster läuft. Der NameNode übernimmt die Koordination der DataNodes. Als Master-Node kennt er die Struktur des Verzeichnisbaums und ‘weiß’ welcher Block auf welchem DataNode liegt.

Der DataNode-Daemon speichert die HDFS-Blöcke als einzelne Files auf dem unterliegenden Linux-Filesystem. Der Screenshot zeigt die Files der HDFS-Blöcke auf Linux-Ebene.

Ausfallsicherheit dank Replikation

Werden Hunderte von Rechnern in einem Cluster organisiert, dann ist die Wahrscheinlichkeit sehr hoch, dass gerade einer davon nicht funktioniert.

Als Gesamtsystem darf HDFS nie ausfallen. Aus diesem Grund werden die Blöcke repliziert. Auf wieviele DataNodes ein Block repliziert werden soll, kann ebenfalls konfiguriert werden. Fällt jetzt einer der Nodes aus, dann sind ja noch weitere Nodes im Cluster, von denen dieselben Daten gelesen werden können.

Der Endanwender merkt davon nichts und damit erinnert die Philosophie stark an altbewährte RAID-Systeme.

YARN – Eine Art Betriebssystem geschrieben in Java

Jedes Filesystem entfaltet seine Wirkung erst dank der Programme, die es verwenden. Filesystem und Betriebssystem sind eng gekoppelt:

• Windows > FAT32
• Mac > macOS
• Linux > EXT4

Der ClusterManager YARN bildet die Parallele zum Betriebssystem für HDFS.

YARN sorgt dafür, dass die Anwendungsprogramme zu den Daten gelangen und koordiniert die zeitgleiche (also parallele) Ausführung der Programme auf den einzelnen Servern so, dass ein sinnvolles Ergebnis erzielt wird.

Java Daemons: ResourceManager und NodeManager

Als Master koordiniert der ResourceManager von YARN die Berechnungen. Seine Hauptansprechpartner sind die NodeManager. Diese sind ebenfalls Java-Daemons die auf denselben Servern laufen, wie die DataNodes.

Der ResourceManager von YARN ‘spricht’ auch mit dem NameNode um zu erfahren, auf welchen Servern die Blöcke der Files liegen, die das Anwendungsprogramm analysieren will.

MapReduce – Ein Assembler auf Java-Basis

Zu jedem Betriebssystem gehört eine maschinennahe Sprache. Bei Windows, Mac, Linux heißt sie ‘Assembler’.

MapReduce ist eine Art ‘Assembler’ für HDFS/YARN. Im Wesentlichen ist MapReduce ein Konzept der funktionalen Programmierung. Sprachen wie Java, Scala, Python ermöglichen MapReduce. Wer eine Big-Data-Analyse schreiben möchte, die auf einem Cluster verteilt wird, muss sich auf MapReduce einstellen.

Geheimwaffe DataLocality

DataLocality ist zentral, denn die Berechnungen sollen möglichst dort stattfinden, wo die Daten liegen. Das erspart Übertragung der FileBlöcke im Netzwerk.

Die Programme werden zu den Daten geschickt werden und nicht umgekehrt. Dazu kopiert YARN die JAR-Files mit der Anwendungslogik auf HDFS,  die NodeManager holen sie von dort, starten einen Java-Container und führen die beauftragte Berechnung auf ‘ihrem’ Datenblock aus.

YARN koordiniert das Zusammenspiel werden und Replikate federn Ressourcen-Engpässe auf einzelnen Nodes ab. YARN bauftragt diejenigen DataNodes, die gerade am wenigsten zu tun haben. Dazu YARN kennt die Auslastung der einzelnen Nodes.

YARN koordiniert die MapReduce-Schritte.  Immerhin müssen die Berechnungen in der vorgesehenen Reihenfolge erfolgen. So kann der Shuffle/Sort Schritt erst starten, wenn alle vorherigen Map-Schritte fertig sind.

Jüngste Entwicklungen

HDFS, YARN und MapReduce ermöglichten die Entwicklung einer Vielzahl weiterer Tools und Frameworks zur Verarbeitung und Analyse sehr großer Datenbestände und Datenströme.

Datenanalyse ist nicht mehr an HDFS/YARN gebunden. Dennoch: MapReduce als Grundidee ist überall vorzufinden:

• die Programme zu den Daten bringen,
• die Arbeit der Analyse oder Berechnung parallel auf mehrere Rechner verteilen
• und die Ergebnisse aggregieren.

Jedes moderne Framework variiert die Art und Weise der Ausgestaltung dieses Grundkonzepts. Manche basieren auf HDFS, manche setzen YARN als ClusterManager ein – das MapReduce Programmierkonzept ist überall wiederzuerkennen.

Was noch vor zehn Jahren undenkbar schien, gelangt in Reichweite eines jeden Data Analysten. Und die gute Nachricht: auch APIs mit Python oder R sind immer häufiger anzutreffen.

Das Hadoop-Ökosystem

Wer sich in die Big-Data-Welt einsteigt, hat heute vielfältige Wahlmöglichkeiten. Allein bei Apache werden mehr als hundert Big-Data-Projekte gehostet.

Big Data Analysen ohne Big Data Kenntnis?

Für eine erste Berührung mit der Analyse sehr großer Daten über einem Big-Data-Cluster ist kein tiefes Verständnis zum verteilten Rechnen notwendig.

Wer jedoch produktiv damit arbeiten möchte, benötigt gute Kenntnisse über die unterliegenden Mechanismen.

Die Parallele zu den relationalen Datenbanken drängt sich auf: Einige SQL-Statements sind schnell geschrieben, vielleicht sogar in produktive Anwendungsprogramme eingebettet. Werden die Abfragen jedoch langsam, oder gar fehlerhaft, dann benötigt man gute Kenntnisse des relationalen Designs, der Sprache SQL und des verwendeten Datenbank Management Systems, um robusten Code zu schreiben. Analoges trifft auf Big-Data-Analysen zu.

Fazit

Verteilte Systeme basieren auf den Konzepten und Ideen der nicht-verteilten Systeme und machen sich diese zu Nutze. Gerade in der Open-Source-Welt sind viele verteilte Systeme mit Java oder Scala entwickelt worden. Viele Tools bieten APIs für andere Programmiersprachen und werden von Data Analysten entdeckt. Die Komplexität der unterliegenden verteilten Systeme wird vom Anwender abgeschirmt – dennoch, wer Big-Data-Tools effizient einsetzen will, braucht ein Grundverständnis der Konzepte des verteilten Rechnens

“Big Data – das sind doch die 3V?”, oder waren es 4V? Es ist nicht mehr einfach, nachzuvollziehen, woher diese ‘Definition’ ursprünglich stammt. Im September 2012 wurde die Frage gar wissenschaftlich untersucht.

Diesen Anspruch erhebe ich hier nicht. Vielmehr werfe ich einen Blick zurück auf den mehr als 20-jährigen Versuch einer Definition des Begriffs ‘Big Data’ und aktualisiere die Definition.

Was sind Massendaten?

Das deutsche Wort ‘Massendaten’ hilft auch nicht weiter. Liegen Daten auf IT-Systemen denn nicht immer in ‘Massen’ vor? Ab wann darf man von einer ‘Masse’ sprechen? Ab wann ist ‘big’ wirklich ‘big’?

Was bedeutet ‘Big Data = 3V’?

Die 3V mit denen ‘Big Data’ oft definiert wird, erwähnte oder prägte Doug Laney schon im Februar 2001 in seinem Paper ‘Application Delivery Strategies’, das er bei Meta Group veröffentlichte.

Die 3V stehen für Volumen, Velocity, Variety.

Gemeint sind: große Datenvolumen, große Query-Volumen, große Mengen an Datenquellen. Doch was bedeutet ‘groß’?

Velocity steht für ‘Geschwindigkeit’ – Daten, die schnell eintreffen, die schnell verarbeitet und analysiert werden sollen, Daten, die schnell wachsen. Doch was bedeutet ‘schnell’.

Variety steht für ‘Vielfalt’ – Daten die in vielfältigen Formaten vorliegen, die aus vielfältigen Quellen stammen. Doch trifft das nicht auf alle ‘Daten’ zu?

Die Definition ‘Big Data = 3V’ ist also nicht weiterführend.

Das hilft auch nichts, wenn weitere V-Wörter zu finden. Für ‘Veracity’, ‘Value’, ‘Variability’ – je nach Autor sind in den vergangenen Jahren noch beliebige ‘V’ dazu gekommen und finden auch Eingang in die Lehrbücher.

Diese Begriffe sind eher vage formulierte Anforderungen an ein Datenverarbeitungssystem, als Definitionen mit technischem Hintergrund.

Big Data als Grenze des Machbaren

Es gibt noch weitere Definitionen: Gualtiery schreibt bei Forrester in 2012 in seinem Blog-Post mit dem Titel ‘Forget about the 3 Vs‘

Big Data sei die Grenze der Fähigkeit einer Firma, alle Daten zu speichern, zu verarbeiten und im Zugriff zu haben, die sie benötigt, um zu handeln, zu entscheiden, Risiken zu minimieren und Kunden zu bedienen.

Big Data wird also als Grenze bezeichnet, etwas tun zu können. Doch was passiert jenseits dieser Grenze? Was müssen die Unternehmen tun, wenn sie an diese Grenze stoßen. Das sagt die Definition nicht und der Blog Post auch nicht.

Es ist eher eine philosophische Betrachtung des Mengenbegriffs:

• Frage: ab welcher Menge sprechen wir von ‘big’ Data.
• Antwort von Gualitieri: Sobald ein Unternehmen mit der Menge seiner Daten nicht mehr zurecht kommt.

Der Duden definiert auch

Selbst der Duden definiert Big Data = Technologien zur Verarbeitung und Auswertung riesiger Datenmengen.

Ab wann eine Datenmenge als ‘riesig’ zu bezeichnen ist, erläutert Duden nicht.

Die Wikipedia-Definition

Fragen wir also Wikipedia. Hier werden verschiedene Definitionen angeboten. Beispielsweise diese:

Begriff Big Data [ˈbɪɡ ˈdeɪtə] (von englisch big ‚groß‘ und data ‚Daten‘, deutsch auch Massendaten) steht in engem Zusammenhang mit dem umfassenden Prozess der Datafizierung und bezeichnet Datenmengen, welche beispielsweise zu groß, zu komplex, zu schnelllebig oder zu schwach strukturiert sind, um sie mit manuellen und herkömmlichen Methoden der Datenverarbeitung auszuwerten..

Quelle: Wikipedia

‘Manuell’ ist hoffentlich ironisch gemeint. Und was sind ‘herkömmliche Methoden’?

Big Data – 20 Jahre später

Der Begriff ‘Big Data’ mit seinen verschiedenen Definitionsversuchen geistert schon seit mehr als 20 Jahren herum. Grund genug, nach Gemeinsamkeiten zu suchen, die Tools und Technologien aufweisen, die als ‘Big Data’ bezeichnet werden.

Eine Gemeinsamkeit drängt sich auf: All diese Tools oder Frameworks sind in der Lage, die Verarbeitung und Analyse der Daten auf mehrere Rechner zu verteilen.

Die Parallele zur Baustelle: Arbeit verteilen

Um die Vorzüge der verteilen Berechnungen zu erläutern, bietet sich die Parallele zur Baustelle an.

Baut ein Mann allein ein Haus, dann kommt das den von Wikipedia erwähnten ‘herkömmlichen’ Methoden gleich.

Soll der Hausbau beschleunigt werden, dann gibt es zwei Möglichkeiten:

Einen kräftigeren Mann einstellen oder auch diesen mit besseren Maschinen ausstatten. Das kommt der vertikalen Skalierung (scale up) gleich, wie sie bei den herkömmtlichen Methoden der Datenverarbeitung praktiziert wird: Wir beschaffen einfach einen größeren Rechner mit mehr RAM, besserer CPU, größerer Festplatte.

Die zweite Methode zur Beschleunigung des Hausbaus: Wir setzen viele Bauarbeiter ein. Das entspricht der horizontalen Skalierung (scale out), wie sie in der Big-Data-Welt zu beobachten ist: Die Rechenlast wird auf mehrere Server verteilt und koordiniert.

Koordination ist der Schlüsselpunkt

• Die Arbeiten müssen in einer sinnvollen Reihenfolge ausgeführt werden: Das Dach kann erst gebaut werden, wenn das Gebäude steht, vorher ist es sinnlos.
• Was muss unternommen werden, wenn einer der Bauarbeiter ausfällt? Wer muss etwas unternehmen? Gibt es einen Bauführer, des das koordiniert? oder sind es die verbliebenen Arbeiter, die selbst koordinieren? Muss ein Ersatzarbeiter einspringen? Falls ja, womit fährt er weiter?

Was wir aus dem täglichen Arbeitsleben kennen, wurde übertragen auf Big-Data-Systeme. So wie es viele Ansätze gibt zur Organisation von Arbeit, zum Aufteilen einer Aufgabe auf mehrere Personen, zur Koordination der Personen, so gibt es viele Protokolle zur Koordination der Rechner im Cluster.

Statt noch immer größere Rechner zu beschaffen, wie bei den ‘herkömmlichen Methoden’ werden mehr Rechner beschafft, zu einem Cluster vernetzt, und die Arbeit wird auf mehrere Rechner aufgeteilt.

Daraus ergeben sich eine lange Liste an Herausforderungen an die Datenverarbeitung und Analyse. Und durch diese unterscheidet sich ‘Big Data’ von den ‘herkömmlichen Methoden’ der Datenverarbeitung.

Kommentar zur Definition

Diese Definition löst sich von der Größe der Daten, denn die verteilten Methoden funktionieren bestens auch für überschaubare Datenmengen, für Daten die in einem fixen Format, und Daten, die sehr langsam oder auch nur einer Quelle eintreffen.
Und hier das große ABER:
Diese Tools und Frameworks skalieren bis zu nahezu beliebigen Größen, Mengen, Varietät an Formaten und zwar deswegen, weil sie die Arbeit in ein Cluster von Rechnern verteilen.