Wenn ich das Hadoop-Ökosystem richtig verstehe, kann ich meine MapReduce-Jobs, die Daten von HDFS oder HBase beziehen, ausführen. Unter der Annahme, dass die vorherige Annahme richtig ist, warum sollte ich eine über die andere wählen? Gibt es einen Vorteil von Leistung, Zuverlässigkeit, Kosten oder Benutzerfreundlichkeit für die Verwendung von HBase als MR-Quelle?
Das Beste, was ich gefunden habe, ist dieses Zitat: "HBase ist die Hadoop-Anwendung, die verwendet wird, wenn Sie in Echtzeit Lese- / Schreibzugriff auf sehr große Datensätze benötigen." - Tom White (2009) Hadoop: Der endgültige Leitfaden, 1. Ausgabe
Wenn Sie Hadoop-Map / Reduce über HDFS verwenden, werden Ihre Eingaben und Ausgaben in der Regel als flache Textdateien oder Hadoop SequenceFiles gespeichert, bei denen es sich einfach um serialisierte Objekte handelt, die auf die Festplatte gestreamt werden. Diese Datenspeicher sind mehr oder weniger unveränderbar. Dies macht Hadoop für Stapelverarbeitungsaufgaben geeignet.
HBase ist eine vollwertige Datenbank (wenn auch nicht relational), die HDFS als Speicher verwendet. Dies bedeutet, dass Sie interaktive Abfragen und Aktualisierungen für Ihr Dataset ausführen können.
Das Schöne an HBase ist, dass es gut mit dem Hadoop-Ökosystem zusammenspielt. Wenn Sie sowohl Stapelverarbeitung als auch interaktive, granulare Operationen auf Datensatzebene auf riesigen Datenmengen durchführen müssen, wird HBase beides gut machen. p>
Einige relevante Einschränkungen von HDFS (das ein Open-Source-Zwilling zum Google-Dateisystem ist) finden Sie in Original Google-Dateisystem Papier .
Über die Ziel-Anwendungsfälle lesen wir:
Drittens werden die meisten Dateien durch Hinzufügen neuer Daten mutiert anstatt vorhandene Daten zu überschreiben. Zufällig schreibt innerhalb eine Datei ist praktisch nicht existent. [...]
[...] Gegeben Dieses Zugriffsmuster auf große Dateien, Anhängen wird der Fokus Leistungsoptimierung und Atomaritätsgarantien, [...]
Als Ergebnis:
[...] wir haben das Konsistenz-Modell von GFS auf erheblich vereinfachen das Dateisystem, ohne eine lästige auferlegen Belastung der Anwendungen. Wir haben auch ein eingeführt atomare Append-Operation, so dass mehrere Clients anhängen können gleichzeitig zu einer Datei ohne zusätzliche Synchronisation zwischen sie.
Ein Datensatz append verursacht Daten (der "Datensatz") zu sein angehängt atomar mindestens einmal sogar in Gegenwart von gleichzeitige Mutationen, [...]
Wenn ich das Papier richtig lese, dann sind die verschiedenen Replikate jeder Datei (im HDFS-Sinn) nicht unbedingt genau gleich. Wenn die Clients nur die atomaren Operationen verwenden, kann jede Datei als eine Verkettung von Datensätzen (jeweils von einer dieser Operationen) betrachtet werden, die jedoch in einigen der Replikate doppelt vorkommen und sich in ihrer Reihenfolge von Replikat zu Replikat unterscheiden können. (Obwohl anscheinend auch etwas Polsterung eingefügt werden kann, ist es nicht einmal so sauber - lies das Papier.) Es liegt an dem Benutzer, die Aufzeichnungsgrenzen, eindeutige Identifikatoren, Prüfsummen usw. zu verwalten.
Das ist also alles andere als die Dateisysteme, die wir auf unseren Desktop-Rechnern gewohnt sind.
Beachten Sie, dass HDFS für viele kleine Dateien nicht gut ist, weil:
Jeder würde in der Regel einen 64-MB-Chunk zuweisen ( Quelle ).
Seine Architektur ist nicht gut in der Verwaltung einer großen Anzahl von Datei Namen (Quelle: das gleiche wie in Punkt 1). Es gibt einen einzigen Master, der alle Dateinamen verwaltet (die hoffentlich in seinen RAM passen).
Tags und Links hadoop implementation