Veröffentlicht am Schreib einen Kommentar

HDFS – Hadoop Distributed Filesystem – Konzepte einfach erläutert

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.

Autorin: Ursula Deriu

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.

Big Data Cluster - schematische Darstellung
Schematische Darstellung eines Big-Data-Clusters. Die einzelnen Server werden in Racks gestapelt. Die Server eines Racks sind dank eines Netzwerkswitches untereinander vernetzt. Die einzelnen Switche sind wiederum miteinander verbunden. Dadurch wird jeder Server für jeden anderen Server (=Nodes) im Cluster erreichbar.

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.

Grundausstattung Big Data Cluster
Auf jedem Server (=Node) im Cluster ist eine identische Grundausstattung zu installieren. Diese besteht aus einem Linux Betriebssystem, einem Linux Filesystem und einer JRE (Java Runtime Environment). Der Einfachheit halber werden die einzelnen Nodes isoliert dargestellt.

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.

HDFS - schematische Darstellung
Schematische Darstellung des HDFS. Das File (unten links) wird in Blöcke aufgeteilt. Diese werden auf den DataNodes gespeichert und repliziert.

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.

HDFS Datenblöcke
Auf jedem DataNode legt HDFS ein Linux-Verzeichnissystem an. Dort werden die Blöcke und deren Metadaten als einzelne Linux-Files gespeichert.

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.

Schematische Darstellung von YARN
Auf jedem Data-Node läuft mit dem NodeManager ein weiterer Java-Daemon. Der ResourceManager von YARN kontrolliert das Zusammenspiel der NodeManager.

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.

Konzeptionelle Darstellung von MapReduce
Map Reduce - konzeptionell dargestellt. Das Framework stellt den gesamten Workflow sicher. Entwickler entwerfen und codieren eine Abfolge von Map und Reduce-Schritten. Die Darstellung zeigt, wie Wörter in einem Text gezählt werden.

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 MaprReduce-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.

Das MapReduce-Programm im Bild zählt Wörter im Text. Dazu zerlegt der Split-Step den Text in Blöcke. Jeder Block liegt auf einem anderen DataNode und wird mit dem Map-Schritt im Hinblick auf die Programmlogik gefiltert. Hier wird pro Wort ein Schlüssel-Wert-Paar ausgegeben. Der Wert ist 1, was sich aus dem Ziel der Analyse ergibt.

Sind alle Map-Schritte beendet, dann führt YARN den Shuffle/Sort-Schritt aus. Sortiert wird nach Schlüssel. Danach werden neue Blöcke gebildet und zwar ein Block pro Schlüssel-Wert. Jeder Block wird zu einem anderen NodeManager geschickt, der die Reduce-Logik ausführt. Hier werden die 1en addiert und damit die Wörter gezählt.

YARN stellt anschließend das Endergebnis zusammen und informiert das aufrufende Programm.

Insgesamt ist die Ausführung von MapReduce in HDFS sehr komplex. Doch die Frameworks unterstützen. Letztendlich konzentriert sich der Programmierer auf die Logik als Abfolge von Map- und Reduce-Schritten und überlässt die Ausführung YARN als Framework.

Die Frameworks unterstützen. Letztendlich wird man als Programmierer die Logik in Map- und Reduce-Schritte aufteilen und die Ausführung YARN als Framework überlassen.

SQL-Statements können sogar automatisch in MapReduce-Jobs übertragen werden. Und so liegt die Analyse von Big-Data-Files in Reichweite von allen, die SQL gelernt haben und es nicht scheuen, die Spezialitäten des verteilten Rechnens zu erkunden, um die Tools auch zielführend einsetzen zu können.

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.

Hadoop Ökosystem in Kategorien
Schematische Darstellung des Hadoop Ökosystems in Kategorien.

Kategorien helfen, einen Überblick über diese Projekte zu gewinnen. Ein und dieselben Tools können auch unterschiedlichen Ökosystemen zugeordnet werden.  Apache Spark beispielsweise gehört in die Kategorie Analytics. Spark selbst umfasst ein eigenes Ökosystem an Möglichkeiten.  Die Tools im Hadoop-Ökosystem basieren alle auf HDFS als unterliegendem Filesystem. Es gibt auch Big-Data-Tools, die nicht HDFS verwenden, wie beispielsweise Apache Kafka oder Apache Cassandra.

HDFS das Filesystem und YARN, den Cluster-Manager hen wir bereits vorgestellt.

Analytics in HDFS

