четверг, декабря 13, 2007

Microsoft Dryad

Инженер из Микрософта рассказывает об аналоге MapReduce, под названием Dryad. В отличие от MapReduce, работа идет с ацикличным графом, с его помощью можно разные интересные штуки делать с обработкой данных. Вообще произвольный ацикличный граф - штука мощная, тут при желании сложность можно задрать до небес. Но если без фанатизма, то Dryad выглядит интересно.

Доклад вообще хороший. Но есть неприятные моменты. Во-первых, несколько раз подчеркивается, что это "как MapReduce, только лучше". То есть MapReduce их очень задевает.
Во-вторых, докладчик сильно нервничает, но явно на пустом месте. На вопросе про устойчивость к ошибкам его разве что не трясло. При этом он явно знает о чем говорит, что-то где-то забыл, но это нормально...

По ссылке с Geeking with Greg.

Ссылки по теме:
Кроме видео, есть документ Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks
Про MapReduce можно почитать здесь: Передовые технологии Гугла.

3 коммент.:

Alex Ott комментирует...

да, интересный доклад. вообще в googletechtalks много интересного пролетает

Finder комментирует...

Иногда простота сама по себе является главной фичей, даже в ущерб функциональности. Особенно для библиотек и прочего middleware, в том числе и внутреннего. Такое ощущение, что среди omnipotent Microsoft beings эта идея непопулярна.

Подозреваю, стоимость разработки MapReduce (и количество багов в нем) раз так в пять меньше.

navi комментирует...

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

Я в течение всего доклада думал о том, как эта модель сильно напоминает модель редукции графов (например в реализациях ленивых функциональных языков), и вспоминал про Distributed Haskell. В нём, конечно, задачи более низкоуровневые потенциально, но, как я понимаю, ничего не мешает выбирать уровень дробления задач, так чтобы накладные расходы на параллелизацию и ожидание минимизировались.

Ещё понравилась идея, как они фактически на уровне большой модели избавляются от „Тьюринг-полноты”, гарантируя конечность всего вычисления (в случае конечности вычислений на каждой ноде).