За последние полгода к нам обратились сразу несколько заказчиков с запросом модифицировать или мигрировать структуру их OLAP-кубов – естественно, с сохранением функциональности. Прежде чем браться за задачу, неплохо бы вспомнить, с чем мы имеем дело.
Об OLAP-кубах, как о некоей абстракции, я услышал во второй половине 2000-х гг., а в реальности столкнулся с ними несколькими годами позже.
Что такое OLAP-куб
Согласно [1], OLAP-куб – это структура данных, которая позволяет быстро анализировать данные по множеству измерений, определяющих бизнес-задачу. Многомерный куб для отчетности по продажам может, например, состоять из нескольких измерений: продавец, регион, продукт, месяц, год.
Идея размещения данных в кубах возникла для преодоления ограничений традиционных реляционных баз данных, которые не предназначены для почти мгновенного анализа и отображения больших объемов данных. Они лучше подходят для создания записей из серии транзакций, известных как OLTP (онлайн-обработка транзакций). Создание отчетов на основании РСУБД зачастую занимает много времени, если требуется обобщить всю базу, а также вызывает сложности, когда пользователи хотят изменить ориентацию отчетов или анализов в соответствии с различными многомерными представлениями, называемыми срезами (slices). Использование кубов ускоряет для конечных пользователей интерактивную работу с данными.
OLAP-куб можно рассматривать как расширение структуры моделирования, предоставляемой электронной таблицей, которая размещает данные в строках и столбцах, то есть в двумерном массиве данных. Куб может вмещать в себя любое количество массивов или измерений.
Говоря об OLAP-кубах, важно упомянуть их составные части – компоненты куба (подробные определения см в [20]):
· Dimension (Измерение) – основная характеристика анализируемых элементов данных, срез;
· Measure (Мера) – это реальные числовые данные в OLAP-кубах. Меры хранятся в своих собственных измерениях, которые называются измерениями мер;
· Member (Член) – единичный элемент данных в измерении. Доступ к членам обычно реализуется через OLAP-структуру измерений, иерархий и уровней;
· Hierarchy (Иерархия) – предопределенная агрегация уровней в указанном измерении. Иерархия OLAP-куба позволяет создавать сводные данные и анализировать их на разных уровнях структуры, не углубляясь в отношения между этими уровнями;
· Level (Уровень) – это категории, которые агрегируются в общую иерархию. Уровни можно воспринимать как поля данных, которые можно запрашивать и анализировать отдельно друг от друга.
Техническая реализация OLAP-движка, ответственного за выполнение вычислений, может существенно различаться, что оказывает прямое влияние на производительность и масштабируемость системы.
Типы OLAP | Описание |
MOLAP | Multidimensional OLAP считается стандартной формой OLAP и, как правило, упоминается просто как OLAP. В этом примере OLAP-куба данные хранятся в многомерном массиве, а не в реляционной базе данных. Система требует предварительных вычислений перед запуском. |
ROLAP | В отличие от классического OLAP, Relational OLAP работает непосредственно с реляционными базами данных и не требует предварительных вычислений. Тем не менее, база данных OLAP-куба должна быть тщательно спроектирована для использования в ROLAP. |
HOLAP | Hybrid OLAP, как следует из названия, является гибридом MOLAP и ROLAP. Этот тип позволяет пользователям указывать, какое количество данных будет храниться в MOLAP и в ROLAP соответственно. |
В переводной статье [2] (к сожалению, ссылка на оригинал отсутствует, но, вероятно, это [3]) приведены следующие типичные задачи, решаемые с помощью OLAP-кубов:
· Roll Up: объединить показатели в категории разрезов уровнем выше (город => область);
· Drill Down: разбить обобщённые категории на категории уровнем ниже (область => город);
· Slice and Dice: выбрать сегмент данных из одного или нескольких разрезов;
· Pivot: поменять оси табличного представления.
В этом контексте OLAP-куб – это агрегат многомерных данных, а OLAP-система – интерфейс сводных таблиц, предназначенный для исследования куба с помощью языка запросов или GUI.
Какое-то время понятия OLAP (онлайн-аналитическая обработка) и OLAP-куб ошибочно считались синонимами, что не соответствует действительности:
OLAP – способ использования базы данных, если вы выполняете типичный анализ данных (например, фильтруете набор данных по некоторым измерениям, агрегируете значения или представляете данные по этим измерениям);
OLAP-куб – это структура данных, используемая для выполнения OLAP-нагрузки. Есть шуточное мнение, что OLAP-кубы — это просто «очень сложные вложенные массивы».
OLAP-кубы являются результатом более чем 40 лет исследований и разработок. Кубы реализованы с десятками оптимизаций, включая продвинутые техники сжатия данных, различные встроенные структуры для помощи в индексации и фильтрации, а также эвристики для определения того, что загружать в память, что предагрегировать и сохранять на диске.
Иными словами, OLAP-запросы могут выполняться как на OLAP-кубе, так и непосредственно в базе данных. Таким образом, понятия «OLAP» и «OLAP-куб» не являются тождественными.
История возникновения OLAP-кубов
OLAP-куб возник из простой идеи: взять данные и поместить их в структуру, известную как «двумерный массив», то есть список списков. Развитие этой идеи заключается в том, что чем больше измерений вы хотите анализировать, тем больше вложенных массивов вам нужно. Трехмерный массив — это список списков списков, четырехмерный массив — это список списков списков списков и так далее. Поскольку вложенные массивы существуют во всех основных языках программирования, идея загрузки данных в такую структуру была очевидной для разработчиков первых BI-систем.
Но что делать, если вы хотите выполнять анализ на наборах данных, которые значительно превышают доступную память вашего компьютера? Разработчики первых BI-систем поступили логично и просто: они агрегировали и кэшировали подмножества данных внутри вложенного массива — и время от времени сохраняли части вложенного массива на диске. Сегодня понятие «OLAP-кубы» относится, в частности, к контекстам, в которых эти структуры данных значительно превышают размер основной памяти сервера, например, многотерабайтные наборы данных.
Влияние OLAP-кубов было значительным и изменило практику бизнес-анализа. Внутри кубов начал выполняться почти весь анализ. Это в свою очередь означало, что всякий раз, когда требовался новый отчет или новый анализ, приходилось создавать новые кубы.
Предположим, вы хотите создать отчет о продажах автомобилей по провинциям. Если ваш текущий набор кубов не включает информацию о провинциях, вам придется попросить инженера данных создать новый OLAP-куб для вас или изменить существующий куб, чтобы включить недостающие разрезы.
Использование OLAP-кубов также означало, что командам данных приходилось управлять сложными пайплайнами для преобразования данных из SQL-базы данных в эти кубы. Если вы работали с большим объемом данных, подобные задачи преобразования могли занимать много времени, поэтому обычной практикой являлся запуск всех ETL-пайплайнов до того, как аналитики приходили на работу. Таким образом, аналитики не ждали, пока обновятся их кубы — они могли позволить компьютерам выполнять тяжелую работу ночью и сразу начинать работу утром. Этот подход, конечно, стал проблемным по мере глобализации компаний и открытия офисов в нескольких часовых поясах, требующих доступа к одним и тем же аналитическим системам (как запускать ваши пайплайны ночью, когда ваша ночь — это утро другого офиса?).
SQL-базы данных и хранилища данных должны были быть организованы таким образом, чтобы упростить создание кубов. Если вы стали аналитиком данных в последние лет двадцать, вас, вероятно, обучали сложным методам моделирования: таким как, моделирование по Кимбаллу, моделирование сущностей по Инмону или моделирование хранилищ данных. Эти названия представляют собой методы организации данных в хранилище данных в соответствии с аналитическими требованиями вашего бизнеса.
Кимбалл, Инмон и их коллеги заметили, что в каждом бизнесе возникают определенные паттерны доступа. Они поняли, что что значительные временные затраты команд данных на создание новых кубов свидетельствуют о неэффективности произвольного подхода к организации данных для отчетности.
В конечном счете основоположники индустрии разработали повторяемые методы преобразования бизнес-требований к отчетности в проекты хранилищ данных, , которые облегчали командам извлечение необходимых данных в нужных форматах для OLAP-кубов.
Эти ограничения определяли форму и функции команд данных на протяжении почти четырех десятилетий. Важно понимать, что к созданию концепции OLAP-куба привели существовавшие технологические ограничения, а специфика OLAP-куба способствовала появлению практик, которые мы воспринимаем как должное и сегодня. Например:
Поддерживаем сложные ETL-пайплайны для моделирования наших данных;
Нанимаем большую команду инженеров данных для поддержания этих сложных пайплайнов;
Моделируем данные согласно методологиям Кимбалла, Инмона или Data Vault, чтобы облегчить извлечение и загрузку данных в кубы. Когда мы отошли от кубов, мы продолжаем использовать эти практики для загрузки данных в аналитические и визуализационные инструменты — независимо от того, построены ли они на основе кубов;
Имеем большую команду инженеров данных, которая также поддерживает вторую группу пайплайнов (от смоделированного хранилища данных к кубу).
Однако сегодня многие из ограничений, приведших к созданию OLAP-куба, неактуальны. Компьютеры стали быстрее., память – дешевле. Существуют вычислительные мощности, использующие облачные технологии. Специалисты по данным начинают осознавать, что OLAP-кубы, представляющие собой фактические предрассчитанные агрегированные данные, имеют свои проблемы.
Недостатки OLAP-кубов
При работе с OLAP-кубами существует множество проблем:
1) Технические трудности и затраты. В зависимости от реализации OLAP-кубы могут либо требовать отдельного сервера (что увеличивает общие эксплуатационные расходы), либо нуждаться в специализированных знаниях для внедрения и обслуживания;
2) Длительное время создания и значительные накладные расходы. OLAP-кубы требуют тщательного проектирования перед их созданием. Для их поддержания необходим выделенный специалист. Данные постоянно изменяются, а изменения в исходных источниках данных часто приводят к сбоям OLAP-кубов на следующих этапах. Более того, перерасчет OLAP-куб, чтобы включить в него данные очередного нового отчетного периода, может занимать несколько часов. Таким образом, OLAP-кубы – совершенно неподходящий инструмент для аналитики в режиме NRT (near real-time) [6]. В качестве альтернативы Microsoft развивает так называемые табулярные модели, которые позволяют сжимать данные более эффективно и ускорять выполнение типичных запросов [19];
3) Отсутствие доступности. OLAP-кубы, как правило, сложны для понимания нетехническими сотрудниками. Требуя освоения специализированного ПО или диалекта SQL, они становятся "продвинутой" структурой данных, что препятствует "демократизации" доступа к данным и превращает аналитиков и инженеров данных в узкое место для нетехнических специалистов, нуждающихся в информации;
4) Отсутствие гибкости. OLAP-кубы создавались исходя из предположения о «фиксированной бизнес-модели». Основные измерения и метрики не должны были значительно изменяться, так что OLAP-кубы всегда могли бы отвечать на соответствующие BI-вопросы. Но реальность отличается: данные и бизнес-процессы, которые они описывают, меняются и развиваются ускоренными темпами. Начиная с нового инструмента обработки данных, который вы хотите интегрировать, до изменения бизнес-логики, требующей нового набора метрик, OLAP-кубы не предлагают достаточной универсальности и гибкости;
5) Обработка неаддитивных агрегатов. OLAP-кубы сталкиваются с трудностями при суммировании неаддитивных агрегатов (агрегированных значений, которые нельзя корректно суммировать по всем измерениям, потому что его смысл зависит от уровня агрегации). Примером является процент выполнения плана. Если отдел A выполнил 80% плана, а отдел B — 90%, то нельзя просто сказать, что в среднем компания выполнила 85% плана. Нужно учитывать, сколько задач было у каждого отдела, иначе результат будет некорректным. Чтобы решить эту проблему, часто внутри куба создаётся таблица, хранящая в себе значения NULL для исключенных измерений. Этот подход обеспечивает точные вычисления и предоставляет обходное решение для ограничений традиционных методов агрегации.
Современный статус OLAP-кубов
Всё ещё преимущества… или тоже недостатки?
В [3] и [5] обсуждается, что OLAP-кубы в основном утратили свою актуальность, поскольку хранилища данных могут выполнять агрегацию таблиц продаж на лету. Тем не менее, этот подход все еще предлагает явные преимущества.
1. Запросы к OLAP-кубам действительно быстрее и дешевле, чем запросы к более детализированным данным.
Имеется в виду, что человеко-часы, необходимые для построения всевозможных вариантов предагрегации данных, обойдутся дороже, нежели создание куба.
Важно: если вы работаете в компании с действительно огромными данными, это преимущество может стать более значимым. Убедитесь, что работаете со своими заинтересованными сторонами, чтобы заранее определить, что будет представлять одна запись (например, «одна запись на дату по категории продукта по штату»), чтобы позже не пришлось добавлять измерения.
Я готов поспорить с утверждением, что OLAP-куб значительно быстрее, чем тщательно спроектированный набор витрин с несколькими уровнями агрегации. Несколько лет назад мы сравнивали производительность иерархического отчёта, разработанного с помощью Oracle BI Enterprise Edition на двух источниках данных: OLAP-кубе Oracle Essbase и несколькими таблицами, самая детальная из которых содержала несколько миллионов строк на одну отчетную дату. Разница во времени отклика отчета, основанного на кубе и на таблицах в РСУБД, не превышала 15%. Результаты детальных замеров, как и сведения об используемом серверном оборудовании, к сожалению, не сохранились. Справедливости ради надо отметить, что движок Oracle BI позволяет в качестве источников данных указывать несколько таблиц и эффективно определять необходимый уровень агрегации в зависимости от выбранных измерений, и также может при необходимости выбирать данные из более агрегированных таблиц.
2. При использовании OLAP-куба практически гарантированы одинаковые значения для одной и той же метрики.
В нашем примере общая сумма продаж уже заранее вычислена, так что ситуации, при которых два пользователя определяют продажи как разные значения на уровне записи (включает ли это налог или нет) или используют разные часовые пояса для агрегации этих чисел (используем ли мы UTC, время главного офиса или местное время магазина, в котором были проданы товары), невозможны. Сторонники OLAP-кубов обычно считают это преимущество основным аргументом для продолжения использования этого подхода.
Хотя мы можем мечтать о таблице продаж, которая будет так хорошо спроектирована, что наши заинтересованные стороны просто получат правильный ответ при запросе, – на практике эта мечта недостижима: кто-то всегда найдет способ всё испортить.
С другой стороны, компания Snowflake, ведущий вендор в разработке облачных хранилищ, утверждает [7], что вычислительные способности современных кластеров стали настолько мощными, что OLAP-нагрузка может быть прекрасно реализована без помощи технологии кубов. Однако, заметим, что в случае Snowflake речь идет исключительно об облачных решениях, а вопрос цены остается за кадром.
Аналогичной позиции (и при сходных начальных условиях) придерживаются разработчики, использующие технологии, предоставляемые облачным провайдером Amazon [8].
Отступление про колоночные базы данных
В современных хранилищах роль непосредственного источника данных, на котором строятся запросы в BI, выполняют колоночные базы данных.
Типичная реляционная база данных хранит свои данные в строковой форме. Одна строка транзакции, например, будет содержать поля «дата», «клиент», «цена», «ключ продукта» и так далее. Однако, колоночная база данных хранит каждое из этих полей в отдельных колонках.
Различие между строковой РСУБД и колоночной базой данных
В то время как OLAP-кубы требуют, чтобы вы загружали подмножество интересующих вас измерений в куб, колоночные базы данных позволяют выполнять аналогичные OLAP-запросы с такой же производительностью без необходимости строить новые кубы. Другими словами, это SQL-база данных, идеально подходящая для OLAP-нагрузок.
Как колоночные базы данных достигают таких впечатляющих уровней производительности? Оказывается, есть три основных преимущества хранения данных в колонках:
Колоночные базы данных обладают более высокой эффективностью чтения. Если вы выполняете запрос вроде «дай мне среднюю сумму заказа всех транзакций за последние пять лет», реляционная база данных должна будет загрузить все строки за последние пять лет, даже если ей нужно только агрегировать поле суммы заказа. Колоночная база данных должна будет проверить только одну колонку — суммы. Это означает, что колоночной базе данных нужно «просеять» лишь малую часть общего объема данных.
Колоночные базы данных также лучше сжимаются по сравнению со строковыми реляционными базами данных. Оказывается, когда вы храните схожие данные вместе, их можно сжать гораздо лучше, чем если вы храните очень разные данные. (В теории информации это известно как «низкая энтропия»). Напоминание: колоночные базы данных хранят данные в колонках — то есть значения одного типа и схожие между собой. Это гораздо легче сжимается по сравнению с данными строк, даже если приводит к затратам для распаковки при чтении значений. Но в целом это сжатие означает, что при выполнении агрегирующего запроса в память может быть загружено больше данных, что в свою очередь приводит к улучшению быстродействия.
Последнее преимущество заключается в том, что сжатие и плотная упаковка в колоночных базах данных освобождают место, которое может быть использовано для сортировки и индексации данных внутри колонок. Другими словами, колоночные базы данных обладают более высокой эффективностью сортировки и индексации. Кроме того, это взаимовыгодно: исследователи, изучающие колоночные базы данных, указывают на то, что отсортированные данные лучше сжимаются, чем несортированные, поскольку сортировка снижает энтропию. Суммарный результат всех этих свойств заключается в том, что колоночные базы данных обеспечивают производительность, сравнимую с OLAP-кубами, без необходимости явного проектирования (и построения!) кубов. Это означает, что вы можете выполнять все необходимое внутри своего хранилища данных и избегать утомительной рутины, связанной с обслуживанием кубов.
Существенным недостатком является низкая скорость обновлений в колоночной базе данных (для обновления одной строки вам нужно обратиться к каждой колонке). В результате многие современные колоночные базы данных ограничивают вашу способность обновлять данные после их хранения. Чаще бывает быстрее очистить соответствующую партицию в таблице и вставить данные заново. Однако, последние версии колоночных БД реализуют SQL-операцию UPDATE за адекватное время.
В российских организациях стандартом является использование колоночной БД ClickHouse.
Преимущества ClickHouse:
1. Высокая производительность. ClickHouse – это колоночная база данных, которая оптимизирована для выполнения аналитических запросов с высокой скоростью. Она особенно эффективна для обработки больших объемов данных, как правило, денормализованных;
2. Масштабируемость. Поддерживая горизонтальное масштабирование и распределенную обработку данных, что позволяет обрабатывать петабайты данных;
3. Гибкость. Позволяет работать с неструктурированными и полуструктурированными данными, что расширяет возможности анализа по сравнению с традиционными OLAP-кубами;
4. Реальное время. Поддерживает обработку данных в реальном времени, что позволяет получать актуальные данные и оперативно реагировать на изменения.
ClickHouse способен решить практически все текущие задачи с финальными отчетами. В нём лежит широкая денормализованная детализированная таблица, а далее над ней идут группировки в разных срезах. Часто основная проблема – это собрать такую детализированную таблицу перед сохранением данных в ClickHouse. Причем процесс сборки должен происходить на уровне ниже, например внутри PostgreSQL / Greenplum.
Отступление про колоночные базы данных
Современные инструменты, поддерживающие технологию OLAP-кубов
Несмотря на то, что в целом использование OLAP-кубов считается устаревшей технологией, существует ряд инструментов, которые могут быть сейчас использованы для их разработки:
1. Microsoft SQL Server Analysis Services (SSAS) – мощный инструмент для создания и управления OLAP-кубами, предоставляющий возможности многомерного анализа. Пожалуй, и по сей день этот инструмент остается лидером в части технологий OLAP-кубов, особенно если говорить о последующем анализе данных с помощью сводных таблиц в MS Excel с использованием языка MDX. Microsoft продолжает развивать подходы к созданию кубов [19];
2. Oracle Essbase – OLAP-сервер, который позволяет создавать, управлять и анализировать многомерные базы данных. Также поддерживается подключение к MS Excel (с помощью расширения SmartView) и синтаксис MDX;
3. IBM Cognos – платформа для управления производительностью, включающая мощные возможности OLAP;
4. Pentaho Mondrian – OLAP-сервер с открытым исходным кодом, поддерживающий многомерные запросы и анализ. Этот вариант на данный момент является одним из наиболее работоспособных: можно настроить интеграцию и с MS-Excel, и с Clickhouse;
5. Apache Kylin – OLAP-движок с открытым исходным кодом, разработанный для работы с большими данными, обеспечивающий молниеносные многомерные запросы. Существует расширение kylin-MDX, которое загружает кубы в MS-Excel, но оно уже несколько лет не обновлялось.
Обратим внимание, что все перечисленные инструменты, за исключением первого, довольно специфичны: они сложны в поддержке, слабо документированы, по ним практически отсутствует русскоязычное сообщество.
В статье [10] описан практический опыт работы пользователей в привычном им интерфейсе MS-Excel (сводные таблицы) c Pentaho Mondrian [11] – точнее, его форком eMondrian [12]. В статье [13] даны пошаговые рекомендации – как настроить подключение. Следует отметить, что при таком подходе на плечи группы поддержки ложатся все типичные задачи, связанные с поддержкой и разворачиванием OLAP-куба.
OLAP-кубы в BI
В современных статьях чаще всего упоминание OLAP-кубов встречается в контексте BI-инструментов. Это неудивительно, потому что работа с BI во многом основана на решении задач, упомянутых в начале этого обзора – Rollup, Drill Down, Slice and Dice, Pivot. Подробно о причинах возникновения такой ситуации говорит Бенн Стэнсил, CTO компании ThoughtSpot, разрабатывающей одноименный BI-инструмент, способный конвертировать запрос на человеческом языке в запрос к данным. Интересно посмотреть его доклад «Возвращение OLAP-куба» [14], в котором кратко описывается история технологии и современная ситуация.
Чаще всего кубы в BI создаются в памяти кластера (In-Memory OLAP), либо используются гибридные подходы, в которых задействована и технология ROLAP.
Подробное описание работы OLAP-кубов в BI-инструментах на примере одного из лидеров отечественного рынка BI-инструментов представлено в статье [15]. Вывод, который сделан в этой статье, можно подытожить комментарием её автора: «если сравнивать производительность именно BI системы в целом, то Visiology на базе ViQube будет гораздо лучше работать, чем, например, Mondrian+ClickHouse – за счет правильной работы с кэшем, более эффективной трансляции многомерных запросов в табличные и т.п. А вот когда нужен кластер с шардированием — тут ROLAP с ClickHouse (или его коммерческой версией Arenadata QuickMarts) вне конкуренции».
Цитируя источник: «если в таблице фактов насчитывается более миллионов строк, объем данных превышает 100 Гбайт, либо база обновляется так часто, что временные затраты на импорт данных портят картину real-time аналитики (или всё сразу), то SQL Backend – то есть отказ от использования встроенного куба – становится хорошим решением, хотя и более сложным с точки зрения настройки и оптимизации производительности». Более того, нельзя исключить, что поддержка ViQube в новых версиях продукта останется лишь с целью сохранения обратной совместимости.
Другие отечественные BI-вендоры, заявляющие о построении кубов, – это Polymatica, Планета.Аналитика (на сайте вендора отсутствует подробная информация о технологии), Форсайт.Аналитическая платформа и её упрощенный вариант FlyBI, AlphaBI, Almaz BI, BiSphere (использует Mondrian OLAP) [18]. Однако, все эти кубы служат для внутреннего потребления данных BI-инструментом и не предоставляют интерфейсов для внешних подключений.
Среди зарубежных BI-вендоров, широко использующих возможности OLAP-кубов, следует отметить MicroStrategy и Pentaho BI.
MicroStrategy предоставляет платформу для построения и использования OLAP-кубов с мощными инструментами для анализа и отчетности. В MicroStrategy OLAP-кубы создаются с использованием многоуровневой архитектуры, где данные могут быть извлечены из различных источников, включая реляционные базы данных, и агрегированы в кубы для быстрого доступа и анализа. Пользователи могут создавать сложные отчеты и дашборды, используя интуитивно понятный интерфейс, а также выполнять интерактивный анализ данных через Drill down, Slice and Dice и другие OLAP-операции.
Pentaho BI предлагает набор инструментов для интеграции данных, отчетности и аналитики, включая возможности для построения OLAP-кубов. В Pentaho OLAP-кубы создаются с использованием Pentaho Analysis Services (Mondrian), который позволяет создавать многомерные модели данных. Пользователи могут подключаться к различным источникам данных, настраивать кубы с необходимыми измерениями и показателями, а затем использовать инструменты Pentaho для создания интерактивных отчетов и дашбордов. Pentaho также поддерживает интерактивный анализ данных, позволяя пользователям выполнять операции Drill down, Roll up и другие OLAP-операции.
Заключение
В современных хранилищах данных область задач, для решения которых требуются OLAP-кубы, существенно сократилась за последние 10-15 лет. Всё идет к тому, что эту технологию признают устаревшей. Ранее кубы выигрывали в производительности за счёт того, что фактически данные предагрегировались, и затраты на расчет куба компенсировались быстрым откликом BI-отчетов. Подобные задачи сейчас могут быть решены другими способами с использованием более мощных серверов и бóльших объемов оперативной памяти.
Ключевым инструментом для BI-отчетности в наши дни становятся колоночные базы данных, такие как ClickHouse. Они позволяют работать в режиме NRT (Near Real-Time), что недоступно для традиционных OLAP-кубов. Важно отметить, что для максимальной эффективности в ClickHouse рекомендуется использовать широкие денормализованные таблицы, учитывая особенности реализации SQL-операции JOIN.Тем не менее, в некоторых статьях описаны случаи успешного взаимодействия пользователей с OLAP-кубами, рассчитанными над БД ClickHouse (например, с помощью Pentaho Mondrian), что подтверждается и нашим опытом. Однако, это скорее исключение, подтверждающее правило – будущее аналитики за колоночными базами данных.
Источники
https://olap.com/learn-bi-olap/olap-bi-definitions/olap-cube/
https://www.holistics.io/blog/the-rise-and-fall-of-the-olap-cube/
https://www.yellowfinbi.com/blog/olap-cubes-outdated-bi-technology
https://heartbeat.comet.ml/from-olap-data-cubes-to-redshift-49c9675645cf
https://altinity.com/blog/accessing-clickhouse-from-excel-using-mondrian-rolap-engine
https://www.datacouncil.ai/talks/the-return-of-the-olap-cube
