2012-04-17 9 views

Respuesta

4

PigStorage reconocerá que el archivo está comprimido (por la extensión .gz, esto se implementa realmente en el TextInputFormat que se extiende PigTextInputFormat), pero después de eso tratará con un archivo tar. Si puede manejar las líneas de encabezado entre los archivos en el alquitrán, entonces puede usar PigStorage tal como está; de lo contrario, tendrá que escribir su propia extensión de PigTextInputFormat para gestionar el desglose de las líneas de encabezado de tar entre cada archivo

5

@ La respuesta de ChrisWhite es técnicamente correcta y debes aceptar su respuesta en lugar de la mía (IMO al menos).

Necesita alejarse de los archivos tar.gz con Hadoop. Los archivos Gzip no son divisibles, por lo que te encuentras en una situación en la que si tus archivos gzip son grandes, verás zonas interactivas en tus mapeadores. Por ejemplo, si tiene un archivo .tar.gz de 100 gb, no podrá dividir el cálculo.

Digamos, por otro lado, que son muy pequeños. En ese caso, Pig hará un buen trabajo al juntarlos y el problema de división desaparecerá. Esto tiene la desventaja del hecho de que ahora se trata de toneladas de archivos pequeños con el NameNode. Además, dado que los archivos son pequeños, debería ser relativamente barato computacionalmente reformar los archivos en un formato más razonable.

¿En qué formato debe reformular los archivos? ¡Buena pregunta!

  • Sólo concatenación de todos ellos en un solo archivo comprimido secuencia grande a nivel de bloque podría ser el más difícil, pero el más gratificante en términos de rendimiento .
  • El otro es simplemente ignorar la compresión por completo y simplemente explotar esos archivos, o al menos concatenarlos (ve resultados de rendimiento sin compresión).
  • Finalmente, puedes empalmar archivos en ~ 100MB y luego descomprimirlos gzip.

Creo que sería completamente razonable escribir algún tipo de cargador de tarball en piggybank, pero personalmente preferiría exponer los datos de manera diferente.

Cuestiones relacionadas