Olap cube что это

Обновлено: 19.05.2024

Как устроены системы оперативной аналитики данных, почему для BI больше подходит многомерный анализ и какие базы данных используют в OLAP.

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

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

Самое интересное: многомерный анализ данных

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

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

Давайте бросим взгляд на несколько представителей рынка многомерных БД для OLAP:

Vertica — неплохая база, появившаяся в 2005 году. Самая крутая фишка этой системы — встроенные в нее алгоритмы машинного обучения . Можно применять регрессии и считать кластеры на данных с помощью SQL-запросов, не написав ни строчки кода для создания моделей машинного обучения.
Greenplum — профессиональная база данных, которая работает на основе PostgreSQL. Огромная производительность, надежность и масштабируемость для тех, кому надо ворочать гигабайтами записей в режиме реального времени. Пожалуй, трудно найти что-то гибче и мощнее этой штуки. А еще она доступна в готовом и настроенном виде в облаке — в виде СУБД Arenadata DB . Облачный сервис поможет развернуть сложную многомерную базу данных в максимально короткие сроки.
Hadoop . Штука, в общем-то, не предназначенная для OLAP-процессов. Но, тем не менее, может выполнять роль ядра OLAP-системы. Качество и скорость, понятное дело, будут страдать, но зато этот инструмент всегда под рукой, он прост и умеет справляться со своими задачами. То есть вариант для быстрого прототипирования OLAP-систем. Также может интегрироваться с Greenplum, и в этом случае такая система подходит для работы с big data .

ManyToManyRelationship (отношение "многие ко многим")

ManyToManyRelationship позволяет разработчику кубов добавлять пользовательские и многие - - измерения в куб OLAP для реализации расширенных аналитических сценариев. Определение - связей типа «многие ко - многим» выходит за рамки данного документа. Тем не менее можно изучить данную концепцию и ее преимущества. Дополнительные сведения о ManyToManyRelationship см. в статье - - революция 2,0.

Во время развертывания куба Service Manager автоматически добавляет к - - Кубу много измерений для всех связей "один - прыжок" без какого бы то ни было взаимодействия. Однако Service Manager не добавляет много для нескольких - - измерений для каскадных связей с ( несколькими - прыжками из- ) за экспоненциального увеличения возможных связей, которые можно добавить. Добавление таких отношений в полном объеме может привести к значительному снижению производительности при просмотре куба OLAP. Это обусловлено тем, что агрегаты многих - и - многих связей обычно не вычисляются во время обработки, а так как при просмотре куба OLAP будут вычисляться объединения. Если требуется конкретная каскадная связь типа «многие - ко - многим», можно определить связь с помощью элемента пакета управления, которая будет добавлена в куб OLAP. И наоборот, можно перезаписать автоматически формируемую связь типа «многие - ко - многим» для использования другой промежуточной группы мер в экземплярах, где существуют несколько промежуточных групп. В этом случае Service Manager автоматически использует первую найденную группу. Ниже приведен пример - - элемента управления отношениями "многие ко многим".

В таблице ниже дается описание атрибутов отношения "многие ко многим".

attribute	Обязательно	Значения	Определение
CubeDimension	Да	Строка	Имя - измерения куба «многие ко - многим»
TargetMeasureGroup	Да	Строка	Целевая группа мер для создания связи "многие - ко - многим"
IntermediateMeasureGroup	Да	Строка	Промежуточная группа мер для создания связи "многие - ко - многим"

Организации и предприятия могут использовать ключевые показатели эффективности ключевых показателей эффективности ( ) для быстрой оценки работоспособности предприятия за счет измерения его хода выполнения до предопределенной цели. Каждый показатель KPI имеет целевое и фактическое значение. Целевое значение — это количественная цель, достижение которой важно для успеха организации. Крупные объемы данных отфильтровываются в одно дискретное значение, которое можно использовать для наблюдения за производительностью предприятия и оценки его продвижения в сторону важных целей и вех. Некоторые примеры ключевых показателей эффективности — это учебный курс, в котором 90% от их учащихся находится в течение четырех лет или группы баскетбол, в результате чего противоположная команда выводит меньше 50 процентов для игры. Для отображения группы показателей KPI можно использовать систему показателей, позволяющую представить общую работоспособность компании в виде моментального снимка. Ниже приведен образец показателя KPI.

