Sehr grundlegende Frage zu Hadoop und komprimierten Eingabedateien

Question

Ich habe begonnen, mich mit Hadoop zu beschäftigen. Wenn ich es richtig verstanden habe, könnte ich eine sehr große Datei verarbeiten und sie würde auf verschiedene Knoten aufgeteilt werden. Wenn die Datei jedoch komprimiert ist, könnte sie nicht aufgeteilt werden und müsste von einem einzigen Knoten verarbeitet werden (was den Vorteil der Ausführung eines Mapreduce-Clusters mit parallelen Maschinen zunichte macht).

Meine Frage ist, vorausgesetzt, die oben genannten korrekt ist, ist es möglich, eine große Datei manuell in feste Größe Chunks oder tägliche Chunks zu teilen, komprimieren Sie Sie und übergeben Sie dann eine Liste der komprimierten Eingabedateien, um eine Mapreduce durchzuführen?

Answer 1

BZIP2 ist in Hadoop splittbar - es bietet eine sehr gute Kompressionsrate, aber von der CPU-Zeit und Leistung her liefert es keine optimalen Ergebnisse, da die Kompression sehr CPU-lastig ist.

LZO ist in Hadoop aufteilbar - Ausnutzung hadoop-lzo Sie haben splittbare komprimierte LZO-Dateien. Sie benötigen externe .lzo.index-Dateien, um sie parallel verarbeiten zu können. Die Bibliothek bietet alle Möglichkeiten, diese Indizes lokal oder verteilt zu erzeugen.

LZ4 ist in Hadoop aufteilbar - Ausnutzung hadoop-4mc Sie haben splittbare komprimierte 4mc-Dateien. Sie benötigen keine externe Indizierung und können Archive mit dem mitgelieferten Kommandozeilentool oder mit Java/C-Code innerhalb/außerhalb von Hadoop erzeugen. 4mc stellt in Hadoop LZ4 in jedem Geschwindigkeits-/Kompressionsverhältnis zur Verfügung: vom schnellen Modus, der eine Kompressionsgeschwindigkeit von 500 MB/s erreicht, bis hin zum High/Ultra-Modus, der ein erhöhtes Kompressionsverhältnis bietet, das fast mit dem von GZIP vergleichbar ist.

Answer 2

Erwägen Sie die Verwendung der LZO-Kompression. Sie ist aufteilbar. Das bedeutet, dass eine große .lzo-Datei von vielen Mappern verarbeitet werden kann. Bzip2 kann das auch, aber es ist langsam.

Cloudera hatte eine Einführung darüber. Für MapReduce scheint LZO ein gutes Gleichgewicht zwischen Kompressionsverhältnis und Komprimierungs-/Dekomprimierungsgeschwindigkeit zu sein.

Answer 3

Ja, Sie können eine große komprimierte Datei oder mehrere komprimierte Dateien haben (mehrere Dateien, die mit -files oder der API angegeben werden).

TextInputFormat und seine Abkömmlinge sollten automatisch mit .gz-komprimierten Dateien umgehen. Sie können auch Ihre eigene InputFormat (der die Eingabedatei zur Verarbeitung in Stücke aufteilt) und RecordReader (die einen Datensatz nach dem anderen aus dem Chunk extrahieren)

eine andere Alternative für eine generische Kopression könnte die Verwendung eines komprimierten Dateisystems sein (wie ext3 mit dem Kompressionspatch, zfs, compFUSEd oder FuseCompress...)

Answer 4

Sie können bz2 als Kompressionscodec verwenden, und dieses Format kann auch aufgeteilt werden.