Хранилище данных лидарного зондирования в распределенной информационной системе

УДК 004.75:004.9:004.7 М.Ю. Катаев, А.И. Петров

Хранилище данных лидарного зондирования в распределенной информационной системе

Приводится описание хранилища данных для распределенной информационной системы лидарного зондирования параметров атмосферы. Рассматриваются различные варианты построения хранилища данных. Показывается, что для данной предметной области хранилище данных должно быть согласовано с методами обработки. Приведен интерфейс окна клиента информационной системы, который явно связан с хранилищем.

Ключевые слова: лидар, атмосферные параметры, распределенные системы, хранилище данных.

Введение

Лидар как устройство для исследований атмосферы Земли, ее газового состава, аэрозоля, перемещений воздушных масс стал обычным инструментом. Этот инструмент используется для сбора и записи информации о параметрах атмосферы Земли и даже планет Солнечной системы. Он может быть установлен на морских судах, самолетах, космических летательных аппаратах и др. География стационарных станций лидарного зондирования атмосферы весьма обширна и все время расширяется. Данные, собираемые по всему миру, позволяют полнее изучить атмосферные процессы и протестировать новые алгоритмы обработки применительно к новым условиям и оборудованию [1, 2].

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

Для организации оперативного обмена и обработки данных лидарного зондирования атмосферы (ЛЗА) в Томском государственном университете систем управления и радиоэлектроники (ТУСУР) совместно с ИОА СО РАН создается распределенная информационная система [3]. Данная система базируется на результатах предыдущей работы [4, 5]. Система предполагает наличие в г. Томске сервера приложений, позволяющего удаленно обрабатывать данные ЛЗА с целью восстановления профилей концентрации озона, отношения аэрозольного рассеяния, профилей температуры. Предполагается создание клиентского программного обеспечения, реализующего отдельные алгоритмы обработки самостоятельно, без обращения к центральному узлу — серверу. Но в случае необходимости с помощью веб-интерфейса можно будет осуществить полный цикл обработки с помощью главного узла системы. Сервер также предоставляет возможности пополнения банка экспериментальной информации и обновления клиентского программного обеспечения. Основная часть информационной системы уже работает, и во время эксплуатации выяснились особенности хранения и передачи данных, которые невозможно было решить традиционными способами. Поэтому нами предпринята попытка разработать новый подход хранения и организации данных, который базируется на применении идеи Хранилища данных.

Определение хранилища данных

Хранилище данных — это «предметно-ориентированная, интегрированная, содержащая исторические данные, неразрушимая совокупность данных, предназначенная для поддержки принятия управленческих решений» [6, 7].

Данные из различных источников помещаются в хранилище, а их описания — в базу метаданных. Пользователь с помощью различных инструментов может анализировать данные в хранилище. Результатом является информация в виде готовых отчетов, закономерностей, таблиц, графиков. Способы и средства работы пользователя с хранилищем данных могут быть самыми разнообразными, и теоретически их выбор не должен влиять

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008

на структуру хранилища и функции его поддержания в актуальном состоянии. Физическая реализация данной схемы может быть самой разнообразной.

Первый вариант. Виртуальное хранилище данных — это система, предоставляющая доступ к обычной регистрирующей системе, которая эмулирует работу с хранилищем данных. Виртуальное хранилище можно организовать двумя способами. Можно создать ряд «представлений» в базе данных или использовать специальные средства доступа к базе данных. Далее — преимущества и недостатки виртуальных хранилищ.

Преимущества: простота и малая стоимость реализации, единая платформа с источником информации, отсутствие сетевых соединений между источником информации и хранилищем данных. Недостатки: работа всего лишь с иллюзией хранилища данных, проблемы с производительностью, трансформацией данных, интеграция данных с другими источниками, отсутствие истории, чистота данных, зависимость от доступности и структуры основной базы данных.

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

Преимущества: витрины данных строятся значительно быстрее, чем хранилище. Недостатки: впоследствии могут возникнуть серьезные проблемы с интеграцией, если первоначальное планирование проводилось без учета полной модели системы.

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

Преимущества: простота и малая стоимость реализации, высокая производительность за счет физического разделения регистрирующих и аналитических систем, выделение загрузки и трансформации данных в отдельный процесс, оптимизированная под анализ структура хранения данных, поддержка истории, возможность добавления метаданных.

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

Под подготовкой данных понимают их преобразование и проведение определенных проверок. Наличие оперативного склада данных просто необходимо при различном регламенте поступления информации из источников. Третий уровень представляет собой набор предметно-ориентированных витрин данных, источником информации для которых является центральное хранилище данных. Именно с витринами данных и работает большинство пользователей [8, 9].

