Каталог метаданных для описания Грид

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
РОССИЙСКАЯ АКАДЕМИЯ НАУК
ГЕОФИЗИЧЕСКИЙ ЦЕНТР
УТВЕРЖДАЮ
Директор ГЦ РАН
чл.-корр. РАН
_______________ А.Д. Гвишиани
“20” ноября 2008 г.
ОТЧЕТ О НАУЧНО-ИССЛЕДОВАТЕЛЬСКОЙ РАБОТЕ
по государственному контракту № СГ-2/07 от 16 июля 2007 г.
на выполнение научно-исследовательских работ по теме
"Развитие, исследование и внедрение средств высокопроизводительных
вычислений на основе технологий Грид с поддержкой гетерогенных,
территориально-распределенных вычислительных комплексов" шифр
2007-СГ-01, НИОКР "Создание средств хранения информации в
территориально-распределенных средах. Геоинформатика "
вид отчета: окончательный
Научный руководитель: ____________ к.ф.-м.н. М.Н. Жижин
Москва 2008
СПИСОК ОСНОВНЫХ ИСПОЛНИТЕЛЕЙ
Научный руководитель
к.ф.м.н., зав.лаб.
М.Н. Жижин
Коллектив исполнителей
ст.н.с.
А.В. Андреев
к.ф.м.н., ст.н.с.
С.Б. Березин
вед.инж.
А.Г. Власова
н.с.
Д.С. Войцеховский
к.т.н., ст.н.с.
А.В. Говоров
вед.инж.
А.Д. Груднев
вед.инж.
Д.С. Коковин
н.с.
Д.Ю.Мишин
н.с.
Д.П. Медведев
и.о.н.с.
А.С. Новиков
н.с.
А.А. Пойда
к.т.н., н.с.
А.Н. Поляков
2
РЕФЕРАТ
Отчет содержит 44 страницы, 21 рисунок и 4 таблицы.
Ключевые слова: Грид-сервис, высокопроизводительные вычисления, геоинформатика,
хранилище данных, общая модель данных, климатология, космическая погода.
Целью проекта является разработка технологии распределенного CDM-хранилища
данных на платформе СКИФ-ГРИД для геофизических приложений. Разработка грид–
сервисов доступа, поиска и визуализации данных в сверх-больших геофизических архивах
и демонстрация высокопроизводительной платформы СКИФ-ГРИД.
Результаты работы:
В рамках выполнения работ по этапу Государственного контракта № СГ-2/07 от
16 июля 2007 г. были проведены следующие запланированные научные исследования и
получены следующие результаты:
 разработан
каталог метаданных
для
описания Грид-сервисов данных
по
окружающей среде
o Разработана схема метаданных для каталога грид-сервисов.
o Разработана
архитектура
дополнительных
компонент
грид-сервисов
каталога метаданных, численного моделирования и распределения заданий
для загрузки OLAP-кубов данных по окружающей среде
 разработано активное хранилище данных в CDM-модели на базе кластера
реляционных баз данных для описания Грид-сервисов данных по окружающей
среде
o Разработана схема кластера баз данных для активного CDM-хранилища.
o Разработана
архитектура
клиентской
библиотеке
и
дополнительных
компонент грид-сервисов для параллельной записи, обработки и выборки
CDM-хранилища данных по окружающей среде.
o Проведено
профилирование
производительности
CDM-хранилища
на
тестовых наборах данных.
o Загружена в CDM-хранилище терабайтная база данных по реанализу
климата за последние 60 лет.
 Разработана технология параллельной выборки, обработки и добычи данных на
распределенном гриде источников данных по окружающей среде.
3
 Сервисы параллельной обработки данных реализованы в качестве расширений к
стандартной библиотеки функций грид-контейнера OGSA-DAI версии 3.0.
 Создан полигон для тестирования технологии параллельной обработки в
распределенной сети хранилищ данных.
 Проведено профилирование технологии на полигоне для библиотеки тестовых
запросов. Произведены оценки производительности и масштабируемости
технологии распределенных грид-сервисов моделирования и хранения данных.
 Пилотный сервис ESSE-СКИФ внедрен для производственного функционирования
в
инфраструктуру СКИФ-Грид
на
основе
промежуточного
программного
обеспечения UNICORE.
 Подготовлена документация по информационной системе, включая руководства
пользователя, программиста, администратора, и обобщающая научная публикация
(глава в монографии).
 Составлен итоговый научно-технический отчет (настоящий документ).
