Архитектурные подходы к консолидации. Часть I - Классификация существующих подходов

В статье подробно рассматриваются основные подходы к консолидации
аналитических структур. Теоретические рассуждения иллюстрируются
многочисленными практическими примерами.

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

Краткая классификация методов консолидации аналитических данных

В ходе опроса, проведенного аналитиками международной организации TDWI (The Data Warehousing Institute - Институт Хранилищ данных), было выявлено восемь основных подходов к консолидации данных. Данные подходы можно разделить на категории: перенос структур (rehosting) и интеграция. Перенос подразумевает перемещение существующих аналитических структур на новую платформу без их объединения или изменения. Интеграция, с другой стороны, включает объединение метаданных и моделей данных в новой аналитической структуре.

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

Перенос структур

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

В ряде случаев причиной переноса является желание заменить "фирменную" технологию или снятие поставщиком продукта с поддержки, что, например, происходило со многими клиентами Red Brick и Informix. Для других компаний перенос - первый шаг в проведении проекта по консолидации. Например, Банк Америки (Bank of America), подобно многим финансовым институтам появился в результате многочисленных слияний и поглощений, происходивших в 80-е и 90-е годы. После объединения в 1998г. с Национальным банком (NationsBank) руководство обновленного Банка Америки решило сосредоточить усилия на развитии банка и сохранении существующих клиентов. Частью корпоративной стратегии стала задача интеграции двух существующих Хранилищ данных.

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

Централизованные подходы

Как известно, часто проще построить что-то новое, чем реставрировать старое - это подтвердит любой строитель. Это наблюдение справедливо и в отношении Хранилищ данных. Часто компании, которым приходится согласовывать разрозненные аналитические среды, приходят к выводу, что наиболее простой и экономически оправданный способ - это начать проект по консолидации "с нуля" (start from scratch).

Часто при разработке новой среды архитекторы опираются на существующие системы. "Мы хотели создать настоящее корпоративное Хранилище данных, которое было бы более обширным и современным по сравнению с существующими, - рассказывает представитель Банка Америки. - Мы позаимствовали некоторые из идей, которые были реализованы в существующих Хранилищах данных, однако, чтобы построить новую логическую модель, нам потребовалось около года, чтобы опросить более 60 бизнес-пользователей".

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

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

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

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

Определение корпоративного стандарта и последующий переход к нему (designate and evolve) - определение существующих Хранилищ или витрины данных в качестве корпоративного стандарта и немедленный или постепенный перевод других структур к этому стандарту.

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

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

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

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

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

"Нам была нужна архитектура, которая обеспечила бы согласованность данных и позволила бы бизнес-подразделениям контролировать свои данные и сервера, - поясняет Джордж Мортис (George Mortis), менеджер отдела по управлению ресурсами данных. - Сейчас, когда мы создали общие данные, группы пользователей могут скачивать их в свои витрины данных".

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

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

Такой тип операционного склада данных принято называть "интеграционным концентратором данных" (data integration hub). Концентратор данных обычно состоит из следующих компонент:

• Согласующий процессор (Matching engine). Согласующий процессор использует правила или нечеткую логику для идентификации и согласования дублирующихся записей. Процессор также присваивает дублирующимся записям уникальный ключ.
• Таблицы преобразования (Translation Tables). Таблицы преобразования трансформируют с помощью уникальных ключей дублирующиеся записи из различных исходных систем. Благодаря этому происходит оптимизация процесса преобразования и получается чистое, консолидированное представление объектов среди систем.
• Стандартизующий процессор (Standardization engine). Стандартизующий процессор преобразует данные из различных исходных систем к стандартному формату для каждого поля в справочном множестве (например, "Ул." становится "Улица", "Шос." - "Шоссе"). Часто концентратор хранит небольшое множество данных объекта (например, имя, адрес, ключ) в стандартном формате. Это позволяет создать базовый справочный набор, к которому могут обращаться приложения или пользователи, либо которой можно скачивать.
• Программное обеспечение, реализующие правила (Rules Software). Концентратор позволяет проектировщикам создавать правила о том, как преобразовывать и редактировать дублирующиеся данные. Например, правила наследования указывают, какой источник имеет более высокий приоритет при заполнении или корректировке полей в справочных данных
• Программное обеспечение для управления основными данными (Master Data Management software). Концентратор обычно позволяет авторизованным пользователям корректировать и поддерживать справочные данные, просматривать и модифицировать отвергаемые записи и т.п.
• Процессор для извлечения, перемещения и преобразования данных (Data extraction, movement, and transformation engine). Этот процессор перемещает данные между исходными системами и концентраторами в пакетном режиме или в реальном времени в зависимости от требований, предъявляемых исходной системой. При необходимости, процессор может преобразовывать данные в формат, запрашиваемый концентратором или исходной системой.

