что такое olap куб простыми словами

Что такое OLAP-куб и принцип его настройки

OLAP-куб – это инструмент, который напоминает сводную таблицу в Excel.

Принцип работы примерно тот же: сгруппировать по одинаковому признаку числа или даты – и далее делать с ними дополнительные действия или вычисления.

Всё начинается с того, что нужно вытащить числа по каким-то критериям.

Какие есть числа про проект? – Реквизиты-числа в объектах (задачах, например) и в справочниках.

Но нужно не просто взять и всё сложить, а вычленить по какому-то признаку. Этим признаком может быть:

OLAP на яблоках

И так далее. Можно добавлять всё новые и новые измерения, по которым будет проводиться расчёт.
Измерений может быть не 2, как в обычной таблице, а не ограниченное количество:

От яблок к ADVANTA

Чтобы увидеть результат, нужно на основе созданного OLAP-куба создать OLAP-отчёт. И/или использовать этот OLAP-куб как источник для дальнейших вычислений.

Если не указано иное, содержимое этой вики предоставляется на условиях следующей лицензии:
CC Attribution-Share Alike 4.0 International

Источник

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

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

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

Быстрый доступ к данным
Собственно быстрый доступ к данным, независимо от размеров массива, и является основой 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 – скорее всего в том, что описывать нужно не то как мы хотим выбрать данные, а что именно мы хотим.
Например,

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

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

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

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

Заключение

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

Источник

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

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

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

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

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

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

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

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

Звезда.

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

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

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

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

HabraDW.

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

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

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

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

Источник

olap для маленькой компании

В посте Многомерные кубы, OLAP и MDX Vitko написал: «тема очень интересная и с каждым днем становится все более актуальной». К сожалению, это заклинание произносится уже очень давно (по крайней мере я его слышу с 2004 года ), но olap проектов до сих пор очень мало. Возможно, потому что традиционно считается, что всё, что связанно с olap нужно только для крупных компаний с большими объемами накопленных данных и стоит очень дорого. Но это не совсем так. Я хочу рассказать о проекте, который внедрен в одной относительно небольшой компании.

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

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

Основная учетная система — 1С «Торговля и склад» 7.0, причем dbf версия. Она достаточно успешно справляется с задачами учета товара. Но получить в ней отчеты за большие периоды времени практически нереально. Подобные попытки создают серьезную нагрузку на сервер, начинаются проблемы у операторов 1с, жалобы в It отдел.

Потребность в таких отчетах была постоянная. Сложилась идеальная ситуация для реализации bi проекта: большой объём информации + люди заинтересованные в её анализе.

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

Посмотреть avi в нормальном качестве можно скачав отсюда 5,25Mb ( 6 минут )
Поработать с локальным кубом можно скачав пример 2,64Mb
или тут 8Mb

Как это реализовано:

В принципе необязательно строить «хранилище». Данные для куба можно получать напрямую из базы 1с ( MsSQL или dbf ). Но в моем случае из 1с данные прошлых периодов периодически удаляются и очищаются справочники. Кроме того перед загрузкой в хранилище данные немного «чистятся».

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

Любой пользователь может получить информацию разными путями:

Сначала использовался только excel, но возникало много проблем с тем, что екселевские файлы «разбредались», нужно было получить одну «точку входа» для выбора информации.
Поэтому был создан локальный сайт, на котором опубликованы страницы с PivotTable. Сотрудник, который хочет получить пару цифр «здесь и сейчас» заходит на этот сайт и строит отчет в нужной ему форме. Если человеку нужно использовать этот отчет в дальнейшем – он может написать заявку, чтобы его отчет опубликовали в SSRS или сам сохраняет его в excel.

Локальные кубы

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

Как правило, поставщику тоже неудобно работать с большими отчетами. Поэтому большая часть, попробовав работать с локальными кубами, согласилась получать отчетность в таком виде. Список отчетов, которые формировал отдел маркетинга, значительно сократился. Оставшиеся тяжелые отчеты были реализованы в SSRS, созданы подписки (отчеты формируются автоматически и рассылаются поставщикам по расписанию)

Основные параметры системы

Конфигурация сервера:

процессор: 2xAMD Opteron 280
память: 4Gb
дисковые массивы:
операционная система: RAID 1 (зеркало) 2xSCSI 15k
данные: RAID 0+1 4xSCSI 10k

Согласитесь, такую машинку сложно назвать «мощным» сервером

Объем данных:

хранилище 10Гб, данные с 2002 года
агрегация 30%
Размер многомерной базы 350М
кол-во членов «больших измерений»: товары 25 тыс., адреса – 20 тыс.
кол-во документов в день — 400. среднее кол-во строк в документе — 30

Что в итоге получила компания:

Плюсы

Для руководства предприятия

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

Для менеджера

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

Для поставщиков

Возможность интерактивной работы с информацией

С точки зрения it-специалиста

Уменьшение рутинной работы. Большую часть отчетов пользователь получает самостоятельно.

Источник

OLAP и многомерные СУБД: как устроен оперативный анализ данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник