> For the complete documentation index, see [llms.txt](https://book.konstantinsecurity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.konstantinsecurity.com/readme/big-data/olap-data-qubes.md).

# OLAP data qubes

<https://habr.com/ru/companies/vk/articles/703508/>

![](/files/UzKyk9LqudV0HL8hTmDc)

![](/files/qdmH29oikeo1sMo4AQ7Q)

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

Команда [VK Cloud](https://mcs.mail.ru/) перевела статью, в которой заполняются пробелы и развенчиваются мифы, окружающие тему кубов данных.

## Что такое куб данных

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

Дизайн-паттерн реализован в основном в двух контекстах:

1. Как предварительно агрегированная таблица в реляционной базе данных.
2. Как объект данных в специализированной OLAP-системе.

В обоих контекстах кубы данных должны помогать бизнес-аналитикам предварительно упаковывать и агрегировать важные для стейкхолдеров показатели. Если вкратце, с 1980 по 2010 год специалисты прибегали к предварительной упаковке и агрегированию. Это помогало избежать оперативных агрегатных запросов, из-за которых резко снижалась доступная на тот момент пропускная способность обработки.

Сегодня эти проблемы стоят не так остро. Но к этой теме мы вернёмся позже.

## Кубы данных в реляционных БД

Рассмотрим пример — таблицу с данными по продажам по региону, магазину и продукту:

![](/files/t8lCVbKSzNGNoCzqKdVB)

Чтобы создать куб данных из взятого для примера дата-сета, нужно **агрегировать сумму цен по каждой комбинации разрезов**. В PostgreSQL и MS SQL имеется подблок GROUP BY под названием CUBE, который сделает эту работу за вас.

Вот как выглядит запрос CUBE с этими данными:

```
SELECT SUM(price) as total_sales,
       region,
       store,
       product
FROM sales
GROUP BY CUBE(region, store, product);
```

Поскольку у взятого для примера дата-сета есть три разреза: регион, магазин, продукт, — вышеуказанный запрос выдаст восемь сгруппированных множеств и 29 строк данных (исходя из количества уникальных значений по разрезам).

Чтобы рассчитать общее количество сгруппированных множеств, созданных кубом данных, воспользуйтесь формулой: 2^number\_of\_dimensions.

Сгруппированные множества для этого примера:

```
(region, store, product),
(region, store),
(region, product),
(store, product),
(region),
(store),
(product),
()
```

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

## Кубы данных в OLAP-системах

Как мы показали выше, куб данных можно реализовать в таблице стандартной БД, но их чаще используют в приложении Online Analytical Processing (OLAP).

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

## Краткий исторический экскурс

Сейчас давайте ненадолго вернёмся в прошлое и разберёмся, что такое OLAP-системы и почему их вообще создали.

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

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

### Приход OLAP-систем

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

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

* **Roll up**: объединить показатели в категории разрезов уровнем выше (город => область).
* **Drill Down**: разбить обобщённые категории на категории уровнем ниже (область => город).
* **Slice and Dice**: выбрать сегмент данных из одного или нескольких разрезов.
* **Pivot:** поменять оси табличного представления.

В этом контексте OLAP-куб — это агрегат многомерных данных, а OLAP-система — интерфейс сводных таблиц, предназначенный для исследования куба с помощью языка запросов или GUI. Современные версии OLAP-систем — это IMB Cognos, Oracle Olap и Oracle Essbase.

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

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

![](/files/UhQn7g7QOrKAsKn1aTs0)

OLAP drill up\&down en.png со [страницы Wikipedia](https://en.wikipedia.org/wiki/OLAP_cube)

### Вчера и сегодня

С тех пор как разработчики разворачивали кубы данных и OLAP-системы в качестве решения для бизнес-аналитики, технологический ландшафт кардинально изменился. Эффективность обработки данных экспоненциально выросла, а благодаря облачным платформам вроде AWS, GCP и VK Cloud, ещё и существенно подешевела. Кроме того, колоночные хранилища упростили доступ к большому объёму данных при стандартных нагрузках.

Благодаря этим переменам необходимость в кубах и OLAP-системах заметно снизилась.

Сегодня аналитики могут безо всяких проблем на лету агрегировать данные по разным разрезам с помощью платформ типа BigQuery и Snowflake. Да и использование GUI для сведения воедино больших объёмов данных уже не вызывает трудностей. Такие инструменты, как DOMO и PowerBI, позволяют аналитикам с лёгкостью фрагментировать и анализировать данные вдоль и поперёк.

## Заключение

Вернёмся к исходному вопросу — так что же такое OLAP-куб? Если очень коротко, это многомерная сводная таблица в OLAP-системе. Если не брать в расчёт особенности технической реализации, она похожа на сводную таблицу Excel.

> Команда VK Cloud развивает
>
> [собственные Big Data-решения](https://mcs.mail.ru/bigdata/)