Prueba de Hadoop usando MRUnit

Question

Estoy actualizando un conjunto de pruebas de unidades Hadoop existentes que anteriormente se ejecutaban en un clúster en memoria (usando MiniMRCluster) en MRUnit. Los casos de prueba existentes esencialmente proporcionan entrada a la fase de Mapa y luego prueban la salida de la fase Reducir.

Tengo tres preguntas, y la mejor respuesta a cualquiera de ellos a calificar:

1) ¿Qué pierdo, arquitectónicamente, por la unidad de pruebas con MRUnit en lugar de un clúster en memoria?

2) ¿Vale la pena dividir los casos de prueba existentes en pruebas de solo mapas y pruebas de solo reducción o no? ¿Hay algún caso en el que tendría que separarlos?

3) ¿Hay algún escenario de prueba que MRUnit no pueda cubrir?

Answer 1

El proceso de retroadaptación me ha enseñado algunas respuestas posibles, que voy a publicar aquí. Sin embargo, preferiría escuchar lo que otros tienen que decir, así que no aceptaré esta respuesta.

1) Pierdo al menos dos cosas. Primero, la tubería de MR se burla. Por lo tanto, existe la posibilidad de que parte de la 'burla' oculte un problema que pueda existir en el trabajo de MR. En segundo lugar, un trabajo de MR consiste en la entrada del sistema de archivos y la salida al sistema de archivos, además de la partición y el pedido entre el mapa y la fase de reducción. MRUnit no maneja completamente estos aspectos de Hadoop, por lo que si un trabajo de MR depende de estas funciones, no se pueden probar. Sin embargo, todavía es posible reescribir las pruebas para probar solo las partes Correlacionar/Reducir.

2) En su mayor parte, no vale la pena romper las pruebas existentes. Si una prueba existente depende de un particionador, por ejemplo, entonces puede tener sentido dividir la prueba para que el Mapa y Reducir pueda ser probado sin la participación del particionador. En general, sin embargo, no vale la pena hacer "solo para hacerlo".

3) Sí - Particioners para uno. Formatos de salida para otro. Puede que esto no sea tan importante para algunas personas, pero muchos de nuestros trabajos existentes dependen de estas dos características y dado que las pruebas unitarias van en contra del resultado final del formato de salida, tengo que reescribir algunas pruebas. para hacerlos trabajar

[editar]

acabamos de leer un blog de Cloudera que se dirige a la respuesta así:

http://www.cloudera.com/blog/2009/07/debugging-mapreduce-programs-with-mrunit/

Answer 2

Tome un vistazo a MRUNIT-101, dentro de una semana o así que habrá añadido la capacidad de probar formatos de salida reales