Swarm DPL

Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL

Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

  • http:// Constantine

    Я посмотрел презентацию, но, честно говоря, так и не понял — какие преимущества дает перенос состояния между нодами? Он сравнивает с map-reduce, но так там же вычисления происходят параллельно, а здесь — последовательно. В чем выигрыш?

  • http://artamonov.ru splix

    Иногда получается что итоговое вычисление это несколько map-reduce операций, и при этом нужно передавать данные между нодами (из за группировки и сортировки ключей). Если их много то это заметно замедляет процесс вычисления.

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

    А вообще, конечно, спорно все это 🙂 Но идея интересная.

  • http:// Constantine

    Пытался придумать случай из реальной жизни, где такая схема работала бы лучше остальных... Не смог.

  • http://artamonov.ru splix

    Ну и собственно статья от GridGain по поводу того как подобную оптимизацию делать в нем:

    Portable Continuations with GridGain

  • http:// Kostya

    Проблема даже не столько в том, что данные гоняются между нодами, а в том, что в случае Map/Reduce данные находятся в изоляции на каждой ноде.

    Т.е. нельзя одновременно работать с некоторым объектом xi и yi находящимися на нодах x и y соотвественно.

    Насколько я знаю, в данный момент нельзя сделать что-то подобное в других языках, потому что delimeted continuations поддерживаются только в скале (т.е. в языке должна быть в первую очередь поддержка DC).

    Чем Delimeted Continuations отличаются от обычных продолженений?

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