file - descargar - Hadoop MapReduce: ¿Tamaño de archivo de entrada apropiado?

mapreduce ibm

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 ajustar 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?

¡Gracias por tus comentarios!

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

Answer 1

Hadoop divide el trabajo según el tamaño de división de entrada. 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; de http://hadoop.apache.org/common/docs/r0.18.3/mapred_tutorial.html

La cantidad de mapas generalmente está determinada 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 de división, de forma 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.

Digamos que su tamaño de 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 tu lógica de procesamiento. ¿Puedes dividir con solo introducir más reductores? Esto creará más archivos de salida, pero qué lógica de particionamiento necesita para estos archivos (de forma predeterminada, será hash particionado por su clave)

Answer 3

Tamaño de los archivos de entrada:

Una forma de ajustar esto es observar qué tan rápido se están completando las tareas de su 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 mapas puede ejecutar su clúster al mismo tiempo. Puede tratar de ajustar su archivo y bloquear tamaños para que pueda aprovechar la mayor cantidad posible de tareas de mapas. Consulte esta publicación en el 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 hacerlo es especificar más de un reductor (cada reductor producirá un solo 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 mires comprimir tus 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 al establecer mapred.compress.map.output=true .