Anwendungsprogramm in einem Big-Data-Filesystem dienen üblicherweise zur Datenanalyse. Apache HIVE war das erste ein Hadoop-Data Warehouse, das schon seit mehreren Jahren existiert und immer weiter entwickelt wird. Mittlerweile gibt es jüngere, in der Handhabung leichtgewichtigere Data Warehouses, die selbst auf HIVE basieren, Impala ist ein Beispiel. Analysen in Data Warehouses haben üblicherweise relativ lange Antwortzeiten. Das ist auch bei HDFS nicht anders.

Die Programme werden in Hadoop zu den Daten geschickt. Mitterweile gibt es eine Vielzahl von Ansätzen, wie das erfolgen kann. Apache Spark ist ein weit verbreitetes Framework. Apache Drill eine weitere Möglichkeit von vielen anderen.

Datenbanken in HDFS

Will man kurze Antwortzeiten, beispielsweise im Online Transaction Processing zu implementieren, oder will man auch einzelne Datenfelder verändern können, dann wird man spezielle, auf HDFS basierte Datenbanksysteme einsetzen wollen. HBase ist ein solches System. Es ist nicht relational, was den Umgang damit etwas gewöhnungsbedürftig macht. Aber es ist ausgelegt auf Datenmengen, die mit relationalen Datenbanken nicht mehr gehandhabt werden können.

FileFormate, Datenstrukturen, Algorithmen

Um Tools wie HBase zu bauen, das Antwortzeiten im ms-Bereich liefert und dennoch auf dem relative langsamen HDFS zu implementieren, das zusätzlich noch die Eigenschaft hat, dass die Files nicht verändert werden können, waren einige Kunstgriffe nötig. Diese sind im Diagramm unter “File Formate, Datenstrukturen und Algorithmen” zusammengefasst. Parquet und Avro gehören zu den File Formaten. Bloom Filter sind ein Beispiel von Datenstrukturen und Algorithmen, die in unter anderem in HBase verwendet werden.

Koordination der Komponenten des Hadoop-Ökosystems

Die schematische Darstellung zeigt weitere Komponenten: Die Nodes in einem Cluster koordinieren sich mit Hilfe von Apache Zookeeper. Dieser kamperprobte Koordinationsservice für verteilte Systeme wird oft eingesetzt, auch von Tools, die nicht zum Hadoop Ökosystem gehören.

Ingestion ins HDFS

Unter Ingestion und Streaming fallen Tools, wie Kafka, Spark, Flink, Storm, Flume und andere. Diese sind für die schnelle Verarbeitung von Datenströmen gedacht. Ihren Platz im Hadoop Ökosystem verdienen Sie dadurch, dass damit die realtime eintreffenden Daten in HDFS  gespeichert und weiter analysiert werden können. Und letztendlich bieten gerade Tools wie Spark, Flink die Möglichkeit, die Hdfs-Daten mit Machine Learning auszuwerten. Besondere Herausforderungen besprechen wir im Artikel Realtime Big Data Stream Processing.

Workflows/Scheduler

Mit geeigneten Architekturen baut man ein Big-Data-System, das Daten realtime verarbeitet. Um dies zu realisieren, sind viele verschiedene Komponenten des Hadoop Ökosystems zu orchestrieren. Dies wird durch Tools aus der Kategorie “Workflow und Scheduler” unterstützt. NiFi ist ein Beispiel aus dieser Kategorie.

Administration

Und letztendlich möchten wir Tools haben, um den Cluster zu installieren und zu Überwachen. Ambari ist ein Beispiel aus dieser Kategorie.

Die genannten Tools sind alle Top-Level-Projekte bei der Apache Foundation. Sie können dort heruntergeladen und installiert werden.

Die Toolunterstützung für Hadoop wird rasant besser und ist natürlich auch ein Markt für viele neue Player. Diese tragen zur Weiterentwicklung der Open Source Projekte bei und bieten auch kostenpflichtige Varianten ihrer Tools mit weiteren Features an.

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

  • Bilde dich weiter - Grundwissen Echtzeitanalyse

  • E-Mail-Training - 5 Tage - 5 Learning Nuggets

  • Trade-Offs der Real-Time Analyse großer Datenströme

  • E-Mail-Training - Trade-Offs der Real-Time Analyse großer Datenströme

Elefanten und Tierwärter im Beitragsbild?
Als Doug Cutting zusammen mit Joe Cafarella das verteilte Filesystem schrieb, suchte nach einem Namen für seine Software. Etwas Großes musste es sein. Sein damals dreijähriger Sohn spielte mit einem gelben Plüsch-Elefanten, den er liebevoll ‘Hadoop’ nannte, und so kam das Filesystem zu seinem Namen.
Viele Produkte des Hadoop Ökosystems wurden von Tiernamen abgeleitet. Selbst einen Wärter gibt es:  Apache ZooKeeper ist ein Koordinationsdienst für verteilte Systeme.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.