Архитектуры управления данными

На рис. 1 показана классификация существующих решений управления данными по двум измерениям. Измерение "Administrative Proximity" ("административная близость") показывает, насколько близки различные источники данных с точки зрения административного управления. "Near" ("близко") означает, что источники находятся под единым или, по крайней мере, координированным управлением, а "Far" (далеко) показывает более слабую координацию и даже, может быть, полное отсутствие координации. Чем ближе административное управление группы источников данных, тем сильнее гарантии (например, согласованность, стабильность), которые могут быть предоставлены системой управления данными.

Измерение "Semantic Integration" ("семантическая интеграция") является мерой того, насколько близко могут быть сопоставлены схемы различных источников данных. Другими словами, насколько хорошо соответствуют типы, имена, единицы измерения, смысл и т.д. данных в источниках. На дальнем конце ("low") информация о схемах вообще отсутствует. В промежутке между "high" и "low" размещаются различные решения и подходы интеграции данных, основанные на полуструктурированных данных и контролируемых словарях. Это измерение показывает уровень, на котором могут быть обеспечены семантически развитые средства запрашивания данных и манипулирования данными над группой источников данных, причем более высокий уровень интеграции обеспечивает более развитые функциональные возможности.

Как показывает рисунок, традиционные СУБД представляют только одну точку (хотя и очень важную) в пространстве решений управления данными. СУБД требуют, чтобы все данные находились под единым административным управлением и соответствовали единой схеме. В ответ на удовлетворение этих ограничений СУБД могут обеспечить развитые средства манипулирования данными и обработки запросов с понятной и строгой семантикой, а также строгие транзакционные гарантии обновлений, параллельного доступа и долговременного хранения (так называемые свойства "ACID"). Важной точкой на рис. 1 являются "системы интеграции данных". На самом деле, системы интеграции данных и обмена данными традиционно предназначаются для поддержки многих других осмысленных служб в системах пространств данных. Особенность состоит в том, что в системах интеграции данных требуется семантическая интеграция до того, как могут быть обеспечены какие-либо прочие услуги. Поэтому, хотя и отсутствует единая схема, которой соответствуют все данные, система должна знать точные взаимосвязи между элементами, используемыми в каждой схеме. В результате для создания системы интеграции данных требуется существенная предварительная работа.

Пространства данных не являются подходом к интеграции данных; скорее, это подход сосуществования данных. Цель поддержки пространства данных состоит в обеспечении базового набора функций надо всеми источниками данных, а не в их интеграции. Например, DSSP может обеспечить надо всеми своими источниками данных поиск по ключевым словам, аналогично тому, что обеспечивают существующие поисковые системы в десктопах. При потребности в более сложных операциях, таких как запросы в реляционном стиле, анализ данных (data mining) или мониторинг каких-либо источников, можно приложить дополнительные усилия к более тесной интеграции этих источников в инкрементной манере "оплаты текущих счетов" ("pay-as-you-go").

Аналогичная гибкость имеется и в измерении административной близости рис. 1. Если желательно наличие административной автономии, то DSSP не сможет гарантировать согласованность, устойчивость результатов операций обновления и т.д. Для удовлетворения потребности в более строгих гарантиях нужны дополнительные усилия для достижения соглашений между владельцами источников данных и открытия некоторых интерфейсов (например, для протоколов фиксации транзакций).

Подводя итог, отличительными свойствами систем пространств данных является следующее:

• DSSP должны работать с данными и приложениями в разнообразных форматах, доступных от многих систем через различные интерфейсы. От DSSP требуется поддержка всех данных пространства данных, без каких-либо исключений (как это бывает при использовании СУБД).
• Хотя DSSP обеспечивает средства интегрированного поиска, запрашивания, обновления и администрирования пространств данных, те же самые данные часто могут быть доступны для чтения и обновления через собственный интерфейс системы, непосредственно управляющей данными. Поэтому, в отличие от СУБД, DSSP не имеет полного контроля над своими данными.
• Могут обеспечиваться разные уровни услуг по обработке запросов к DSSP, и в некоторых случаях они могут возвращать наилучшие из возможных приблизительные ответы. Например, если некоторые источники данных становятся недоступными, DSSP может обеспечить наилучший из возможных результат на основе данных, доступных во время выполнения запроса.
• DSSP должны поддерживать средства для обеспечения более тесной интеграции данных пространства, если это становится необходимо.

