Интеграция данных — это моделирование их смысла

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

Энди Хейлер из компании Kalido - автор эссе, опубликованного на Web-сайте американской версии Intelligent Enterprise ("EII: Dead on Arrival" - в вольном переводе: "Мертворожденная интеграция корпоративных данных") утверждает, что концепция Enterprise Information Integration (EII) была незрелой и подавила развитие важных направлений хранилищ данных. Хейлер полагал, что заявления о преимуществах, обещанных EII-решениями, которые требуют "федеративного", а не централизованного подхода к хранилищам данных, исходили из ошибочных предпосылок и были недостаточно продуманы. В частности, Хейлер считает, что EII не решает проблему исторических данных, качества информации и скорости обработки запросов систем, не оптимизированных для поддержки принятия решений.

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

За прошедшие десять с небольшим лет каждый важный компонент хранилища данных оказывался в центре внимания. Вначале особое внимание уделялось базам данных и серверам баз данных, особенно их масштабируемости - способности обрабатывать большие количества пакетных обновлений и справляться с большой нагрузкой по обработке запросов. Затем все активно интересовались ETL-инструментами (extract, transform, and load). Чуть позже, но очень надолго, в центр внимания попали метаданные. Семь или восемь лет тому назад наблюдался огромный интерес к моделированию данных, но ему на смену пришла бизнес-аналитика, или BI (business intelligence).

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

Тектонические сдвиги

Рационализация данных всего предприятия - задача исключительно сложная, и сегодня она решается по частям. Однако ситуация меняется. Грядут коренные перемены. Во-первых, закон Мура никто не отменял, и на рынке появляются все более мощные аппаратные средства за вполне разумные деньги. Во-вторых, развитие Интернета сделало возможным постоянное подключение и доступ. В-третьих, электронная коммерция - немного потерявшая былой блеск, но все еще брызжущая жизнью - подпитывает развитие технологий бизнес-интеграции (Enterprise Application Integration, EAI), которые в основном обеспечивают интеграцию приложений предприятия.

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

Наконец, есть другие перспективные направления: Web-сервисы, сервисноориентированная архитектура и бурно развивающиеся стандарты совместного использования информации с использованием XML, проект Semantic Web, инфраструктура описания ресурсов RDF (Resource Description Framework), онтология, а также инициативы новых и уже существующих ведущих поставщиков корпоративных приложений в области использования стандартов. К таким инициативам следует отнести превращение наборов приложений в модульные компоненты, реализуемое за счет создания инфраструктуры интеграции, и создание инструментов и методологий для построения гибких бизнес-процессов, особенно за счет использования стандарта BPML (Business Process Modeling Language). Вывод прост: многие из существующих подходов к интеграции данных остро нуждаются в переосмыслении.

В поисках правды

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

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

В борьбе с проблемой некачественной информации компании пытаются реализовать принцип "одной версии правды" (Single Version of the Truth, SVOT). Интересно, что поборники хранилищ данных активно участвуют в SVOT-инициативах, стараясь оправдать затраты на свои довольно дорогие проекты. Безотносительно к достижению конечной цели многие теперь используют SVOT как оправдание использования хранилища данных - на мой взгляд, это немного непоследовательный вывод. Качественно спроектированное хранилище данных вполне способно поддержать единственную версию данных, однако "правда" менее уловима - для нее нужно намного больше, чем просто хранилище данных. Бизнес-правила, модели, метрики, представления и интерпретации - все это составляющие "правды", и они обычно находятся за рамками реляционной базы данных и ее ETL-процессов. Кроме того, в большинстве организаций есть не одно хранилище данных - факт, вынуждающий задать законный вопрос: так сколько же версий "правды" должно быть?

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

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

• перепроектирования логической модели;
• перепроектирования физической модели;
• изменения ETL-процедур;
• обновления всех затронутых представлений, запросов и процедур экспорта;
• учета невозможности дальнейшей работы с более не поддерживаемыми "низкоуровневыми" приложениями, такими как электронные таблицы и персональные базы данных;
• перезагрузки данных;
• обширного тестирования.

Короче говоря, "оперативное" обновление хранилища данных занимает месяцы, а не дни, часы или минуты. Такая вот задержка.

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

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

История EAI

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

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

Естественно, для интеграции нестандартных систем организации использовали комплекты "переходников". Это иллюстрирует недостаток EAI: для поддержки и интеграции решений все еще требовался довольно значительный объем программирования. К тому же EAI-решения не обеспечивали достаточной интеграции данных, так как функционировали на уровне бизнес-процессов и поддерживали прежде всего обработку транзакций. Для многих организаций недолговечность EAI-интеграции - оперативно, но ненадолго - также не подходила из-за значительных затрат усилий и денег. Уровень предусмотренной в EAI и соответствующих ERP-системах стандартизации семантики (обычно это называлось "каноническим представлением") не позволял представлять метаданные способом, удобным для других инструментальных средств.

Справедливости ради стоит заметить, что большинство поставщиков EAI-решений расширили предлагаемые системы и обогатили инструменты и знания для использования более широкой аудиторией. С другой стороны, поставщики интеграционных решений не стояли на месте и обогащали свои системы, сводя на нет различия между ETL, EAI и EII.

История EII

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

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

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

EII, конечно же, придется подтвердить свой потенциал делами. Разумно ли предположение, что, развернув EII-систему на нескольких базах данных и эффективно организовав сложные запросы, можно обойтись без хранилища данных? Ясно, что некоторые EII-решения слишком "легковесны" для решения этой сложной задачи. Вместе с тем другие решения демонстрируют надежные возможности по поддержке интеграции, но способом, в корне отличающимся от методик разработки моделей хранилища данных.

Фокус - на моделирование смысла

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

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

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

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

Важно правильно оценить сложность разработки единых метамоделей. Однако если это напоминает то, с чем столкнулась компания при разработке модели данных предприятия, советуем вам остановиться, так как вы на неверном пути. Язык для определения метамоделей должны понимать бизнес-пользователи. Кроме того, компания не должна создавать метамодели на пустом месте. Уже есть промышленные метамодели, пример - отраслевые страховые решения ACCORD и FinXML для рынка ценных бумаг. К другим примерам следует отнести языки IRML (Investment Research Markup Language), XFRML (Extensible Financial Reporting Markup Language), XBRL (Extensible Business Reporting Language) и VRXML (Vendor Reporting Extensible Markup Language).

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

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

Разве это не более близко к обычной схеме работы предприятия? Вместо того чтобы называть три различных определения термина "клиент" проблемой качества данных и пытаться свести все к "одной версии правды", разве не логичнее радоваться множеству значений? Ключ в том, чтобы делать все без путаницы и ошибок. Это основа Semantic Web - решения, которое ставит под сомнение все, что сейчас привыкли делать в области интеграции данных.

С чего начать?

Так с чего же начать? Сначала выберите четко определенные участки, на которых нужно добиться быстрого возврата инвестиций на каждый потраченный рубль. Это может быть удовлетворение требований регулирующих органов, деятельность по слиянию и поглощению компаний, стратегические интеграционные инициативы и приоритетные направления BI. Можно создать базовую информационную модель и потом последовательно развивать ее, хотя лучше начать с отраслевого стандарта, такого как ACCORD. Нюансов здесь масса, но, я надеюсь, вы поняли, что основа, на которой мы раньше создавали нашу архитектуру интеграции информации, становится шаткой. Предвещает ли это конец хранилищам данных? Нет. Но в некоторых отношениях хранилища данных уступят свои позиции, предоставляя определенные функции и вместе с тем потеряв контроль в других областях.