El almacenamiento en caché de aplicaciones de mapas en Hadoop MapReduce?

Question

En cuanto a la combinación de MapReduce y HBase desde una perspectiva de flujo de datos, mi problema parece encajar. Tengo un gran conjunto de documentos que lo desee asignar, combinar y Reducir. Mi aplicación SQL anterior fue a dividir la tarea en operaciones por lotes, almacenando de forma acumulativa lo que sería el resultado de la Hoja en la tabla y luego realizar el equivalente de una reducir. Esto tenía la ventaja de que en cualquier momento durante la ejecución (o entre ejecuciones), que tenía los resultados del mapa en ese punto en el tiempo.

A mi entender, la ejecución de este trabajo como MapReduce requeriría todas las funciones mapa para ejecutar cada vez.

Mis funciones mapa (y de hecho cualquier función) siempre da la misma salida para una entrada dada. Simplemente no hay sentido volver a calcular la salida si no es necesario. Mi entrada (un conjunto de documentos) estará creciendo continuamente y que se ejecutará mi operación MapReduce periódicamente sobre los datos. Entre las ejecuciones que debería realmente sólo tiene que calcular las funciones de los mapas para los documentos recién añadidos.

Mis datos serán probablemente HBase -> MapReduce -> HBase. Teniendo en cuenta que Hadoop es todo un ecosistema, puede ser capaz de saber que una función dada ha sido aplicado a una fila con una identidad determinada. Asumo entradas inmutables en la tabla HBase. No / Hadoop puede tener en cuenta esta?

Estoy hecho conscientes de la documentación (sobre todo los vídeos Cloudera) que re-cálculo (de datos potencialmente redundantes) puede ser más rápido que la persistencia y recuperación para la clase de problema que Hadoop está siendo utilizado para.

Cualquier comentario / respuestas?

Answer 1

Si usted está buscando para no correr el Mapa paso cada vez, romperlo como su propio paso (ya sea mediante el uso de la IdentityReducer o establecer el número de reductores para el trabajo a 0) y ejecutar posteriores pasos utilizando la salida de su mapa de paso.

Si esto es realmente más rápido que volver a calcular a partir de los datos en bruto cada vez depende del volumen y forma de los datos de entrada frente a los datos de salida, lo complicado de su paso mapa es, etc.

Tenga en cuenta que el funcionamiento de su asignador de nuevos conjuntos de datos no se añadirá a carreras anteriores - pero se puede evitar esto mediante el uso de una carpeta de salida de fecha. Esto quiere decir que usted podría almacenar el resultado de asignar el primer lote de archivos en my_mapper_output/20091101, y el lote de la próxima semana en my_mapper_output/20091108, etc. Si desea reducir lo largo de todo el conjunto, que debe ser capaz de pasar en my_mapper_output como el carpeta de entrada, y la captura de todos los conjuntos de salida.

Answer 2

Por qué no aplicar el flujo de trabajo de SQL en un entorno diferente? Es decir, añadir una columna "procesado" a su mesa de entrada. Cuando llega el momento de ejecutar un resumen, ejecute un oleoducto que dice algo como:

mapa (map_function) el (tabla de entrada filtrada por procesado!); almacenar en map_outputs ya sea en hbase o simplemente HDFS.

mapa (reducen la función) en (map_outputs); almacenar en hbase.

Puede hacer la vida un poco más fácil, suponiendo que se está almacenando sus datos en hbase ordenados por fecha de inserción, si graba en algún lugar de las marcas de tiempo se ejecuta resumen exitosas, y abrir el filtro de insumos que son de fecha posterior que en la última Resumen exitosa - se ahorrará un tiempo de exploración significativa.

Aquí hay una interesante presentación que muestra cómo una empresa Architected su flujo de trabajo (a pesar de que no utilizan hbase): http: //www.scribd. com / doc / 20971412 / Hadoop-Mundial-Producción-Profundización-con-alta disponibilidad