Comments 6
Учитывая «неторопливость» Apache-community, необходимо принимать во внимание высокую вероятность того, что промежуток времени между выходом release-версии YARN и release-версий распределенных алгоритмов, отличных от map/reduce, написанных с использованием YARN API, может составлять года.
На самом деле уже на альфа версии есть реализации разных, отличных от map/reduce, приложений: wiki.apache.org/hadoop/PoweredByYarn
В частности, issues.apache.org/jira/browse/MAPREDUCE-2911 — Возможность запуска MPI приложений на кластере Hadoop
Совершенно верно. Этот не безрадостный факт я даже упоминал в своем одном посте на хабре, посвященном YARN.
… промежуток времени между выходом release-версии YARN и release-версий распределенных алгоритмовВ посте я вел речь именно рисках, связанных с 'затягиванием' выхода release-версий реализаций распределенных алгоритмов.
Выбирая из двух зол «затягивание выпуска release-версий» vs «гарантия не выхода» я всегда выбираю первый пункт.
Инструмент должен решать ВАШУ поставленную задачу,
даже если он в бете, даже если на других задачах он падает, но решает ВАШУ конкретную задачу,
то я его беру и использую, так как это всегда лучше, чем оставить задачу без решения.
Приходилось и в Hive лезть сорцы и в Hadoop, когда на наших задачах были проблемы, но никто другой их в установленном бюджете решить не мог.
Архитектура Dryad местами интересна, но уже давно не уникальна.
Спасибо за материал, но задевает сам стиль подачи, когда вся информация несет заряд о том какой Dryad хороший и перспективный.
Инструмент должен решать ВАШУ поставленную задачу,
даже если он в бете, даже если на других задачах он падает, но решает ВАШУ конкретную задачу,
то я его беру и использую, так как это всегда лучше, чем оставить задачу без решения.
Приходилось и в Hive лезть сорцы и в Hadoop, когда на наших задачах были проблемы, но никто другой их в установленном бюджете решить не мог.
Архитектура Dryad местами интересна, но уже давно не уникальна.
Спасибо за материал, но задевает сам стиль подачи, когда вся информация несет заряд о том какой Dryad хороший и перспективный.
Несколько замечаний.
Во-первых, Хадуп и Дриад из одной песочницы, MPI и GPU из другой. Разноуровневые языки, разные уровни абстракции и параллелизма, сильно разный оверхэд. Исард сравнивал Дриад с MPI и GPU в публикации, представляющей Дриад, но это по-моему некорректно, или как минимум требует дополнительного рассказа о том, в каких ситуациях высокоуровневые фреймворки хуже.
Вы ругаете инструменты, построенные на Хадуп, как «зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения». Я не понимаю, чем это плохо. Думаете, лучше сверхабстрактный Дриад? Ну а как вы на нем будете решать задачи обработки BigData? У вас, или у комьюнити Дриад есть эффективные рецепты для всех возможных задач, для которых Дриад в принципе мог бы подойти? В итоге, если бы вдруг Дриад стал более популярным, думаю, использовали бы не его напрямую, а строили из него велосипеды и рекламировали бы их как фреймворки под конкретную задачу.
Ваши листинги разной длины, но из этого не следует эффективность фреймворков или какие-либо заключения о преимуществах одного фреймворка над вторым. Во-первых, они написаны на разных языках. C# в некоторых моментах экономнее Java. Для Java есть много библиотек, которые можно использовать, и не писать самодельный подсчет суммы. Во-вторых, в Хадупе есть оптимизация — комбайнер, без которого можно обойтись. Ну и так далее.
Во-первых, Хадуп и Дриад из одной песочницы, MPI и GPU из другой. Разноуровневые языки, разные уровни абстракции и параллелизма, сильно разный оверхэд. Исард сравнивал Дриад с MPI и GPU в публикации, представляющей Дриад, но это по-моему некорректно, или как минимум требует дополнительного рассказа о том, в каких ситуациях высокоуровневые фреймворки хуже.
Вы ругаете инструменты, построенные на Хадуп, как «зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения». Я не понимаю, чем это плохо. Думаете, лучше сверхабстрактный Дриад? Ну а как вы на нем будете решать задачи обработки BigData? У вас, или у комьюнити Дриад есть эффективные рецепты для всех возможных задач, для которых Дриад в принципе мог бы подойти? В итоге, если бы вдруг Дриад стал более популярным, думаю, использовали бы не его напрямую, а строили из него велосипеды и рекламировали бы их как фреймворки под конкретную задачу.
Ваши листинги разной длины, но из этого не следует эффективность фреймворков или какие-либо заключения о преимуществах одного фреймворка над вторым. Во-первых, они написаны на разных языках. C# в некоторых моментах экономнее Java. Для Java есть много библиотек, которые можно использовать, и не писать самодельный подсчет суммы. Во-вторых, в Хадупе есть оптимизация — комбайнер, без которого можно обойтись. Ну и так далее.
По поводу листинга скажу больше: в одном случае он реализует UDF функцию для Pig (не лучший выбор), а в другом уже использует шарпы с предоставленной оберткой.
Почему не udf для hive (под хайв они зачастую достаточно короткие)?
Почему не голый MR (для среднего тоже будет элементарно, можно глянуть пример WordCount, в редьюсе посчитать сумму и на выходе отдать деление, а не сумму)?
Но ответ кроется в авторах листинга: M. Isard, Y. Yu, одни из основных разработчиков Dryad, то есть уже показана предвзятость.
Про MPI/GPU vs Dryad/Hadoop сравнение тоже по-моему не совсем корректно, связки GPU+Hadoop потенциально даже применимы, но вот на практике все проекты останавливаются на ресеч и бета стадиях (можно погуглить, несколько полуживых 2-3 летней давности + пару фирм предоставляющих консалтинг без описания use cases), так как сама парадигма map-reduce не очень хорошо вяжется с gpu подходом.
Так же согласен с вами в том, что на данный момент идет сравнение "Dryad мог бы" и "Hadoop и экосистема делает".
Высказывание автора:
И все эти инструменты предоставляют зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения как парсинга логов, так и подсчета PageRank и анализа графов
Мне тоже режет ухо, так можно на любую вещь сказать, что она предоставляет дублирующий интерфейс:
1. специализированный набор ключей в автомастерской, некоторые дублируют функцию друг друга
2. языки высокого уровня, чем им asm не угодил, ведь предоставляет все необходимые примитивы
3. набор различных фреймворков под разные задачи, пускай в некоторых сферах они и пересекаются
MR & YARN — низкоуровневые примитивы
Pig — императивное описание тасков, работаем со стримом данных
Hive — декларативное, работаем как с sql
Giraph — работа с графовым представлением данных
Storm — event processing, данные обрабатываются еще до сохранения на диск, ациклический граф
Spark — в первую очередь итеративные алгоритмы и машинное обучение, высокая скорость за счет хранения в распределенной таблице в памяти
vs
Dryad & DryadLINQ — абстракция над данными и вычислениями, реализации алгоритмов еще не написаны.
Хотя по поводу 3го пункта с поклонниками ms и c# трудно спорить, так как считают, что есть единственно правильный путь и решение (фреймворк)
За Dryad я наблюдал очень давно, так как альтернативные реализации всегда полезно знать, но все что там было уже давно реализованно в других продуктах, нету только работы через SharedMemory, но по мне это очень спорное решение, уж лучше тогда через pipe работать (что и ожидается в хадупе для обмена данными на одном хосте между task и data нодами). В остальном же, хотели получить достаточно большой комбайн на все случаи жизни, но как и любые попытки обхватить необъятное она провалилась.
p.s. Посмотрел я на этот Naiad и дальше простейшей демки ничего полезного представить они не могут. Опять идет сравнение внутренней разработки и "мы возможно будем делать" с работающей системой для анализа графов.
Почему не udf для hive (под хайв они зачастую достаточно короткие)?
Почему не голый MR (для среднего тоже будет элементарно, можно глянуть пример WordCount, в редьюсе посчитать сумму и на выходе отдать деление, а не сумму)?
Но ответ кроется в авторах листинга: M. Isard, Y. Yu, одни из основных разработчиков Dryad, то есть уже показана предвзятость.
Про MPI/GPU vs Dryad/Hadoop сравнение тоже по-моему не совсем корректно, связки GPU+Hadoop потенциально даже применимы, но вот на практике все проекты останавливаются на ресеч и бета стадиях (можно погуглить, несколько полуживых 2-3 летней давности + пару фирм предоставляющих консалтинг без описания use cases), так как сама парадигма map-reduce не очень хорошо вяжется с gpu подходом.
Так же согласен с вами в том, что на данный момент идет сравнение "Dryad мог бы" и "Hadoop и экосистема делает".
Высказывание автора:
И все эти инструменты предоставляют зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения как парсинга логов, так и подсчета PageRank и анализа графов
Мне тоже режет ухо, так можно на любую вещь сказать, что она предоставляет дублирующий интерфейс:
1. специализированный набор ключей в автомастерской, некоторые дублируют функцию друг друга
2. языки высокого уровня, чем им asm не угодил, ведь предоставляет все необходимые примитивы
3. набор различных фреймворков под разные задачи, пускай в некоторых сферах они и пересекаются
MR & YARN — низкоуровневые примитивы
Pig — императивное описание тасков, работаем со стримом данных
Hive — декларативное, работаем как с sql
Giraph — работа с графовым представлением данных
Storm — event processing, данные обрабатываются еще до сохранения на диск, ациклический граф
Spark — в первую очередь итеративные алгоритмы и машинное обучение, высокая скорость за счет хранения в распределенной таблице в памяти
vs
Dryad & DryadLINQ — абстракция над данными и вычислениями, реализации алгоритмов еще не написаны.
Хотя по поводу 3го пункта с поклонниками ms и c# трудно спорить, так как считают, что есть единственно правильный путь и решение (фреймворк)
За Dryad я наблюдал очень давно, так как альтернативные реализации всегда полезно знать, но все что там было уже давно реализованно в других продуктах, нету только работы через SharedMemory, но по мне это очень спорное решение, уж лучше тогда через pipe работать (что и ожидается в хадупе для обмена данными на одном хосте между task и data нодами). В остальном же, хотели получить достаточно большой комбайн на все случаи жизни, но как и любые попытки обхватить необъятное она провалилась.
p.s. Посмотрел я на этот Naiad и дальше простейшей демки ничего полезного представить они не могут. Опять идет сравнение внутренней разработки и "мы возможно будем делать" с работающей системой для анализа графов.
Sign up to leave a comment.
Microsoft Dryad vs Apache Hadoop. Неначатое сражение за Big Data