Hadoop MapReduce vs MPI(vs Spark vs Mahout vs Mesos)-¿Cuándo usar uno sobre el otro?

parallel-processing

Question

Soy nuevo en computación paralela y apenas estoy empezando a probar MPI y Hadoop + MapReduce en Amazon AWS. Pero estoy confundido acerca de cuándo usar uno sobre el otro.

Por ejemplo, un consejo de la regla de oro común que veo se puede resumir como ...

• Big data, no iterativo, tolerante a fallos => MapReduce
• Velocidad, datos pequeños, iterativos, no tipo Mapper-Reducer => MPI

Pero también veo la implementación de MapReduce en MPI ( MR-MPI ) que no proporciona tolerancia a fallas, pero parece ser más eficiente en algunos puntos de referencia que MapReduce en Hadoop, y parece manejar big data utilizando memoria fuera de núcleo.

A la inversa, también hay implementaciones de MPI ( MPICH2-YARN ) en la nueva generación de Hadoop Yarn con su sistema de archivos distribuidos (HDFS).

Además, parece que hay disposiciones dentro de MPI (dispersión de recolección, Checkpoint-Restart , ULFM y otra tolerancia a fallas ) que imitan varias características del paradigma MapReduce.

¿Y cómo encajan Mahout, Mesos y Spark en todo esto?

¿Qué criterios pueden usarse al decidir entre (o un combo de) Hadoop MapReduce, MPI, Mesos, Spark y Mahout?

Answer 1

El enlace que publicó sobre FEM se está realizando en MapReduce: 2

utiliza MPI. Lo dice allí mismo en abstracto. Combinaron el modelo de programación de MPI (no vergonzosamente paralelo) con HDFS para "poner en escena" los datos para explotar la localidad de datos.

Hadoop es puramente para cálculos paralelos vergonzosamente. Cualquier cosa que requiera procesos para organizarse e intercambiar datos de manera compleja obtendrá un excelente rendimiento con Hadoop. Esto se puede demostrar tanto desde el punto de vista de la complejidad algorítmica como desde el punto de vista de la medición.

Answer 2

Puede haber buenos criterios técnicos para esta decisión, pero no he visto nada publicado en ella. Parece que hay una brecha cultural en la que se entiende que MapReduce se utiliza para examinar los datos en entornos corporativos, mientras que las cargas de trabajo científicas utilizan MPI. Esto puede deberse a la sensibilidad subyacente de esas cargas de trabajo al rendimiento de la red. Aquí hay algunos pensamientos acerca de cómo descubrir:

Muchas implementaciones modernas de MPI pueden ejecutarse en múltiples redes, pero están altamente optimizadas para Infiniband. El caso de uso canónico de MapReduce parece estar en un grupo de sistemas de productos básicos de "caja blanca" conectados a través de Ethernet. Una búsqueda rápida en "MapReduce Infiniband" lleva a http://dl.acm.org/citation.cfm?id=2511027 que sugiere que el uso de Infiniband en un entorno MapReduce es algo relativamente nuevo.

Entonces, ¿por qué querría ejecutarse en un sistema altamente optimizado para Infiniband? Es significativamente más costoso que Ethernet, pero tiene un mayor ancho de banda, menor latencia y escala mejor en casos de alta contención de red (ref: http://www.hpcadvisorycouncil.com/pdf/IB_and_10GigE_in_HPC.pdf ).

Si tiene una aplicación que sea sensible a los efectos de las optimizaciones para Infiniband que ya están incorporadas en muchas bibliotecas MPI, tal vez eso sea útil para usted. Si su aplicación es relativamente insensible al rendimiento de la red y dedica más tiempo a los cálculos que no requieren comunicación entre procesos, tal vez MapReduce sea una mejor opción.

Si tiene la oportunidad de ejecutar puntos de referencia, puede hacer una proyección en el sistema que tenga disponible para ver qué tanto le ayudaría mejorar el rendimiento de la red. Intente limitar su red: disminuya la velocidad de GigE a 100mbit o Infiniband QDR a DDR, por ejemplo, trace una línea a través de los resultados y vea si la compra de una interconexión más rápida optimizada por MPI lo llevaría a donde quiere ir.