Консалтинг и автоматизация в области управления
эффективностью банковского бизнеса

Журнал ВРМ World

Выбор архитектуры Хранилища данных

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

Однако остается один вопрос, на который многие до сих пор затрудняются ответить. Какую архитектуру стоит использовать?

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

Пять архитектур

На сегодняшний день предложено множество архитектур, опишем пять наиболее распространенных:

  1. независимые витрины(independent data marts);
  2. шина взаимосвязанных витрин (data-mart bus architecture with linked dimensional data marts);
  3. архитектура «звезда» (hub-and-spoke);
  4. централизованное Хранилище (centralized data warehouse);
  5. федеративная архитектура (federated architecture).

Независимые витрины (independent data marts)

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

Шина взаимосвязанных витрин данных

Предложена Ральфом Кимбэлом (Ralph Kimball).

Создание такой архитектуры начинается с анализа требований для конкретных бизнес-процессов, таких как заказы, клиенты, счета и проч. Первая витрина (data mart –DM) строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах.
Последующие DM разрабатываются с использованием этих измерений, что в результате приводит к созданию логически интегрированных витрин.

Архитектура «Звезда»

Продвигается известным экспертом в области Хранилищ Билом Инмоном (Bill Inmon). Представляет собой централизованное Хранилище с зависимыми витринами данных.

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

Зависимые витрины разрабатываются для подразделений или конкретных функциональных областей, целей (например, для data mining) и могут быть как нормализованными, так и денормализованными, либо в виде любой агрегированной структуре данных. Большинство пользователей выполняет запросы на зависимых витринах данных.

Иногда архитектуру hub-and-spoke называют подходом «сверху вниз», а шину витрин - подходом «снизу вверх». В этом есть некоторый смысл, так как первая ориентирована на исходно заданную инфраструктуру и процессы, а шина витрин – на разработку проекта, который решает критические бизнес-задачи.

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

Централизованное Хранилище (Без зависимых витрин)

Эта архитектура похожа на архитектуру «звезда», исключая отсутствие зависимых витрин. Хранилище содержит детальные данные, некоторое количество агрегированных данных и логические представления. Запросы и приложения выполняются как на реляционных данных, так и на многомерных представлениях.

Федеративная архитектура

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

Факторы, влияющие на выбор архитектуры

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

Согласно исследованиям компании TDWI, существует 10 основных факторов, влияющих на выбор архитектуры.

Рациональные факторы

Информационная зависимость между организационными подразделениями

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

Информационные потребности руководства

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

Срочность внедрения Хранилища

Иногда компании необходимо реализовать возможности Хранилища в очень краткие сроки. Некоторые виды архитектур внедряются быстрее.

Характер пользовательских задач

Ряд пользователей выполняет сложные и нестандартные задачи. Структурированных запросов и отчетов не достаточно для реализации их потребностей. Им необходимо анализировать данные новыми способами, а, следовательно, иметь в распоряжении такую архитектуру, которая позволит анализировать данные «налету», нетривиальными методами.

Ограниченные ресурсы

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

Стратегическое представление Хранилища до внедрения

Разные компании имеют разные планы на Хранилище. Иногда необходимо «точечное решение» для конкретного подразделения, а иногда – инфраструктура поддержки принятия решений, содержащая множество приложений. В зависимости от стратегического назначения Хранилища меняется и архитектура.

Совместимость с существующими системами

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

Возможности персонала

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

Технические факторы

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

Социальные факторы

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

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

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

Руководствуясь принципами выбора, предложенными TDWI, можно избежать множества ошибок.

Кроме того, целесообразно учитывать еще целый ряд компетентных соображений. Приведем советы одного из практических специалистов в области внедрения BI – Брайана Шварбрика (Brian Swarbrick).

