Komprimieren von Daten in Hadoop - Dummies

verfügbar sind. Die riesigen Datenmengen, die in einer typischen Hadoop-Implementierung Realität sind, machen die Komprimierung zu einer Notwendigkeit. Die Datenkomprimierung spart auf jeden Fall viel Speicherplatz und beschleunigt die Datenübertragung in Ihrem Cluster. Es überrascht nicht, dass eine Reihe von verfügbaren Komprimierungsschemata, so genannte Codecs, zur Verfügung stehen.

In einer Hadoop-Bereitstellung handelt es sich (potenziell) um eine große Anzahl einzelner Slave-Knoten, von denen jeder eine Reihe großer Festplattenlaufwerke hat. Es ist nicht ungewöhnlich, dass ein einzelner Slave-Knoten mehr als 45 TB freien Speicherplatz für HDFS zur Verfügung hat.

Auch wenn Hadoop-Slave-Knoten kostengünstig sind, sind sie nicht kostenlos, und bei großen Datenmengen, die mit steigender Geschwindigkeit wachsen, ist die Komprimierung ein offensichtliches Werkzeug, um extreme Datenmengen.

Zunächst einige grundlegende Begriffe: Ein Codec, , der eine verkürzte Form von co mpressor / dec ompressor ist, ist Technologie (Software oder Hardware oder beide) zum Komprimieren und Dekomprimieren von Daten; Es ist die Implementierung eines Komprimierungs- / Dekomprimierungsalgorithmus.

Sie müssen wissen, dass einige Codecs eine so genannte splittbare Komprimierung unterstützen und dass Codecs sich sowohl in der Geschwindigkeit unterscheiden, mit der sie Daten komprimieren und dekomprimieren können, als auch in welchem ​​Grad sie komprimiert werden können.

Splittable compression ist ein wichtiges Konzept in einem Hadoop-Kontext. Die Funktionsweise von Hadoop besteht darin, dass Dateien geteilt werden, wenn sie größer als die Blockgröße der Datei sind, und einzelne Dateisplits können von verschiedenen Mapper parallel verarbeitet werden.

Bei den meisten Codecs können Textdateisplits nicht unabhängig von anderen Teilen derselben Datei dekomprimiert werden. Diese Codecs sind also nicht teilbar, daher ist die MapReduce-Verarbeitung auf einen einzelnen Mapper beschränkt.

Da die Datei nur als Ganzes dekomprimiert werden kann und nicht als einzelne Teile, die auf Splits basieren, kann es keine parallele Verarbeitung einer solchen Datei geben, und die Leistung kann einen großen Treffer erzielen, wenn ein Job auf einen einzelnen Mapper wartet. verarbeiten mehrere Datenblöcke, die nicht unabhängig voneinander dekomprimiert werden können.

Die teilbare Komprimierung ist nur ein Faktor für Textdateien. Bei Binärdateien komprimieren Hadoop-Komprimierungscodecs Daten in einem binär codierten Container, abhängig vom Dateityp (z. B. SequenceFile, Avro oder ProtocolBuffer).

Apropos Leistung: Die Komprimierung der Daten, die in Ihren Hadoop-Cluster geschrieben werden, verursacht Kosten (in Bezug auf Verarbeitungsressourcen und Zeit).

Bei Computern ist wie beim Leben nichts frei. Beim Komprimieren von Daten tauschen Sie Verarbeitungszyklen für Speicherplatz aus. Und wenn diese Daten gelesen werden, gibt es auch Kosten für das Dekomprimieren der Daten. Achten Sie darauf, die Vorteile der Speicherersparnis gegen den zusätzlichen Leistungsaufwand abzuwägen.

Wenn die Eingabedatei zu einem MapReduce-Job komprimierte Daten enthält, wird die zum Lesen dieser Daten aus HDFS benötigte Zeit reduziert und die Jobleistung verbessert. Die Eingabedaten werden automatisch entpackt, wenn sie von MapReduce gelesen werden.

Die Eingabe-Dateinamenerweiterung bestimmt, welcher unterstützte Codec verwendet wird, um die Daten automatisch zu dekomprimieren. Beispiel: a. Die Erweiterung gz identifiziert die Datei als gzip-komprimierte Datei.

Es kann auch nützlich sein, die Zwischenausgabe der Map-Phase im MapReduce-Verarbeitungsfluss zu komprimieren. Da die Ausgabe der Kartenfunktion auf die Festplatte geschrieben und über das Netzwerk an die Reduzierungsaufgaben gesendet wird, kann die Komprimierung der Ausgabe zu erheblichen Leistungsverbesserungen führen.