В таблице ниже дается описание атрибутов показателя KPI.

attribute	Обязательно	Значения	Определение
ID	Да	Строка	Наименование показателя KPI
Caption	Да	Строка	Описание показателя KPI
Значение	Да	Строка	Сценарий MDX, определяющий числовое значение показателя KPI
Цель	Да	Строка	Целевое значение показателя KPI
Green Threshold (зеленый порог)	Да	Строка ( между 0,1 и 1)	Любое число, которое выше или ниже данного порога (в зависимости от направления), показывается зеленым в символе состояния.
Yellow Threshold (желтый порог)	Да	Строка ( между 0,1 и 1)	Любое число, которое выше или ниже порога (в зависимости от направления), однако не соответствует зеленому порогу, показано желтым в символе состояния. Число, которое находится за пределами желтого порога, отмечено красным в символе состояния.
Направление	Да	(Вверх, вниз)	Если данный параметр имеет значение Up ("вверх"), все числа, превышающие зеленый или желтый порог, будут отмечены соответствующим символом. Со значением Down ("вниз") соответствующим символом будут отмечены все числа, находящиеся ниже зеленого или желтого порога.
Status Graphic (символ состояния)	Да	(Фигуры, Траффиклигхт, Роадсигнс, датчик, Реверседгауже, термометр, цилиндр, Гранки, Варианцеарров)	Символ, которым будет представлен показатель KPI.

Подстановка

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

Это продемонстрировано в следующем примере.

В данном примере группа мер IncidentAssignedToUser указывает на отношение WorkitemAssignedToUser . Однако помимо инцидентов данное отношение будет содержать запросы на изменение и проблемы, назначенные каким-либо пользователям. Чтобы гарантировать, что эта группа мер содержит только инциденты, Service Manager заменит WorkItemDim на IncidentDim. Это означает, что таблица, которая создается для группы мер в представлении источника данных, автоматически выполняет внутреннее соединение измерения WorkItemDim с IncidentDim, и возвращает только те экземпляры, для которых соединение проходит успешно на основании значений EntityDimKey или BaseManagedEntityId.

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

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

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

И наконец, подстановки можно применять не только для фактов отношений, но и для пользовательских фактов. В таком сценарии конечной точкой отношения будет значение None. В таблице ниже дается описание атрибутов подстановки.

attribute	Обязательно	Значения	Определение
MeasureGroupName	Да	Строка	Имя группы мер, в которой следует выполнить подстановку
RelationshipEndPoint	Да	(Целевой объект, источник, нет)	Конечная точка отношения, в которой требуется выполнить подстановку. По умолчанию имеет значение None для пользовательских фактов.
Связь	Нет	ManagementPackRelationship	Подстановочное отношение.
AliasTargetDimensionAs	нет	Строка	Псевдоним исходного целевого измерения
AliasReplacementDimensionsAs	нет	Строка	Псевдоним подстановочного измерения
DimensionAlias	Нет	ManagementPackDimension	Псевдоним измерения из пользовательского факта (при наличии)

Действие

Действия — это события, которые могут быть активированы в кубе OLAP при выполнении доступа к данным куба. -Service Manager поддерживаются только действия детализации. Пример действия приведен ниже.

В таблице ниже дается описание атрибутов действия.

