Техническая библиотека CITForum.ru CITKIT.ru - все об Open Source Форумы Курилка
Все новости / Все статьи Деловая газета - шквал(!) IT-новостей :: CITCITY.RU
Первая полоса ИТ-Инфраструктура Телекоммуникации Безопасность BI Интеграционные платформы КИС IT-бизнес Ширпотреб Точка зрения

23.10.2017

Новости:


Все новости

Business Intelligence

Архитектурные подходы к консолидации

Часть II - Предпочтения пользователей и рекомендации по выбору оптимальной стратегии консолидации

Подготовлено по материалам зарубежных сайтов (доклад TDWI)
Перевод: Intersoft Lab

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

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

В ходе опроса, проведенного аналитиками международной организации 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. - Дело в том, что наш отдел занимается быстрой разработкой приложений. Нам не требуется перемещать много данных - нас устраивает то, где они находится. Хотя иногда мы дублируем данные, когда это требует производительность".

Часть II - Предпочтения пользователей и рекомендации по выбору оптимальной стратегии консолидации

Наиболее часто используемые методы консолидации: результаты опроса

Как показало исследование, проведенное аналитиками международной организации TDWI (The Data Warehousing Institute - Институт Хранилищ данных), у большинства компаний нет явных предпочтений в отношении того или иного метода консолидации. Так, некоторые организаций используют только одни подход на протяжении всего проекта по консолидации, другие - на разных стадиях проекта применяют различные методики. Наконец, ряд компаний в силу изменения бизнес-условий сталкивается с необходимостью отказываться от ранее выбранного метода и переходить к другому.

Если перейти на язык цифр, то станет очевидным, большинство фирм (55%) одновременно применяют и перенос структур, и интеграцию (см. рис.).

Предпочтительные методы консолидации
Предпочтительные методы консолидации

Стоит подчеркнуть, что только треть компаний сначала переносят структуры, а затем их интегрируют. Интересно, что весьма незначительная часть респондентов (4%) отдала предпочтение использованию только одного метода консолидации - переносу структур.

Основные подходы к консолидации: какой путь избрать?

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

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

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

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

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

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

Практические рекомендации по выбору метода консолидации аналитических структур

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

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

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

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


Intersoft Lab

Последние комментарии:

Самое интересное:


© 2004–2009 Проект CITCITY.ru