Хранилище данных: центральное или функционально-ориентированное

Автор: Пётр Подымов

Введение

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

Два варианта архитектуры

Существуют две концепции проектирования хранилищ данных, авторами которых принято считать соответственно Билла Инмона и Ральфа Кимбела.

В хранилище «по Инмону» достаточно чётко разделяются область детальных данных и область анализа. С точки зрения моделирования хранилище чётко декомпозируется на предметные области, описывающие определённый объект учёта (например, клиент, договор или событие). Таким образом, данные хранятся в нормализованном виде в уникальной для каждой предметной области структуре, которая определяется концептуальной моделью бизнеса. Витрины данных реляционные или многомерные, содержащие преобразованные для целей анализа факты и агрегаты, строятся дополнительно либо на одной платформе с хранилищем, либо отдельно.

Структура «по Кимбелу» создается априори подготовленной для аналитических задач, благодаря применению непосредственно в хранилище реляционных структур, оптимизированных для этих целей. Описанные принципы характерны для проектирования витрин данных; схемы называют: «звезда», «снежинка» или «созвездие». Хранилище может содержать несколько уровней агрегации данных, но при этом область анализа и область детальных данных явным образом не разделяются, хотя верхние уровни агрегации для оптимизации, как и в предыдущем варианте, могут выделяться, например, в отдельные OLAP-кубы. Таким образом, можно говорить, что хранилище представляет собой комплекс связанных на уровне единой системы справочников витрин данных.

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

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

Центральное хранилище

Центральное или, по-другому, корпоративное хранилище данных создается для обеспечения единого взгляда на информацию всей финансовой организации. Построение такого хранилища должно включать в себя предварительную разработку единой согласованной системы классификаторов, в том числе НСИ (нормативно-справочной информации), а также типизацию и согласование структур сущностей, определяющих различные представления объектов учёта (клиентов, счетов, продуктов, документов и т.д.). Различные виды одного объекта учёта могут описываться разными сущностями, имеющими общего предка (по объектно-ориентированному представлению) – центральную сущность. Связи между сущностями напрямую отражают бизнес-правила.

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

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

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

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

Функционально-ориентированное хранилище

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

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

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

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

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

Предположим, аналитикой является клиент. В то же время, стороны, вовлеченные в бизнес организации – это не только клиенты. Стороны могут быть разных видов (человек, организация и др.), по-разному соотноситься с другими сущностями (например, быть клиентом или поручителем) и иметь отличные друг от друга наборы специфических атрибутов. Атрибуты придётся хранить в обобщенной структуре, что значительно «утяжеляет» справочник и делает многие бизнес-правила скрытыми (не понятными из модели). Другой пример: «многомерный» подход к моделированию ограничивает вариативность в плане отслеживания истории, особенно истории связей.

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

Выбор решения

На рынке управленческих систем представлено несколько открытых решений основанных на хранилищах данных для финансовых организаций. Примерами функционально-ориентированного хранилища является OFSA Financial Data Manager или EPF; центрального – IBM BDW и Teradata LDM. Можно увидеть варианты, когда хранилище моделируется в нормализованном виде, но состав и структура ограничиваются необходимым набором исходных данных конкретных бизнес-приложений. Примером таких моделей являются компоненты решений от компании SAS.

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

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

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

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

По этой теме можно также почитать:

• Архитектуры систем поддержки принятия решений

Для удобства отслеживания новых публикаций на сайте рекомендую подписаться на рассылку или подписаться на канал RSS.

Если вы нашли в сети интересные ссылки на ресурсы по технологиям хранилищ данных, OLAP, CRM или data mining, и хотите поделиться ими с другими, присылайте их. Я с удовольствием размещу их на этом сайте.