Comments 17
Можно было начинать со сравнения, по характеристикам Dryad устарел лет на 10ть
Не мешало бы Ваше замечание разбавить фактами.
Если честно, я кластеры от MS даже обсуждать не хочу. Будете проводить детальное сравнение, сами все увидите. Отзывы почитайте на досуге, а если будет возможность потестить — сразу у вас все вопросы пропадут
Спасибо, за факты. Очень конструктивно.
Вы ожидаете, что я исследование проведу, чтобы вам очевидные вещи показать? То, что Microsoft и вычислительные кластеры не совместимы скажет вам top500.org. Там тоже без лишней демагогии: Linux для продакшна, Win для игрушек. все
Linux для продакшна, Win для игрушекВы, наверное, про XP?
Ну, а вообще: сомнение — признак интеллекта; а с процитированным категоричным высказыванием лучше на форум, чем в хабр.
Естественно, что это «художественное» преувеличение. Область применения Win шире, но сильно ограничена AD-based инфраструктурами под пользовательские ПК и Exchange, который пока еще не списан со счетов. В остальном MS не конкурент. В свое время я очень удивился тому, что эти ребята(MS) ухитрились запилить свои собственные проприетарные стандарты работы DNS-сервера. Exchange, который даже серые списки не поддерживает из коробки. Azure, недоклаудос с едиными точками отказа. SQL сервер конечно не так страшен как IIS по глючности, но TSQL они явно зря делали, когда в наличии миллион стандартизованных расширений.
ну хотите фактов, давайте обсудим статью и рассмотрим факты:
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10
Это ваша статья и вы её доите, но… по вычислительным кластерам. сегодня разработчик Pelican'а объявил о завершении(закрытии) проекта, но его вычислительный кластер включал 120 000 узлов года два назад. Вы пишите о 10к в 2013 году?
* промахнулся я
* промахнулся я
> Вы пишите о 10к в 2013 году?
Первое, я пишу: >10^5 вычислительных узла.
Второе: я не пишу, что это порог масштабирования.
Последнее: искренне поздравляю команду Pelican'а!
Первое, я пишу: >10^5 вычислительных узла.
Второе: я не пишу, что это порог масштабирования.
Последнее: искренне поздравляю команду Pelican'а!
1. В самом начале картинка(10^4), после в тексте: «10K вычислительных узлов». Вы издеваетесь?
2. Порог как раз
* Мой косяк, в топ-500 действительно просочились три виндусячих кластера(132й и ниже), но это 0,6% при том, что используют больше физических вычислительных ресурсов.
2. Порог как раз
* Мой косяк, в топ-500 действительно просочились три виндусячих кластера(132й и ниже), но это 0,6% при том, что используют больше физических вычислительных ресурсов.
Со степенью напутал. Исправлюсь: >10^4 вычислительных узлов.
После прочтения статьи в голове роются мысли что кто-то overarchitect'ил этот проект. Проще система, проще взаимосвязи, проще написание модулей для неё. В данном случае всё портит сложность.
(хотя есть конечно и противоположная крайность, вызывающая в памяти популярную шутку: «хадуп для парсинга логов»)
(хотя есть конечно и противоположная крайность, вызывающая в памяти популярную шутку: «хадуп для парсинга логов»)
Разбирал как-то статью по этому фреймворку. Сложилось впечатление, что во-первых система сложна для применения в индустрии, потому что предоставляет слишком высокий по сравнению с тем же Hadoop уровень абстракции. Кроме того, при проектировании алгоритмов для Dryad нет четкой концепции того, как прийти от проблемы к решению. В MapReduce это значительно проще.
Ну и мне кажется, что Микрософт больше не собирается этот фреймворк активно продвигать. Не взлетел.
Если интересно, вот моя рецензия статьи о Dryad (на английском). На кафедре высокопроизводительных вычислений с выводами согласились.
Ну и мне кажется, что Микрософт больше не собирается этот фреймворк активно продвигать. Не взлетел.
Если интересно, вот моя рецензия статьи о Dryad (на английском). На кафедре высокопроизводительных вычислений с выводами согласились.
UFO just landed and posted this here
Не хотел расстраивать топикстартера, сформулировал мысль так мягко, как только было возможно, и еще мягче.
Microsoft не сделал из Dryad коммерческого продукта (но он изначально таким и не был, да и я обратного не утверждал).
Для клиентов Windows Azure фреймворком распределенных вычислений стал Hadoop. И я об этом хорошо знаю — даже на хабре месяца 3 назад пост писал).
Про 'полностью похоронил' или все же развивается (например, проект Naiad) — еще надо хорошо подумать прежде, чем категорично утверждать один из вариантов.
Ну и к теме: все-таки предметом моего внимания (предположу, что и Вашего) в этом проекте является не (около)маркетинговая составляющая, а инновационная.
Для клиентов Windows Azure фреймворком распределенных вычислений стал Hadoop. И я об этом хорошо знаю — даже на хабре месяца 3 назад пост писал).
Про 'полностью похоронил' или все же развивается (например, проект Naiad) — еще надо хорошо подумать прежде, чем категорично утверждать один из вариантов.
Ну и к теме: все-таки предметом моего внимания (предположу, что и Вашего) в этом проекте является не (около)маркетинговая составляющая, а инновационная.
Sign up to leave a comment.
Dryad. Фреймворк распределенных вычислений