Исследования по упорядочиванию, хранению и организации доступа к данным по сети Интернет в атмосферных науках ведутся в рамках многих международных и национальных программ. Над этим работают крупные мировые организации. Например, в NASA (National Aeronautics and Space Administration) [10, 11] создан распределенный архив данных (DAAC), содержащий терабайты данных по множеству космических проектов данной программы и размещаемый в восьми центрах данных с разбивкой данных по предметным областям исследований. Разработки в этой сфере наук направлены на предоставление доступа ко всем наборам данных, полученных этими организациями. Существует потребность в ресурсе, где бы хранились данные лидарного зондирования, и был предоставлен инструментарий для их обработки и анализа.

Нами, в рамках распределенной информационной системы [3, 11, 12], было разработано специализированное хранилище данных. Хранилище данных состоит из двух частей физических частей. Это база данных для контроля привилегий доступа к данным, их структуризации и быстрого доступа, и файловое хранилище, которое хранит непосредственно сами данные и их метаописания. Информация обо всех данных, находящихся в хранилище, содержится в базе данных, что позволяет однозначно определить наличие конкретных данных и получить прямой указатель на их физическое местоположение.

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008

Хранилище данных лидарного зондирования

Логически хранилище данных состоит из двух хранилищ (рис. 1): данные ЛЗА и результаты и методы обработки. Такая организация позволяет пополнять систему как новыми данными и результатами, так и новыми методами обработки.

Рис. 1. Схема хранилища данных

На рис. 2 показана схема работы системы [3].

Рис. 2. Схема работы системы

Пользователь обращается к системе и запускает задачу обработки на выполнение. Данные помещаются в хранилище данных и могут быть извлечены оттуда в любой момент времени. Управляющий сервер формирует очередь заданий, исходя из задачи и имеющихся данных, и отдает задания на выполнение вычислительным узлам. Вычислительный узел, в свою очередь, извлекает необходимые для выполнения задания данные из хранилища данных, а вычислительные методы — из хранилища методов. После проведения вычислений полученный результат помещается в хранилище данных. Итоговый результат выполнения задачи отображается в интерфейсе пользователя в виде графиков или таблиц.

Рис. 3. Логическое представление метода обработки

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

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008

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

После завершения обработки данных результаты работы будут помещены в хранилище данных с определенным идентификатором. Четкое описание входных и выходных данных позволяет не пересчитывать уже посчитанные результаты более одного раза. Также это позволяет реализовать систему поддержки принятия решений (СППР). Система всегда знает, какие данные, какому модулю можно подать на вход, чтобы получить требуемый результат, либо, имея данные определенного типа, какой результат мы можем получить.

Данные ЛЗА могут представлять собой файлы форматов NetCDF, HDF или текстовый файл, в котором записан сигнал, в виде таблицы [12, 13]. Эти данные могут иметь мета-описание со следующими характеристиками:

- высотный диапазон Н1 — Н2 и шаг по высоте,

- количество точек,

- длины волн L1 — LN,

- атмосферная ситуация,

- минута, час, день, месяц, год,

- формат записи,

- параметры лазера,

- параметры приемного телескопа,

- параметры лидара.

Хранимый метод представляет собой исполняемый файл и метаописание, которое определяет:

- строку запуска метода на выполнение для определенной операционной системы,

- список входных файлов и их типов (текстовый файл, NetCDF, HDF),

- перечень параметров метода, с которыми он будет запущен,

- список выходных файлов и их типов.

Такое метаописание позволяет определить, может ли быть получен нужный результат и существуют ли необходимые данные для обработки. Вычислительный сервер получает задания, сформированные на основе метаописания метода, с указанными входными файлами, параметрами и выходными файлами. В задаче лидарного зондирования методы могут быть следующие:

- метод сглаживания,

- метод дифференцирования,

- метод восстановления отношения рассеяния,

- метод восстановления профиля температуры,

- метод восстановления профиля газа.

Решение задачи лидарного зондирования может состоять из следующих этапов:

- анализ сигнала (поиск пропуска, нулей и др.),

- сглаживание сигнала,

- вычисление оптической толщи,

- анализ оптической толщи (выбор высотного диапазона, мертвой зоны),

- дифференцирование,

- анализ на флуктуации исследуемых параметров,

- визуализация данных,

- вычисление косвенных параметров.

Рассмотрим на примере сглаживания сигнала (рис. 4) связи между методами и данными. Пользователь через интерфейс определяет входные данные и параметры для выбранного метода. Сформированное на основе метаописания метода задание передается вычислительному серверу. Вычислительный сервер на основе задания получает из хранилища методов указанный метод, а из хранилища данных — указанные входные данные. Входные параметры для запуска метода, указанные пользователем, определены в задании для вычислительного сервера. После того как все необходимые данные для запуска метода присутствуют, запускается непосредственно сам метод. Полученные в результате его работы выходные данные получают метаописание, на основе которого они помещаются в хранилище данных. Заметим, что подобный подход доступа к данным и методам позволяет организовать потоковые вычисления, когда на входе может быть много сигналов и формат обработки каждого из них унифицирован.

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008