Степень внедрения. Разработано программное обеспечение активного хранилища
данных по окружающей среде в инфраструктуре СКИФ-Грид. ПО внедрено в порталы
проектов ESSE (внебюджет Microsoft) и CLASS (внебюджет NOAA).
Область применения. Архитектура и интерфейсы грид-сервисов пространственновременных данных
может быть рекомендована для практического использования на
следующем этапе научно-исследовательской работы и для решения других задач
геоинформатики и дистанционного зондирования Земли из космоса. Технологии создания
каталога метазаписей, поиска и интеграции данных, добычи данных в иерархии OLAPкубов в общей модели данных могут быть рекомендованы для использования при
создании Грид-сервисов и баз данных по окружающей среде в инфраструктуре СКИФГрид и для публикации в научной и учебной литературе.
Экономическая эффективность или значимость работы. Технико-экономическая
эффективность внедрения определяется тем, что на базе инфраструктуры СКИФ-Грид
создается
единая
кросс-платформенная
распределенная
высоко-производительная
платформа для доступа, анализа и визуализации многодисциплинарных сверхбольших
архивов геофизических данных.
4
Содержание
Введение .........................................................................................................................................6
Каталог метаданных для описания Грид-сервисов данных по окружающей среде ...............8
Схема метаданных для каталога Грид-сервисов.....................................................................8
Грид-сервисы выборки и моделирования данных ................................................................11
Сервис загрузки данных в хранилище ...................................................................................13
Примеры использования каталога..........................................................................................13
Интерактивный ресурс данных по солнечно-земной физике SPIDR ..............................13
Виртуальная обсерватория по радиационным поясам ViRBO ........................................18
Система поиска погодных сценариев ЕССЕ. Прототип интерфейса к архиву
спутниковых данных НОАА CLASS..................................................................................19
Активное хранилище данных в CDM-модели на базе кластера реляционных баз данных
для описания Грид-сервисов данных по окружающей среде..................................................21
Активное хранилище данных .................................................................................................21
Общая модель данных (Common Data Model, CDM) ...........................................................23
Схема кластера реляционных баз данных .............................................................................23
Параллельная обработка запросов к CDM-хранилищу........................................................25
Программный интерфейс управления данными ...................................................................25
Профилирование производительности CDM-хранилища ...................................................26
Реализация Грид-инфраструктуры ............................................................................................28
на основе проекта OGSA-DAI ....................................................................................................28
Оценки производительности и масштабируемости распределенных грид-сервисов
хранения данных..........................................................................................................................31
Внедрение сервисов данных по окружающей среде на основе OGSA-DAI на полигоне
СКИФ-Грид ..................................................................................................................................37
Визуализация данных об окружающей среде ...........................................................................40
Заключение...................................................................................................................................42
Список использованных источников.........................................................................................43
5
Введение
Дадим краткую характеристику современного состояния решаемой научнотехнической проблемы и исследований в данной области в Российской Федерации и за
рубежом.
Информатика окружающей среды - это быстро развивающаяся область на стыке
таких вычислительной техники и естественных наук, как искусственный интеллект,
геоинформационные системы (ГИС),
численное моделирование, программные и
пользовательские интерфейсы. Растущие объемы данных в сегодняшних системах
хранения и потребности научного сообщества, которое нуждается в интегрированном и
надежном представлении информации об окружающей среде для нужд моделирования,
требуют нового подхода к организации доступа и управления данными. Понятие
"окружающая среда" включает в себя элементы из многих областей, таких как
околоземное космическое пространство, атмосфера, океан, топография.
В настоящее время в области создания распределенных хранилищ данных
активные работы ведутся по следующим направлениям: каталоги метаданных, репликация
коллекций файлов, сверх-большие базы данных, объектные файловые системы (Network
Attached Storage), и веб- (или грид-) интерфейсы управления данными, [26 ] Foster, Ian;
Carl Kesselman. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann
Publishers. ISBN 1-55860-475-8.
Примерами реализаций каждого из направлений могут служить соответственно Global
Change Master Directory NASA [1], Database and Replica Services LCG [2], Apache Lucene
[3], и OGSA-DAI [4].
Во многих случаях, когда хранилище данных строится под конкретный набор
приложений, схема метаданных и общая модель данных (Common Data Model, CDM)
заранее известны, и все вышеупомянутые «универсальные» технологии можно
объединить и оптимизировать в единой распределенной иерархической системе хранения
и поиска данных, которые мы называем CDM-хранилищем.
За рубежом подобные разработки ведутся в рамках проекта NOAA Comprehensive
Large Array Stewardship System (CLASS) [5], который со-финансирует предлагаемый
проект совместно с исследовательской лабораторией Микрософт в Кембридже (в рамках
исследовательского проекта Environmental Scenario Search Engine), и Европейским гридконсорциумом DEGREE (в рамках шестой рамочной программы Европейской комиссии).
6
Распределенное хранение сверх-больших баз данных по окружающей среде и
параллельная конвертация данных на выходе численной модели в общую модель данных
(Common Data Model, CDM), и запись в реляционную базу данных. Например, данные в
CDM-хранилище поступают в виде набора бинарных файлов в специализированном метео
формате (GRIB) и в разных системах координат (сферические гармоники или
прямоугольная координатная сетка).
Необходимо параллельно извлечь массивы данных из файлов, привести их к общей
системе координат, и записать в CDM-хранилище в виде многомерных OLAP-кубов,
которые динамически выбираются на чтение в зависимости от геометрии запроса по
времени или по координатам средствами реляционной СУБД и грид-сервиса данных.
Доступ
(чтение,
инвентаризация
и
запись)
в
CDM-хранилище
осуществляется
посредством грид-сервисов с стандартизированным интерфейсом, поиск наличия данных
осуществляется в двухуровневом (коллекция – гранула) регистре метаданных типа
Виртуальная Обсерватория.
Для европейского реанализа погоды ERA-40 [6] за 40 лет на глобальной
координатной сетке 1 град. с шагом по времени 6 ч, из 20 Гб/год в формате GRIB
получается 60 Гб/год в формате СУБД MySQL за неделю счета на Dual Opteron сервере.
Полученная на выходе база данных (OLAP-куб) объемом ~3 Тб в свою очередь может
служить источником граничных условий для региональных климатических моделей
высокого разрешения.
7
Каталог метаданных для описания Грид-сервисов данных по
окружающей среде
На
сегодняшний
день
существует
возможность
высоко
реалистичного
моделирования окружающей среды на самых разных уровнях. Такие системы, как Global
Change Master Directory [1], разработанная в НАСА или Master Environmental Library [7],
созданная Отделом моделирования Министерства обороны США и др., позволяют искать
климатические (мета)данные, распределенные по сети, но возможности параллельного
поиска сразу в нескольких архивах метаданных, использующих различные XML схемы
для хранения записей, и тем более динамически формировать формы для запроса,
обработки и добычи данных в распределенных Грид-сервисах данных по окружающей
среде (наборы условий внутри архивов данных) вне разработанной нами технологии до
настоящего времени не было.
Нами было разработано и внедрено программное обеспечения для создания
федерации каталогов метазаписей, которые позволяют параллельный поиск, интеграцию и
добычу данных в распределенных Грид-сервисах и при этом поддерживают множество
различных схем метаданных из разных предметных областей.
Схема метаданных для каталога Грид-сервисов
Практически
все
существующие
форматы
научных
метаданных
не
предусматривают инструкций, позволяющих составить запрос на выборку данных, и не
всегда в достаточной мере описывают данные, доступные через сервисы. В то же время
сервисы данных, предусматривающие подобные инструкции, выдают метаданные в самых
разных форматах, что крайне неудобно для каталогизации метаданных по источникам.
Нами был разработан формат (XML схема) для описания способов запроса данных
из источника (Грид-сервиса) данных по окружающей среде, который назвали Ordering
Extensions (OE). Запись в формате ОЕ может служить основанием для создания формы
запроса к сервису данных в веб-интерфейсе заказа данных из источника или
использоваться программой-клиентом для создания запроса к Грид-сервису.
Использование формата ОЕ позволяет регистрировать в каталоге источники
данных и посылать им запросы пользователей на выборку, обработку и визуализацию
данных, тем самым приближая пользователей каталога через метаданные к самим данным.
В то же время, описание источников в едином формате облегчает агрегацию данных,
приходящих из разных источников (data fusion), и собственно поиск источников (data
8
discovery) независимо от типа метаданных, предоставляемых самим сервисом. ОЕ формат
позволяет описать как запрос к серверу электронных карт OpenGIS WMS/WFS/WCS [8], к
Грид-сервису OGSA-DAI [4] или Веб-сервису OPeNDAP [9].
Помимо перечисленного, ОЕ выполняет и функцию ограничения доступа к
данным. В формате ОЕ можно ограничить списки параметров и значений, запрашиваемых
в источнике, в сторону наиболее интересных для данной предметной области (Рис. 1).
Некоторые аргументы при заказе можно сделать «скрытыми», создавая тем самым фильтр
на получаемые от сервиса данные (например, ограничить список возможных форматов,
возвращаемых данных только одним, для которого имеются инструменты визуализации).
XML records
FGDC
OE 2
OE 1
Source
description
OE 3
Query
description
Source 1
Source 2
DataSource
Source 3
Max OE
WEB forms
Рисунок 1. Сопровождение одного источника данных несколькими записями метаданных
При использовании формата ОЕ для создания метазаписи появляется возможность
хранить в каталоге несколько записей для одного ресурса, различающихся между собой
направленностью на те, или иные характерные запросы пользователей. Такой подход
видится перспективным для использования описания сервисов предоставляющих широкие
возможности, но не всегда востребованные в полной мере пользователями. Большой
список параметров, форматов вывода, и других критериев выборки данных, может
смущать пользователей, и серьёзно осложнять заказ данных. Ограничивая критерии
достаточным списком на уровне ОЕ, администраторы сервиса и приложения могут
сделать заказ данных более простым и удобным для пользователей.
9
Формат ОЕ позволяет хранить информацию общую для ресурса данных и
необходимую для заказа данных через сервис:
 Идентификаторы ресурса (сервиса) данных
 Описательную информацию о сервисе и данных
 Описание доступных данных
o Пространственную привязку
o Временную привязку
o Параметрическую привязку
o Привязку к станциям
 Дополнительную информацию для заказа
o Возвращаемые форматы
o Скрытые ключи, и служебные флаги
 Информацию используемую приложением (интерфейсом из которого делается
заказ)
Путем преобразования XML метазаписи в форму заказа, вся эта информация
используется для обращения к сервису и предоставлению пользователям удобного
интерфейса (Рис. 2).
10
Рисунок 2. Веб-форма заказа данных полученная из ОЕ метазаписи
Грид-сервисы выборки и моделирования данных
Представляется
невозможным
написание
универсального
программного
обеспечения для обращения к любым сервисам доступа моделирования и доступа к
данным, поэтому, был сделан выбор в пользу небольших подключаемых модулей (plugin),
обслуживающих группы сервисов работающих по одной технологии или по одному
стандарту.
Объект, содержащий пользовательский заказ (queryObject), приходящий с формы
на основании ОЕ метазаписи, передаётся общему системному блоку, который на
основании специальных отметок в ОЕ, переправляет заказ соответствующему модулю.
При этом, заказ сохраняется в пространстве пользователя, а результат обработки заказа на
выборку или моделирования данных в виде объекта сохраняется за тем же пользователем
в одном из хранилищ.
11
Для приёма заказа от приложения, модуль должен иметь стандартный метод
(process), который в качестве входных параметров принимает запрос с формы заказа
(request) и идентификатор под которым заказ регистрируется в приложении. Далее,
модуль перестраивает полученный запрос в тот вид, какой необходим для запроса сервиса
данных, и передаёт сообразно технологии, в рамках которой работает сервис. Получив от
сервиса ответ (объект данных, dataObject), модуль сохраняет полученные данные в
хранилище.
Data Access
&
Processing
OE
(XML record)
Request
restrictions
Query form
(web-page)
Request
creation
DataQueryAction
(class)
Save
request
details
Service plugin
(class)
Redirect
request
User basket
Query
object
Data
service
Store
request
result
Storage
Link by
identifier
Data
object
Visualization,
Converting, ets.
Рисунок 3. Получение данных от Грид-сервиса через подключаемый модуль (plugin)
Подключение новых модулей к хранилищу в приложение максимально упрощено.
Что бы подключить возможность заказа данных из определенного сервиса, необходимо:
 Создание модуля для обращения к этому сервису (возможно использование модуля
для сервисов с такой же сигнатурой)
 Настройка модуля на работу внутри системы, объявление модуля для приложения
 Создание метазаписи о сервисе в формате OE, со ссылкой на модуль, которому