Например, одна компания, специализирующаяся в области высоких технологий, создала интеграционный концентратор, который содержит 1,8 ТБ данных, собираемых из 60 различных систем. Этот концентратор использует процессор преобразования для выявления дублирующихся данных в исходных системах и присваивает каждому из них уникальные ключи. Затем он стандартизирует некоторые поля, которые хранит (например, название организации и адрес) во всех исходных системах, а также уникальные поля из каждой системы. Авторизованные пользователи этой компании могут скачивать эти данные из концентратора и использовать их в маркетинговых кампаниях и других мероприятиях.

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

"Наш концентратор позволяет синхронизировать данные, которые необходимы для основных подразделений, работающих с клиентами - продажи, обслуживание, CRM, - объясняет менеджер отдела информационных технологий Кевин Мэки (Kevin Mackey). - По нашей оценке, в будущем еще больше групп пользователей станут активными подписчиками концентратора, и мы ожидаем, что наша система будет функционировать в реальном времени, используя Web-сервисы".

Распределенные подходы

Еще один способ консолидировать витрины данных, не прибегая к их физическому объединению, это внесение измерений в структуру каждой витрины, чтобы они были согласованы друг с другом. Данный подход опирается на методологию Ральфа Кимболла (Ralph Kimball), в соответствии с которой компании создают одну временную промежуточную область, данные из которой используются для заполнения согласованных витрин данных. Благодаря введению этой новой промежуточной области консолидируются избыточные передаваемые данные, т.е. сокращаются расходы.

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

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

В качестве примера можно привести Транспортное управление округа Ориндж, штат Калифорния, США (Orange County Transportation Authority), которое взяло на вооружение данный подход и консолидировало четыре независимые витрины данных, которые функционировала на базах данных Informix. Методика Ральфа Кимболла привлекла внимание сотрудников Транспортного управления по целому ряду причин.

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

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

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

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

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

Подобно подходу "витрина из витрин данных" при применении этого метода существующие неинтегрированные аналитические структуры остаются на месте. Однако, вместо инструментов ETL и пакетной обработки, используемых для создания консолидированного представления, в данном случае такое представление строится "на лету" с помощью SQL.

Средства для построения распределенных запросов существуют уже несколько десятков лет. В 90-х их поборники предлагали использовать эти инструменты для создания "виртуальных Хранилищ данных". Сегодня эти инструменты называются средствами интеграции корпоративной информации. Каково бы ни было их название, эти инструменты обеспечивают представление общих метаданных - распределенных источников данных, включая реляционные, традиционные и даже Web, XML и текстовые данные. Данные средства избавляют пользователей от сложностей, связанных с обращением к распределенным, гетерогенным системам - они генерируют сложный SQL-запрос, необходимый для объединения разрозненных данных, и оптимизируют производительность запроса. Кроме того, они производят простые преобразования, необходимые для трансформации данных в общий формат.

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

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

Так, для генерации распределенных запросов Global Services, подразделение корпорации IBM, использует инструмент от фирмы Meta5. Этот инструмент собирает данные из более 30 витрин данных и систем отчетности, установленных в Global Services, и передает их в инструментальные панели, предназначенные для руководства компании. На первой стадии в панели передаются показатели, а затем, если пользователи запрашивают дополнительные данные, "на лету" к соответствующим витринам формируются запросы, результаты выполнения которых объединяются и выдаются на экран. Пользователи могут воспользоваться имеющимися средствами Business Intelligence для обращения к панелям.

"Это была самая быстрая из всех альтернатив, - рассказывает Дуглас Джоунз (Douglas Jones), менеджер программы IT Business Solutions подразделения Global Services. - Дело в том, что наш отдел занимается быстрой разработкой приложений. Нам не требуется перемещать много данных - нас устраивает то, где они находится. Хотя иногда мы дублируем данные, когда это требует производительность".

Рекомендуемая литература

1. "Проблема консолидации аналитических данных - результаты исследование TDWI".
2. "Стратегии консолидации разрозненных аналитических данных и приложений. основные понятия, постановка проблемы".
3. "Консолидация аналитических данных: текущее состояние проектов по консолидации, основные сложности, виды интегрируемых структур".
4. "Экономическая эффективность проектов по консолидации разрозненных аналитических структур".
5. "Интеграция корпоративной информации: новое направление".

Автор: По материалам зарубежных сайтов (<a href="http://www.tdwi.org/research/display.aspx?ID=7173">доклад TDWI</a>)