SSAS Tabular вместо OLAP-куба: xVelocity жмёт 50 млн строк в 2 ГБ

Задача пришла от клиента с формулировкой «хотим красивые отчёты и чтобы не ждать». За этим стоял конкретный боль-пойнт: OLAP-куб на Analysis Services 2008 R2, который строился ночью, к утру иногда не успевал, а запросы по нему через Excel жили своей жизнью - то летели, то думали минуты три без видимой причины.

Мы занимались проектами по хранилищам данных и BI уже не первый год, поэтому первый разговор с архитектором решения занял минут двадцать. Вывод был простой: куб переусложнён, измерений много, партиции настроены по принципу «работает - не трогай», а данных за пять лет накопилось прилично. Дальше тащить это на старом движке смысла не было.

Почему Tabular, а не чинить куб. SQL Server 2012 SP1 вышел в конце прошлого года, но SP1 добавил к Tabular-модели несколько вещей, которые закрывали наши вопросы: стала нормально работать DirectQuery для отдельных сценариев, улучшилась обработка больших таблиц через xVelocity (колоночный in-memory движок, он же VertiPaq), подтянули интеграцию с Power View в SharePoint. Многомерная модель (классические кубы) никуда не делась, она просто оказалась не нужна для этого проекта - у клиента не было сложных many-to-many, нет полуаддитивных мер в экзотическом виде, зато есть большая таблица продаж и десяток измерений.

Что показало нагрузочное. Загрузили в Tabular-модель факт-таблицу около 50 млн строк - история транзакций за пять лет плюс несколько справочников. После обработки модель заняла чуть больше 2 ГБ в памяти. Это не магия - xVelocity применяет словарное кодирование и RLE-сжатие по столбцам, и на транзакционных данных с небольшим числом уникальных значений в измерениях это работает очень хорошо. Тот же объём в реляционном виде занимал бы на порядок больше.

Запросы через Excel Power Pivot и через Power View в SharePoint - в обоих случаях ответ на типовой срез «продажи по регионам за квартал с детализацией по менеджерам» укладывался в секунды. Не «субъективно быстро», а реально 1-3 секунды на сложные агрегации. Руководство попросило показать ещё раз - просто чтобы убедиться, что это не кеш.

Где пришлось повозиться. DAX после MDX - отдельный разговор. Разработчики, которые умеют писать MDX, не всегда интуитивно берут DAX. Синтаксис другой, логика вычислений контекстно зависимая, и первые попытки написать скользящий итог или year-to-date через CALCULATE с DATESINPERIOD выглядели как занятие медитацией. Пару дней ушло на то, чтобы разобраться с контекстом строки и контекстом фильтра - это принципиально важная вещь в Tabular, без понимания которой формулы будут давать внешне правильные, но неверные числа.

Ещё один момент - права доступа. В Tabular row-level security настраивается через DAX-фильтры на таблицы, и это немного непривычно после кубового подхода с ролями и измерениями. Настроили, проверили на тестовом пользователе, убедились что региональный менеджер видит только свой регион.

Обработка и расписание. Full process на всю модель занимает около 40 минут. Инкрементальная обработка партиции за текущий месяц - 5-7 минут. Это уже другой разговор по сравнению с ночным кубом, который успевал к утру с запасом в полчаса. Настроили SQL Agent job на ночную полную обработку и часовое инкрементальное обновление в рабочее время.

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

Мы не строили иллюзий насчёт того, что Tabular закрывает вообще всё. Для сложной финансовой консолидации с many-to-many и кастомными агрегациями многомерный куб остаётся сильным инструментом. Но для большинства задач операционной и коммерческой аналитики Tabular оказался быстрее в разработке, проще в поддержке и ощутимо быстрее для конечного пользователя.

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