Логические компоненты пространств данных

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

Рис. 2. Пример пространства данных и компоненты системы пространства данных

Участниками пространства данных являются индивидуальные источники данных: они могут быть реляционными базами данных, репозиториями XML, текстовыми базами данных, Web-сервисами и пакетами программного обеспечения. Они могут храниться или быть потоками данных (локально управляемыми системами потоков данных), или даже сенсорными установками.

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

Пространство данных должно уметь моделировать любой вид связи между двумя (или несколькими) участниками. В более традиционном варианте мы должны уметь моделировать ситуации, когда один участник является представлением или репликой другого участника, или отображать одна на другую схемы двух участников. Однако нам хотелось бы моделировать намного более широкий набор связей, например, что источник A был вручную произведен из источников B и C, или что источники E и F создавались независимо, но отражают одну и ту же физическую систему (например, ДНК мыши). Связи могут быть даже менее конкретными, например, два набора данных образованы из одного источника данных в одно и то же время.

Пространства данных могут вкладываться одно в другое (например, пространство данных факультета Computer Science вкладывается в пространство данных университета), и они могут перекрываться (например, пространство данных факультета Computer Science может разделять некоторых участников с факультетом Electrical Engineering). Поэтому в пространстве данных должны содержаться правила разграничения доступа. Вообще говоря, в некоторых случаях границы между пространствами данных могут быть плавающими, но мы ожидаем, что в большинстве случаев эти границы будут определяться естественным образом.

Сервисы пространства данных

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

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

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

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

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

Не каждый участник пространства данных будет обязательно обеспечивать интерфейсы, требуемые для поддержки всех функций DSSP. Поэтому появится потребность в различных расширениях источников данных. Источник не обязательно будет хранить свои собственные метаданные, поэтому для таких источников нам потребуется независимый репозиторий метаданных. Может потребоваться облечение информации во внешнюю форму на основе источника или его контекста. Например, для списка агенств скорой помощи из Вашингтона может потребоваться явная пометка "Вашингтон", чтобы его можно было объединить с аналогичными списками из Орегона и Калифорнии. Или для научного набора данных может потребоваться наложенная схема. Элементы данных в источнике могут обогащаться аннотациями, рейтингами, ссылками на элементы в других источниках. Для источников, в которых отсутствует собственная служба нотификации, может потребоваться поддержка соответствующего мониторинга.

Системы пространств данных

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

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

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

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

Поиск и запрашивание: Этот компонент должен обеспечивать следующие возможности:

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

(2) Стуктурированные запросы: Запросы в стиле баз данных должны поддерживаться на основе общих интерфейсов (т.е. схем-посредников), обеспечивающих доступ к нескольким источникам, или же они могут адресоваться к конкретному источнику данных (с использованием его собственной схемы) с намерением получения ответов и от других источников (как в системах управления одноранговыми данными — Peer-Data Management System). Запросы могут формулироваться на разнообразных языках (и на основе разных моделей данных), и они должны, по возможности, наилучшим образом переформулироваться на другие модели данных и схемы, обеспечивая точные и приближенные семантические отображения.

(3) Запросы к метаданным: В системе должен поддерживаться широкий спектр запросов к метаданным. Должны обеспечиваться возможности (a) получения данных об источнике ответа или о том, как этот ответ был выведен или вычислен; (b) обеспечения временных меток на элементах данных, которые участвовали в вычислении ответа; (c) указания того, какие другие элементы данных в пространстве данных могут зависеть от заданного элемента данных, и поддержки гипотетических запросов (т.е. Что бы изменилось, если бы я удалил элемент данных X?); (d) запрашивания источников и уровня недостоверности ответа.

DSSP должны также поддерживать запросы на установление местоположения данных, ответами на которые являются источники данных, а не конкретные элементы данных. Например, система должна быть в состоянии отвечать на запросы Где я могу найти данные про IBM? или В каких источниках имеется атрибут "salary"?. Аналогично, при наличии XML-документа должна иметься возможность запросить XML-документы с похожей структурой и соответствующие XML-преобразования. Наконец, при наличии фрагмента схемы или описания Web-сервиса должно быть возможно найти в пространстве данных похожие фрагменты.

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

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

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

Нам может захотеться кэшировать некоторые фрагменты пространства данных (вертикальные или горизонтальные), чтобы (1) строить на них дополнительные индексы для поддержки более эффективного доступа; (2) повысить уровень доступности данных, хранимых в ненадежных участниках и (3) уменьшить нагрузку запросами участников, которые не могут обрабатывать непредусмотренные внешние запросы.

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

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

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

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

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

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

Исследовательские проблемы

В этом разделе определяются некоторые новые проблемы, возникающие при построении DSSP.