LINUX.ORG.RU

Запутался в трех соснах. MapReduce.

 , ,


0

2

Значит так, все мы понимаем, что такое map & reduce и как это работает с точки зрения пользователя. Я пытаюсь заглянуть под капот, и выходит какая-то каша. Я приведу два примера, насколько я понял, а вы поправьте, что не так.

Первый - подсчет частоты слов в файле (это пример с википедии) (примерный псевдокод):

1. records : file.readline
2. map : for (line <- input) accumulate <word, word count in line>

Вот здесь первый вопрос: так как это пока все работает на хосте, то, пусть и с распараллеливанием, мы выполняем фактически подзадачи основной задачи на одной ноде. Что я понял неправильно?

3. partition: здесь мы для каждой пары в аккумуляторе (там же сейчас могут быть пары с одинаковыми словами из разных строк?) считаем, например, хэш ключа и отправляем это в соответствующий reducer. Таким образом, у нас в конце-концов получится разбиение на непресекающиеся классы и все такое.
4. Полученные N списков пар <word, word frequency>, среди которых могут быть пары с одинаковыми ключами (или здесь нужно включать shuffle, чтобы он делал пары <word, {frequency_in_line1, ..., frequency_in_lineK}>?), мы теперь отправляем на N узлов, где уже традиционными методами считаем эти частоты.
5. Делаем union всех N результатов?[pre/] Здесь непонятно, потому что снова - это же уже на мастер-узле делается? Это не будет бутылочным горлышком?

Второй пример. Считаем pi методом Монте-Карло (pi/4 = (число случайных пар, выбранных из [0,1]^2, у которых радиус меньше, чем 1) / (число всех опытов)).

Здесь вход - M бросаний (пусть для конкретности 100 000), т.е. тех самых пар (x, y) <- (Uniform[0, 1], Uniform[0, 1]).

Теперь на этапе Map нужно как-то создать пары <Key, Value>, но я здесь вообще не соображаю: если считать за ключ r^2 = x^2 + y^2, а за значение - 1, если r^2 <= 1, и 0 в обратном случае, то снова - большой объем вычислений происходит на мастер-ноде. И потом на этапе «партишен» мы просто распихаем по хэшам r^2 снова на N нод, а там будем только суммировать единицы, отдавать сумму на мастер, на мастере снова суммировать выхлопы с нод, а затем просто делить сумму на M? Снова мне кажется, что reducer'ы делают меньше работы, чем Map.

Я понимаю, что примеры какие-то полувырожденные; и что я, наверное, просто ниасилил, но было бы хорошо, если бы вы помогли разобраться. Бложики хипстеров от MapReduce в основном объясняют, что такое Map & Reduce как ФВП, а не технику работы.

Скастую-ка я кого-нибудь, например, Reset как писателя хайлода (на всякий случай), maxcom как представителя джава-Ънтерпрайза, vertexua туда же, ну и всех анонимусов, которым есть что сказать. А, и buddhist, mv, quasimoto, как спв. Простите, если с кем-то мимо.

★★★★★

Последнее исправление: cdshines (всего исправлений: 3)
Ответ на: комментарий от exception13

Какое это имеет отношение к теории? Пусть, например, Spark, но как это поможет мне понять принцип работы, если бы я взялся писать свой велосипед?

cdshines ★★★★★
() автор топика

Что-то ты и нас запутал. Концепция-то простая. Всю «поэлементную» работы ты раскидываешь по узлам, а работу, учитывающую связи между элементами, выполняешь после этого на одном узле. Тут главное повернуть свой мозг в нужном алгоритме и подогнать свой код под такую концепцию. Практически любой цикл можно переписать либо как map (filter — частный случай), либо как reduce.

buddhist ★★★★★
()
Ответ на: комментарий от buddhist

Так в том-то и дело. Любую работу с коллекцией в этой плоскости можно представить как map/reduce, это еще в sicp было, да и вообще. Но вот если попробовать представить себе, как это работает, то у меня выходит, что в обоих примерах большинство работы в map. Это примеры неудачные или я не понимаю?

cdshines ★★★★★
() автор топика
Последнее исправление: cdshines (всего исправлений: 1)

Я, как и подобает диванному теоретику, нифига не понял. Слушай, вот с первым примером:

  1. считываем построчно текст
  2. отправляем строки в ноды
  3. ноды возвращают Map(Word, Count)
  4. соединяем результаты, считаем частоты

а у тебя почему как-то подругому?

RedPossum ★★★★★
()
Ответ на: комментарий от buddhist

То но map же принято делать на одной ноде? Или на ты имеешь в виду, что одна нода не значит один поток?

cdshines ★★★★★
() автор топика
Ответ на: комментарий от RedPossum

Ага, то есть мы строки по нодам рассылаем? Интересно, на en.wiki в статье о сабже делается как у меня, т.е. сороки еще на мастере разбиваются на слова.

Я не против твоего примера, мне так понятнее и естествннее даже, но тогда непонятно, по какому принципу происходит партишенинг строк по reducer'ам.

cdshines ★★★★★
() автор топика
Последнее исправление: cdshines (всего исправлений: 1)
Ответ на: комментарий от buddhist

Ну да, он делается на куске уже отмапленных данных. Меня волнует, что я не вижу четкой границы. То есть, мап должен возвращать пары ключ-значение, но для этого нужно что-то уже считать.

Хотя погоди, ты хочешь сказать, что редьюс весь целиком делается на одном узле? Но в секции dataflow на Вики написано не так.

cdshines ★★★★★
() автор топика
Ответ на: комментарий от cdshines

редьюс весь целиком делается на одном узле

Не обязательно, но удобно представлять себе это таким образом.

buddhist ★★★★★
()
Ответ на: комментарий от cdshines

http://www.rabidgremlin.com/data20/ — первая картинка (hadoop-like), map на разных узлах, ес-но.

Более подробная картинка из первоисточника (figure 1) — http://research.google.com/archive/mapreduce.html, map на разных рабочих (в этом поинт), reduce — тоже может быть (но уже не обязательно), но на мастере работает только сама реализация MapReduce, а map и reduce — на воркерах, сам изначальный вход и конечный выход могут распределённо храниться. Однородность (коммутативность) входа может играть роль, коммутативность / ассоциативность операции reduce — тоже, но не обязательно, в зависимости от реализации.

З.Ы. то есть map с reduce в sicp, да, а MapReduce больше про распределённую инфраструктуру.

quasimoto ★★★★
()
Последнее исправление: quasimoto (всего исправлений: 1)
Ответ на: комментарий от quasimoto

Ага, я тут почитал исходники Spark повнимательнее, там так и выходит примерно. Правда, там все так абстрагировано, что пока продерешься через дебри context и т. д., суть почти ускользает.

cdshines ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.