Распределение работы по нескольким ядрам: параллельные коллекции Hadoop или Scala?

Как лучше всего использовать несколько ядер для параллельной обработки в системе Scala/Hadoop?

Допустим, мне нужно обработать 100 миллионов документов. Документы не очень большие, но обработка их требует больших вычислительных ресурсов. Если у меня есть кластер Hadoop на 100 машин с 10 ядрами в каждом, я мог бы:

A) отправить 1000 документов на каждую машину и позволить Hadoop запустить карту на каждом из 10 ядер (или столько, сколько доступно)

или же

B) отправить 1000 документов на каждую машину (все еще используя Hadoop) и использовать параллельные коллекции Scala для полного использования нескольких ядер. (Я бы положил все документы в параллельную коллекцию, а затем map на коллекции). Другими словами, используйте Hadoop для распространения на уровне кластера и используйте параллельные коллекции для управления распределением по ядрам на каждой машине.

3 ответа

Решение

Ответ зависит от следующего вопроса - способен ли ваш код Scala полностью использовать все доступные ядра. Вероятно, если у вас есть хорошая внутренняя синхронизация между частями документа, подлежащего обработке, или какой-либо другой способ паррализировать алгоритм без конфликта блокировок - тогда лучше использовать букву "B". Если это так - настройте по одному мапперу на узел и позвольте своему мапперу использовать ядра в лучшем виде.
Если ваша выгода от парралелизации не так уж хороша, и добавление большего количества потоков (ядер) к обработке не улучшает линейную производительность - тогда "А" может быть лучшим способом. Эффективность "А" также зависит от размера вашей оперативной памяти - вам понадобится оперативная память для 10 картографических узлов на узел.
Я могу подозревать, что идеальное решение может быть где-то посередине. Поэтому я предлагаю разработать mapper, который принимает количество потоков, используемых в качестве параметра, а затем проводит несколько тестов, увеличивая количество потоков на каждый mapper и уменьшая количество отображений на узел.

Hadoop предложит гораздо больше, чем просто распараллеливание. Он предлагает платформу для распределения работы, планировщик для обработки одновременных заданий, распределенную файловую систему, возможность выполнения распределенного сокращения и отказоустойчивость. Тем не менее, это сложная система и иногда может быть трудно работать.

Если вы планируете, чтобы несколько пользователей отправляли много разных заданий, Hadoop - это путь (из двух вариантов). Однако, если вы выделяете кластер для постоянной обработки документов с помощью одной и той же функции, вы можете без особых проблем разработать систему с параллельными коллекциями Scala и участниками для взаимодействия между машинами. Решение Scala даст вам больше контроля, система сможет реагировать в режиме реального времени, и вам не придется иметь дело с большим количеством настроек Hadoop, которые не относятся к вашей задаче.

Если вам нужно запускать различные задания на больших объемах данных (больше, чем уместилось бы на одном узле), используйте Hadoop. Я могу дать вам больше информации, если вы опишите ваши требования более подробно.

Обновление: миллион - это довольно небольшое число. Возможно, вы захотите сделать некоторые вычисления и посмотреть, сколько времени это займет на одной машине с параллельными коллекциями. Преимущество здесь в том, что время разработки минимально!

Hadoop не очень хорош для обработки большого количества маленьких файлов, но для обработки небольшого количества очень больших файлов. Есть ли способ объединить файлы перед их обработкой, или они все совершенно разные? Hadoop сам занимается распределением и параллелизмом, поэтому нет необходимости явно отправлять X-документы на Y-машины. И также я не думаю, что вы должны использовать hadoop только как механизм распространения, это не то, для чего он создан. Вы должны либо использовать реальную карту / уменьшить, либо создать свою собственную систему для всего, что вы пытаетесь сделать, но не пытаться подчинить хадуп своей воле.

Другие вопросы по тегам