attribute	Обязательно	Значения	Определение
ID	Да	Строка	Имя действия детализации -
MeasureGroupName	Да	Строка	Целевая для действия группа мер
Тип действия	Да	(Подробно)	Тип действия -Service Manager поддерживаются только действия детализации.
CubeDimension	Да	Строка	Измерение куба, являющееся целью действия (должно являться срезом для группы мер).
PropertyName	Да	Строка	Атрибут измерения, отображаемый при выполнении действия детализации -

CubeExtension

Основное предназначение элемента CubeExtension — позволить вносить изменения в куб OLAP после развертывания его в службах SSAS без необходимости удаления и повторной установки куба. Если куб OLAP содержит многолетние данные, воссоздание куба может занять длительное время, так как потребуется полная обработка всех разделов куба.

Элемент CubeExtension может определять следующие элементы:

NamedCalculation (именованное вычисление)

ManyToManyRelationship (отношение "многие ко многим")

CustomMDX (пользовательский сценарий MDX)

Любую настройку, выполненную в элементе CubeExtension, также можно определить в объекте SystemCenterCube. Единственной недопустимой настройкой является добавление в куб фактов, групп мер и подстановок.

Как можно реализовать OLAP на практике: виды таких систем

Самый простой и очевидный подход — создать систему, которая напрямую ничего не хранит, но умеет быстро вынимать разные записи из разных мест и в правильном виде показывать данные менеджерам. Такие системы хорошо работают, когда данные разложены по однотипным СУБД. Например, все подразделения сидят на реляционной СУБД PostgreSQL.

OLAP с такой архитектурой будет называться Relational OLAP (ROLAP) — OLAP, построенный на отношениях таблиц и баз данных между собой. Такая система не требует предварительной подготовки записей в таблицах для анализа — можно брать все нужные значения напрямую и в режиме онлайн.

Если же данные лежат не только в однотипных корпоративных базах данных, то надо собирать информацию по разным источникам и сводить всё это вместе. Появляется этап предварительной подготовки данных на отдельном сервере. И такая система — это уже Multidimensional OLAP (MOLAP) , или многомерный OLAP. Такую штуку построить сложнее, но иногда без нее никак — чем больше ваша компания, тем больше разнородных систем хранения данных в ней будет задействовано. Это наиболее эффективный тип для аналитической обработки, так как позволяет структурировать данные под разные запросы пользователей.

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

SystemCenterCube

Элемент SystemCenterCube определяет куб OLAP с варьирующейся степенью детализации, которая зависит от ваших потребностей. Этот элемент состоит из следующих субэлементов:

CustomMDX (пользовательский сценарий MDX)

NamedCalculation (именованное вычисление)

Действие. ( - в настоящее время поддерживаются только действия по детализации)

ManyToManyRelationship (отношение "многие ко многим")

Группа мер

Каждый куб OLAP содержит коллекцию фактов, размещенных в киоске данных, при этом каждый член коллекции соответствует группе мер. Имя каждой группы мер должно быть уникальным в кубе OLAP. Однако один и тот же факт может соответствовать нескольким группам мер в кубе OLAP. К примеру, абстрактное отношение WorkItemAssignedToUser может быть трижды определено в кубе OLAP, используя уникальные имена групп мер ChangeRequestAssignedToUser, IncidentAssignedToUser и ProblemAssignedToUser. Факт можно настроить таким образом, чтобы в соответствующую группу мер куба OLAP включались только запросы на изменение, инциденты и проблемы.

Ниже приведен образец элемента пакета управления для группы мер IncidentAssignedToUser.

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

attribute	Обязательно	Значения	Определение
DateDimAlias	нет	Строка	Имя измерения даты, которое используется для фильтрации данной группы мер. Если псевдоним не определен, автоматически будет использоваться имя " ( MeasureGroupName ) _ измерение datedim" для роли измерения даты.
MeasureGroupName	Да	Строка	Имя группы мер в кубе. Это имя должно быть уникальным в пределах куба.
Факты	Да	Факт отношений или пользовательский факт	Целевой объект группы мер, который должен являться фактом из хранилища данных.

