Вычислительная система управляемая потоками данных (DataFlow)

Аннотация
  Пожалуй, ничто не развивается столь интенсивно, как сфера информационных технологий. Однако в своей основе, все эти технологии базируются на управлении процессами обработки данных и операционных системах (ОС), обеспечивающих процессы системными ресурсами. А если что-то надо новое делать с данными, то потребуется внести изменения в алгоритмы процессов, так что эта работа станет занимать всё больше ресурсов.
  Я уже давно считаю, что этот подход устарел и тормозит развитие. Пора переходить к более прогрессивному способу обработки, а именно к «управлению по данным» (dataflow). О dataflow говорят часто, но обычно оно только выглядит так - имитация в процессных технологиях, не без хост-процесса, либо жёсткое функциональное разделение.
  Ещё в СССР, в НИИ АН СССР довелось заведовать лабораторией (хотя по специальности я физик), в которой разрабатывались принципы управления по данным в мультипроцессорных системах. Но во время «перестройки» НИИ был ликвидирован. Нижеописанное я здесь размещаю с целью показать преимущества управления по данным, а то «вдруг мужики-то, в Сколково, не знают!». Может у них всё и получится, а в качестве вклада в развитие IT предлагаю описание языка программирования параллельных вычислений в системе управляемой потоками данных (язык DFCS - что-то вроде language of the data flow control system).
Оглавление
Программирование и блок-схемы
О программировании в системе управляемой данными
Архитектура распределённых вычислительных комплексов
О распределённых данных. Онтологии и метаданные.
Резюме о параллельных распределённых вычислениях
Язык DFCS программирования параллельных вычислений в системе управляемой потоками данных

Программирование и блок-схемы

  Языков программирования много - слишком много! Большинство мало чем друг от друга отличаются, но есть и экзотические. Сначала впечатляли те, в которых вычислительный процесс можно было описать почти по-человечески и в знакомой математической символике. Однако со временем в языковых конструкциях получили распространения дефиниции объектов с почти неограниченным количеством опций, и о красивом синтаксисе можно уже забыть. В этом проявилась глубинная суть компьютерных вычислений, как исполнение процедур или подпрограмм. Ибо на самом деле любой алгоритм и представляет собой последовательность исполнения процедур. И любые красивые синтаксические конструкции, равно как и бинарные арифметические операторы, могут быть представлены в виде процедур с параметрами. Так вот на мой взгляд и не надо было огород городить (это и объектно-ориентированного программирования касается), ибо алгоритм, если его записать в виде последовательности процедур, станет только понятнее.
  Первоначально алгоритм, как правило, изображается в виде блок-схемы, в которой эти процедуры изображаются прямоугольниками, а соединительные линии обозначают также передаваемые данные или зависимость по управлению. Очевидно, что между графическим изображением блок-схемы и процедурной записью алгоритма легко установить взаимно-однозначное соответствие. Собственно сейчас именно так, в виде графических блок схем (модели IDEF0), обычно и представляют алгоритмы управления бизнес-процессами в языках BPL. Жизнь заставляет. Моё предложение более универсально - а именно, компилировать в исполняемый код любой, описанный или представленный в виде блок-схемы, алгоритм.

К_ОГЛАВЛЕНИЮ

О программировании в системе управляемой данными

  Легко видеть, что при появлении данных на входах (или «фишки» на разрешение исполнения, которая по сути тоже данное), блок может начать исполняться, а основная ведущая программа (хост-процесс), организующая весь процесс вычислений, просто не нужна. Более того, совершенно не нужной оказывается и операционная система, которая должна бы управлять вычислительными и системными ресурсами. Таким образом, управление по данным обеспечивает полностью децентрализованный процесс параллельных вычислений. Соответственно, система может быть распределённой по любым вычислительным ресурсам в пределах платы, «корзины», сети или «облака».
  Модели организации таких вычислений известны как машина Денниса или сеть Петри. Впрочем, как часто бывает, теория оказывается малополезной для практического применения. В частности и поэтому управление по данным не получило развития, и пока все вычислительные системы и языки программирования ориентированы на процессное управление, в котором задача распараллеливания вычислений является весьма сложной. Но жизнь заставляет, и в качестве паллиатива распределённым вычислениям используются «ситуационное программирование» или, например, технологии «обмена сообщениями», сервисные «шины данных».

К_ОГЛАВЛЕНИЮ

Архитектура распределённых вычислительных комплексов.
Суперкомпьютер "в подарок"

  Алгоритмам, представленным блок-схемами, идеально соответствовал бы вычислительный комплекс (ВК), в котором каждому блоку выделен отдельный вычислительный модуль (ВМ), состоящий из процессора и локальной памяти, соединенный каналами связи с другими ВМ соответственно топологии блок-схемы. Но так нерационально.
