Каковы некоторые сценарии, для которых MPI лучше подходит, чем MapReduce?

Question

Насколько я понимаю, MPI дает мне гораздо больший контроль над тем, как именно будут взаимодействовать разные узлы в кластере.

В MapReduce / Hadoop каждый узел выполняет некоторые вычисления, обменивается данными с другими узлами, а затем сопоставляет свое распределение результатов. Кажется простым, но, поскольку вы можете повторять процесс, даже такие алгоритмы, как K-means или PageRank, вполне соответствуют модели. В распределенной файловой системе с локальным планированием производительность, по-видимому, хорошая. Для сравнения, MPI дает мне явный контроль над тем, как узлы отправляют сообщения друг другу.

Кто-нибудь может описать сценарий кластерного программирования, где более общая модель MPI является очевидным преимуществом по сравнению с более простой моделью MapReduce?

Answer 1

Почти любой научный код - конечные различия, конечные элементы и т. Д. Какой тип приводит к циклическому ответу, что любая распределенная программа, которая не может легко отобразиться в MapReduce, будет лучше реализована с более общей моделью MPI. Не уверен, что это сильно вам поможет, я опущу этот ответ сразу после публикации.

Answer 2

Хотя на этот вопрос дан ответ, я хотел бы добавить / повторить один очень важный момент.

MPI лучше всего подходит для задач, которые требуют много межпроцессного взаимодействия.

Когда данные становятся большими (петабайты, кто-нибудь?), А межпроцессное взаимодействие мало, MPI становится проблемой. Это связано с тем, что процессы будут тратить все время на отправку данных друг другу (пропускная способность становится ограничивающим фактором), а ваши процессоры будут оставаться в режиме ожидания Возможно, еще большая проблема - чтение всех этих данных.

Это основная причина, по которой стоит иметь что-то вроде Hadoop. Данные также должны быть распределены - распределенная файловая система Hadoop!

Короче говоря, MPI хорош для параллелизма задач, а Hadoop хорош для параллелизма данных.

Answer 3

Когда вычисления и данные, которые вы используете, имеют нерегулярное поведение, которое в основном приводит к многочисленным сообщениям между объектами, или когда вам нужны низкоуровневые доступы на аппаратном уровне, например, RDMA тогда MPI лучше. В некоторых ответах, которые вы видите здесь, упоминается задержка задач или модель согласованности памяти, фреймворки, такие как Spark или Actor Models, такие как AKKA, показали, что они могут конкурировать с MPI. Наконец, следует учитывать, что MPI на протяжении многих лет является основной базой для разработки библиотек, необходимых для научных вычислений (это наиболее важные недостающие части, отсутствующие в новых средах с использованием моделей DAG / MapReduce).

В целом, я думаю, что преимущества, которые модели MapReduce / DAG приносят в таблицу, такие как динамические менеджеры ресурсов, и вычисления отказоустойчивости сделают их осуществимыми для научных вычислительных групп.

Answer 4

Я ожидаю, что MPI легко превзойдет MapReduce, когда задача выполняет итерацию по набору данных, размер которого сопоставим с кэшем процессора, и когда часто требуется связь с другими задачами. Многие научные подходы распараллеливания доменной декомпозиции соответствуют этому шаблону. Если MapReduce требует последовательной обработки и связи, или завершения процессов, то выигрыш в вычислительной производительности при решении проблемы размера кэша теряется.

Answer 5

Лучший ответ, который я могу придумать, заключается в том, что MPI лучше, чем MapReduce, в двух случаях:

1. Для коротких задач, а не для пакетной обработки . Например, MapReduce нельзя использовать для ответа на отдельные запросы - каждая работа, как ожидается, займет минуты. Я думаю, что в MPI вы можете создать систему ответа на запрос, где машины отправляют друг другу сообщения для маршрутизации запроса и генерации ответа.

2. Для узлов заданий необходимо сообщать больше , чем то, что поддерживают итеративные задания MapReduce, но не слишком, чтобы накладные расходы на коммуникацию делали вычисления непрактичными. Я не уверен, как часто такие случаи встречаются на практике.