Общие сведения о моделировании кубов OLAP в Service Manager в пакетах управления

Эта версия Service Manager достигла конца поддержки, рекомендуется выполнить обновление до Service Manager 2019.

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

Что такое OLAP и зачем нужны такие системы

OLAP — это online analytical processing, оно же — оперативный анализ данных. Давайте попробуем определить это понятие на человеческом языке.

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

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

А почему «оперативный»? Допустим, вы управляете большим интернет-магазином и прямо сейчас тестируете на эффективность несколько рекламных кампаний. Из всех кампаний нужно отобрать самую эффективную и уже с ней работать дальше. Система обработки данных, конечно, позволит увидеть нужные цифры и принять правильные решения. Но данные из нее надо достать быстро — если построение отчета займет недели, то с такой задержкой хорошие решения принять нельзя.

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

Весь этот подход и программы, которые задействованы в таком быстром сборе и анализе информации, и называется OLAP.

Создаем OLAP куб. Часть 1

Продолжая тематику Многомерные кубы, OLAP и MDX и olap для маленькой компании, традиционно, предлагаю начать с простенького «Hello World» куба, который будет анализировать процессы и тенденции голосований на Хабре.

сама суть Data Warehouse-а хранить «очищенные» данные, готовые для анализа, поэтому даже его изначальная структура может сильно отличаться от структуры нашей хабра-OLTP базы данных
в HabraDW (так мы его назовем) мы вынесем только ту информацию, которая нам нужна будет для анализа, ничего лишнего
к Data Warehouse не накладываются требования нормализации. Даже наоборот, денормализировав некоторые данные можно добиться более понятной схемы для построения куба, а также скорости загрузки данных в куб

Немного теории.

чисто виртуальный (например, определенным как множество SELECT-ов или даже вызовов сложных хранимых процедур, которые каким-то образом определят входные данные для куба)
вполне реальным, то есть существовать физически на каком-то сервере (или серверах)

Каким же должен быть Data Warehouse?

Все очень просто – ваш Data Warehouse должен иметь структуру формы звездочки (star model) или снежинки (snowflake model) и состоять из фактов (facts) и измерений (dimensions).

Факты – это фактические записи (records) о каком-то процессе, который мы хотим анализировать, например, процесс голосования на Хабра, или процесс изменения цены товара на бирже. Очень часто факты содержат какие-нибудь числовые данные, например, фактическое значение голоса или цены.

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

Определив где у нас факты, а где измерения — очень просто построить модель звезды.

Звезда.

В центре указываем нашу таблицу фактов, а лучами выводим измерения.

А теперь снежинка.

Снежинка — это та же звезда, только измерения могут зависеть от измерений следующего уровня, а те в свою очередь могут включать еще уровни.

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

HabraDW.

Перейдем к собственно разработке нашего Data Warehouse-а.

в какое время года/месяца/недели голосуют лучше/хуже/чаще
как голосуют по пятницам и понедельникам (например)
как влияет на результат голосования наличие в посте слов Microsoft, или Карма
средняя активность пользователей, «пики» голосования
и т.п.

Таблица фактов FactHabravote – определяет кто, когда, за что и как именно проголосовал. Значение Vote в нашем случае будет +- 1, но тип поля позволяет расширить дельту голосами, например, +- 10
Измерение времени DimTime – определяет нужные для анализа атрибуты времени (значения и названия)
Измерение пользователей DimUser – определяет пользователей Хабра, пока только никнейм
Измерение постов DimPost – определяет посты, в нашем случае содержит заголовок и булевые поля, определяющие содержит ли пост слова Microsoft и Карма.

Итоговая схема нашей звезды будет такой.

А здесь исходный SQL скрипт, который создает и наполняет (пока что только случайными данными) наше хранилище.

Ну вот, теперь все готово, чтобы загрузить данные в куб.
До встречи в следующей статье.

Именованное вычисление

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

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