Каждый метод завязан на определенные типы входных данных, которые должны содержаться в хранилище данных. Выходные данные также завязаны на типы данных хранилища. Результат обработки всегда помещается в хранилище данных.

Работая с системой, пользователь, по сути, работает с интерфейсом к хранилищу данных (рис. 5) и вычислительному серверу. Для получения результатов обработки он добавляет свои данных в персональную область хранилища данных. Система снабжает его данные метаописанием на основе данных пользователя. После этого данные пользователя могут быть использованы в расчетах. Затем он выбирает один из алгоритмов обработки данных, руководствуясь тем, какой результат ему нужно получить. Далее система запускает процесс обработки, формирует задания и отдает управление вычислительным узлам. Каждый вычислительный узел обращается к хранилищу данных за входными данными и методом обработки. После окончания работы метода вычислительный узел помещает результат в хранилище данных. После того как расчет будет закончен, пользователь сможет запросить данные через интерфейс системы. Хранилище данных по указанному идентификатору результата вернет данные.

Хранилище данных

Рис. 4. Схема связи между методом и данными

Рис. 5. Интерфейс хранилища данных

Заключение

Данная архитектура хранилища данных позволяет формировать различные задачи на основе хранилища методов. Хранимые методы имеют строгое описание типов входных и

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008

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

Литература

1. Назаров И.Н. Основы дистанционных методов мониторинга загрязнения природной среды / И.Н. Назаров, А.Н. Николаев, Ш.Д. Фридман. — Л.: Гидрометеоиздат, 1983. - 277 с.

2. Межерис Р. Лазерное дистанционное зондирование. — М.: Мир, 1987. — 550 с.

3. Бойченко И.В. Программа распределенной обработки лидарных данных атмосферного зондирования / И.В. Бойченко, М.Ю. Катаев, А.И. Петров // Изв. ТПУ. — 2006. Т. 309, №8. C. 81—84

4. Информационная система для обработки, анализа и хранения стратосферных оптических измерений / И.В. Бойченко, В.В. Зуев, М.Ю. Катаев и др. // Оптика атмосферы и океана. — 1999. — Т. 12. — №5. — C. 134—141

5. Бойченко И.В. Информационная система для анализа данных лидарного зондирования озона / И.В. Бойченко, М.Ю. Катаев, В.Н. Маричев // Гидрология и метеорология. — 2001. — №12. — C. 96—105.

6. Сбор и хранение данных [Электронный ресурс]. — Режим доступа: http://www.spc-consulting.ru/solution/database.htm, свободный.

7. Хранилище данных [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/Datawarehouse, свободный.

8. Аналитическая обработка в реальном времени [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/OLAP, свободный.

9. Концепция Витрин данных [Электронный ресурс]. — Режим доступа: http://ru.wikipedia.org/wiki/Витрина_данных, свободный.

10. Review of NASA's Distributed Active Archive Centers. — Washington, D.C.: National Academy Press, 1999. — 544 p.

11. Supporting Research and Data Analysis in NASA's Science Programs. Engines for Innovation and Synthesis. — Washington, D.C.: National Academy Press, 1998. — 254 p.

12. Kataev M.Yu. The distributed information system of lidar data processing of ozone, aerosol and temperature sounding / M.Yu. Kataev, I.V. Boichenko, V.N. Marichev, A.I. Pet-rov // Atmospheric and ocean optics. Atmospheric physics: XIII joint int. symp. — Tomsk, 2006. — P. 42.

13. Boichenko I.V. The distributed information system for solving lidar sounding tasks. / I.V. Boichenko, M.Yu. Kataev, A.I. Petrov // ENVIROMIS. — Tomsk, 2006. — P. 25.

Катаев Михаил Юрьевич

Д-р. техн. наук, проф. каф. АСУ ТУСУРа

kmy@asu.tusu!. га (kataev@mail. tomsknet.ru) Тел.: +7 (382-2) 41-31-91

Петров Андрей Игоревич Аспирант каф. АСУ ТУСУРА

M.Yu. Kataev, A.I. Petrov

Warehouse of lidar sounding data in distributed information system

Description of warehouse of lidar sounding data of atmosphere parameters intended for distributed information system is given. Different variants of the warehouse construction are considered. It is shown the warehouse should be matched with the processing methods for the given subject domain. The user graphical interface of the information system client, which is obviously connected with the warehouse, is presented.

Key words: lidar, atmospheric parameters, distributed systems, data warehouse.

Доклады ТУСУРа, № 2 (18), часть 2, декабрь 2008