Und wenn Sie die MapReduce-Ausgabe als Verlaufsdateien für zukünftige Verwendung speichern möchten, kann die Komprimierung dieser Daten den Platzbedarf in HDFS erheblich reduzieren.

Es gibt viele verschiedene Kompressionsalgorithmen und -werkzeuge, deren Eigenschaften und Stärken variieren. Der häufigste Kompromiss besteht zwischen Komprimierungsraten (dem Grad, zu dem eine Datei komprimiert wird) und Komprimierungs- / Dekomprimierungsgeschwindigkeiten. Das Hadoop-Framework unterstützt mehrere Codecs. Das Framework komprimiert und dekomprimiert die meisten Eingabe- und Ausgabedateiformate transparent.

Die folgende Liste enthält einige allgemeine Codecs, die vom Hadoop-Framework unterstützt werden. Achten Sie darauf, den Codec auszuwählen, der den Anforderungen Ihres speziellen Anwendungsfalls am ehesten entspricht (zum Beispiel bei Workloads, bei denen die Geschwindigkeit der Verarbeitung wichtig ist, wählen Sie einen Codec mit hohen Dekompressionsgeschwindigkeiten):

• Gzip: Eine Komprimierung Das vom GNU-Projekt übernommene Dienstprogramm Gzip (kurz für GNU zip) generiert komprimierte Dateien mit einem. gz Erweiterung. Sie können den Befehl gunzip verwenden, um Dateien zu entpacken, die von einer Reihe von Komprimierungsprogrammen, einschließlich Gzip, erstellt wurden.

• Bzip2: Aus Usability-Sicht sind Bzip2 und Gzip ähnlich. Bzip2 erzeugt ein besseres Komprimierungsverhältnis als Gzip, aber es ist viel langsamer. In der Tat ist Bzip2 von allen verfügbaren Komprimierungscodecs in Hadoop mit Abstand am langsamsten.

  Wenn Sie ein Archiv einrichten, das Sie selten abfragen müssen und das Platzangebot sehr hoch ist, dann wäre Bzip2 vielleicht eine Überlegung wert.

• Snappy: Der Snappy-Codec von Google bietet bescheidene Kompressionsraten, aber schnelle Komprimierungs- und Dekompressionsgeschwindigkeiten. (In der Tat hat es die schnellsten Dekompressionsgeschwindigkeiten, was es sehr wünschenswert für Datensätze macht, die wahrscheinlich häufig abgefragt werden.)

  Der Snappy-Codec ist in Hadoop Common integriert, einer Reihe von allgemeinen Hilfsprogrammen, die andere Hadoop-Teilprojekte unterstützen… Sie können Snappy als Add-on für neuere Versionen von Hadoop verwenden, die noch keine Snappy-Codec-Unterstützung bieten.

• LZO: Ähnlich wie Snappy liefert LZO (Abkürzung für Lempel-Ziv-Oberhumer, das Trio von Informatikern, das den Algorithmus entwickelt hat) bescheidene Kompressionsraten, aber schnelle Kompressions- und Dekompressionsgeschwindigkeiten. LZO ist unter der GNU Public License (GPL) lizenziert.

  LZO unterstützt die spaltbare Komprimierung, die die parallele Verarbeitung komprimierter Textdateisplits durch Ihre MapReduce-Jobs ermöglicht. LZO muss beim Komprimieren einer Datei einen Index erstellen, da bei Komprimierungsblöcken mit variabler Länge ein Index erforderlich ist, um dem Mapper mitzuteilen, wo er die komprimierte Datei sicher teilen kann. LZO ist nur dann wirklich wünschenswert, wenn Sie Textdateien komprimieren müssen.

Hadoop-Codecs

Codec	Dateierweiterung	Teilbar?	Komprimierungsgrad	Komprimierungsgeschwindigkeit
Gzip	. gz	Nein	Mittel	Mittel
Bzip2	. bz2	Ja	Hoch	Langsam
Bissig	. bissig	Nein	Mittel	Schnell
LZO	. lzo	Nein, sofern nicht indiziert	Mittel	Schnell

Alle Komprimierungsalgorithmen müssen Kompromisse zwischen dem Grad der Komprimierung und der Geschwindigkeit der Komprimierung eingehen, die sie erreichen können. Die aufgeführten Codecs geben Ihnen eine gewisse Kontrolle darüber, wie das Verhältnis zwischen Komprimierungsrate und Geschwindigkeit bei der Komprimierung sein sollte.

Mit Gzip können Sie beispielsweise die Geschwindigkeit der Komprimierung regulieren, indem Sie eine negative ganze Zahl (oder ein Schlüsselwort) angeben, wobei -1 die schnellste Komprimierungsstufe angibt und -9 die langsamste Komprimierungsstufe angibt. Die Standardkomprimierungsstufe ist -6.