Как говорит нам история, в 1996 году Microsoft приобретает фирму занимающуюся OLAP-технологиями, в 1997 году появляется первая спецификация языка многомерных запросов MDX, а в 1998 году OLAP Services (SSAS) становятся доступны вместе с тогда новой SQL Server 7.0
То были временя одноядерных процессоров, неторопливо шуршащих жёстких дисков, а серверная оперативка едва насчитывала несколько сотен мегабайт. Даже простой по сегодняшним меркам запрос с группировкой пары миллионов строк, мог быть непосилен для тогдашних серверов.
Основная идея кубов заключалась в долгом ночном процессинге, когда по основным разрезам тех же продаж по товарам, магазинам, календарным дням и тд., рассчитывались и сохранялись агрегаты. Медленные компьютеры той эпохи могли часиков за 8 посчитать основные агрегаты с нужной степенью гранулярности, чтобы потом во время рабочего дня аналитик мог быстро крутить сводными таблицами.
Гениальным ходом Microsoft было сделать бесшовную интеграцию с экселем, который мог использовать OLAP-куб в качестве источника для сводных таблиц в разных разрезах. Люди любят эксель, не так ли?
Именно эта интеграция с экселем и является той причиной, почему от использования SSAS в некоторых компаниях так и не могут уйти. Какие-нибудь серьёзные менеджеры так привыкли получать отчёты сразу в экселе, что им не нужен никакой модный BI. Технология для консерваторов, так мягко скажем.
Но как насчёт того, чтобы самому писать многомерные запросы к кубу? Кстати, один из ключевых авторов языка MDX родился... в Ленинграде! Сейчас он известен как Mosha Pasumansky. У него даже есть личный ютуб-канал, где он исполняет с гитарой песни на русском языке... Но мне показалось, что канал слишком личный, чтобы прикладывать ссылку на него.
Почему MDX не взлетел? Ну потому что в отличии от супер-очевидного SQL, когда мы выбираем сразу колонки к выводу, то MDX предлагал выбрать сетку, где мы раскладываем данные по колонкам и строкам.
Вот пример кода с сайта Microsoft, который раскладывает меры сумм продаж и налогов по двум колонкам, а календарные годы по строкам:
SELECT
{ [Measures].[Sales Amount],
[Measures].[Tax Amount] } ON COLUMNS,
{ [Date].[Fiscal].[Fiscal Year].&[2002],
[Date].[Fiscal].[Fiscal Year].&[2003] } ON ROWS
FROM [Adventure Works]
WHERE ( [Sales Territory].[Southwest] )
Вроде понятно, что должен быть результат следующего вида, но запрос выше получился слишком громоздким для восприятия.
| Fiscal Year | Sales Amount | Tax Amount |
| ----------- | ------------ | ---------- |
| 2002 | 1,234,567.00 | 123,456.00 |
| 2003 | 1,345,678.00 | 134,567.00 |
Вы можете сами подумать, как бы выглядел аналогичный SQL-запрос и понять, что он был бы более читаем и прост в написании.
Таким образом, по причине громоздкости MDX не стал популярным в аналитике инструментом, и написание логики на MDX стало уделом немногих энтузиастов, за которыми некоторым компаниям приходится охотиться, если им не повезло остаться с важным легаси, логика которого завязана на MDX и кубы в целом. Один раз эйчар одного банка даже спрашивала меня, что это за технология такая SSAS, что она не может никак найти ни одного кандидата.
По итогу движок кубов эволюционировал от долгого ночного процессинга MOLAP (Multidimensional OLAP) к ROLAP (Relational OLAP), который уже под капотом джойнил в нужный момент таблицы, как это делают привычные нам реляционные СУБД. Сейчас движок OLAP-кубов в ROLAP исполнении продолжает жить в сердце PowerBI, поэтому если вы пользуетесь PowerBI, то где-то у вас под капотом живёт OLAP-куб родом ещё из 90х.