В качестве оптимальной архитектуры ВК (схематично изображено на рисунке слева) можно предложить линейку ВМ, расположенных вдоль общей магистрали передачи данных (МПД), состоящей из десятков или сотен шин данных. К магистрали могут быть подключены адаптеры, осуществляющие связь с внешними устройствами, общей памятью и другими ВК.
  В каждый ВМ должны загружаться группы процедур относящихся к некоторому количеству блоков общего алгоритма. Медленно исполняющиеся блоки могут дублироваться во множестве ВМ. Смысл в том, что определённый этап вычислений должен подхватывать тот ВМ, в котором присутствует требуемая процедура блока и который в данный момент не занят обработкой данных. Данные между ВМ должны передаваться по любой свободной шине магистрали.
  Ввиду того, что каждый модуль блок-схемы сам сам состоит из более детальных блок-схем, процесс распараллеливания может продолжаться почти до уровня машинных команд. Ограничения здесь связаны с пропускной способностью магистрали. Захват свободной шины должен выполняться за 1 - 2 такта независимо от числа ВМ - нанотехнологии в помощь и XXI век на дворе всё-таки, но в упомянутой в аннотации лаборатории проблема была решена даже в «железе». Некоторые ВМ могут иметь специализированные процессоры и содержать именно те процедуры, для которых он необходим. Но ясно, что экономически выгодно наращивать число ВМ при упрощении и удешевлении локальных процессоров и памяти. Ну да, по сравнению с престижными суперкомпьютерами описываемые общая магистраль и вычислительные модули стоят «копейки», но именно поэтому могут получить широкое распространение и, в итоге, оказаться более полезными.
  Ввиду полной децентрализации всех устройств и функций ВК, он легко масштабируется, а комплекты блоков задач можно подгружать и дублировать по мере необходимости и наличия свободных ресурсов. В принципе, задача может сама распараллеливать и подгружать блоки перед которыми создаётся очередь данных. В идеале может быть сконфигурирована параллельно - конвейерная система вычислений, когда результаты будут получаемы за один акт передачи данных между ВМ при вводе комплекта входных данных из обрабатываемого массива.

К_ОГЛАВЛЕНИЮ

О распределённых данных. Онтологии и метаданные.

  Данные естественным образом группируются по происхождению, назначению (содержанию), способам использования и т.д. Нас будут интересовать те данные, которые хранятся в базах данных (БД). Способов компоновать пакеты данных практически бесконечно много, какие либо нормативы отсутствуют, и поэтому структурно различных баз данных создано немерянное количество. «Виноваты» учёные, которые, как и в случае с приложением лингвистики в синтаксических языках программирования, увидели здесь практическое приложение теории множеств.
  Однако то, что на самом деле нужно пользователям, а именно возможность разместить в БД любой объект со всеми его атрибутами, возможность указать связи объектов между собой, а главное описать согласно классификаторам назначение, «смысл» (т.н. онтологические характеристики) объектов данного типа и их атрибутов (т.н. метаданные) - это так и не было сделано. То есть никем не была предложена БД, которая удовлетворяла бы настоящим и будущим потребностям ВСЕХ. При том, что структура такой БД не может быть существенно вариабельной и логически вырисовывается почти однозначно. Подобная БД была мною разработана и штатно эксплуатировалась в течение ряда лет вполне успешно в системе документооборота, опробовалась в системе регистрации лицензий и генераторах отчётов.
  А пока нет широкого применения такой БД, можно забыть о возможности автоматически находить и выбирать данные по их смысловому значению (онтологии) в любом месте их создания или использования. В принципе, разработчики файловых систем (FAT, NTFS и пр.) могли бы озадачиться, но у них свои, узкие цели - вот и нет стандарта на универсальную БД, а то можно было бы СУБД заложить в BIOS. Жизнь уже как бы заставляет.
  Чтобы создать новый тип данных нужно в его метаданных описать назначение нового объекта и его реквизитов. Причём реквизиты зачастую получаются из уже имеющихся данных по определённому алгоритму. Поэтому в метаданных для нового типа следует указать, из каких данных и каким алгоритмом их нужно получать, а также и о том, как их следует отображать. Процедуры и модули ведь сами являются всего лишь данными с определённым способом применения и, как и любые другие, могут храниться в БД. Соответственно, когда какие-нибудь данные открываются в браузере на планшете пользователя, вместе с ними из метаданных загружаются и модули, которые обеспечивают правильное отображение и работу пользователя с данными. Удовлетворить эту жизненную потребность, хотя бы частично, сейчас призваны такие средства как JavaScript и т.д. То есть жизнь заставляет, но проблема не воспринимается в целом - например, что Web-браузер, это всего лишь частный случай для отображения HTML-кода. В результате в него стараются впихнуть вообще всё, а в свете вышеизложенного, я бы сказал «не с той стороны».
  Кстати, можно отметить, что при наличии универсальной БД, языки разметки (HTML, XML) становятся не нужны, т.к. данные достаточно самоопределяются в своих метаданных по месту их хранения, что гораздо эффективнее и экономнее, нежели использование линейных по-байтовых файлов.