План работ в области пространств данных

По всем меркам, исследовательское сообщество управления данными остается активным, энергичным и растущим. Однако возникает ощущение, что в настоящее время у сообщества отсутствует основная идея - эквивалент "реляционной СУБД" для нового мира разнородных децентрализованных данных. Кроме того, у многих исследователей возникает все более сильное ощущение, что термин "исследование баз данных" является ограничительным для широты тематики, затрагиваемой сообществом. Хотя, возможно, наша область просто стала слишком большой, чтобы можно было согласовать единую, сжатую концепцию, целью этой статьи является выработка предложения, которое могло бы помочь при дальнейших обсуждениях соответствующих проблем.

В сообществе баз данных давно происходит процесс самооценки, в ходе которого известные исследователи периодически встречаются для анализа состояния дел в данной области и определения обещающих исследовательских направлений в будущем (последними из опубликованных результатов таких собраний являются Asilomar Report и Lowell Self-Assessment). Эта статья основывается на многих целях и проблемах, определенных в этих отчетах. На самом деле, в большей части исследований в сообществе управления данными уже прямо поддерживаются требования пространств данных и DSSP, включая такие направления, как сопоставление схем, интеграция данных и управление моделями, единообразный поиск над несколькими типами данных; комбинирование структурированных, полуструктурированных и неструктурированных данных, приближенная обработка запросов; запросы к неточным данным и их происхождению; управление и обработка потоковых и сенсорных данных. Таким образом, можно считать, что пространства данных - это все лишь "зонтик" над этими разнообразными исследовательскими работами. Однако, как мы обсудим позже, мы также полагаем, что единое представление на основе пространств данных и DSSP может и само привести к новому набору исследовательских проблем.

Примеры

Мы начнем с описания двух сценариев пространств данных.

Управление персональной информацией: Цель управления персональной информацией (Personal Information Management, PIM) состоит в обеспечении простого доступа и манипулирования всей информацией на персональном компьютере с возможными расширениями к мобильным устройствам, персональной информации в Web и даже всей информации, накопленной в течение жизни человека.

Поисковые средства, доступные на десктопах в настоящее время, представляют важный первый шаг для PIM, но они ограничиваются запросам на основе ключевых слов. Наши десктопы обычно содержат некоторые структурированные данные (например, электронные таблицы), и между различными элементами десктопа имеются важные ассоциации. Поэтому на следующем шаге развития PIM пользователю должно быть позволено производить поиск в десктопе более осмысленным образом. Например, "найти список студентов, которые прослушали мой курс по базам данных в прошлой четверти" или "вычислить общий баланс моих банковских счетов". Нам также хотелось бы искать по ассоциациям, например, "найти сообщение электронной почты, которое Джон послал мне в тот день, когда я вернулся с Гавайев" или "выбрать все пробные файлы, имеющие отношение к моей статье на конференцию SIGMOD в этом году". Наконец, нам хотелось бы запрашивать данные об источниках, например, "найти все статьи, в которых я приношу благодарность на предоставление данного гранта" или "найти все электронные таблицы, включающие столбец дисперсии".

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

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

Такая группа легко накопит миллионы продуктов данных в течение всего лишь нескольких лет. Хотя может оказаться, что для каждого файла кто-то в группе знает, где он находится и что означает, ни один человек не сможет знать ни все хранилище целиком, ни то, что означает каждый файл. Людям, обращающимся к этим данным, в особенности, тем, которые не входят в состав данной группы, понадобится сводный реестр основных атрибутов файлов, таких как период времени, к которому относится данный файл, географический район, высота или глубина, физические параметры (уровень солености, температура, скорость ветра), вид продукта данных (график, диаграмма из изолиний, анимация), предсказание это или ретроспективный прогноз и т.д. Когда интересующие продукты данных обнаруживаются, наиболее важным становится понимание их происхождения, чтобы можно было анализировать и сравнивать продукты: Какая использовалась версия кода? Какая сетка конечных элементов? Каким был временной шаг симуляции? Какой атмосферический набор данных использовался на входе?

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

Этот сценарий иллюстрирует несколько требований пространства данных: (1) каталог пространства данных; (2) поддержку анализа происхождения данных и (3) создание коллекций и индексов сверх тех, которые поставляются любым участвующим в пространстве источником данных.

Пространства данных

Опишем теперь логические компоненты пространства данных и сервисы, ожидаемые нами от DSSP.