parallel processing - ¿Cuáles son algunos escenarios para los que MPI es mejor que MapReduce?
parallel-processing distributed (5)
Por lo que entiendo, MPI me da mucho más control sobre cómo exactamente diferentes nodos en el clúster se comunicarán.
En MapReduce / Hadoop, cada nodo realiza algún cálculo, intercambia datos con otros nodos y luego recopila su partición de resultados. Parece simple, pero como puedes iterar el proceso, incluso algoritmos como K-means o PageRank se ajustan bastante bien al modelo. En un sistema de archivos distribuidos con la localidad de programación, el rendimiento es aparentemente bueno. En comparación, MPI me da un control explícito sobre cómo los nodos se envían mensajes entre ellos.
¿Alguien puede describir un escenario de programación de clústeres donde el modelo MPI más general es una ventaja obvia sobre el modelo MapReduce más simple?
A pesar de que esta pregunta ha sido respondida, me gustaría agregar / reiterar un punto muy importante.
MPI es más adecuado para problemas que requieren mucha comunicación entre procesos.
Cuando los datos se vuelven grandes (¿petabytes, alguien?), Y hay poca comunicación entre procesos, el MPI se convierte en una molestia. Esto es así porque los procesos pasarán todo el tiempo enviándose datos entre sí (el ancho de banda se convierte en un factor limitante) y sus CPU permanecerán inactivas. Quizás un problema aún mayor es leer todos esos datos.
Esta es la razón fundamental detrás de tener algo como Hadoop. Los datos también deben distribuirse: ¡Sistema de archivos distribuidos de Hadoop!
Para decir todo esto, MPI es bueno para el paralelismo de tareas y Hadoop es bueno para el paralelismo de datos.
Casi cualquier código científico: diferencias finitas, elementos finitos, etc. ¿Qué tipo de respuesta conduce a la respuesta circular, que cualquier programa distribuido que no se asigne fácilmente a MapReduce se implementaría mejor con un modelo de MPI más general? No estoy seguro de que sea de mucha ayuda para ti, rechazaré esta respuesta justo después de publicarla.
Cuando el cálculo y los datos que está utilizando tienen comportamientos irregulares que en su mayoría se traducen en muchos pases de mensajes entre objetos, o cuando necesita accesos de bajo nivel de hardware, por ejemplo, RDMA, entonces MPI es mejor. En algunas respuestas que se ven aquí se menciona la latencia de las tareas o el modelo de consistencia de la memoria, marcos como Spark o Actor Models como AKKA han demostrado que pueden competir con MPI. Finalmente, se debe considerar que MPI tiene la ventaja de ser durante años la base principal para el desarrollo de las bibliotecas necesarias para los cálculos científicos (estas son las partes faltantes más importantes que faltan en los nuevos marcos que utilizan los modelos DAG / MapReduce).
En general, creo que los beneficios que los modelos MapReduce / DAG están aportando a la mesa, como los gestores de recursos dinámicos, y el cálculo de tolerancia a fallos los harán factibles para los grupos de computación científica.
Espero que MPI supere fácilmente a MapReduce cuando la tarea se itera sobre un conjunto de datos cuyo tamaño es comparable con el caché del procesador y cuando se requiere con frecuencia la comunicación con otras tareas. Muchos enfoques de paralelización de dominio científico-descomposición se ajustan a este patrón. Si MapReduce requiere procesamiento y comunicación secuenciales, o finalización de los procesos, entonces se pierde el beneficio del rendimiento computacional de tratar un problema del tamaño de un caché.
La mejor respuesta que pude encontrar es que MPI es mejor que MapReduce en dos casos:
Para tareas cortas en lugar de procesamiento por lotes . Por ejemplo, MapReduce no se puede utilizar para responder a consultas individuales: se espera que cada trabajo demore unos minutos. Creo que en MPI, puede construir un sistema de respuesta de consulta donde las máquinas se envían mensajes entre sí para enrutar la consulta y generar la respuesta.
Para los trabajos, los nodos necesitan comunicarse más de lo que iteraba con el soporte de trabajos de MapReduce, pero no demasiado, de modo que los gastos generales de comunicación hacen que el cálculo sea poco práctico. Sin embargo, no estoy seguro de cuán a menudo ocurren tales casos en la práctica.