Однородный программный интерфейс для параллельных вычислений на кластере

Текущие исследования по созданию интерфейса программирования
высокого уровня для суперкомпьютеров и кластеров направлены на то,
чтобы
• изменить существующий функциональный язык для параллельного
выполнения программы, написанной на этом языке, в кластере;
• создать движок, позволяющий выполнять направленный ациклический
граф задач (программ или скриптов) на кластере с учетом их
зависимостей.
Преимущество первого подхода заключается в том, что если у вас уже
есть последовательная программа, написанная на функциональном языке, вы
можете выполнить ее на кластере с использованием либо компилятора,
который генерирует параллельный код, либо библиотеки, которая
предоставляет те же функциональные формы (например, map, reduce),
которые реализованы для параллельного выполнения на нескольких узлах
кластера. Однако этот подход представляет некоторые сложности: обработка
спекулятивного выполнения различных ветвей кода и устойчивость к сбоям
узлов кластера. Вероятно, главный недостаток этого подхода заключается в
том, что на функциональных языках написано не так много
высокопроизводительных приложений: большинство из них написано на
низкоуровневых императивных языках по соображениям эффективности, и
этот подход не предоставляет средств для их выполнения в кластере.
Преимущество второго метода по сравнению с подходом на
функциональном языке состоит в том, что он позволяет выполнять
произвольные программы и сценарии в кластере и определять
информационные зависимости между ними. К сожалению, большинство
механизмов рабочих процессов используют XML для определения задач, их
аргументов и зависимостей. Этот подход неэффективен, поскольку XML не
является языком программирования, и добавление тегов, представляющих
циклы, условные выражения и другие важные конструкции потока
управления, приводит к созданию языка сценариев с синтаксисом языка
разметки – возможно, наиболее неинтуитивно понятным и многословным
способом написания программ. Несмотря на эти недостатки, существуют
реализации потоков задач, которые популярны и достаточно развиты, чтобы
их можно было использовать для решения реальных проблем.
Таким образом, можно сказать, что функциональный подход не
является достаточно высокоуровневым, чтобы его можно было использовать
для написания сценариев, выполняющих существующие программы в
сложном потоке задач, а потоки задач слишком высокоуровневы для
написания сценариев общего назначения. Причина отсутствия
промежуточного подхода заключается в том, что планировщики пакетных
заданий предоставляют интерфейс для выделения узлов кластера и запуска
на них любого исполняемого файла, но интерфейс для написания
параллельных программ (MPI) – это просто библиотека, которая динамически
связывается с исполняемым файлом и не предоставляется планировщиком.
Функциональный подход часто основан на использовании библиотеки MPI, а
потоки задач основаны на интерфейсе планировщика пакетных заданий. Это
создает разрыв между технологиями, который не позволяет создать
универсальный и унифицированный интерфейс для выполнения вычислений
в кластере, и заставляет выбрать один из двух подходов.
В то же время планировщики заданий, которые используются при
анализе больших данных, такие как YARN [21], не имеют этой проблемы,
поскольку они предоставляют низкоуровневый интерфейс на основе Java для
запуска приложений. Различные среды программирования, такие как Apache
Hadoop [1] и Apache Storm [2], построены поверх этого интерфейса, чтобы
обеспечить интерфейс высокого уровня для написания определенных видов
программ, таких как пакетная обработка или работа в реальном времени.
Существуют интерфейсы более высокого уровня, такие как Oozie [11]. Эта
иерархическая архитектура позволяет выбрать правильный уровень
абстракции для программы и представляет собой единый интерфейс для
запуска приложений на кластере.
Существует множество фреймворков и языков программирования для
параллельных и распределенных вычислений [17, 19, 22, 23], которые
успешно применяются как в промышленности, так и в академических кругах,
однако все они изолированы и самодостаточны. Основная причина
отсутствия общего знаменателя между этими фреймворками и языками
заключается в том, что нет протокола или низкоуровневого языка для
распределенных вычислений. Для последовательных вычислений у нас есть
байт-код (например, LLVM [13], байт-код Java, байт-код Guile), который
используется в качестве промежуточного, переносимого и универсального
представления программы, написанной на любом языке; также у нас есть
ассемблер, который не является переносимым, но все же является
популярным промежуточным представлением.
Почему общий низкоуровневый язык существует для
последовательных вычислений, но не существует для параллельных и
распределенных вычислений? Одна из причин, которая относится как к
распределенным, так и к параллельным вычислениям, заключается в том, что
люди все еще думают о программах как о последовательности шагов – так же,
как люди сами выполняют сложные задачи. Императивные языки, на
которых программы записываются в виде последовательности шагов, по-
прежнему преобладают в промышленности и академических кругах; это
контрастирует с непопулярными функциональными языками, на которых
программы написаны как композиции функций без подразумеваемого
порядка вычислений. Другая причина, которая относится к распределенным
вычислениям, заключается в том, что эти вычисления по своей сути
ненадежны и не существует универсального подхода для обработки выхода
из строя узлов кластера. Хотя императивные языки позволяют писать более
эффективные программы, они не обеспечивают защиты от взаимных
блокировок и не гарантируют отказоустойчивость. Кроме того, их намного
сложнее писать, так как человеку приходится работать с изменяемым
состоянием (локальные и глобальные переменные, объекты и т. д.), и трудно
держать это состояние в голове при написании кода. Функциональные языки
минимизируют использование изменяемого состояния, обеспечивают
частичную защиту от взаимных блокировок (при условии, что программист
не использует блокировки вручную) и могут быть изменены для обеспечения
отказоустойчивости. С точки зрения автора, люди понимают потенциал
функциональных языков, но еще не осознали этот потенциал, чтобы
получить все их преимущества; люди осознали весь потенциал
императивных языков, но не знают, как избавиться от их недостатков.