- PVSM.RU - https://www.pvsm.ru -
Представьте себе фреймворк общего назначения для распределенного исполнения приложений со следующими статистическими показателями*:
* Статистические данные за 2011 год.
А теперь представьте, что это не Hadoop.
О том, что это за фреймворк, о идеях и концепциях, заложенных в его основу и о том, почему этот фреймворк даже более инновационный (субъективно), чем Hadoop, речь пойдет ниже.
Dryad – программный фреймворк общего назначения для распределенного исполнения приложений. Dryad является проектом подразделения Microsoft Research. Центральной концепцией проекта Dryad является построение направленного ациклического графа (directed acyclic graph, DAG) для каждой распределенной задачи. Вершины графа представляют собой операции над данными (по сути, программы), а ребра графа — каналы, по которым данные передаются.
Абстракция на основе модели направленного ациклического графа дает возможность эффективно реализовывать планы исполнения большого количества параллельных алгоритмов, итеративных алгоритмов, алгоритмов машинного обучения. Таким образом, единственная (до появления YARN [1]) программная модель map/reduce, реализованная в Hadoop**, по сути является лишь частным случаем модели распределенных вычислений, которую предоставляет Dryad.
Dryad оптимизирован для запуска на среднем или большом вычислительном кластере (от 100 до 10K вычислительных узлов) и нацелен, главным образом, на длительные batch-задания, не требующие частых взаимодействий.
Попытки разобраться с прошлым, настоящим и будущим Dryad привели меня к довольно ограниченному количеству статей, авторы которых, ссылаясь и нет на первоисточники, утверждают, что:
Один из основополагающих документов, описывающих концепции заложенные в Dryad, удостоился награды «Best Paper» на OSDI’08 (USENIX Symposium on Operating Systems Design and Implementation).
В ноябре 2009 года Dryad стал доступен по академической лицензии.
В 2011 году командой Windows HPC Team анонсирована beta-версия «LINQ to HPC» (Dryad для Windows HPC Server) для соответствующей линейки ОС Windows. В этом же году было объявлено, что LINQ to HPC «не выйдет» из preview-версии (т.е. фактически о прекращении поддержки).
Стоит отметить, что команда Windows HPC Team ничего не заявляла (да и не могла заявить в принципе) о поддержке/развитии Dryad Project. Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
Проект Dryad состоит из 3-ех ключевых компонентов:
Ниже подробнее рассмотрим элементы экосистемы Dryad: среду исполнения Dryad runtime и язык запросов DryadLINQ.
Dryad runtime представляет собой среду исполнения распределенных приложений, как и Hadoop, беря на себя такие функции как:
Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных. Этот логический граф отражается (mapped) исполняемой средой на физические ресурсы, находящиеся в кластере. В общем, случае количество вершин в графе превышает количество физических вычислительных узлов в кластере.
Каналы данных, также как и вершины, являются абстракциями и представлены:
Необходимость раскрывать информацию о физических ресурсах кластера для наиболее эффективного исполнения распределенной задачи делает абстракцию канала не такой «чистой», как представляется на первый взгляд. Тем не менее разработчик распределенного приложения «не видит» нарушения абстракции «канал», т.к. она скрывается под другими уровнями (менеджером заданий), о которых речь пойдет ниже.
Модель данных в Dryad представляет собой shared-nothing архитектуру. К достоинствам такой архитектуры традиционно относят масштабируемость, отсутствие необходимости в поддержке отслеживания изменений, реализации сложных транзакций, использовании примитивов синхронизации. Платформа Dryad хорошо подходит для больших статических объемов данных и не подходит для часто изменяемых или потоковых данных.
Dryad рассчитывает получить неизменяемое (immutable) и конечное количество входных данных. Результаты выполнения распределенной программы не будут доступны пока не выполняться все подпрограммы. Логично предположить, что задачи с потоковыми данными являются принципиально неисполнимыми в Dryad.
Оркестровкой выполнения Dryad-задания занимается менеджер заданий Job Manager (JM). Job Manager содержит специфический для приложения (application-specific) код для создания графа вычисления задач.
Job Manager ответственен за:
Данные приложения пересылаются напрямую от vertex-операции к vertex-операции. Job Manager же ответственен только за инициализацию, планирование и контроль исполнения распределенных заданий. Поэтому JM не является узким местом в исполнении приложения. Кроме того, при пересылке код vertex-операции может быть как переслан от Job Manager, так и с ближайшего вычислительного узла, на котором выполняется аналогичная vertex-операция.
За раскрытие информации о доступных вычислительных узлах и их топологическом расположении в кластере отвечает сервер имен Name Server.
На каждом вычислительном узле запущен процесс Daemon, главной целью которого является запуск vertex-операций, присланных Job Manager. Daemon выступает как прокси-объект, поэтому Job Manager имеет возможность узнать статус и этап выполнения vertex-операции, запущенной удаленным Daemon.
Архитектура Dryad и место в этой архитектуре Job Manager, Name Server (NS) и Daemon (PD) приведены ниже.
Источник иллюстрации [3]
(Пояснения к иллюстрации: JM инициализирует граф выполнения, основываясь на данных о доступных узлах и их расположении, полученных от NS. JM контролирует исполнение графа, получаю статусы от PD. PD обмениваются данными по доступным каналам в обход NS и JM. Затененная область на иллюстрации демонстрирует операции исполняемые в текущий момент времени.)
Job Manager, по аналогии с JobTracker в Hadoop, проводит статическую оптимизацию исполнения. Но в отличие от Hadoop, в Dryad реализована возможность динамической оптимизации исполнения.
Благодаря центральной для Dryad концепции направленного ациклического графа и поддержке механизма обратных вызовов (callback информирует JM об изменении этапа выполнения vertex-операции), граф исполнения способен изменяться в процессе выполнения (runtime). Динамическое изменение позволяет довольно изящно решать следующие задачи:
Кроме того, благодаря динамическому изменению графа во время исполнения и абстрагированию понятия «канал» от конкретного способа передачи данных, принципиально (т.е. возможно реализовать, если не реализовано) данные в вершины могут попасть не только с узла, на котором физически хранятся данные, но и:
Как уже ранее упоминалось, Daemon представляет собой прокси, поэтому Job Manager имеет возможность узнать статус и этап выполнения vertex-операции, запущенной удаленным Daemon. Если Daemon «упал», то Job Manager об этом узнает:
После диагностики отказа PD, операция, выполняемая на нем, перевыполняется на другом Daemon.
В документации к Dryad я не нашел информации о том, что произойдет в случаем падения Name Server. Разумно предположить, что при отсутствии heartbeat от NS-процесса Job Manager перезапустит NS на другом узле. На время простоя Name Server часть вычислительной мощности кластера, за раскрытие информации о которой NS отвечает, просто «выпадет».
Также из документации не стало ясно, какие меры предприняты для того, чтобы Job Manager не стал единичной точкой отказа. В случае если каждое распределенное приложение имеет свой собственный Job Manager, то остановка Job Manager не будет приводить к простою целого кластера, как это имеет место у Hadoop при отказе Name Node.
Но наличие отдельных JM-процессов для каждого из распределенных приложений сразу представляет 2 проблемы:
Dryad доступен бесплатно по академической лицензии [4]. Для запуска фреймворка понадобиться Windows HPC cluster с Microsoft HPC Pack 2008 SP1, 4 Gb RAM, 1Gb Ethernet и 200 Gb свободного места на каждой ноде кластера [1].
Приложения под Dryad можно писать как на С++, так и на C# (разумно предположить, что подойдет любой CLS-совместимый язык).
Инструкция по распределенному выполнению операции для Dryad выглядит следующим образом (InitialReduce, Combine, Initialize, Iterate, Merge – это имена функций, ответственных за соответствующие стадии распределенного выполнения; примеры в листингах считают среднее арифметическое):
///<summary>For iterator-based implementation</summary>
[AssociativeDecomposable("InitialReduce", "Combine")]
public static TOutput H(IEnumerable<TInput> source) { … }
public static double Average(IEnumerable<int> g) {
IntPair final = g.Aggregate(x => PartialSum(x));
if (final.second == 0) return 0.0;
return (double)final.first / (double)final.second;
}
[AssociativeDecomposable("InitialReduce", "Combine")]
public static IntPair PartialSum(IEnumerable<int> g) {
return InitialReduce(g);
}
public static IntPair InitialReduce(IEnumerable<int> g) {
return new IntPair(g.Sum(), g.Count());
}
public static IntPair Combine(IEnumerable<IntPair> g) {
return new IntPair(g.Select(x => x.first).Sum(),
g.Select(x => x.second).Sum());
}
///<summary>For accumulator-based implementation</summary>
[AssociativeDecomposable("Initialize", "Iterate", "Merge")]
public static TOutput H(IEnumerable<TInput> source) { … }
public static double Average(IEnumerable<int> g) {
IntPair final = g.Aggregate(x => PartialSum(x));
if (final.second == 0) return 0.0;
else return (double)final.first / (double)final.second
}
[AssociativeDecomposable("Initialize", "Iterate", "Merge")]
public static IntPair PartialSum(IEnumerable<int> g) {
return new IntPair(g.Sum(), g.Count());
}
public static IntPair Initialize() {
return new IntPair(0, 0);
}
public static IntPair Iterate(IntPair x, int r) {
x.first += r;
x.second += 1;
return x;
}
public static IntPair Merge(IntPair x, IntPair o) {
x.first += o.first;
x.second += o.second;
return x;
}
Язык запросов DryadLINQ инкапсулирует сложность кода, поэтому, в общем случае, разработчику приложения не придется писать приведенные в листингах конструкции. DryadLINQ будет рассмотрен в следующей статье из этого цикла.
В заключении обзорно рассмотрим ограничения Dryad и «неверные» ожидания, связанные, в первую очередь, с неправильным представление предназначения такого класса программных средств.
Одним из главных ограничений Dryad является сложность адаптации для работы в realtime-режиме и, вероятно, принципиальная невозможность работы с потоковыми данными. Также следует добавить, что фреймворк Dryad покажет хорошую эффективность для batch-заданий, но применение Drayd не будет оправдано для с random-access операций. Дополнительно отмечу потенциальную проблему с единичной точкой отказа [на уровне приложения] при «падении» менеджера заданий Job Manager (возможно такой точки отказа и нет, но из документации не ясно, как эта проблема решается).
Также необходимо понимать, что Dryad только фрейморк распределенных вычислений, поэтому и не стоит ожидать от Dryad:
В остатке Dryad – мощная и гибкая абстракция для разработчика распределенных приложений. Платформа представляет собой крайне органичный симбиоз современных концепций и представлений о разработке параллельного ПО, предоставляющий знакомые ЯП и элегантные пути решения проблем, с которыми часто сталкиваются (и редко решают) фреймворки распределенных вычислений.
[1] The Dryad Project [2]. Microsoft Research.
[2] Y. Yu, P. K. Gunda, M. Isard. Distributed Aggregation for Data-Parallel Computing: Interfaces and Implementations, 2009.
[3] M. Isard, M. Budiu, Y. Yu, A. Birrell, and D. Fetterly. Dryad: Distributed data-parallel programs from sequential building blocks.
In Proceedings of European Conference on Computer Systems (EuroSys), 2007.
[4] Dryad and DryadLINQ Academic Release [3]. Microsoft Research.
* Упорядочены по алфавиту.
** Сравнение в статье происходит исключительно с 1-ой версией платформы Hadoop (т.е. без YARN). Подробное сравнение Dryad с СУБД, GPU-вычислениями и фреймворком Hadoop будет выполнено в заключительной статье цикла про Dryad.
Автор: codezombie
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/parallel-ny-e-vy-chisleniya/35892
Ссылки в тексте:
[1] YARN: http://www.codeinstinct.pro/2012/11/hadoop-mapreduce-2-0.html
[2] The Dryad Project: http://research.microsoft.com/en-us/projects/dryad/
[3] Dryad and DryadLINQ Academic Release: http://research.microsoft.com/en-us/downloads/03960cab-bb92-4c5c-be23-ce51aee0792c/default.aspx
[4] Источник: http://habrahabr.ru/post/182164/
Нажмите здесь для печати.