Swarm DPL
2 октября 2009
Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL
Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.
Рекомендую посмотреть презентацию:
Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.
Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.
октября 15, 2009 в 18:20
Я посмотрел презентацию, но, честно говоря, так и не понял — какие преимущества дает перенос состояния между нодами? Он сравнивает с map-reduce, но так там же вычисления происходят параллельно, а здесь — последовательно. В чем выигрыш?
октября 15, 2009 в 18:27
Иногда получается что итоговое вычисление это несколько map-reduce операций, и при этом нужно передавать данные между нодами (из за группировки и сортировки ключей). Если их много то это заметно замедляет процесс вычисления.
А вот в этой идеи получается наоборот, данные лежат на своих местах, и код (точнее состояние текущего вычисления) прыгает между нимим. Я так думаю в некоторых ситуация (когда состояние существенно меньше объема данных) это даст выигрыш.
А вообще, конечно, спорно все это
Но идея интересная.
октября 16, 2009 в 12:30
Пытался придумать случай из реальной жизни, где такая схема работала бы лучше остальных... Не смог.
октября 22, 2009 в 14:33
Ну и собственно статья от GridGain по поводу того как подобную оптимизацию делать в нем:
Portable Continuations with GridGain
сентября 18, 2011 в 19:31
Проблема даже не столько в том, что данные гоняются между нодами, а в том, что в случае Map/Reduce данные находятся в изоляции на каждой ноде.
Т.е. нельзя одновременно работать с некоторым объектом xi и yi находящимися на нодах x и y соотвественно.
Насколько я знаю, в данный момент нельзя сделать что-то подобное в других языках, потому что delimeted continuations поддерживаются только в скале (т.е. в языке должна быть в первую очередь поддержка DC).
Чем Delimeted Continuations отличаются от обычных продолженений?
В обычных продолжениях сериализуется (запаковывается) весь стек процесса, в то время как в DC фреймворк сам определит необходимые куски кода, которые нужно передавать (ненужные не будут гоняться по нодам).