Хранилище данных: центральное или функционально-ориентированное.
Хранилища данных в современном мире уже перестали считаться новой технологией. Между тем рынок управленческих систем – решений построенных на базе хранилищ данных – развивается очень динамично. Когда речь заходит о хранилищах данных, важно понимать говорим ли мы о центральном хранилище организации или о хранилище, поддерживающем функциональность определенной промышленной либо заказной управленческой системы. Третий вариант – попытка совмещения обоих вариантов в одном, исходя из текущих потребностей бизнеса и возможностей организации.
Два варианта архитектуры.
Существуют две концепции проектирования хранилищ данных, авторами которых принято считать соответственно Билла Инмона и Ральфа Кимбела.
В хранилище «по Инмону» достаточно чётко разделяются область детальных данных и область анализа. С точки зрения моделирования хранилище чётко декомпозируется на предметные области, описывающие определённый объект учёта (например, клиент, договор или событие). Таким образом, данные хранятся в нормализованном виде в уникальной для каждой предметной области структуре, которая определяется концептуальной моделью бизнеса. Витрины данных реляционные или многомерные, содержащие преобразованные для целей анализа факты и агрегаты, строятся дополнительно либо на одной платформе с хранилищем, либо отдельно.
Структура «по Кимбелу» создается априори подготовленной для аналитических задач, благодаря применению непосредственно в хранилище реляционных структур, оптимизированных для этих целей. Описанные принципы характерны для проектирования витрин данных; схемы называют: «звезда», «снежинка» или «созвездие». Хранилище может содержать несколько уровней агрегации данных, но при этом область анализа и область детальных данных явным образом не разделяются, хотя верхние уровни агрегации для оптимизации, как и в предыдущем варианте, могут выделяться, например, в отдельные OLAP-кубы. Таким образом, можно говорить, что хранилище представляет собой комплекс связанных на уровне единой системы справочников витрин данных.
Первый вариант обеспечивает большую гибкость и лучшую масштабируемость в плане новых бизнес-задач. Второй вариант позволяет получить скорейший результат, адаптированный под конкретные текущие бизнес-требования. Стоит заметить, что различия не очень велики: проведя мысленный эксперимент, увидим, что по мере нормализации структуры хранения детальных данных, модели и отношений справочников, если бы таковая проводилась, модель хранилища по варианту два приближалась бы к варианту номер один.
Возвращаясь к практическому применению, при создании решений для финансовых организаций, построение «по Инмону» оказывается характерным для центрального хранилища, построение «по Кимбелу» – для функционально-ориентированного. Далее рассмотрим оба варианта подробнее.
Центральное хранилище.
Центральное или, по-другому, корпоративное хранилище данных создается для обеспечения единого взгляда на информацию всей финансовой организации. Построение такого хранилища должно включать в себя предварительную разработку единой согласованной системы классификаторов, в том числе НСИ (нормативно-справочной информации), а также типизацию и согласование структур сущностей, определяющих различные представления объектов учёта (клиентов, счетов, продуктов, документов и т.д.). Различные виды одного объекта учёта могут описываться разными сущностями, имеющими общего предка (по объектно-ориентированному представлению) – центральную сущность. Связи между сущностями напрямую отражают бизнес-правила.
Модель хранилища в таком случае являет достаточно объемной, но зато прозрачно согласующейся с бизнес-логикой. При наличии готовой отраслевой модели, для обеспечения такой согласованности требуется аккуратно выделить необходимое для текущего проекта подмножество и последовательно кастомизировать сущности и связи в соответствии с моделью предметной области конкретной организации. Указанные приемы моделирования позволяют обеспечить поддержку развития бизнеса без значительных доработок уже разработанных предметных областей. Под развитием, здесь подразумевая не только масштабирование по мере увеличения количества операций, но и качественное развитие при появлении новых продуктов и услуг, развития методологии учёта и т.д.
Центральное хранилище внедряется поэтапно, в соответствии с приоритетами бизнес-подразделений, на каждом этапе решаются новые бизнес-задачи, при этом само хранилище лишь дорабатывается.
Ограничениями общекорпоративного хранилища является практическая нецелесообразность прямой работы BI/CPM систем с информацией в хранилище. Это несколько усложняет процесс и повышает риски внедрения и, на начальных этапах, отодвигает получение бизнес-результата.
Однако, будучи грамотно выстроенным, оно становится базой для построения всех управленческих систем и модулей выгрузок на общем источнике данных, оправдывая своё идеологическое предназначение, обеспечивая получение обобщенной и непротиворечивой информации на единой платформе. Снижаются затраты на развитие и сопровождение, упрощается поддержка изменений учётных систем.
Функционально-ориентированное хранилище.
Функционально-ориентированными хранилищами данных можно назвать подсистемы, лежащие в основе большинства разнообразных промышленных управленческих систем, которые поставляются в максимально готовом виде с определенными возможностями расширения. В состав решения входят приложения для внутренней обработки данных, инструменты для доступа к информации и создания отчётов. На уровне семантического слоя предопределенны метрики и аналитики. Аналитическая или управленческая система, в состав которой входит хранилище, в зависимости от функциональности включает готовые отчёты, элементы управления, различные программные модули и т.п.
Хотя описанные выше системы довольно дороги, вложения компенсируется, во-первых, бизнес-функционалом, в который вложен значительный интеллектуальный потенциал. Во-вторых, возможностью относительно быстрого внедрения: оставляя функционал без изменений, для начала работы оказывается достаточным загрузить в хранилище качественные детальные данные (что, однако тоже не просто).
Помимо прочего, на основе информации загруженной в хранилище могут функционировать дополнительные внешние витрины данных, например, обязательная отчётность. Однако может ли функционально-ориентированное хранилище стать общекорпоративным?
Цель получить систему максимальной готовности накладывает на хранилище ряд ограничений. Как уже было сказано, изначально такое хранилище содержит определенный расширяемый набор аналитик разработанных с учётом функционала конечной управленческой системы. Или, если мы говорим о системе разрабатываемой «с нуля», то, аналогично ODS, многие сущности перенимают структуру из ключевой исходной системы.
Функционально-ориентированное хранилище отражает в своей модели принципы анализа, а не бизнес-логику предметной области. При этом обычно не учитываются особенности различных объектов учёта попадающих в одну аналитику.
Предположим, аналитикой является клиент. В то же время, стороны, вовлеченные в бизнес организации – это не только клиенты. Стороны могут быть разных видов (человек, организация и др.), по-разному соотноситься с другими сущностями (например, быть клиентом или поручителем) и иметь отличные друг от друга наборы специфических атрибутов. Атрибуты придётся хранить в обобщенной структуре, что значительно «утяжеляет» справочник и делает многие бизнес-правила скрытыми (не понятными из модели). Другой пример: «многомерный» подход к моделированию ограничивает вариативность в плане отслеживания истории, особенно истории связей.
В результате функционально-ориентированное хранилище обеспечивает более быстрое внедрение, меньшую длительность ETL и в определенных случаях более высокую производительность запросов. Однако такое хранилище имеет заметно меньше возможностей для расширения вместе с развитием бизнеса, как при увеличении объемов данных, так и при расширении перечня продуктов и услуг.
Выбор решения.
На рынке управленческих систем представлено несколько открытых решений основанных на хранилищах данных для финансовых организаций. Примерами функционально-ориентированного хранилища является OFSA FinancialDataManager или EPF; центрального – IBM BDW и Teradata LDM. Можно увидеть варианты, когда хранилище моделируется в нормализованном виде, но состав и структура ограничиваются необходимым набором исходных данных конкретных бизнес-приложений. Примером таких моделей являются компоненты решений от компании SAS.
На практике часто можно обнаружить определенное комбинирование подходов, при проектировании различных элементов решения.
Функционально-ориентированное хранилище может приобретаться, как составляющая аналитического решения или управленческой системы, и предназначено для поддержки определенного спектра бизнес-задач. Приобретая центральное хранилище, получаем проработанную с точки зрения бизнеса отраслевую модель данных и шаблоны типовых витрин на базе данной модели по ключевым направлениям банковского бизнеса (финансы, риски, CRM и прочее), но без прикладной функциональности.
Если масштабы и приоритеты финансовой организации позволяют, функционально-ориентированное хранилище данных может быть внедрено в составе и как основа для решения наиболее востребованных бизнес-задач, и затем использоваться в качестве источника для некоторых вновь создаваемых витрин. Однако на определённом этапе развития бизнеса оно не сможет выполнять эти функции в достаточной степени и потребует значительной доработки или замены. Много зависит от детальных особенностей того или иного решения (архитектуры, модели данных и т.д.).
В любом случае выбор должен осуществляться с учётом экономических соображений на основе глубокого анализа состояния и потребностей каждой финансовой организации индивидуально с привлечением экспертов по хранилищам данных и ключевым областям работы самой организации.
Витрина данных
Витрина данных (англ. Data Mart; другие варианты перевода: хранилище данных специализированное, киоск данных, рынок данных) — срез хранилища данных, представляющий собой массив тематической, узконаправленной информации, ориентированный, например, на пользователей одной рабочей группы или департамента.
Концепция витрин данных
Концепция витрин данных была предложена Forrester Research ещё в 1991 году. По мысли авторов, витрины данных — множество тематических БД, содержащих информацию, относящуюся к отдельным аспектам деятельности организации.
Концепция имеет ряд несомненных достоинств:
Аналитики видят и работают только с теми данными, которые им реально нужны.
Целевая БД максимально приближена к конечному пользователю.
Витрины Данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.
Для реализации витрин данных не требуется высокомощная вычислительная техника.
Но концепция витрин данных имеет и очень серьёзные пробелы. По существу, здесь предполагается реализация территориально распределённой информационной системы с мало контролируемой избыточностью, но не предлагается способов, как обеспечить целостность и непротиворечивость хранимых в ней данных.
Идея соединить две концепции — хранилищ данных и витрин данных, по видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника данных для витрин данных.
И сегодня именно такое многоуровневое решение:
первый уровень — общекорпоративный БД на основе реляционной СУБД с нормализованной или слабо денормализованной схемой (детализированные данные);
второй уровень — БД уровня подразделения (или конечного пользователя), реализуемые на основе многомерной СУБД (агрегированные данные);
третий уровень — рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;
постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:
компактное хранение детализированных данных и поддержка очень больших БД, обеспечиваемые реляционными СУБД;
простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые многомерными СУБД.
Реляционная форма представления данных, используемая в центральной общекорпоративной БД, обеспечивает наиболее компактный способ хранения данных. Современные реляционные СУБД уже умеют работать с БД имеющими размер порядка нескольких терабайт. Хотя такая центральная система обычно не сможет обеспечить оперативного режима обработки аналитических запросов, при использовании новых способов индексации и хранения данных, а также частичной денормализации таблиц, время обработки заранее регламентированных запросов (а в качестве таких, можно рассматривать и регламентированные процедуры выгрузки данных в многомерные БД) оказывается вполне приемлемым.
В свою очередь, использование многомерных СУБД в узлах нижнего уровня обеспечивает минимальные времена обработки и ответа на нерегламентированные запросы пользователя. Кроме того, в некоторых многомерных СУБД имеется возможность хранить данные как на постоянной основе (непосредственно в многомерной БД), так и динамически (на время сеанса) загрузить данные из реляционных БД (на основе регламентированных запросов).
Таким образом, имеется возможность хранить на постоянной основе только те данные, которые наиболее часто запрашиваются в данном узле. Для всех остальных хранятся только описания их структуры и программы их выгрузки из центральной БД. И хотя, при первичном обращении к таким виртуальным данным, время отклика может оказаться достаточно продолжительным, такое решение обеспечивает высокую гибкость и требует более дешевых аппаратных средств
OLAP
OLAP (англ. online analytical processing, аналитическая обработка в реальном времени) — технология обработки информации, включающая составление и динамическую публикацию отчётов и документов. Используется аналитиками для быстрой обработки сложных запросов к базе данных. Служит для подготовки бизнес-отчётов по продажам, маркетингу, в целях управления, т. н. data mining — добыча данных (способ анализа информации в базе данных с целью отыскания аномалий и трендов без выяснения смыслового значения записей).
Основоположник термина OLAP, Эдгар Кодд, предложил в 1993 году «12 законов аналитической обработки в реальном времени».
Действие OLAP
Причина использования OLAP для обработки запросов — это скорость. Реляционные БД хранят сущности в отдельных таблицах, которые обычно хорошо нормализованы. Эта структура удобна для операционных БД (системы OLTP), но сложные многотабличные запросы в ней выполняются относительно медленно.
OLAP-структура, созданная из рабочих данных, называется OLAP-куб. Куб создаётся из соединения таблиц с применением схемы звезды или схемы снежинки. В центре схемы звезды находится таблица фактов, которая содержит ключевые факты, по которым делаются запросы. Множественные таблицы с измерениями присоединены к таблице фактов. Эти таблицы показывают, как могут анализироваться агрегированные реляционные данные. Количество возможных агрегирований определяется количеством способов, которыми первоначальные данные могут быть иерархически отображены.
Например, все клиенты могут быть сгруппированы по городам или по регионам страны (Запад, Восток, Север и т. д.), таким образом, 50 городов, 8 регионов и 2 страны составят 3 уровня иерархии с 60 членами. Также клиенты могут быть объединены по отношению к продукции; если существуют 250 продуктов по 2 категориям, 3 группы продукции и 3 производственных подразделения, то количество агрегатов составит 16560. При добавлении измерений в схему, количество возможных вариантов быстро достигает десятков миллионов и более.
OLAP-куб содержит в себе базовые данные и информацию об измерениях (агрегатах). Куб потенциально содержит всю информацию, которая может потребоваться для ответов на любые запросы. Из-за громадного количества агрегатов, зачастую полный расчёт происходит только для некоторых измерений, для остальных же производится «по требованию».
Вместе с базовой концепцией существуют три типа OLAP — OLAP со многими измерениями (Multidimensional OLAP — MOLAP), реляционный OLAP (Relational OLAP — ROLAP) и гибридный OLAP (Hybrid OLAP — HOLAP). MOLAP — это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. HOLAP использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP — R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.
Каждый тип хранения имеет определённые преимущества, хотя есть разногласия в их оценке у разных производителей. MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных. ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается. HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается. Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.
Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми.
Реализации OLAP
Первым продуктом, выполняющим OLAP-запросы, был Express (компания IRI). Однако, сам термин OLAP был предложен Эдгаром Коддом, «отцом реляционных БД». А работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт — Essbase (позже купленный Hyperion, которая в 2007 г. была поглощена компанией Oracle) — годом ранее.
Другие хорошо известные OLAP-продукты включают Microsoft Analysis Services (ранее называвшиеся OLAP Services, часть SQL Server), Oracle OLAP Option, DB2 OLAP Server от IBM (фактически, Essbase с дополнениями от IBM[источник не указан 247 дней]), SAP BW, SAS OLAP Server, продукты Brio[источник не указан 247 дней], BusinessObjects, Cognos, MicroStrategy и других производителей.
C технической точки зрения, представленные на рынке продукты делятся на «физический OLAP» ((M)ultidimensional) OLAP, ((H)ybrid OLAP) и «виртуальный» ((R)elational OLAP).
В первом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную БД, обеспечивающую быстрое извлечение. Примеры таких продуктов — Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion Essbase, Prognoz, SAS OLAP Server, Cognos PowerPlay. Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной БД, а агрегаты — в многомерной БД.
Во втором случае данные хранятся в реляционных СУБД, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов — SAS, SAP BW, Deductor, BusinessObjects, Microstrategy.
Системы, имеющие в своей основе «физический OLAP» обеспечивают стабильно лучшее время отклика на запросы, чем системы «виртуальный OLAP». Поставщики систем «виртуальный OLAP» заявляют о большей масштабируемости их продуктов в плане поддержки очень больших объемов данных.
С точки зрения пользователя оба варианта выглядят похожими по возможностям.
Наибольшее применение OLAP находит в продуктах для бизнес-планирования и хранилищах данных.
