Создавая корпоративную аналитическую систему, необходимо не только учитывать текущие аналитические потребности предприятия, но и минимизировать совокупную стоимость владения всем решением в процессе эксплуатации...
Создавая корпоративную аналитическую систему, необходимо не только учитывать текущие аналитические потребности предприятия, но и минимизировать совокупную стоимость владения всем решением в процессе эксплуатации
Одно из ключевых препятствий на пути освоения и эффективного использования корпоративных аналитических систем — непрозрачность информационного содержимого системы. Бизнес-пользователи жалуются: сложно понять, какая информация вообще есть в системе, при этом у них уходит много времени на поиск и получение доступа к нужным данным.
Кроме того, многие крупные компании сталкиваются с необходимостью снижения высоких затрат на сопровождение корпоративных аналитических систем в условиях постоянно изменяющихся требований бизнеса. Однако адаптация к изменениям никогда не была сильной стороной этих систем. Нередко расходы на сопровождение такой системы составляют 40-100% в год от первоначальной стоимости разработки.
Традиционно корпоративные аналитические системы строятся так, чтобы удовлетворять текущим потребностям анализа бизнес-информации. Однако организации никогда не стоят на месте. В условиях возрастающей конкуренции, нестабильности законодательства, экономической глобализации, слияний и просто повседневной коммерческой активности компаниям приходится постоянно совершенствовать свои бизнес-структуры (а следовательно, и поддерживающие их информационные технологии). Такая изменчивость приводит к значительным текущим расходам и высоким трудозатратам персонала, отвечающего за поддержку и управление аналитическими системами.
Решение проблем непрозрачности информационного наполнения и высокой стоимости владения аналитической системы возможно за счет создания системы с помощью методов и средств бизнес-аналитики (Business Intelligence, BI), существенной особенностью которых является широкое применение метаданных. Использование метаданных, описывающих предметную область, бизнес-правила и логику работы системы, позволит вносить изменения без перепрограммирования (или минимизировать число ручных операций), что обеспечит единый, централизованный взгляд на информационное наполнение системы и даст бизнес-пользователям ключ к пониманию содержимого системы и происходящих в ней процессов. Кроме того, это приведет к сокращению стоимости владения системой в целом.
Классический подход
Организационная структура, категории продукции, географические границы и другие бизнес-понятия изменяются с течением времени. Более того, различные пользователи могут иметь различные взгляды на свои собственные (относящиеся к работе конкретного департамента) и общекорпоративные данные.
Так, за пять лет может измениться многое:
- структура кода продукции — из-за появления новых линеек продуктов;
- организационная структура компании — из-за развития, слияния, реинжиниринга и т. п.;
- территориально-административное деление местности;
- состав ведущих мировых валют и пр.
Классический подход, которого придерживаются при реагировании на изменения, — отражение их непосредственно в системе (менять структуры данных, отчеты и т. п.). Разработчик узнает об изменении, анализирует его, перепроектирует базы данных, переписывает программы загрузки и обработки данных, преобразовывает старые данные к новому виду, добавляет новые программы и т. п. Затем проводит тестирование новой версии системы. А на следующий день после того, как новая версия системы реализована, происходят очередные изменения в бизнесе, технологиях или в мире, и разработчик вынужден опять переделывать систему.
Однако высокие постоянные трудозатраты на поддержание системы являются не главной проблемой. При изменении структуры данных могут быть потеряны все накопленные аналитические результаты. Скажем, аналитик подготовил в январе отчет, который понравился руководству. Затем в марте были произведены серьезные изменения в структуре базы данных. А в мае руководство снова обратило внимание на этот аналитический отчет и потребовало провести более детальный анализ. К сожалению, выполнить те же аналитические запросы, которые использовались в январе при составлении отчета, будет уже невозможно. Придется сделать новый отчет на новой структуре базы данных, и можно только надеяться на то, что результаты не будут кардинально отличаться от полученных в январе.
При таком подходе остаются нерешенными и другие типичные проблемы:
- плохая «приживаемость» крупных аналитических систем из-за отсутствия у конечных пользователей ясного и полного обзора представленной в системе информации;
- высокая себестоимость сопровождения и поддержки соответствия системы текущим бизнес-потребностям.
Аналитическая система на основе метаданных
Информацию, с которой имеет дело аналитическая система, можно разделить на три категории (рис. 1):
Виды информации в BI |
- фактографические данные — данные о транзакциях и отчетные данные;
- контекстные данные — классификаторы, реестры и справочники;
- метаданные — описание данных.
Фактографические данные отражают оперативную деятельность компании, описывают бизнес-события и связанные с ними данные транзакций и отчетности. Примером транзакции является факт продажи, доставки, операция по договору. Примеры фактографических данных — конкретные значения количества проданной продукции, полученной прибыли, уровня удовлетворенности клиента и т.п. В многомерном моделировании такие данные называются значениями показателей или фактами. Фактографические данные описывают количественное влияние событий на бизнес, а именно на бизнес-сущности, описываемые контекстными данными.
Контекстные данные описывают внутренние или внешние по отношению к бизнесу сущности, участвующие в транзакциях и в отчетности в виде классификаторов, реестров и справочников. Примером контекстных данных является конкретный клиент (скажем, ЗАО «Международная пивная компания»), продукт («банка пива 0,5 л алюминиевая»), единица территориального деления («Московский регион»). В многомерном моделировании такие данные называются элементами измерений.
Метаданные — это данные о данных, которые могут описывать как контекстные, так и фактографические данные. Метаданные принято разделять на бизнес- и технические метаданные. Основное назначение бизнес-метаданных состоит в описании решаемой задачи (предметной области) для того, чтобы аналитикам было удобно ориентироваться во всех данных системы. В терминах многомерного моделирования данных бизнес-метаданными являются описания показателей и измерений. Примерами бизнес-метаданных могут служить описания показателей «Доход», «Количество проданной продукции», «Уровень удовлетворенности клиента» и измерения «Клиент», «Категория продукции», «Территориально-административное деление». Технические метаданные предназначены для ИТ-специалистов, занимающихся созданием или поддержкой системы , и описывают структуры хранения данных и их связь с понятиями предметной области (бизнес-метаданными).
Фактографические данные, как правило, не изменяются с течением времени, поскольку они описывают конкретный исторический факт (транзакция). Изменяются контекстные данные (структура компании, состав мировых валют и т. п.) и метаданные (расширение набора атрибутов какой-либо бизнес-сущности или добавление нового показателя).
С точки зрения прикладного специалиста (бизнес-аналитика), для того чтобы не происходило устаревание аналитической системы, она должна быть устойчивой к любым изменениям в предметной области. Это означает, что внутренняя структура системы должна быть устроена таким образом, чтобы хранить историю изменения контекстных данных и метаданных. Это даст возможность исполнять аналитические отчеты, подготовленные в разные моменты времени, вне зависимости от того, происходили какие-либо изменения в предметной области или нет.
Технические аспекты реализации
Чтобы быть устойчивой к изменениям, корпоративная аналитическая система должна иметь специализированную внутреннюю архитектуру.
В рассматриваемых подходах аналитическая система строится на основе BI, в частности технологии хранилищ данных. При этом в общем случае выделяется следующая цепочка доставки информации (рис. 2): источники данных — оперативный склад данных — центральное хранилище данных — витрины данных (не обязательно) — аналитические приложения.
BI-система как цепочка доставки информации |
При этом ключевым компонентом является центральное хранилище данных, в котором содержится история всех данных системы за все время. Оно строится на основе реляционной модели, предназначенной для хранения многомерных данных (ROLAP). Для реализации возможности хранения истории изменения контекстных данных в качестве основы могут быть использованы методы работы с так называемыми «медленно меняющимися измерениями» [1, 2], которые предлагают специальную организацию реляционных таблиц, содержащих элементы измерений.
Зависимость метаданных от времени фиксирует специальный компонент BI-системы — репозитарий, предназначенный для ведения метаданных с поддержкой функции контроля версий. Реализация стандартной модели checkin/checkout 0 позволяет организовать многопользовательскую работу с метаданными с возможностью получения полного описания (конфигурации) системы на любой момент времени.
Роль метаданных в BI
Теперь попытаемся понять, почему создание корпоративных информационно-аналитических систем является такой нетривиальной и затратной задачей. В цепи доставки информации, образованной четко специфицированным потоком данных, каждый шаг перегрузки или преобразования данных выполняется одним или несколькими программными продуктами (инструментами), предназначенными для выполнения узкого круга задач данного шага. Чтобы цепь преобразования данных была эффективной, все программные продукты должны быть полностью интегрированы. Каждый инструмент должен иметь полное представление о данных, которые он получает на входе: смысл всех полей, какие преобразования необходимо выполнить, куда поместить результат, какие процессы будут потреблять результирующие данные и т. п.
Ключом к пониманию смысла данных и правил их использования являются метаданные. Все современные программные продукты и инструменты, применяемые на различных этапах обработки данных, основываются на метаданных, которые представляют собой основной управляющий вход, задающий логику обработки. Для того чтобы заданный набор инструментов мог эффективно образовывать цепочку доставки информации и обеспечивал взаимодействие на уровне данных, необходимо единое понимание метаданных, описывающих обрабатываемые данные. Иными словами, все программные системы и инструменты, входящие в состав BI, должны быть интегрированы между собой на уровне метаданных прежде, чем они смогут быть эффективно интегрированы на уровне данных 0.
Бизнес-метаданные описывают предметную область и поэтому являются общими для всех компонентов, составляющих BI-систему. Технические метаданные могут носить как общий, так и частный характер. Общими будем считать метаданные, значимые более чем для одного компонента системы, а остальные будем называть локальными.
Эволюция BI-системы при изменении бизнеса
Как отмечалось, изменения в предметной области могут затрагивать контекстные (справочные) данные либо метаданные.
Для обеспечения устойчивости BI-системы при изменении контекстных данных используется специальная структура данных центрального хранилища, позволяющая хранить историю версий для каждого элемента медленно меняющегося измерения. При получении очередной порции контекстных данных в оперативном складе данных происходит их сопоставление с предыдущей версией, и при необходимости порождаются новые версии элементов измерений в центральном хранилище.
Аналитические приложения могут либо изначально строиться с расчетом на работу с медленно меняющимися измерениями, либо не учитывать возможность существования множества версий для одного элемента измерения. Первый вариант предпочтительнее, так как не требует при изменении контекстных данных никаких дополнительных действий по адаптации аналитических приложений. Однако, даже если последние изначально не рассчитаны на изменчивость контекстных данных, можно создать специализированные витрины данных, предоставляющие доступ только к одной «нужной» версии справочных данных (например, к последней). Таким образом, система хранит все версии контекстных данных и автоматически переходит на использование нужной версии при их изменении. При этом не требуется вмешательства разработчиков для адаптации BI-системы к новым бизнес-требованиям.
Более сложными являются изменения в составе и структуре бизнес-понятий, то есть в метаданных. В этом случае необходимо обратиться к истории метаданных, которая ведется средствами центрального репозитария. Адаптация системы к таким изменениям производится техническим специалистом, сопровождающим систему. В отличие от традиционного подхода эта деятельность автоматизирована — существует специальный компонент системы, в котором отражаются необходимые изменения в метаданных. Затем обновленное описание всей системы в виде общих метаданных передается во все компоненты BI-системы, которые либо автоматически, либо с участием технических специалистов (на этапе создания локальных метаданных) настраиваются на работу с обновленной предметной областью.
Использование центрального репозитария для хранения истории метаданных позволяет существенно сократить трудозатраты на актуализацию системы при изменениях в бизнесе, например при появлении новых показателей и измерений.
Существующие решения
Ведением и управлением метаданных занимается специальный компонент в составе системы — репозитарий метаданных. Реализовать описанные принципы создания BI-системы можно исходя из двух альтернативных подходов.
Централизованное управление метаданными
Его идея в том, что для построения BI-системы создается интегрированный комплекс средств — своеобразный «конструктор» хранилищ данных. В этом случае его производитель предлагает полный набор средств и инструментов для реализации системы, в состав которых входит специализированный репозитарий метаданных. При этом все метаданные хранятся и обрабатываются в центральном репозитарии, а остальные компоненты не имеют своих метаданных и работают непосредственно с центральным репозитарием (рис. 3).
Централизованное управление метаданными |
Преимущества такого подхода — максимально короткий срок развертывания корпоративной информационно-аналитической системы и высокая производительность при операциях с метаданными. Основным недостатком является «закрытость» решения с точки зрения возможного состава: система должна строиться из продуктов одного производителя, тесно интегрированных между собой.
Наиболее интересным средством для реализации такого подхода является продукт KALIDO Data Warehouse Lifecycle Management (DWLM) Suite. Продукт включает в себя компоненты, реализующие оперативный склад, центральное хранилище и витрины данных, а также функции по управлению метаданными. Для хранения используются специализированные структуры данных, а аналитические приложения «видят» ROLAP-представление данных. Аналитические приложения не попадают под единую систему управления метаданными, и их выбор не ограничен продуктами одного производителя. По утверждению разработчика, прототип системы на реальных данных предприятия разворачивается за три недели.
Конфедеративное управление метаданными
При таком подходе построение BI-системы рассматривается как задача системной интеграции — объединения в одну систему изначально не связанных между собой программных продуктов (в том числе выпущенных различными производителями). Общие для компонентов системы метаданные ведутся в специально выделенном репозитарии и затем передаются в компоненты, которые имеют собственные репозитарии метаданных. Этот подход реализован в программном продукте «Корпоративный каталог показателей» компании ЛАНИТ.
Задача интеграции на уровне метаданных решается за счет ведения общих метаданных в одном месте — центральном репозитарии системы (рис. 4). При этом целостность и согласованность описаний может быть гарантирована средствами репозитария, а настройка компонентов системы на решаемую задачу будет осуществляться за счет импорта общих метаданных из центрального репозитария.
Централизованное управление метаданными |
Для обмена метаданными используются XML-файлы, построенные в соответствии со спецификацией консорциума OMG Common Warehouse Metamodel 0. Обмен метаданными в этом формате поддерживают практически все крупные производители программных продуктов, используемых для создания BI.
Подход назван конфедеративным, поскольку централизованно ведутся только общие метаданные, а локальные порождаются лишь в тех программных продуктах/инструментах, в которых они имеют смысл и могут быть использованы. При этом общие метаданные, полученные из центрального репозитария системы, не могут быть изменены в локальном репозитарии, а могут быть только дополнены локальными метаданными.
Выбирай любую...
Централизованное и конфедеративное управление метаданными решают проблему адаптации системы к непрерывно изменяющимся бизнес-требованиям и снижают стоимость владения системой BI (до 20-50% в год от стоимости первоначальной разработки). Основным преимуществом централизованного управления метаданными является высокая скорость развертывания корпоративной информационно-аналитической системы. Основное преимущество конфедеративного подхода — возможность использования решений различных производителей в роли компонентов BI, что позволяет построить систему на основе лучших в своем классе продуктов.
Бизнес-пользователи в обоих случаях получают инструмент для поиска информации, охваченной BI, и для совместной работы с формализованным описанием предметной области.
Литература
- Kimball R. Slowly Changing Dimensions// DBMS Magazine, April 1996.
- Luedtke J. Implementing Slowly Changing Dimensions// SQL Magazine, February 2000.
- Feiler P. Configuration Management Models in Commercial Environments// Software Engineering Institute, March 1991.
- Poole J., Chang D., Tolbert D., Mellor D. Common Warehouse Metamodel: An Introduction to the Standard for Data Warehouse Integration// John Willey & Sons, 2002.
- Common Warehouse Metamodel (CWM) Specification, version 1.0// Object Management Group, January 2001.
Алексей Шовкун — руководитель проектов компании ЛАНИТ, bisystems@lanit.ru