Hadoop MapReduce: Tamaño de archivo de entrada apropiado?

Question

Tengo conjuntos de datos en una magnitud de 3 dígitos GB o incluso 1 o 2 dígitos TB. Los archivos de entrada son, por lo tanto, una lista de archivos, cada uno con un tamaño de 10 GB. Mi mapa reduce trabajo en hadoop procesa todos estos archivos y luego solo da un archivo de salida (con la información agregada).

Mis preguntas son:

1. Cuál es el tamaño de archivo adecuado para afinar el marco Hadoop/mapreduce de Apache? Escuché que los tamaños de archivo más grandes son más preferidos que los pequeños. ¿Tienes alguna idea? Lo único que sé con certeza es que hadoop lee bloques, cada uno con 64 MB por defecto. Entonces sería bueno si el tamaño del archivo es un tipo de multiplicador de 64MB.

2. Por el momento, mi aplicación está escribiendo el archivo de salida en un solo archivo. El tamaño del archivo es, por supuesto, de 3 dígitos gigabit. Me pregunto qué tan eficientemente puedo particionar el archivo. Por supuesto, puedo usar algunas herramientas de Unix para hacer este trabajo. Pero, ¿se prefiere hacer esto directamente en hadoop?

Thx para sus comentarios!

P.S .: No estoy comprimiendo los archivos. El formato de archivo de los archivos de entrada es text/csv.

Answer 1

Hadoop divide el trabajo en función del tamaño de la entrada dividida. Divide el tamaño total de los datos por su tamaño dividido y así es como determina cuántos trabajos de mapas se producirán. El consenso general es que desea entre 10 y 100 mapas por máquina; desde http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html

El número de mapas generalmente está determinado por el tamaño total de las entradas, es decir, el número total de bloques de los archivos de entrada. El nivel correcto de paralelismo para los mapas parece estar alrededor de 10-100 mapas por nodo, aunque se ha configurado hasta 300 mapas para tareas de mapa muy ligero. La configuración de tareas lleva un tiempo, por lo que es mejor si los mapas tardan al menos un minuto en ejecutarse.

Con algunos formatos de entrada puede establecer el tamaño dividido, de manera predeterminada la mayoría (incluido TextInputFormat) crea un mapa por bloque. Por lo tanto, si tiene varios archivos diferentes, terminará con más bloques de 64mb no completos que son un desperdicio de un mapa.

Procesar un archivo gigante es mucho más eficiente que procesar varios archivos. La configuración para el trabajo lleva más tiempo cuando tiene que dar cuenta de varios archivos. El núcleo de hadoop realmente se centró en pequeños números de archivos de gran tamaño. Además, HDFS está configurado para manejar pequeños números de archivos de gran tamaño y cuantos más archivos tenga, más ram se comerá el namenode para poder seguirlos.

Answer 2

Si no está comprimiendo los archivos, entonces hadoop procesará sus archivos de gran tamaño (digamos 10G), con un número de mapeadores relacionados con el tamaño de bloque del archivo.

Supongamos que el tamaño de su bloque es 64M, entonces tendrá ~ 160 mapeadores procesando este archivo 10G (160 * 64 ~ = 10G). Dependiendo de cuán intensivo sea el CPU de su lógica de mapeo, este podría ser un tamaño aceptable de bloques, pero si descubre que sus mapeadores se están ejecutando en tiempos submínimos, entonces puede querer aumentar el trabajo realizado por cada mapeador (aumentando el tamaño del bloque) a 128, 256, 512 m: el tamaño real depende de cómo intente procesar los datos).

Un tamaño de bloques más grande reducirá la cantidad de mapeadores utilizados para procesar el archivo 10G.Por supuesto, puede aumentar el tamaño de división mínimo utilizado por TextInputFormat, pero probablemente se encontrará con una ubicación de datos más baja, ya que el mapeador puede procesar 2 o más bloques, que pueden no residir localmente en ese nodo.

En cuanto a la salida, esto nuevamente depende de lo que esté haciendo su lógica de procesamiento. ¿Puede realizar la partición simplemente introduciendo más reductores? Esto creará más archivos de salida, pero lo que la lógica de partición no se requieren para estos archivos (por defecto serán de hash dividido por su clave)

Answer 3

tamaño de los archivos de entrada:

Una manera de sintonizar este es ver qué tan rápido se están completando las tareas del mapa. Cada tarea de mapa tomará en 1 archivo como entrada y si se completan en menos de 30-40 segundos de lo que debería considerar aumentar el tamaño de cada archivo para que cada asignador tenga más trabajo por hacer. Esto se debe a que una tarea de mapa tarda unos 30 segundos en inicializarse antes de realizar un trabajo real.

También depende de cuántas tareas de mapa puede ejecutar su clúster a la vez. Puede tratar de ajustar su archivo y bloquear tamaños para que pueda aprovechar la mayor cantidad posible de tareas de mapas. Ver esta entrada del blog para obtener más ideas: http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/

tamaño de los archivos de salida:

La forma más sencilla de hacer esto es especificar más de un reductor (cada reductor producirá un único archivo de salida). Si desea particionar los resultados con alguna tecla (por ejemplo, año-mes), puede incluir eso en la clave de salida de su tarea de mapa y se ordenarán en el mismo reductor. Luego solo necesita verificar cada archivo para ver qué clave de año-mes tiene.

Compresión:

recomiendo que no mire a la compresión de los archivos. Hacer esto hará que los archivos de entrada sean "más grandes" ya que cada uno contendrá más datos para que funcione una única tarea de mapa. También reducirá la cantidad de disco que usa en su clúster. En todo caso, también podría aumentar el rendimiento de mapreduce en su clúster porque se producirá menos E/S de disco y tráfico de red al leer y mover los archivos.

Además, comprima la salida intermedia de su tarea de mapa (salida de la tarea de mapa antes de que vaya al reductor). Aumentará el rendimiento de manera similar. Esto se hace configurando mapred.compress.map.output=true.