Выбирая лучшую архитектуру BI-решения, важно рассмотреть следующие вопросы:

  1. Продуман ли и задан ли масштаб проекта? Строится ли решение для поддержки требований отдела или в качестве фундамента корпоративного проекта, который необходимо постепенно расширять для поддержки будущих требований и других подразделений? Если задача ограничивается одним отделом, то архитектура может быть проще. Однако если предполагается долгосрочное решение, то необходимо тщательно продумать подход. Выбор должен учитывать как архитектурные аспекты, так и согласованность с организационными и IT-стратегиями и будущими планами.
  2. Сложность. Корпоративные решения обычно предполагают использование нескольких слоев баз данных, которые отделяют слой интеграции от аналитического слоя. Эти слои часто называют Хранилищами данных или областями подготовки, они могут быть как постоянными, так и временными. Однако важнее всего подход к внедрению.
  3. Важно ли отделить компоненты интеграции данных от аналитических компонентов и почему? (Речь идет о корпоративных решениях как для краткосрочных, так и для долгосрочных задач).
    Исходные данные могут поступать как изнутри организации, так и извне. Данные могут уже существовать или появиться завтра, или поступить в отдаленном будущем. Правила интеграции данных могут быть сложными. Кроме того, необходимо учитывать требования к отчетности.
    В частности одним из путей является разделение и моделирование слоев данных и слоев отчетности. В результате обеспечивается гибкость и учет постоянно добавляемых и изменяемых бизнес-требований.
  4. Организационный интерес к качеству данных. Если качество данных не играет принципиальной роли, а отчетные требования исходят от подразделений (а не от компании в целом), то лучше всего выбрать самое простое отчетное ПО. Если же задача повышения качества данных стоит остро, то лучше выбрать решение, описанное в пункте 3. Разработка архитектурного слоя, ориентированного на сбор и интеграцию данных, подразумевает дальнейшее расширение и внедрение поддержки качества. Такая архитектура позволяет повышать качество данных, а также отчетности и аналитических операций.
  5. Гибкость для будущего роста. Часто сбор и интеграция данных, а также витрины данных, строятся на одной базе. Подготовительные слои обычно временные и используются для поддержки текущих требований к отчетности (заданных еще до начала проекта). По мере изменения требований и поступления новых, витрины данных расширяются. Но часто такие проекты не удается расширить до корпоративных масштабов без существенной переработки. Если в соответствии с новыми требованиями необходимы данные, не доступные в витрине или доступные в ином формате, то витрина теряет смысл. Витрины хороши для поддержки известных бизнес-требований, но при этом не достаточно гибки при их изменении.
  6. Бюджет. Корпоративные проекты бывают дорогими. Обычно они содержат множество компонентов, и не всегда есть время на разработку «одноразовых» витрин для подразделений. Время на поддержку и разработку увеличивается. Однако если грамотно продумать архитектуру, то проект можно выполнить довольно быстро. Предпочтителен итеративный подход, основанный на структурированной архитектуре и методологии, что позволяет быстро создавать корпоративную инфраструктуру и обеспечивать пользу для бизнеса на каждом из этапов процесса.
    Лучше всего разрабатывать проекты с помощью готовых ETL-продуктов и отчетных средств. ETL-средство не должно зависеть от платформы и базы, но при этом должно работать в распределенной среде. Отчетные инструменты обязаны обеспечивать множество функций, в том числе пакетную, нерегламентируемую и оперативную обработку. Стоимость этих инструментов зависит от обеспечиваемой функциональности.
  7. Проект бывает успешным лишь тогда, когда в нем используются необходимые ресурсы и навыки. Организация должна обеспечить материальные возможности и кадры. Для локальных (внутри отдела) проектов усилий потребуется меньше.

Успех архитектур

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

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

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

Архитектура «звезда» чаще всего используется в корпоративных проектах для создания крупных Хранилищ. Это самые долгосрочные и дорогие проекты, однако и самые результативные. Ничего удивительного тут нет. Функциональный охват таких проектов шире и размер Хранилища больше. Эта архитектура требует большей вовлеченности руководства и планирования, а следовательно, материальных и временных ресурсов.

Шина витрин часто выбирается в той ситуации, когда ресурсов вполне достаточно, представление о Хранилище не носит четкой стратегической ориентации, и совместимость с уже внедренными средствами не играет принципиальной роли.

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

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

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

Публикации:

  1. BI Архитектура: Каков лучший выбор для организации? (BI Architecture: What is the Best Choice for My Organization?), Брайан Шварбрик (Brian Swarbrick), январь 2008, http://www.dmreview.com/specialreports/2007_54/10000521-1.html;
  2. Ключевые факторы в выборы Архитектуры Хранилища (Key Factors in Selecting a Data Warehouse Architecture) Тилини Ариячандра (Thilini Ariyachandra), Хуг Уотсон (Hugh J. Watson), 2005, http://findarticles.com/p/articles/mi_qa5525/is_200504/ai_n21371849;
  3. Какая архитектура Хранилища наиболее успешна? (Which Data Warehouse Architecture Is Most Successful?) Тилини Ариячандра (Thilini Ariyachandra), Хуг Уотсон (Hugh J. Watson), 2006, http://www.tdwi.org/Publications/BIJournal/display.aspx?ID=7890.