будут передаваться запросы
12
Сервис загрузки данных в хранилище
Для обеспечения загрузки в хранилище файлов данных пользователями была
разработана система, позволяющая создавать мета-запись одновременно с загрузкой
файла. Таким образом, пользователи получили возможность загружать изображения и
объекты данных
одновременно с созданием в каталоге метазаписи по загружаемому
объекту. Поиск объектов производится по описанию их в метазаписи, с последующей
визуализацией метазаписи и с возможностью получить из хранилища сам найденный
файловый объект.
При
этом,
хранение
файловых
объектов
обеспечивается
специальными
хранилищами, подключаемыми к приложению. В простом случаи роль хранилища может
выполнять директория на диске, в более сложных вариантах хранилище может
представлять из себя отдельное самостоятельное приложение, связанное с ВО при
помощи прикладного программного интерфейса (API) предусмотренного в этом
приложении, например, хранилище файлов S3 [10] или Веб-база данных SimpleDB фирмы
Amazon [11].
На сторону хранилища могут быть перенесены не только задачи по загрузке,
хранению и выгрузке объектов, но и по обработке, такие как, переформатирование, поиск
внутри объектов, создание сопутствующих объектов (например, мини-изображений для
предварительного просмотра и т.д.).
Примеры использования каталога
Задачи поиска метаданных и интеграции данных достаточно типичны в
современных приложениях геоинформатики, поэтому разработанные нами программное
обеспечение каталога метазаписей и схема OE уже оказались востребованы в нескольких
информационных системах из разных предметных областей областей, включая солнечноземную физику, анализ глобального изменения климата, и дистанционное зондирование
Земли из космоса. Далее мы приводим краткие описания указанных приложений с
указанием основных особенностей использования в них каталога метазаписей.
Интерактивный ресурс данных по солнечно-земной физике SPIDR
Space Physics Interactive Data Resource [12] – источник данных в области солнечноземной физики, функционирующий в рамках системы Мировых центров данных. Он
представляет собой распределенную сеть баз данных и серверов приложений,
позволяющую выбирать, визуализировать и моделировать исторические данные по
13
космической погоде в сети Интернет. SPIDR может работать как полноценное webприложение (портал) или как набор Веб-сервисов, предоставляющий функции доступа к
архивам данных для использования другими приложениями.
Р
Рисунок 4. Домашняя страница московского узла SPIDR
SPIDR осуществляет агрегацию разнородных источников данных, которая
становится возможной благодаря их «виртуализации». Под виртуализацией мы понимаем
создание унифицированного интерфейса для доступа к данным SPIDR-API, общего для
всех источников данных, доступных через SPIDR. Таким образом, системе не надо знать
ни природу своих источников данных, ни специфические методы доступа к ним. Все, что
нужно – это сетевой адрес, чтобы узнать содержимое этих источников на логическом
уровне (на уровне метаданных), и заказать выборку, обработку, форматирование, если
данные найдены.
SPIDR работает в основном с данными прямых наблюдений, представленными в
виде временных рядов, возможно, с привязкой к станции или координатам. Этим
14
объясняется специфика как проблем, решаемых данным программным средством, так и
модели представления данных.
Основные функции SPIDR по выборке, первичной обработке и моделирование
данных:
 усреднение данных по времени (например, в базе данных хранятся результаты
измерений с интервалом в один час, а нужно получить ряд осредненных значений
за каждый день наблюдений);
 оптимизация запросов путем выбора наиболее подходящих архивов данных. (во
многих источниках данных информация пересекается; например, существует два
хранилища, где представлена одна и та же физическая величина, но с различным
шагом по времени; тогда, в зависимости от запроса, выбираются данные либо из
базы данных с ближайшим шагом по времени);
 синтез данных и приведение к единой системе координат (например, общий
временной ряд объединяется из данных, попеременно полученных с нескольких
спутников).
Фактически, SPIDR может работать с любым хранилищем данных, для которого
существует описание на уровне метаданных и который поддерживается SPIDR API.
Однако, модель данных SPIDR на данный момент не совместима ни с одним
распространенным стандартом, вследствие чего приходится писать трансляторы из
стандартных протоколов в SPIDR. Для некоторых типов источников данных такие
трансляторы уже написаны (Рис. 5).
15
Реляционная
СУБД
SQL/JDBC
Объект данных
Служба доступа
к виртуальным
источникам
SOAP
Web-сервис
...
Другие
источники данных
Клиент
HTTP
FTP
Архив
изображений
Хранилище
файлов
Рисунок 5. Виртуализация источников данных в SPIDR
В настоящий момент это: базы данных (SQL/JDBC), хранилища файлы (FTP),
архивы изображения (HTTP). Кроме того, SPIDR может использовать Веб-сервисы в
качестве источников данных. Заметим, что так как сам SPIDR может работать как Вебсервис и, кроме того, он поддерживает SPIDR-API, то на множестве Веб-сервисов может
быть организовано иерархическое «дерево источников данных».
Источники данных, зарегистрированные в SPIDR на данный момент, перечислены
в Таблице 1.
16
Таблица 1. Источники данных SPIDR
Вид наблюдений
Спутники GOES
OMNI IMF – межпланетное
магнитное поле
IMF, минутные данные
Интервал
дат
1986 – 2005
Шаг по
времени
1 и 5 мин
Покрытие
1973 – 2005
1 час
1992 – 2005
1 и 5 мин
1 и 3 часа, 1
день
1 день
от 15 мин до
1 часа
3 спутника
7 спутников
Геомагнитные индексы
1932 – 2005
Число солнечных пятен
1610 – 2005
Ионосферные данные
1900 – 2005
Геомагнитное поле
1900 – 2005
1 мин и 1 час
461 станций
HPI NOAA
1978 – 2005
около 100
мин
9 спутников
HPI DMSP
1983 – 2005
около 50 мин
9 спутников
Космические лучи
(предварительные)
1999 – 2005
1 час
5 станций
Космические лучи (формат 4096)
1953 – 2005
1 час
117 станций
Космические лучи (общий формат)
1951 – 1999
1 час
39 станций
Изображения Солнца
1915 – 2005
1 день
6 диапазонов
Снимки со спутников DMSP
1996 – 2005
Данные датчика SSJ4 спутников
DMSP
2000 – 2005
Ночные огни городов мира
1991 и 2000
События космической погоды
1975 – 2000
4 снимка в
день
около 100
мин
206 станций
6 спутников
4 спутника
Метаданные верхнего уровня хранятся в стандартном формате FGDC [13] в XMLбазе данных разработанного нами каталога метаданных, программное обеспечение
который является составной частью новой версии SPIDR, установленной на узлах в
Болдере, Москве, Петропавловске-Камчатском и Кейптауне в ноябре 2007 г. Каталог
метаданных используется в текущей версии SPIDR для поиска данных по метазаписям
FGDC, редактирования раздела документации с текстовыми описаниями данных и для
управления
метазаписями
с
информацией
о
геомагнитных
станциях.
Создание
динамических форм запроса данных в SPIDR было реализовано ранее без использования
записей ОЕ.
17
Механизм интеграции данных и динамических запросов на основе метаданных
уровня каталога и инвентаризации системы SPIDR послужил прототипом для создания
настоящего каталога метазаписей в проекте СКИФ-Грид. По результатам работ в сентябре
был сделан доклад на международном совещании в Суздале, посвященном 50-летию
Международного геофизического года и в октябре 2007 г. была написана и представлена к
печати научная статья в новый журнал Earth Science Informatics издательства Springer [14],
которая в настоящее время находится на этапе рецензирования.
Виртуальная обсерватория по радиационным поясам ViRBO
Virtual Radiation Belts Observatory [15] – совместный проект РАН, НОАА и НАСА
по созданию специализированного каталога метазаписей по источникам данных для
исследования радиационных поясов (Рис. 6). Основной (но не единственной) ХML схемой
хранения метазаписей в каталоге ViRBO является Space Physics Archive Search and Extract
[16].
Рисунок 6. Домашняя страница каталога метазаписей ViRBO
18
Проект ViRBO целиком основан на разработанном нами каталоге метазаписей и
использует все его компоненты и функции, включая поиск данных, хранилища бинарных
объектов и доступ к Грид-сервисам данных по механизму ОЕ.
В декабре 2007 г. информационная система ViRBO демонстрировалась на съезде
Американского геофизического общества (опубликован абстракт, сделан устный доклад и
проведена демонстрационная сессия).
Система поиска погодных сценариев ЕССЕ. Прототип интерфейса к архиву
спутниковых данных НОАА CLASS
Демонстрационный портал интерфейса к архиву спутниковых данных НОАА
Comprehensive Large Array Stewardship System [5] использует разработанный нами каталог
метаданных для поиска данных по дистанционному зондированию Земли из космоса и
динамического формирования запросов на выборку данных из Грид-сервисов CLASS API
(Рис. 7).
Рисунок 7. Домашняя страница портала Грид-сервисов CLASS
19
Портал класс использует поисковик для добычи данных, разработанный нами
совместно с Исследовательской лабораторией Майкрософт в Кембридже Environmental
Scenario Search Engine [17,18,19,20,21], который со-финансирует работы по проекту
СКИФ-Грид. Поисковик ESSE использует механизм нечеткой логики для формирования
сценариев запросов к Грид-сервисам на поиск событий в окружающей среде.
Поиск данных архиве CLASS, формирование динамических запросов на выборку
данных и редактирование погодных сценариев в терминах нечеткой логики реализовано с
помощью разработанного нами каталога метазаписей.
По результатам работы в проектах CLASS и ESSE были сделаны доклады и
опубликованы статьи в ноябре 2007 г. на международной конференции ACM GIS 2007
(устный доклад и статья) [20] в Сиэтле и в декабре 2007 г. на съезде Американского
геофизического общества (абстракт и постер), а также подготовлена и находится в печати
глава книги Grid Data Mining [21].
20
Активное хранилище данных в CDM-модели на базе кластера
реляционных баз данных для описания Грид-сервисов данных
по окружающей среде
Опыт работы с большими массивами данных по окружающей среде говорит о том,
что создание специализированной базы для каждого набора данных – будь то реанализ
или прогноз погоды, геомагнитные или ионосферные вариации, и т.п. – достаточно
трудоемкий процесс. При этом оптимизация схемы и индексации базы данных под
определенный набор «типичных» запросов зачастую приводит к тому, что другие, не
предусмотренные
заранее
запросы
(напр.,
по
времени,
когда
оптимизируется
пространственный поиск), будут выполняться неоправданно долго. В любом случае
приходится использовать большие бинарные объекты (binary large objects, BLOBs) для
хранения групп наблюдений в едином массиве, с тем чтобы «сэкономить» объем
индексируемых объектов и, тем самым, объем и время доступа к ним. До настоящего
времени мы использовали «жесткую» конфигурацию геометрии и объема бинарных
объектов, которые в дальнейшем будем называть «чанки» (chunks). Выбор подмножеству
чанка, будь то интервал значений или прореженный массив, всегда осуществлялся на
стороне клиента, которому передавался весь чанк, выбранный из базы данных. В
литературе по базам данных подобная технология называется column database, Bigtable: A
Distributed Storage System for Structured Data (25).
Активное хранилище данных
При разработке архитектуры активного хранилища научных массивов данных мы
поставили следующие цели:
1. Создать универсальный контейнер для хранения массивов данных, которые можно
представить в виде общей модели данных (Common Data Model, CDM). Заметим,
что модель данных многомерного массива отличается от общепринятых в теории
баз данных реляционной, объектной и XML моделей.
2. Массивы данных в контейнере должны храниться в виде индексированных подмассивов (чанков), форма и объем которых могут заранее определяться при
создании массива.
3. Контейнер должен позволять распределенную и параллельную запись и чтение
чанков на кластере баз данных.
21
4. В случае нескольких узлов хранения массива, базовые операции по выделению
подмножеств чанка и простейшая обработка данных (напр., изменение геометрии
или интерполяция) должны производиться на процессоре, ближайшем к диску, на
котором записан чанк (для этого мы используем термин «активное» хранилище).
5. Хранилище должно иметь простой интерфейс, функционально соответствующий
общей модели данных и абстрагирующий пользователя от конкретной реализации
и схемы базы данных.
6. Реализация хранилища должна максимально использовать готовые решения из
области баз данных для эффективной индексации, ввода-вывода и синхронизации
данных.
В настоящее время уже имеются системы управлениями базами данных (СУБД),
которые позволяют программируемую обработку бинарных объектов с помощью
хранимых процедур на языках высокого уровня (С, С++, Java) внутри движка баз данных,
напр. MS SQL Server или Postgres. Для реализации прототипа активного хранилища
многомерных массивов мы выбрали MS SQL Server, поскольку он позволяет
программирование хранимых процедур на целом множестве языков платформы .NET,
включая объектно-ориентированные C# и J#.
Рабочий поток по обработке запроса данных в активном хранилище многомерных
массивов показан на Рис. 8. Выборка и первичная обработка чанков данных проводится на
сервере баз данных. Массив предварительно обработанных чанков передается из базы
данных клиентской библиотеке, которая объединяет их в новый массив (возможно,
отличной геометрии, но той же модели данных) и передает его приложению пользователя.
1. Call the client library with array
coordinates as call parameters
xmax, ymax
3. Select the requested data parts from
the appropriate chunks
2. Issue commands to the
database server
xmin, ymin
SQL Server
database
Client library
5. Merge the data parts and
return the whole array to the user
4. Return the data parts to
the client library
Рисунок 8. Выборка массива данных из активного хранилища.
22
Общая модель данных (Common Data Model, CDM)
Общая модель данных, которая соответствует многомерному массиву и вводобработка-вывод которой поддерживается на уровне интерфейса пользователя активного
хранилища, представлена на Рис. 9. В нашем прототипе мы используем упрощенный
вариант общей модели данных, предложенной консорциумом UNIDATA для объединения
моделей, форматов и сетевых интерфейсов доступа к массивам данных NetCDF и HDF.
Namespace
-name
1
*
1
Attribute
DataType
Dimension
-name
-dataType
-value
-name
-length
*
*
*
-byte
-short
-int
-long
-float
-double
-char
-String
Variable
1
-name
-shape
-dataType
+GetData()
*
Рисунок 9. Общая модель данных для активного хранилища многомерных научных массивов.
Переменная (Variable) является контейнером для многомерных массивов данных.
Она имеет имя (name), тип (DataType), координатные оси (Dimensions), и расширяемый
набор атрибутов (Attribute) для метаданных. Атрибуты имеют имя, значение, тип.
Например, атрибуты могут определять сдвиг и масштаб для значений массива.
Атрибутами мы задаем геометрию чанков для хранения массива. Координатная ось,
например – широта, долгота или время – имеет имя и длину. Значения координат хранятся
в переменных. Тип данных определяет тип хранимых данных, напр. целый или строковый.
Переменные могут иметь только числовые типы. Атрибуты могут быть строками.
Схема кластера реляционных баз данных
Разработанная нами универсальная схема реляционной базы данных для хранения
многомерных массивов научных данных состоит из двух частей – метаданных и
индексированного набора чанков.
23
Схема метаданных следует общей модели данных (Рис. 10). Назначение таблиц
variables, namespaces, dimensions, attributes, и types достаточно очевидно – в них хранятся
соответствующие атрибуты. В таблице shapes хранится геометрия (связь переменных и
координат) многомерного массива. Таблица servers используется в распределенных
запросах к кластеру баз данных.
servers
PK,FK1
PK
PK
PK
namespaces
var_id
host
port
database
PK
ns_id
U1
ns_name
login
passwd
dimensions
variables
PK
FK1,U1
U1
FK2
U2
U3
FK1,U1 dim_ns
U1
dim_name
dim_length
var_ns
var_name
var_type
data_table
index_table
attributes
type_id
type_name
type_length
dim_id
var_id
types
PK
PK
shapes
PK,FK1
PK
var_id
att_name
PK,FK2,U1 var_id
PK
dim_index
FK2
att_type
att_value
FK1,U1
dim_id
Рисунок 10. Таблицы метаданных в активном хранилище многомерных массивов.
Собственно данные хранятся в индексированных таблицах бинарных чанков,
которые в свою очередь могут быть равномерно распределены по параллельному кластеру
баз данных (в этом случае таблицы метаданных для массива копируются на каждый узел
кластера). Таблица чанков содержит объекты типа BLOB. Каждый чанк состоит из двух
частей: заголовка и массива данных. В заголовке чанка хранятся границы индексов
массива данных, являющегося подмножеством массива переменной в общей модели
данных и следующего в чанке сразу за этим заголовком (Рис. 11). Порядок следования
индексов в массиве данных следует стандартам языка C. Все данные хранятся с порядком
байт big-endian. Границы индексов для чанков хранятся в отдельной индексной таблице
базы данных для ускорения поиска необходимых чанков в случае запроса и обработки
части хранимого массива.
Header
x0min
x0max
...
Data
xn-1min xn-1max
24
air_data
PK
air_index
chunk_key
PK,FK1
PK
chunk_key
dim_index
I1
I1
key_min
key_max
chunk
Рисунок 11. Структура бинарных чанков и индекса данных в активном хранилище.
Параллельная обработка запросов к CDM-хранилищу
Рабочий поток выполнения распределенного запроса к активному хранилищу на
кластере баз данных показа на Рис. 12. Как видим, выделение части чанка происходит уже
на уровне СУБД, при этом уменьшается объем передаваемых клиенту данных и
равномерно
распределяется
нагрузка
на
их
обработку
между
процессорами
вычислительного кластера.
SQL Server
database
...
Client library
SQL Server
database
Рисунок 12. Баланс загрузки процессоров в распределенный запросе данных к активному
хранилищу.
Программный интерфейс управления данными
Пользовательский интерфейс управления активным хранилищем многомерных
массивов функционально приближен к интерфейсу NetCDF [22]. С этим интерфейсом
нами реализованы клиентские библиотеки функций на языках Matlab, Java и C#. Пример
скрипта на языке Matlab на выборку и визуализацию данных из активного хранилища
приведен на Рис. 13. Программисту, работающему с внешними массивами данными в
25
Matlab, разница в использовании функций из библиотеки NetCDF и из библиотеки для
активного хранилища будет практически незаметна.
Рисунок 13. Пример использования интерфейса к активному хранилищу на языке Matlab.
Профилирование производительности CDM-хранилища
Для иллюстрации различий в производительности при выполнении различных
запросов на выборку данных между column database и активным хранилищем
многомерных массивов мы провели сравнительный анализ трех способов хранения одного
и того же массива данных – реанализа погоды,
полученного по результатам
моделирования глобальной циркуляции атмосферы Национальным центрами защиты
окружающей среды и атмосферных исследований США (NCEP/NCAR Reanalysis). Данные
реанализа представляют собой четырехмерные массивы значений параметров погоды
(напр., относительной влажности) за период с 1948 по настоящее время для регулярной
сетки координат (2,5 град), уровней высот, с постоянным шагом по времени (6 час). В
случае column database в качестве бинарных объектов мы использовали либо временные
ряды в узлах координатной сетки (индексация по пространству NCEP_FULL), либо
26
данные на сетке координат (индексация по времени NCEP_G). В активное хранилище
массивы данных реанализа NCEP/NCAR записаны в виде прямоугольных чанков
(интервалы времени-координат-высот), проиндексированных по всех координатам
(SINGLE и MULTI). Времена выполнения запросов на выборку одного объема данных с
различной геометрией (от временного ряда до поля координат) к трем базам данных
показаны в виде графиков на Рис. 14.
Рисунок 14. Сравнение производительности column database и активного хранилища.
Как видим из графиков на Рис. 14, при выполнении запросов со специальной
геометрией, отвечающей геометрии бинарных объектов в column database, они имеют
преимущество перед универсальным подходом, принятым в активном хранилище. Когда
же геометрия запроса существенно отличается от геометрии column database, технология
активного хранилища имеет явное преимущество по скорости доступа к данным. При
этом общий объем набора данных в column database и в активном хранилище отличаются
не принципиально.
Разница в скорости выборки данных из активного хранилища в случаях SINGLE и
MULTI объясняется тем, что в случае SINGLE мы использовали один сервер баз данных
MS SQL Server, а в случае MULTI чанки многомерного массива выбирались из
параллельного кластера на четырех компьютерах с MS SQL Server.
27
Реализация Грид-инфраструктуры
на основе проекта OGSA-DAI
Для совместимости с инфраструктурой Грид мы используем контейнер Гридсервисов OGSA-DAI [4]. Целью проекта OGSA-DAI является разработка промежуточного
программного обеспечения для помощи в интеграции данных с раздельных источников
через Грид. Контейнер сервисов OGSA-DAI обеспечивает доступ к ресурсам данных,
например реляционным или XML-базам данных через веб-сервисы. Сервисы OGSA-DAI
позволяют запрашивать, изменять и перемещать данные между контейнерами и
клиентским приложением. Сервисы OGSA-DAI могут быть встроены в инфраструктуру
Грид (Globus Toolkit 4, UNICORE, gLite). Таким образом, OGSA-DAI предоставляет
пользователю возможность использовать Грид-среду для своих ресурсов данных.
Чтобы встроить новый сервис данных в контейнер OGSA-DAI, надо реализовать
стандартный интерфейс ресурса данных DataServiceResource и набор методов (поанглийски “activities”), которые этот ресурс будет поддерживать. В результате мы создали
следующий набор “activity” для внедрения в OGSA-DAI, представленный в таблице 2.
Условно наши методы можно разделить на выборку, поиск и обработку данных, а также
запрос метаданных.
Таблица 2 - Список функций, поддерживаемых в OGSA-DAI контейнере
Метод
Описание
GetMetadataActivity
Возвращает метаданные по требуемому
источнику
GetCdmDataActivity
Производит выборку данных с требуемыми
параметрами
FuzzySearchActivity
Принимает на вход один или более
временных рядов и возвращает набор
коэффициентов релевантности
DataProcessActivity
Принимает на вход один или более
временных рядов и возвращает новый
временной ряд
28
Функции по поиску сценариев событий в данных в FuzzySearchActivity не привязаны к специальному источнику или типу данных. Это делает наш поисковик
исключительно гибким. В простейшем случае можно искать события по нескольким
параметрам, хранящимся на локальной базе данных. Для этого нужно объединить в одном
«perform»-документе результаты с выхода нескольких запросов на выборку данных во
входной поток для поиска данных на том же OGSA-DAI-сервере (Рис. 15).
Рисунок 15. Запрос на поиск на одном OGSA-DAI-сервере
В более продвинутом сценарии можно объединять данные для поиска из разных
источников OGSA-DAI. На Рис. 16 показана ситуация, когда часть данных для сценария
выбирается и обрабатывается на удаленном сервере, полученная там «частичная» функция
принадлежности передается с помощью стандартных транспортных операций на
локальный сервер, где затем объединяется с остальными данными в общий резуль-тат
поиска событий.
Рисунок 16. Распределенные запросы в OGSA-DAI
29
Выход новой версии контейнера Грид-сервисов данных OGSA-DAI 3.0 в 2007 г.
существенно расширил возможности его использования для создания распределенных
параллельных потоков обработки данных. Более того, версия 3.0 позволяет интеграцию с
большинством версий промежуточного программного обеспечения для инфраструктуры
Грид, в частности с Globus Toolkit 4 («американский» Грид), gLite (EGEE) и UNICORE, на
котором основана инфраструктура СКИФ-Грид. В области распределенной обработки
новая версия OGSA-DAI позволяет полноценный асинхронный вызов сервисов и
синхронизацию потоков данных на локальном и удаленном узле.
30
Оценки производительности и масштабируемости
распределенных грид-сервисов хранения данных
Большие многодисциплинарные архивы данных по необходимости распределены
между удаленными хранилищами, поэтому особый интерес приобретает возможность
эффективной распределенной обработки данных. Это возможно путем вычисления ряда
предикатов и подвыражений на удаленных машинах, с последующей сборкой частичных
результатов на одном узле. Попробуем оценить эффективность такой организации
рабочего потока. Для простоты будем считать, что у нас два узла и на каждом есть
источник данных. Требуется произвести поиск по некоторому алгоритму на некотором
суммарном объеме данных V. В первую очередь нас интересует работа со сверхбольшими
базами данных, поэтому будем рассматривать линейные алгоритмы. Кроме того, считаем,
что линейный алгоритм легко распараллеливается.
Рассмотрим три случая. В первом случае мы половину данных берем с первого
узла, половину со второго. Каждую половину обрабатываем на том же источнике, на
котором находятся данные. Частичные результаты объединяем на одном из узлов. Это
распределенный вариант поиска. Во втором случае мы берем половину данных с первого
узла, половину – со второго. Необработанные данные со второго узла пересылаем на
первый, где производится обработка всего объема данных целиком. Это распределенная
параллельная выборка и нераспределенный последовательный поиск. В третьем же случае
мы будем считать, что у нас и выборка и обработка производятся на одном узле. Это
локальные последовательные выборка и поиск. Для удобства предположим, что
вычислительные характеристики обоих узлов равны. В случае распределенного поиска
получаем
V
V  V
 V
 V
