¿Es posible tener múltiples entradas con múltiples mapeadores diferentes en Hadoop MapReduce?

Question

¿Es posible tener múltiples entradas con múltiples mapeadores diferentes en Hadoop MapReduce? Cada clase de asignador trabaja en un conjunto diferente de entradas, pero todas emitirían pares clave-valor consumidos por el mismo reductor. Tenga en cuenta que no estoy hablando de encadenar mapeadores aquí, estoy hablando de ejecutar diferentes mapeadores en paralelo, no secuencialmente.

Answer 1

Esto se conoce como unión.

Desea utilizar los correlacionadores y reductores en los paquetes mapred. * (Más antiguos, pero aún compatibles). Los paquetes más nuevos (mapreduce. *) Solo permiten una entrada de mapeador. Con los paquetes de mapred, se utiliza la clase MultipleInputs para definir la unión:

MultipleInputs.addInputPath(jobConf, 
        new Path(countsSource),  
        SequenceFileInputFormat.class, 
        CountMapper.class); 
MultipleInputs.addInputPath(jobConf, 
        new Path(dictionarySource), 
        SomeOtherInputFormat.class, 
        TranslateMapper.class); 

jobConf.setJarByClass(ReportJob.class); 
jobConf.setReducerClass(WriteTextReducer.class); 

jobConf.setMapOutputKeyClass(Text.class); 
jobConf.setMapOutputValueClass(WordInfo.class); 

jobConf.setOutputKeyClass(Text.class); 
jobConf.setOutputValueClass(Text.class); 

Answer 2

voy a responder a su pregunta con otra pregunta, 2 respuestas, y un anti-recomendación.

La pregunta es: ¿qué beneficio se ve al ejecutar los trabajos de mapas heterogéneos en paralelo, en lugar de ejecutarlos en serie, generando resultados homogéneos que se pueden barajar correctamente? ¿La idea es evitar pasar los mismos registros dos veces, una vez con un mapa de identidad?

La primera respuesta es programar simultáneamente ambos trabajos de asignador, cada uno en la mitad de su flota (o la proporción que mejor se adapte al tamaño de datos de entrada), generando resultados homogéneos, seguido de un trabajo de reductor que realiza la unión.

La segunda respuesta es crear un archivo de entrada personalizado que sea capaz de reconocer y transformar ambos sabores de la entrada heterogénea. Esto es extremadamente feo, pero te permitirá evitar el mapa de identidad innecesario de la primera sugerencia.

La contra-recomendación es no usa las API Hadoop obsoletas de la respuesta de Chris. Hadoop es muy joven, pero las API se están estabilizando en torno al "nuevo" sabor. Llegará a la versión de bloqueo eventualmente.