Помните, что Service Manager поддерживает только измерения, предназначенные для именованные вычисления. Целевыми объектами элемента NamedCalculation не могут быть факты. В таблице ниже дается описание атрибутов именованного вычисления.

attribute	Обязательно	Значения	Определение
ID	Да	Строка	Имя именованного вычисления.
целевого объекта	Да	ManagementPackDimension	Целевое измерение меры
ColumnType	Да	(Int, Double)	(тип SQL язык SQL ) столбца
Тип	Нет	(Количество, сумма)	Тип меры

<Calculation>Вложенный элемент содержит в качестве значения определение именованного вычисления. Значение хранится в виде выражения MDX.

Пользовательские меры позволяют выполнять статистические вычисления, используя числовые атрибуты измерений. Service Manager не поддерживает пользовательские меры, основанные на фактах. Продолжим пример вычисления, приведенный выше, Service Manager определяет пользовательскую меру в Incidentspasttargetresolutiontime образом следующим образом:

В приведенном XML-коде в качестве целевого измерения меры указывается IncidentDimension, целевым же свойством является IncidentsPastTargetResolutionTime. Это пользовательское свойство, определенное ранее. Пользовательские меры могут ссылаться как на собственные, так и на вычисляемые свойства измерения.

И наконец, тип измерения указывается как Sum ("Сумма"). Тип измерения может указываться как Sum или Count. Из-за соображений производительности Service Manager типы мер числа различных объектов не допускаются. В таблице ниже дается описание атрибутов меры.

attribute	Обязательно	Значения	Определение
ID	Да	Строка	Наименование меры
целевого объекта	Да	ManagementPackDimension	Целевое измерение меры
Свойство	Да	Строка	Свойство целевого измерения
Тип	Нет	(Количество, сумма)	Тип меры

Custom MDX (Пользовательские сценарии MDX)

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

Многомерные кубы, OLAP и MDX

Довольно давно являюсь обитателем Хабра, но так и не доводилось читать статьи на тему многомерных кубов, OLAP и MDX, хотя тема очень интересная и с каждым днем становится все более актуальной.
Не секрет, что за тот небольшой промежуток времени развития баз данных, электронного учета и онлайн систем, самих данных накопилось очень много. Теперь же интерес также представляет полноценный анализ архивов, а возможно и попытка прогнозирования ситуаций для подобных моделей в будущем.
С другой стороны, большие компании даже за несколько лет, месяцев или даже недель могут накапливать настолько большие массивы данных, что даже их элементарный анализ требует неординарных подходов и жестких аппаратных требований. Такими могут быть системы обработки банковских транзакций, биржевые агенты, телефонные операторы и т.д.
Думаю, всем хорошо известны 2 разных подхода построения дизайна баз данных: OLTP и OLAP. Первый подход (Online Transaction Processing — обработка транзакций в реальном времени) рассчитан на эффективный сбор данных в реальном времени, второй же (Online Analytical Processing – аналитическая обработка в реальном времени) нацелен именно на выборку и обработку данных максимально эффективным способом.

быстрый доступ к данным
преагрегация
иерархии
работа с временем
язык доступа к многомерным данным
KPI (Key Performance Indicators)
дата майнинг
многоуровневое кэширование
поддержка мультиязычности

Немного подробнее о возможностях

Быстрый доступ к данным
Собственно быстрый доступ к данным, независимо от размеров массива, и является основой OLAP систем. Так как основной упор именно на этом, хранилище данных обычно строится по принципам, отличным от принципов реляционных баз данных.
Здесь, время на выборку простых данных измеряется в долях секунды, а запрос, превышающий несколько секунд, скорее всего, требует оптимизации.

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

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

Работа с временем
Так как в основном анализ данных происходит на временных участках, именно времени в OLAP системах выделено особое значение, а значит, просто определив для системы, где у нас тут время, в дальнейшем можно с легкостью пользоваться функциями типа Year To Date, Month To Date (период от начала года/месяца и до текущей даты), Parallel Period (в этот же день или месяц, но в прошлом году) и т.п.

