Security ist ein stets aktuelles Thema in der IT. Deshalb widmet sich das ADMIN-Magazin 04/2012 speziell Sicherheitsaspekten und gibt Antworten auf die Fragen: ... (mehr)

MRv1 vs. MRv2

CDH4 ist zu den letzten API-Versionen des Map-Reduce-Frameworks kompatibel (von 0.20.205 an). Hier spricht man auch vom Map-Reduce-Framework 1.0 (MRv1). Dieses Framework ist das Standard-Framework für die Erstellung von Map-Reduce-Anwendungen in Java. Neu hinzugekommen ist die alternative MRv2-Implementierung eines Map-Reduce-Frameworks, die speziell für sehr große Cluster-Installationen von Hadoop (mehr als 4000 Rechner-Knoten) entwickelt wurde. Dieses von Yahoo 2010 entwickelte Framework, das dort unter dem Namen YARN (Yet Another Resource Negotiator) firmiert, ermöglicht es, die Last der Jobtracker-Daemons zu reduzieren. In der MRv1-Welt erfüllt der Jobtracker-Daemon von Hadoop zwei Aufgaben:

1. Er kümmert sich um die Planung der einzelnen Jobs und deren Verteilung auf die Tasktracker

2. Er kümmerte sich um den Ablauf der einzelnen Tasks.

Das YARN-System trennt diese beiden Aufgaben und verteilt sie auf zwei neue Daemons. Dabei kümmert sich der Resource Manager um die Verteilung der (Job-) Resourcen über das Cluster hinweg. Der Application Master kümmert sich um die Ausführung der Map-Reduce-Anwendung. Im Gegensatz zu einem globalen Jobtracker, der sich um das Wohl aller Map-Reduce-Anwendungen gleichermaßen kümmert, ist der Application Master nur für eine Map-Reduce-Anwendung zuständig. Der Application Master muss die benötigten Anwendungs-Resourcen vom Resourcen-Manager zugeteilt bekommen. Dieser etwas andere Ansatz bei der Verteilung von Speicher und CPU im Cluster orientiert sich stärker an dem ursprünglichen Ansatz aus Googles Map-Reduce-Konzept [2].

Neuigkeiten im Ökosystem

Den noch bis vor Kurzem herrschenden Konkurrenzkampf zwischen den Protocol Buffers von Google [3], dem Thrift-System [4] und Avro hat CDH4 zugunsten des Avro-Formats entschieden. Kein Wunder, ist Doug Cutting, der Erfinder von Hadoop, gleichzeitig auch Erfinder von Avro und bei Cloudera unter Vertrag. Avro ist für den Austausch großer, strukturierter Datenbestände, als Transportformat konzipiert worden. Definiert werden Avro-Schema mithilfe von JSON. Innerhalb der CDH4 können alle Anwendungen mit Avro im Datenimport und -Export umgehen.

Daten werden innerhalb eines Hadoop-Ökosystems in der Regel importiert, verarbeitet und in andere Systeme exportiert. Als universeller "Streamer" nutzt Clouderas Distribution das Apache Flume System [5] in der Version 1.1.0. Flume implementiert dabei das Konzept der Datenquelle- und Senke. Quellen können zum Beispiel Log-Dateien-Ströme oder Daten im Avro-Format sein, Senken lassen sich mit HDFS oder einer HBase-Datenbank realisieren.

Apache HBase, die spaltenorientierte Datenbank für Hadoop, wurde mit der Version 0.92.1 in CDH4 integriert. Neu in dieser Version sind Logging-Mechanismen, um langsame Abfragen (HiveQL) zu identifizieren, Tools für die Reparatur korrupter Daten, Nutzer-Authentifizierung und besseres Monitoring über Javas Management Extensions (JMX).

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019