T1  a    c  Q  R   d  R  R 
2
2
2
 2
 2
(27) ,
где
a - коэффициент, обратно пропорциональный скорости выборки данных из источника,
который не зависит от объема V, так как можно считать, что скорость выборки из
источника линейна по объему.
c - коэффициент временной задержки процесса обработки. Измеряется в единицах
секунда/байт и складывается из двух составляющих: коэффициента сложности
алгоритма (L) и коэффициента производительности узла (P). Коэффициент сложности
является константой, так как мы рассматриваем только линейные алгоритмы, и
показывает, сколько операций над заданным объемом данных надо произвести для
31
достижения цели. Коэффициент производительности задает скорость выполнения
операций на узле и c рассчитывается по формуле c 
L
P
V - объем данных
Q - коэффициент, обратно пропорциональный скорости передачи данных между узлами:
R - отношение объема результирующих данных к объему исходных
d – коэффициент, обратно пропорциональный линейному коэффициенту времени
форматирования (десериалиазации) результирующих данных
Выборка и поиск данных состоят из нескольких этапов (прямая аналогия с Map-Reduce):
1) Выборка сырых данных из источника (мы считаем, что эта величина линейно
зависит от объема данных). Также важна и форма запроса, но будем считать, что
a - параметр, независящий от формы. Кроме того, будем считать, что на обоих
узлах этот параметр одинаков. Деление на два вызвано тем, что на каждом из узлов
данные выбираются параллельно.
2) Обработка половины данных на каждом узле (Map)
3) Пересылка результата, полученного на втором узле, на первый
4) Форматирование общего результата (Reduce)
В этой формуле мы не учли, что для слияния промежуточных результатов
приходится использовать некий второй алгоритм, тоже линейный (пусть коэффициент
временной задержки p ). В противном случае надо прибавить еще одно слагаемое pRV
В случае распределенной выборки и локального поиска имеем
V
V 
T2  a    Q  cV  d  RV 
2
2
(28)
Второе слагаемое включает пересылку сырых данных со второго узла на первый.
В локальном случае
T3  aV  cV  dRV
(29)
Сравним первый и второй случаи:
1
1
T2  T1  V Q1  R   c или T2  T1  V Q 1  R   c  2 pR 
2
2
(30)
В первом случае выигрыш во времени несомненен: пересылать меньший объем
данных и выиграть в два раза на параллельной обработке.
Сравним теперь параллельный случай с последовательным
32
 a c QR 
 a c QR  1
