LINUX.ORG.RU

Посоветуйте язык/платформу/фреймворк для параллельной/распределенной обработки данных


0

0

Доброго времени суток!

Есть задача сложной многоступенчатой обработки данных. Данные организованы в полностью независимые порции. Обработка разбивается на набор элементарных действий, тоже независимых друг от друга. Таким образом, всю систему можно представить как сеть узлов обработки. Отдельный узел принимает на вход порции данных, каким-то образом их обрабатывает и выдает на выход. Каждая порция в каждом узле обрабатывается независимо, можно одновременно обрабатывать в одном узле несколько порций, работа узлов также может идти параллельно.

Нужно задействовать все вычислительные мощности компьютера, на котором это должно выполняться (пока доступна машинка с двумя четырехядерными Зионами), в перспективе - сделать систему распределенной и использовать сетку из обычных разношерстых компов.

Хочется абстрагироваться от реализации базовой части такой системы (параллельная работа узлов, передача данных между ними и прочее) и сосредоточиться на реализации собственно логики обработки. Какие языки/фреймворки/инструменты тут могут помочь? Написал прототип на чем-то вроде JavaScript'а, встроенного в сервер приложений с возможностью параллельного выполнения скриптов - 80 процентов кода отвечает за базовую часть. Можно ли улучшить этот результат?

Сама логика узлов может быть реализована в сторонних программах или программных компонентах, так что нужны инструменты вызова внешних программ и встраивания кода на С.

anonymous

какой-то поток сознания

dimon555 ★★★★★
()

Это такое тонкое описание BOINC?

Sphinx ★★☆☆
()
Ответ на: комментарий от anonymous

bash.

step1 | step 2 -- вот вам многоступенчатость и многопоточность.

step1 & ; step2 -- вот просто многопоточность.

ssh host1 "step1 | ssh host2 step2" -- вот распределенность.

Шедулер (фигня которая будет раскидывать по разным хостам, не запускать слишком много за раз и тд) - по вкусу, их до черта от простых скриптов до хитроумных систем.

gods-little-toy ★★★
()

Это однозначно BOINC.

anonymous
()

Если устроит текстовый формат передачи данных - обычные программы с stdin->stdout и связывание их в пайпы, при желании система легко масштабируется на кластер.

Legioner ★★★★★
()

R, Matlab и т.д. умеют параллелиться

dimon555 ★★★★★
()

> Это такое тонкое описание BOINC?

Хм, про BOINC не знал (про конкретные проекты слышал, про единую открытую реализацию - нет), спасибо. Хотя для моей задачи это, кажется, чересчур. Но все равно интересно.

> Эрланг

Да, это второе, что пришло в голову. Посмотрю.

> bash

Про процессы, соединенные каналами я думал, в принципе, вся схема хорошо на них ложится. Но просто bash, конечно, не подойдет.

Попробую уточнить на примере. Есть исходные данные - файлы (в общем случае могут быть разные типы данных, например, группа файлов как один элемент данных и т.д.). Есть поставщики этих файлов (входные узлы системы). Они по какой-то своей логике откуда-то эти файлы берут и последовательно передают в узлы, подключенные к их выходам, попутно присоединяя некоторые метаданные. Следующие узлы в свою очередь файлы как-то обрабатывают (возможно - меняют или дополняют метаданные, возможно - замещают файлы новым содержимым, возможно - просто передают другим узлам) и передают следующим узлам. И т.д. вплоть до конечных узлов - "приемщиков", которые являются выходами системы.

Например, такая простейшая система:

Есть два поставщика (Поставщик-1 и Поставщик-2). Они назначают файлам метаданные из одного поля - исходного имени каждого файла. Выходы поставщиков подсоединены ко входу Мультиплексора. Его назначение - просто слить два потока файлов в один, поочередно передавая дальше то файл от Поставщика-1, то файл от Поставщика-2. Выход Мультиплексора подсоединен ко входу Демультиплексора. Он каждый принятый файл передает одновременно на оба своих выхода, попутно добавляя в метаданные поле - уникальный идентификатор порции данных в системе. Один выход Демультиплексора подсоединен к Преобразователю-1, другой - к Преобразователю-2. Преобразователь-1 перекодирует файл в другой формат и передает дальше. Преобразователь-2 анализирует файл и извлекает некоторые данные, из которых формирует новый файл, к которому присоединяет метаданные исходного и передает дальше. Выход Преобразователя-1 и выход Преобразователя-2 подсоединены ко входам Объединителя. Объединитель группирует пары файлов с одним значением уникального идентификатора (т.е. результаты обработки одного исходного файла) и комбинирует их в один файл, к которому присоединяет метаданные входящих файлов и передает дальше. Выход Объединителя подсоединен ко входу Приемщика. Приемщик анализирует метаданные файла, создает на их основе объект в БД и прикрепляет к нему сам файл.

Преобразователь-1 и Преобразователь-2 сильно загружают процессор, но сама по себе обработка что в одном, что в другом - последовательная. Поэтому, во-первых, их логика работает в отдельных потоках/процессах, во-вторых, при наличии у них на входе нескольких файлов можно запускать несколько параллельных обработок в каждом из этих узлов. В принципе, это можно распространить и на все остальные узлы. При обработке могут случаться ошибки - это нормально, данные не всегда корректны. Поэтому ошибки надо аккуратно обрабатывать не прерывая работы всей системы, журналировать, соответствующие файлы направлять в коллектор проблемных файлов, откуда обслуживающий персонал может их вернуть на ту же стадию обработки, где произошла ошибка или еще что-то сделать с ними. Также система может быть в любой момент остановлена - потерь данных быть не должно, после перезапуска надо продолжить работу с той точки, на которой остановились.

Узлы достаточно независимы и их можно рассматривать как отдельные компоненты - логичным видится возможность разнесения их по разным компьютерам.

Глобальная диспетчеризация отсутствует - данные путешествуют от узла к узлу, попутно претерпевая изменения. Каждый узел может их обрабатывать в своем темпе, система должна допускать накопление данных на входе любого узла.

У каждого узла какие-то свои настройки, которые обслуживающий персонал может менять в процессе работы. Также, сама сеть может строиться из набора узлов в процессе работы (оператором или по некоторому сценарию), может быть несколько несвязанных сетей.

anonymous
()
Ответ на: комментарий от YesSSS

> C(++) + MPI?

Честно говоря, на сях лениво все это писать. На динамических высокоуровневых языках приятнее. Все ресурсоемкие вычисления - внутри узлов, их внутренности и можно сделать внешними или на сях/еще чем-то. К передача данных между узлами и прочим служебным функциям требований по производительности особых нет.

anonymous
()
Ответ на: комментарий от anonymous

Да, я задумал именно Dataflow-систему. В вики заглянуть не догадался, а там есть интересные вещи. Спасибо!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.