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

🕛 09.10.2008, 09:46

За последние 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).

Независимые витрины данных

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

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

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

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

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

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

Продвигается известным экспертом в области хранилищ данных Билом Инмоном (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; 2. Ключевые факторы в выборы Архитектуры Хранилища (Key Factors in Selecting a Data Warehouse Architecture) Тилини Ариячандра (Thilini Ariyachandra), Хуг Уотсон (Hugh J. Watson), 2005; 3. Какая архитектура Хранилища наиболее успешна? (Which Data Warehouse Architecture Is Most Successful?) Тилини Ариячандра (Thilini Ariyachandra), Хуг Уотсон (Hugh J. Watson), 2006.