Язык доступа к многомерным данным
MDX (Multidimensional Expressions) — язык запросов для простого и эффективного доступа к многомерным структурам данных. И этим все сказано – внизу будет несколько примеров.

Key Performance Indicators (KPI)
Ключевые показатели эффективности — это финансовая и нефинансовая система оценки, которая помогает организации определить достижение стратегических целей. Ключевые показатели эффективности могут быть достаточно просто определены в OLAP системах и использоваться в отчетах.

Дата майнинг
Интеллектуальный анализ данных (Data Mining) — по сути, выявление скрытых закономерностей или взаимосвязей между переменными в больших массивах данных.
Английский термин «Data Mining» не имеет однозначного перевода на русский язык (добыча данных, вскрытие данных, информационная проходка, извлечение данных/информации) поэтому в большинстве случаев используется в оригинале. Наиболее удачным непрямым переводом считается термин «интеллектуальный анализ данных» (ИАД). Впрочем, это отдельная, не менее интересная тема для рассмотрения.

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

Поддержка мультиязычности
Да-да-да. Как минимум Analysis Services 2005/2008 (правда, Enterprise Edition) нативно поддерживают мультиязычность. Достаточно привести перевод строковых параметров ваших данных, и клиенту, указавшему свой язык, будут приходить локализированные данные.

Многомерные кубы

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

Фактически, плоскость (или множество всех таких точек) и будет являться кубом, а, соответственно, Время, Товары и Покупатели – его измерениями.
Представить (и нарисовать) четырехмерный и более куб немного сложнее, но суть от этого не меняется, а главное, для OLAP систем совершенно неважно в скольких измерениях вы будете работать (в разумных пределах, конечно).

Немного MDX

Итак, в чем же прелесть MDX – скорее всего в том, что описывать нужно не то как мы хотим выбрать данные, а что именно мы хотим.
Например,

* This source code was highlighted with Source Code Highlighter .

Что означает – хочу количество iPhone-ов, проданных в июне и июле в Мозамбике.
При этом я описываю какие именно данные я хочу и как именно я хочу их увидеть в отчете.
Красиво, не правда ли?

А вот чуть посложнее:

* This source code was highlighted with Source Code Highlighter .

Фактически, вначале определяем формулу подсчета «среднего размера покупки» и пытаемся сравнить – кто же (какой пол), за один заход в магазин Apple, тратит больше денег.

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

Заключение

На самом деле, данная статья очень мало покрывает даже базовых понятий, я бы назвал ее «appetizer» — возможность заинтересовать хабра-сообщество данной тематикой и развивать ее дальше. Что же касается развития – тут огромное непаханое поле, а я буду рад ответить на все интересующие вопросы.

Кто пользуется OLAP-системами

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

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

Или большие онлайн-магазины и ритейлеры. Наличие запасов на складе и показателей выручки важно знать здесь и сейчас — ведь даже за 10 минут торгового дня эти значения меняются очень быстро.

Думаю, на этих примерах вы мысленно примерили OLAP на свой бизнес. И уже поняли, насколько вам нужна такая система.

OLAP и многомерный анализ данных

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

Поэтому OLAP позволяет строить гипотезы, выявлять причинно-следственные связи между разными параметрами, моделировать поведение системы при изменениях.

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

Вот так выглядит многомерная модель данных. Источник Вот так выглядит многомерная модель данных. Источник

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

Для визуализации данных многомерного куба используют обычные таблицы — тут видно число продаж по регионам за месяц Для визуализации данных многомерного куба используют обычные таблицы — тут видно число продаж по регионам за месяц

OLAP-система собирает информацию из баз данных, ERP, CRM и других источников, а затем формирует многомерный массив данных. В общем виде структура OLAP выглядит так:

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

Читайте также: