Usando Pig/Hive para el procesamiento de datos en lugar del mapa directo de Java, ¿reduce el código?

Question

(Incluso más básico que Difference between Pig and Hive? Why have both?)

Tengo una canalización de procesamiento de datos escritos en varios Java mapa- reducir las tareas más Hadoop (mi propio código personalizado, derivados de asignador de Hadoop y reductor). Es una serie de operaciones básicas como join, inverse, sort y group by. Mi código está involucrado y no es muy genérico.

¿Cuáles son los pros y los contras de continuar este enfoque de desarrollo intensivo cierto que frente a la migración de todo para cerdo/colmena con varios UDF? ¿Qué trabajos no podré ejecutar? ¿sufriré una degradación del rendimiento (trabajando con cientos de TB)? ¿Perderé la capacidad de modificar y depurar mi código cuando lo mantengo? ¿podré canalizar parte de los trabajos como Java map-reduce y usar su entrada-salida con mis trabajos Pig/Hive?

Answer 1

Referencia Twitter: Normalmente, un script de Pig es el 5% del código de mapa/reducción nativo escrito en aproximadamente el 5% del tiempo. Sin embargo, las consultas generalmente toman entre 110-150% el tiempo de ejecución que un trabajo nativo de mapa/reducir hubiera tomado. Pero, por supuesto, si hay una rutina que es altamente sensible al rendimiento, todavía tienen la opción de codificar manualmente las funciones de mapa/reducción nativas directamente.

La referencia anterior también habla de pros y contras de Indias sobre el desarrollo de aplicaciones en MapReduce.

Como con cualquier lenguaje de alto nivel o de la abstracción, la flexibilidad y el rendimiento se pierde con el cerdo/colmena a expensas de la productividad del desarrollador.

Answer 2

En este paper a partir de 2009 se afirma que corre Pig 1,5 veces más lento que MapReduce llanura. Se espera que las herramientas de nivel superior creadas sobre Hadoop rindan más lento que MapReduce, pero es cierto que para que MapReduce funcione de manera óptima, se necesita un usuario avanzado que escriba muchos códigos repetitivos (por ejemplo, comparadores binarios).

Me parece relevante mencionar una nueva API llamada Pangool (de la cual soy desarrollador) que tiene como objetivo reemplazar la simple API Hadoop MapReduce haciendo que muchas cosas sean más fáciles de codificar y comprender (clasificación secundaria, reducción uniones laterales). Pangool no impone una sobrecarga de rendimiento (apenas 5% a partir de su first benchmark) y conserva toda la flexibilidad de la API MapRed original.