Оптимизация методов кэширования и предварительной обработки данных в узлах распределенной океанографической ИС. С целью комплексного обеспечения потребителей гидрометеорологической информацией и информацией о морской деятельности необходимо задействование множества источников данных (НИИ, научных подразделений, лабораторий, ЦД) различной тематической направленности и распределенных географически.
Для решения различных научно-практических задач необходима интеграция этой информации. Например, местоположения судов и высоты волнения в местах их текущего пребывания с целью обеспечения безопасности мореплавания; места ЧС разлива нефти вместе со скоростью и направлением течения и ветра в этом месте для помощи в ликвидации последствий ЧС; наблюденных, прогностических и климатических данных по таким параметрам, как, например, температура воздуха или воды для изучения отклонений от нормы, точности прогностических данных, интегральной оценки обстановки в Мировом океане и пр..
В рамках сетевой модели ЕСИМО предполагается создание серии информационно-телекоммуникационных узлов (персональных, корпоративных, специализированных, региональных, технологических и др.) различного функционального назначения и информационного содержания, создаваемых и действующих по единой технологии и в рамках единой системы безопасности.
Функцией конкретного узла является подготовка и представление информации экспертам (аналитикам, др. конечным пользователям) для решения прикладных задач, объединенных общей тематической и(или) географической областью.
Узел является сложной информационной системой (ИС), состоящей из набора независимых, но взаимосвязанных программных единиц – прикладных компонентов (далее компонентов), функционирующих в веб-среде.
Данные, описанные и оформленные в соответствие с определенными правилами, называются информационными ресурсами (ИР). Каждый ИР состоит из структурных единиц – элементов и делится на логические части – экземпляры.
В том случае, если необходимые прикладному компоненту данные запрашиваются «на лету», то на каждом узле распределенной сети в каждом экземпляре каждого компонента одни и теже данные и метаданные запрашивают повторно при каждом запросе каждого пользователя. Таким образом, многократно возрастает нагрузка на другой системный компонент – Сервер Интеграции (СИ), у которого БИД получает данные и метаданные, сам принимающий узел (его ЦП, ОП, ЖД), сеть. Значительно увеличивается расход трафика.
База Интегрированных Данных (БИД) – это общесистемный компонент ЕСИМО, предназначенный для кэширования и предварительной обработки данных ИР на узле ЕСИМО, перед тем как эти данные будут использованы прикладными компонентами этого узла (Аналитический Комплекс (АК), ГИС-сервер и пр.).
БИД берет на себя такие общесистемные функции как скачивание, декодирование и разбор Транспортных Файлов Данных (ТФД) ИР в формате NetCDF и ASCII, получение метаданных по ИР, элементам и кодам классификаторов от СИ, их интерпретация и загрузка в БД узла, где они доступны всем прикладным компонентам.
Каждый загруженный в БИД ИР представляет собой таблицу. За счет того, что БИД использует весь набор метаданных об ИР, его экземплярах и элементах, загружаемый в БИД ресурс является полностью самоописывающимся. В силу этого любые изменения в составе и структуре ресурса, такие как: добавление или удаление экземпляра, изменение названия или адреса хранения экземпляра в источнике, добавление или удаление элемента, изменение порядка следования элементов в составе ресурса, изменение типа данных элемента, его длины или точности (в случае, если элемент числовой), а также изменения типа записи ИР (точка/профиль/грид), типа источника данных ИР (СУБД/каталог/объектный файл данных/автономное приложение) никак не нарушают процесс обновления ресурса в БИД и не требуют дополнительной перенастройки.
После доставки или планового обновления серии требуемых на узле ИР зачастую их данные не готовы к непосредственному использованию прикладными компонентами и нуждаются в предварительной обработке. Информация, полученная из различных источников, нуждается в интеграции с целью комплексного представления конечному пользователю посредством прикладных компонентов.
В результате изучения серии разнородных ИР, порожденных разными источниками и требований, которые накладывают прикладные компоненты к входному формату данных, для классификации производимых над ИР действий было выделено несколько этапов Жизненного Цикла (ЖЦ), которые может проходить ИР в ходе предварительной обработки его данных: объединение, приведение, фильтрация, вычисление, разбиение, накопление, индексация, пространственное преобразование, экспорт.
На настоящий момент в ЕСИМО зарегистрировано более 2 000 ИР, в состав которых входят элементы из множества элементов размером более 1 500 единиц, при этом число ресурсов и элементов постоянно прирастает. В связи с этим, написание специальных процедур обработки под каждый из используемых на узле ИР, также как и создание подобных процедур под каждый из существующих элементов не представляется возможным. В замен этому был предложен подход, предусматривающий создание проблемно-ориентированных функций обработки данных ИР, каждая из которых предназначена для решения своей задачи или ряда задач, относящихся к определенному этапу ЖЦ ИР. Все функции обработки ИР объединены в единый фреймворк (каркас функций). Функции, входящие во фреймворк, должны отвечать определенным требованиям:
Любая функция фреймворка реализует операцию или серию операций по преобразованию входных данных ИР, в результате которой формируется один или несколько выходных ИР;
Каждая функция определена на пространстве системных элементов (имеет своей областью определения пространство системных элементов);
Имя таблицы выходного (обработанного) ИР самостоятельно составляется (но в соответствие с общими правилами БИД) и возвращается функцией фреймворка в выражении «return». Другими словами, функция фреймворка инкапсулирует функцию именования выходного ИР;
Для каждой функции fwork определен режим макетирования, в котором функция возвращает название таблицы продуцируемого ресурса и состав ее элементов (атрибутов), но при этом никаких физических манипуляций с данными не производится;
Функция должна быть атомарной, т.е. выполнять элементарные действия, не повторяющиеся в других функциях фреймворка, но при этом быть «по возможности» универсальной, т.е. подходить для обработки данных как можно большего числа элементов (например, одна и таже функция используется как для разбиения по срокам, так и по горизонтам, так и по типам платформ);
Одна и таже функция может многократно быть включена в состав ЖЦ одного и того же ИР (подобно макросам);
Для каждого элемента, на котором определена функция, известны возможные значения, которые могут принимать входные параметры функции для данного элемента;
Допускается, чтобы функции частично перекрывали функционал друга;
Одна физическая функция может быть представлена пользователю как серия функций (на выбор) с разными значениями входных параметров, например, функция разбиения данных ресурса по срокам с различным шагом (1 ч./ 4 ч./ 12 ч.);
Модульность. Независимость функций fwork друг от друга. Каждая функция fwork является независимой мини-программой (модулем), набор и состояние переменных которой не зависит от набора и состояния переменных в других функциях fwork;
Любая функция фреймворка самостоятельно описывает метаданные для каждого продуцируемого ей ресурса в соответствие с общим форматом описания метаданных;
В составе входных параметров каждой функции должен быть флаг, указывающий записывать или нет метаданные по производному ресурсу (в зависимости от того, является ли производный ресурс результатом или просто предварительным расчетом).
В режиме выполнения функции все действия, производимые над данными ИР, в реальном времени фиксируются в таблице семафоров с указанием функции фреймворка, выполняемой в текущий момент времени, и этапа ЖЦ, к которому относится данная функция.