Сверху или снизу

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

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

При проектировании "снизу-вверх" начинают с проектирования хранилищ данных и витрин для отдельных подразделений без предварительной разработки глобальной архитектуры данных в организации. Такой подход кажется более удобным во многих случаях, поскольку он быстрее приводит к конечным результатам, однако впоследствии данные могут дублироваться и быть несогласованными. И хотя сторонники этого подхода утверждают важность поэтапной разработки и достижения "быстрых побед", в дальнейшем он приводит к серьезным затратам в случае необходимости сквозного анализа показателей организации. "Проектирование архитектуры хранилища данных связано с логикой проектирования бизнес-процессов – и должно идти в связке, – добавляет ведущий научный сотрудник НИУ ВШЭ Дмитрий Кожевников. – Например, если бизнес-процессы собираются снизу-вверх, как при субъектно-ориентированном подходе, логично и хранилище проектировать так же".

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

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

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

Независимые витрины (independent data marts) – это представление для того или иного потребителя, при этом единых аналитических разрезов и методов анализа не используется. Сквозной анализ данных, представленных в разных витринах, невозможен.

Шина взаимосвязанных витрин (data-mart bus architecture with linked dimensional data marts) – начинается с анализа требований для конкретных процессов. Первая витрина (data mart –DM) строится для одного бизнес-процесса с использованием измерений и показателей, которые в дальнейшем будут применяться в других компонентах. Последующие витрины разрабатываются с использованием этих измерений, что приводит к созданию логически интегрированных витрин (архитектура предложена Ральфом Кимбэлом (Ralph Kimball).

Архитектура "звезда" (hub-and-spoke) представляет собой централизованное хранилище с зависимыми витринами данных. Эта архитектура разрабатывается на основе корпоративного анализа требований к данным. Используя общее представление данных, выполняется итеративная разработка архитектуры, при этом вовлекается одна предметная область за другой. Зависимые витрины получают данные из хранилища и разрабатываются для подразделений или конкретных функциональных областей (архитектура предложена Билом Инмоном).

Централизованное хранилище (centralized data warehouse) – архитектура аналогична архитектуре "звезда", но с отсутствием зависимых витрин.

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

Выбор архитектуры

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

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

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

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

При этом выбор архитектуры хранилища данных зависит от архитектуры бизнеса компании. Если существует серьезная информационная зависимость между организационными подразделениями в рамках сквозного бизнес-процесса, тогда необходимы советующие варианты архитектур, например шина интегрированных витрин. Для крупных регионально-распределенных компаний может быть использована федеративная архитектура. "Она подходит для компаний, которые, как правило, территориально распределены, имеют слабые каналы передачи данных и разрозненные ИТ-платформы, собранные вместе в результате слияний и поглощений, – комментирует архитектор компании "Логика бизнеса 2.0" Виктор Горский. – Такие компании чаще применяют федеративный подход как наиболее быстро реализуемый и менее затратный".

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

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

Централизованное хранилище чаще выбирают для новых проектов, когда внедрение нужно провести в сжатые сроки, и нет большой зависимости от существующих хранилищ и информационных систем. Стоимость такого решения может быть высокой в случае крупных территориально распределенных компаний, – комментирует Виктор Горский. – Архитектура "звезда" чаще всего используется в корпоративных проектах для создания крупных масштабируемых хранилищ. Это долгосрочные и дорогие проекты, однако и самые результативные.

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