La mejor compresión divisible para Hadoop input=bz2?

gzip hdfs

Question

Nos hemos dado cuenta demasiado tarde de que archivar nuestros archivos en formato GZip para el procesamiento de Hadoop no es una gran idea. GZip no es divisible, y como referencia, aquí están los problemas que no repetiré:

• Pregunta muy básica sobre Hadoop y archivos de entrada comprimidos
• Archivos comprimidos Hadoop gzip
• Archivo de entrada de Hadoop gzip usando solo un mapeador
• ¿Por qué no puede hadoop dividir un archivo de texto grande y luego comprimir las divisiones usando gzip?

Mi pregunta es: ¿BZip2 es la mejor compresión de archivo que permitirá que Hadoop procese un solo archivo en paralelo? Gzip definitivamente no, y por mi lectura LZO tiene algunos problemas.

Answer 1

Aquí hay cinco formas con gzip, tres necesitan un índice, dos no.

Es posible crear un índice para cualquier archivo gzip, es decir, no especialmente creado , como lo hace zran.c. Luego puede comenzar la descompresión en los límites del bloque. El índice incluye los 32K de historial de datos sin comprimir en cada punto de entrada.

Si está construyendo el archivo gzip, puede hacerlo con puntos de entrada periódicos cuyo índice no necesita historial sin comprimir en esos puntos de entrada, lo que hace que el índice sea más pequeño. Esto se hace con la opción Z_FULL_FLUSH para deflate() en zlib.

También podría hacer un Z_SYNC_FLUSH seguido de un Z_FULL_FLUSH en cada punto, que insertaría dos marcadores. Luego puede buscar el patrón de nueve bytes 00 00 ff ff 00 00 00 ff ff para encontrarlos. Eso no es diferente de buscar el marcador de seis bytes en los archivos bzip2, excepto que un falso positivo es mucho menos probable con nueve bytes. Entonces no necesita un archivo de índice por separado.

Tanto gzip como xz admiten una concatenación simple. Esto le permite preparar fácilmente un archivo para la descompresión paralela de otra manera. En breve:

gzip < a > a.gz
gzip < b > b.gz
cat a.gz b.gz > c.gz
gunzip < c.gz > c
cat a b | cmp - c

dará como resultado que la comparación tenga éxito.

A continuación, puede simplemente comprimir en trozos del tamaño deseado y concatenar los resultados. Guarde un índice para las compensaciones del inicio de cada flujo de gzip. Descomprimir de esas compensaciones. Puede elegir el tamaño de los trozos a su gusto, dependiendo de su aplicación. Si los haces demasiado pequeños, la compresión se verá afectada.

Con la simple concatenación de archivos gzip, también podría renunciar al índice si hacía que cada fragmento tuviera un tamaño fijo sin comprimir. Luego, cada fragmento termina con los mismos cuatro bytes, la longitud descomprimida en orden little-endian, por ejemplo, 00 00 10 00 para 1 fragmento MiB, seguido de 1f 8b 08 del siguiente fragmento, que es el inicio de un encabezado gzip. Ese marcador de siete bytes puede entonces buscarse como el marcador bzip2, aunque nuevamente con una menor probabilidad de falsos positivos.

Lo mismo podría hacerse con archivos xz concatenados, cuyo encabezado son los siete bytes: fd 37 7a 58 5a 00 00 .

Answer 2

No considero correcta la otra respuesta, bzip2 según esto:

http://comphadoop.weebly.com/

es divisible. LZO también está indexado .

Entonces la respuesta es sí, si quiere usar más mapeadores que archivos, entonces querrá usar bzip2.

Para hacer esto, puede escribir un simple trabajo de MR para leer los datos y luego simplemente escribirlos de nuevo, luego debe asegurarse de establecer mapred.output.compression.codec en org.apache.hadoop.io.compress.BZip2Codec

Answer 3

BZIP2 es divisible en hadoop - proporciona una muy buena relación de compresión, pero a partir del tiempo de CPU y el rendimiento no se obtienen resultados óptimos, ya que la compresión consume mucha CPU.

LZO es divisible en hadoop, aprovechando hadoop-lzo tiene archivos LZO comprimibles y divisibles. Necesita tener archivos .lzo.index externos para poder procesar en paralelo. La biblioteca proporciona todos los medios para generar estos índices en forma local o distribuida.

LZ4 es divisible en hadoop, aprovechando hadoop-4mc tiene archivos de 4mc comprimibles y divisibles. No necesita ninguna indexación externa, y puede generar archivos con la herramienta de línea de comandos proporcionada o con el código Java / C, dentro / fuera de hadoop. 4mc está disponible en hadoop LZ4 en cualquier nivel de relación velocidad / compresión: desde el modo rápido que alcanza una velocidad de compresión de 500 MB / s hasta modos alto / ultra que proporciona una mayor relación de compresión, casi comparable con GZIP one.