T3  T1  V  a  c   V   
 V   
  V  a  c  QR 
2 2 2 
2 2 2  2
(31)
или
1
T3  T1  V  a  c   Q  2 p  R 
2
(32)
Здесь, как мы видим, преимущество у распределенной обработки в том случае,
если затраты на передачу результата и объединение ниже по сравнению с преимуществом,
получаемым за счет ускорения получения чистых данных и скорости обработки.
Ппробуем подтвердить наши расчеты экспериментом. Для этого мы сравнили на
реальном стенде
случаи распределенной параллельной обработки и распределенной
выборки. В эксперименте использовались два узла, но с разными характеристиками.
Чтобы избавиться от влияния неравномерного распределения мощностей, мы меняли
узлы местами и симметризовали результат.
Для экспериментов с распределенной обработкой данных в августе 2008 г. был
создан полигон, который состоит из двух удаленных ресурсных центров СКИФ-Грид, на
каждом из которых установлены серверы баз данных и серверы приложений. Узлы
установлены в вычислительных центрах Геофизического центр и Института космических
исследований РАН и соединены между собой WAN-линком 1 Гбит/c. Узлы имели
следующие характеристики:
Узел 1 (ГЦ РАН)
Сервер приложений dimm.wdcb.ru:
ОС Linux
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
4 GB Ram
JDK 1.6.0_02-b05
Apache Tomcat 5.5.20
MySQL server:
Сервер баз данных arca6.wdcb.ru:
ОС MS Windows 2003
Intel Core 2 DUO 4400 2 Ghz
4GB Ram
MySQL 5.0.51a
Узел 2 (ИКИ РАН)
Сервер приложений и база данных aqua.wdcb.ru:
Linux
Dual core Intel(R) Xeon(TM) CPU 3.00GHz
2 GB RAM
JDK 1.6.0_04-b12
Apache Tomcat 6.0.16
MySQL 5.0.45
33
В ГЦ РАН серверы приложений и баз данных установлены на разных компьютерах,
соединенных между собой LAN-линком 1 Гбит/с. В ИКИ РАН серверы приложений и баз
данных совмещены на одном компьютере. В качестве промежуточного программного
обеспечения для выборки и обработки использовалась программная реализация Гридсервисов OGSA-DAI, представленная в предыдущем разделе.
Рассмотрим
типичный
запрос
по
анализу
климатических
трендов
в
агроклиматологии: вычислить среднемесячную температуру и среднемесячную скорость
выпадения осадков в каждой точке регулярной географической сетки с шагом 2,5 градусов
по широте и долготе в пределах: щирота – от 40 до 75 градусов СШ, долгота от 25 до
177,5 градусов ВД (для территории России). Временной интервал варьируется, чтобы
изменять объем запрашиваемых данных по двум параметрам: 2х25 МБ (запрос на 16 лет),
2х37,5 МБ (запрос за 24 года), 2х50МБ (данные за 32 года). Объем выходных данных
после расчета – в 120 раз меньше исходных. Скорость обмена данными между
удаленными узлами порядка 57 Мбит/сек. Мы использовали два симметричных запроса
для последовательного запроса и распределенной выборки, потому что характеристики
узлов полигона различны. Для каждого объема данных запросы проводились по три раза с
последующим осреднением времени выполнения по шести запросам.
В итоге были
получены следующие результаты, представленные в Таблице 3 и на графике (Рис. 17)
Таблица 3. Временные затраты на три вида обработки на трех объемах данных
Вид обработки
2x25Мб 2x37,5Мб 2x50Мб
Распределенная обработка 16,43
19,9
24,35
Распределенная выборка
26,15
36,07
45,69
Последовательный запрос
22,85
28,82
34,45
34
Рисунок 17. Зависимость временных затрат на обработку от объема обрабатываемых
данных для трех вариантов поиска
Экспериментальный результат соответствует теоретическим предположениям о
том, что распределенная обработка будет наиболее выигрышней во времени. То, что
последовательное выполнение запроса находится между двумя другими запросами также
объяснимо:
коэффициент
R
1
,
120
что
дает
значению
формулы
1
T3  T1  V  a  c  QR  существенное положительное значение. Иными словами,
2
распределенный запрос существенно выигрывает у локального за счет скорости обработки
и не проигрывает много при передаче данных между узлами за счет высокого
коэффициента уменьшения объема данных при обработке. Соотношение результатов при
распределенной выборке с централизованной обработкой и последовательным запросом
объясняется тем, что обработка занимает равное время, но при распределенной выборке
есть существенный проигрыш во времени передачи данных между узлами по сравнению с
передачей данных по локальной сети.
Кроме того, из графика мы видим, что все три результата близки к линейным, что
доказывает масштабируемость наших алгоритмов и программной реализации для
параллельного поиска событий. Незначительные отклонения от линейных графиков в
реальном эксперименте объясняются затратами на управление схемой вычисления и
потоками данных.
35
Теперь попробуем подставить данные эксперимента в формулу на примере
сравнения запросов с распределенной обработкой и распределенной выборкой с
централизованной обработкой.
1
T2  T1  V Q 1  R   c 
2
Здесь R 
(33)
1
, поэтому выражение 1  R  можно приравнять к единице. Приходим к
120
сумме двух слагаемых:
Q
c
V V
2
2
T2  T1 
(34)
Первое слагаемое отвечает за временные затраты на передачу данных между узлами,
второе – за временные затраты при обработке данных. Мы измерили скорость передачи
данных между узлами. На практике она несколько отличалась от объема передаваемых
данных, но в среднем это значение примерно 57Мб/сек. Кроме того, мы измерили затрату
времени на обработку данных в нашей реализации (т.е. мы замерили не c, а все второе
слагаемое). В результате получили следующие цифры, представленные в Таблице 4.
Таблица 4. Разложение временных затрат по составляющим
Временные затраты
50 MB 75 MB 100 MB
затраты на сетевой обмен 3,5
5,26
7,02
затраты на обработку
5,36
8,49
12,03
другие затраты
0,86
2,42
2,29
В таблице в третьей строке представлена разность в секундах между тем, что
должно получиться по формуле и тем, что получилось на самом деле. Заметно
существенное превышение времени, потраченного на обработку над временем,
затраченным на передачу исходных данных, а также нелинейный рост времени обработки.
Оба момента объясняются тем, что замеры производились не для математических
алгоритмов, а для их программной реализации.
Несмотря на некоторые отклонения экспериментально полученных значений от
значений,
полученных
подтверждает
факт
теоретическими
существенного
расчетами,
выигрыша
параллельной обработке данных.
36
по
приведенный
времени
при
эксперимент
распределенной
Внедрение сервисов данных по окружающей среде на основе
OGSA-DAI на полигоне СКИФ-Грид
Основными целями создания СКИФ-полигона являлись отработка технологии
развертывания грид-систем на основе федерации суперЭВМ СКИФ и обеспечение базы
для проведения пилотных проектов использования таких грид-систем как для проведения
научно-исследовательских
расчетов,
так
и
развертывания
сервисов
высокопроизводительной обработки данных. Программное обеспечение СКИФ-полигона
включает в себя как компоненты, которые должны быть установлены на ресурсных узлах
грид-системы, так и программные обеспечения, обеспечивающие интерфейс конечным
пользователям
системы.
В
Институте
программных
систем
РАН
развернут
и
функционирует центр управления СКИФ-полигона, обеспечивающий инфраструктуру
существования грид-среды.
В качестве основы для программного обеспечения промежуточного слоя
(middleware) для СКИФ-полигона используется пакет UNICORE 6.1. Проект UNICORE
(UNIform Interface to COm-puter REsources) финансируется Министерством образования и
науки Германии. Цели разработки UNICORE включают единый и легкий в использовании
графический интерфейс пользователя, открытую архитектуру, основанную на понятии
абстрактного задания, а также эксплуатацию существующих и находящихся на стадии
становления технологий, основанных на стандарте Java и веб-технологиях. UNICORE
обеспечивает интерфейс для подготовки заданий и безопасного их представления на
распределенные ресурсы суперЭВМ.
Распределенные приложения в UNICORE могут выполняться на вычислительных
узлах асинхронно или синхронно-последовательно. Задание в UNICORE содержит
снабжается информацией об узле, для которого оно предназначено, о необходимых
требованиях к вычислительным ресурсам на узл, и зависимостях между различными
частями задания. Структурно задание UNICORE — это рекурсивный объект, содержащий
группы заданий и задач. Главные компоненты UNICORE: агент подготовки заданий (JPA);
контроллер монитора заданий (JMC); веб-портал UNICORE, также называемый шлюзом
(Gateway); супервизор сетевых заданий (NJS); графический интерфейс пользователя,
основанный на Java-аплетах.
Клиент UNICORE дает возможность потребителю создавать, представлять и
управлять заданиями с любой рабочей станции, подключенной к Internet. Клиент
соединяется с UNICORE через шлюз, который подтверждает подлинность клиента.
Задания, предназначенные для локальных компьютеров, выполняются на их пакетных
37
подсистемах, задания для выполнения на удаленных узлах передаются через шлюз. Все
необходимые передачи данных и синхронизации выполняются серверами на узлах.
Серверы также сохраняют информацию о статусе и результатах работы, передавая их
клиентам по запросу пользователя.
Геофизический центр РАН совместно с Институтом программных систем РАН
участвовал в работах по развертыванию промежуточного программного обеспечения
UNICORE на сайтах СКИФ-полигона, а также разработал программное обеспечение для
развертывания сервисов хранения и обработки данных на основе программного
обеспечения OGSA-DAI.
Клиент для сервиса данных OGSA-DAI версии 3 под управлением UNICORE
отличается от «стандартного» клиента OGSA-DAI тем, что он использует специальные
библиотеки для аутентификации соединения с UNICORE. Построение документа для
запроса
происходит
с
использованием
классов
из
пакета
uk.org.ogsadai.namespaces.x2007.x04, входящего в состав библиотеки UNICORE. В
отличие от стандартных клиентских классов OGSA-DAI, где большая часть работы по
построению документа запроса делается автоматически клиентской библиотекой,
построение объекта запроса для UNICORE на всех уровнях происходит через добавление
и связывание классов, представляющих собой отдельные элементы документа запроса.
Инсталляция сторонних модулей OGSA-DAI в промежуточное программное
обеспечение UNICORE ничем не отличается от стандартной. Модификация кода
приложения также не потребовалась.
На Рис. 18 представлена страница портала
UNICORE в Геофизическом центре РАН с зарегистрированным сервисом данных по
окружающей среде под управлением OGSA-DAI. На Рис. 19 представлен результат
работы запроса к сервису данных, полученный клиентом UNICORE. Запрашивались
данные по температуре воздуха в Москве. От сервиса получен XML-документ с данными
и описанием единиц измерений и местоположения.
38
Рисунок 18. Страница портала UNICORE с сервисом данных OGSA-DAI на сервере
Геофизического центра РАН.
Рисунок 19. Результат выполенения запроса к погодному сервису OGSA-DAI клиентом UNICORE.
39
Визуализация данных об окружающей среде
Визуализация является одним из самых эффективных способов анализа и исследования геофизических данных, в том числе данных, полученных со спутников. Можно
сформулировать три основных требования к ПО для визуализации научных данных:
1) ПО должно позволять исследователю охватывать глобальную картину, а при
необходимости быстро увеличивать уровень детализации до необходимого;
2) взаимодействие с системой должно происходить интерактивно, без существенных задержек при смене способа отображения или смене отображаемых данных;
3) система визуализации должна быть максимально универсальной и отображать
данные из максимально широкого круга источников (сервисов) данных.
В качестве исходного ПО для визуализации было взято приложение NASA World
Wind [23], которое позволяет интерактивно отображать трехмерное изображение земного
шара на основе спутниковых изображений Landsat и данных Shuttle Radar Topography.
Особенностью NASA World Wind является доступность исходных текстов и архитекту-ра,
позволяющая расширять возможности ПО. Использование библиотеки Microsoft DirectX и
современных
средств
аппаратного
ускорения
эффективно
отображает
слож-ные
трехмерные данные.
На основе NASA World Wind создана система, позволяющая отображать геофизические данные различных форматов [20,24]. Поддерживаются скалярные поля на
равномерной сетке по широте/долготе, а также визуализация спутниковых данных Defense
Meteorological Satellite Program (DMSP) на поверхности Земли. При визуализации данных
DMSP применяется динамическое изменение разрешения изображений, позволяющее
совместить высокую производительность и необходимый уровень детализации. В
качестве
интерфейса
для
получения
данных
применяются
протоколы
системы
Environmental Search Scenario Engine (ESSE), созданные на основе OGSA-DAI и языка
разметки XML, а также сервисы Thematic Realtime Environmental Distributed Data Services
(THREDDS) по протоколу OPeNDAP. Более того, система построена таким образом,
чтобы собственно визуализация не зависела от источника данных, тем самым делая
простым процесс добавления новых источников данных. Использование метаданных и
широко распространенных протоколов позволяет сделать систему визуализации легко
адаптируемой, в том числе и для отображения спутниковых данных (Рис. 20).
40
Рис. 20. Визуализация данных с грид-сервисов с помощью NASA WorldWind
Для визуализации данных, заданных в системе координат широта/долгота, в веббраузере разработали архитектуру и прототип библиотеки на платоформе .NET, используя
картографические сервисы VirtualEarth, предоставляемые фирмой Microsoft. Изображение
произвольных данных на элементе VirtualEarth является нетривиальной задачей.
VirtualEarth не позволяет штатными средствами вывести текст, положить изображение в
заданный прямоугольник широты/долготы, нарисовать сложный графический объект. В
качестве клиента выступает набор Java-скриптов, работающих в рамках VirtualEarth.
Скрипты конфигурируются таким образом, чтобы им был известен адрес сервера WMS.
На элементе управления VirtualEarth создается панель управления, позволяющая
пользователю управлять временем, а также анимацией, если сервер электронных карт
поддерживает такую возможность, и изменять параметры визуализации согласно
возможностям WMS. Скрипты отслеживают сдвиг карты, изменение масштаба и
реагируют на это запросом на рендеринг нового участка изображения, вызывая метод
WMS GetMap, и изображением полученных данных на поверхности элемента VirtualEarth
(рис. 21).
41
Рисунок 21. Визуализация данных из Грид-сервиса в веб-браузере с наложением на карту
Microsoft Virtual Earth.
Заключение
Результаты работы оформлены в виде главы книги, двух статей и трех докладов на
международных конференциях в США и России.
Архитектура и интерфейсы грид-сервисов пространственно-временных данных
может быть рекомендована для практического использования в научно-исследовательской
работе, а также для решения задач геоинформатики и дистанционного зондирования
Земли из космоса. Технологии создания каталога метазаписей, поиска и интеграции
данных, добычи данных в иерархии OLAP-кубов в общей модели данных могут быть
рекомендованы для использования при создании Грид-сервисов и баз данных по
окружающей среде в инфраструктуре СКИФ-Грид и для публикации в научной и учебной
литературе.
Технико-экономическая эффективность внедрения определяется тем, что на базе
инфраструктуры СКИФ-Грид создается единая кросс-платформенная распределенная
высоко-производительная
платформа
для
доступа,
анализа
и
визуализации
многодисциплинарных сверхбольших архивов геофизических данных.
Результаты НИР превосходят по гибкости языка запросов и скорости выборки
данных предшествующие достижения, известные из литературных источников.
42
Список использованных источников
[1] Каталог метаданных НАСА по окружающей среде Global Change Master Directory
http://gcmd.nasa.gov
[2] Database and Replica Services LCG
[3] Проект Apache Lucene http://lucene.apache.org/
[4] Проект OGSA-DAI http://www.ogsadai.org.uk/
[5] Демонстрационный портал Грид-сервисов данных архива НОАА по дистанционному
зондированию Comprehensive Large Array Stewardship System
http://spidrd.ngdc.noaa.gov/class
[6] Проект по реанализу погодных данных ERA-40
http://www.ecmwf.int/research/era/do/get/era-40
[7] Master Environmental Library Отдела моделирования Министерства обороны США
https://mel.dmso.mil/
[8] Стандарты OGC консорциума http://www.opengeospatial.org/
[9] Стандарт OPeNDAP http://opendap.org/
[10]
Simple Storage Service (S3) фирмы Amazon
http://www.amazon.com/gp/browse.html?node=16427261
[11]
Веб-база данных SimpleDB, разработанная фирмой Amazon
http://docs.amazonwebservices.com/AmazonSimpleDB/2007-11-07/DeveloperGuide/
[12]
Space Physics Interactive Data Resource, Грид сервисов данных по солнечно-земной
физике, http://spidr.ngdc.noaa.gov
[13]
Схема метаданных Federal Geographic Data Committee, США
http://www.fgdc.gov/metadata
[14]
Журнал “Earth Science Informatics” издательства Springer
http://www.springerlink.com/content/120988/
[15]
Virtual Radiation Belts Observatory - каталог метазаписей по данным о
радиационных поясах http://spidrd.ngdc.noaa.gov/virbo
[16]
Space Physics Archive Search and Extract - схема метаданных по солнечно-земной
физике, предложенная НАСА http://www.spase-group.org
[17]
Zhizhin, M., A. Poyda, D. Mishin, D. Medvedev, E. Kihn, V. Lyutsarev. Scenario Search
on the Grid of Environmental Data Sources. MSR Technical Report, July 2006
[18]
Zhizhin, M., A.Poyda, D.Mishin, D.Medvedev, E.Kihn, V.Lyutsarev. Environmental
Scenario Search Engine (ESSE) – distributed, optimized, visible, MSR Technical Report,
May 2007
43
[19]
Zhizhin, M., E. Kihn, R. Redmon, A. Poyda, D. Mishin, D. Medvedev and V. Lyutsarev.
Integrating and mining distributed environmental archives on grids, Concurrency and
Computation: Practice and Experience, vol. 19, pp. 2157 – 2170, 2007
[20]
Zhizhin, M, E Kihn, V Lyutsarev, S Berezin, A Poyda, D Mishin, D Medvedev and D
Voitsekhovsky, Environmental scenario search and visualization, Proc. 15th ACM
symposium on Advances in geographic information systems, 2007
[21]
Zhizhin M, A Poyda, D Mishin, D Medvedev, E Kihn, V Lyutsarev, Grid Data Mining
with Environmental Scenario Search Engine (ESSE), Chapter 13 in Data Mining Techniques
in Grid Computing Environments, Ed. Werner Dubitzky, pp 281-306, Wiley, 2008
[22]
Формат данных NetCDF http://www.unidata.ucar.edu/software/netcdf/
[23]
Приложение NASA World Wind http://worldwind.arc.nasa.gov/
[24]
Жижин, М.Н., А.А. Пойда, Д.Ю. Мишин, А.П. Платонов, А.А. Солдатов, В.Е.
Велихов, М.Н. Боярский, Р.Р. Назиров. Поиск данных в Грид: соотношение
производительности сетей, вычислительных кластеров, хранилищ данных. Открытое
образование, № 4 2008, стр. 29-39
[25]
Bigtable: A Distributed Storage System for Structured Data
[26]
[1 ] Foster, Ian; Carl Kesselman. The Grid: Blueprint for a New Computing
Infrastructure. Morgan Kaufmann Publishers. ISBN 1-55860-475-8.
44