К_ОГЛАВЛЕНИЮ

Резюме о параллельных распределённых вычислениях

  А теперь посмотрим, какая общая картина при использовании технологий управления по данным у нас получилась. Итак, есть универсальная БД и есть вычислительный комплекс (ВК), в котором заложена единственная программа «найти что-нибудь выполнить». Она и найдёт - «занести данные в БД», ибо больше и нет ничего, а затем уже по классификаторам будет выяснено какие именно данные, условия предоставления к ним доступа и пр.
  Далее, по мере накопления и разнообразия данных, будут открываться и возможности уже их использования. Если данные соответствуют классификаторам, то программировать вообще ничего не нужно - сам факт наличия данных (у нас же управление по данным) инициирует исполнение алгоритмов, предусмотренных для работы с этими данными.
  Если нужно получать какие-то новые данные, то программировать тоже ничего не нужно - надо только указать по классификаторам из каких исходных данных получать новые, указать значения или диапазоны их реквизитов, а также простейшие групповые операции (суммирование, максимум, среднее и т.п.), которые надо выполнить над исходными данными, ибо сама программа получения новых объектов уже есть, и ей для работы только входных данных не хватало. При этом поиск исходных данных будет выполняться во всех БД, с которыми данный вычислительный комплекс соединён каналами передачи данных - ибо задача распараллеливается по всем ВК, до которых сможет «дотянуться», включая Интернет если ВК к нему подключён. Условия предоставления данных (можно указать в реквизитах) тоже будут учитываться, и неправильно указанный пароль или не тот IP и пр., не позволят воспользоваться данными. Так что всё контролируемо и появление вирусов теоретически исключено.
  Итак, мы получаем глобальную децентрализованную вычислительную систему автоматически выполняющую все виды предусмотренных обработок данных и рассылку их заявителям. Это и получение итоговых отчётов, и контроль исполнения и т.п. При этом для инициации новых обработок данных не требуется знать их размещение и не требуется модифицировать уже работающие программы - достаточно просто указать, что нового нужно делать с этими данными. А уж для таких задач, как документооборот, управление бизнес-процессами и проектами и пр., не нужно даже рисовать блок-схемы процессов - достаточно указать значения и состояния реквизитов тех данных, которые должны отображаться на «деловой страничке» пользователя. Кстати, последнее может быть реализовано и сейчас на уровне Web-серверов и браузеров, просто имитируя технологию управления по данным.

К_ОГЛАВЛЕНИЮ

Язык DFCS программирования параллельных вычислений в системе управляемой потоками данных

  В каждом участке сети модулей (и внутри любого модуля) данные фигурируют только в принадлежности к входам и выходам, называемых портами. То есть не требуется деклараций переменных и достаточно декларировать представление данных в портах модулей.
Поскольку порядок исполнения модулей определяется по мере готовности данных, то нет необходимости в предписании определённой последовательности исполнения модулей – нужно лишь описать их коммуникации друг с другом – всё равно в каком порядке. То есть язык оказывается декларативным.
Поскольку всё сводится к строкам описания, разбора каких-либо синтаксических конструкций не требуется. Программа в процессе "компиляции" может непосредственно загружаться в память.
  Модульная структура программы идеально отвечает концепции программирования "сверху вниз", а взаимодействие модулей только через порты гарантирует соблюдение принципов инкапсуляции. Кроме того, модульный принцип и естественный интерфейс по данным как нельзя лучше создают все условия для организации коллективной разработки программ. Ну вот, с архитектурой языка всё ясно и даже не пришлось ничего изобретать. Использование для создания программ графических средств (особенно предусматривающих возможность декомпозиции модулей) позволит достичь предельной ясности. Синтаксис подобного языка программирования может быть чрезвычайно лаконичен.
  В нижеприведенных примерах описания языка, принято, как обычно, символом " | " обозначать "или-или", в квадратные скобки заключать необязательные элементы, а термины, повторяющиеся ноль или более раз, заключать в фигурные скобки. Символ " ::= " обозначает «по определению есть».
  Описание привожу в сжатом виде, не претендуя на полноту и безупречность, и не расшифровывая очевидные понятия. Естественно, язык может дополняться опциями и функциями.

К_ОГЛАВЛЕНИЮ

html counterсчетчик посетителей сайта
Сделать бесплатный сайт с uCoz