В этой статье рассказываем о реальном опыте переноса решения Retail Analytics (платформа аналитики для ритейла от Lasmart) с Microsoft SQL Server Analysis Services (SSAS Multidimensional) на Alpha OLAP, входящий в состав российской аналитической платформы Alpha BI.
Привет, Хабр! Меня зовут Лилиана Муллаярова, я маркетолог продукта Alpha BI. Статью готовили с командой продукта Alpha BI и командой нашего партнёра Lasmart, который и проводил миграцию Retail Analytics. Мы сравним, как система работала на MS SSAS, а как на Alpha OLAP, где получили прирост производительности, а где пришлось менять подходы. И главное: стоит ли игра свеч, если вы сегодня выбираете между «остаться на SSAS» или «мигрировать на российский OLAP».
Расскажем:
как выглядела архитектура «до» и «после»;
какие показатели переехали без боли, а какие заставили попотеть;
где Alpha OLAP оказался быстрее SSAS, а где наоборот.
Проект миграции выполнялся на довольно «боевом» датасете: чековые данные, товародвижения и остатки за 3 года, 200 аптек.
Если вы сейчас сомневаетесь, переходить ли с SSAS, этот материал, возможно, сэкономит вам несколько недель анализа.
Почему OLAP до сих пор жив (и ещё долго будет)
OLAP по‑прежнему закрывает задачи, которые плохо решаются чистым SQL или BI‑визуализацией:
сложные KPI и цепочки расчётов;
сценарный и факторный анализ;
аналитика, где критична гибкость: нужно быстро собирать разные срезы «на лету» и работать с понятной, прозрачной моделью данных;
расчёты, чувствительные к иерархиям и временным срезам.
Хорошая метафора здесь всё ещё работает: OLAP — это двигатель аналитики, BI — руль и приборная панель. То есть сравнивать их напрямую некорректно.
Что такое Alpha OLAP и зачем он появился
Alpha OLAP — российский OLAP‑сервер, который работает с многомерными кубами без ограничений по размеру, поддерживает MDX, XMLA и может работать поверх реляционных, колоночных и MPP‑СУБД (PostgreSQL, ClickHouse, Greenplum и др.). Он может использоваться как часть платформы Alpha BI или разворачиваться отдельно, только как OLAP‑движок.
Сейчас на рынке BI “красный океан”: десятки новых решений, десятки направлений. Но сегмент многомерных вычислений — это та самая ниша, где в России до недавнего времени не было полноценного импортонезависимого игрока. Именно туда команда Alpha BI и пошла: закрывать «больные места» SSAS и SAP BW для российских заказчиков.
Ключевые особенности, важные именно в контексте миграции с SSAS:
Поддержка MDX
Совместимость с классическим MDX.
Поддержка дополнительных функций (Divide, Nonempty, ExceptAncestors и др.).
Возможность переносить расчёты постепенно, без тотального переписывания логики.
Поддержка XMLA
Подключение Excel и других BI‑клиентов так же, как к SSAS.
Для пользователей сценарий работы визуально не меняется.
Работа в live‑режиме поверх разных СУБД
PostgreSQL / Oracle
ClickHouse
Greenplum
ADQM / ADB / ADPG
Производительность и масштабирование
Горизонтальное масштабирование кубов.
Вертикальная мультисерверность.
Оптимизированный ROLAP (вычисления по максимуму выполняются на стороне СУБД, а результаты кэшируются, чтобы не пересчитывать одни и те же запросы повторно).
Импортонезависимость
Поддержка отечественных ОС и СУБД.
Возможность работы в закрытых контурах.
Отсутствие санкционных рисков.
Как проходила миграция аналитики для ритейла Retail Analytics
1. Ключевое требование: «оставьте пользователям всё как есть».
И это классика для миграций. Пользователи 50–90% времени проводили в Excel через OLAP‑подключение.
Поэтому при миграции было принципиально важно:
сохранить Excel как основной инструмент;
не ломать пользовательские отчёты;
не менять структуру кубов без необходимости.
Такой подход оказался оправданным: для большинства аналитиков переход прошёл практически незаметно.
«С точки зрения пользователей переход оказался достаточно комфортным: основные изменения коснулись интерфейса работы в Excel и технических особенностей подключения. Например, в Alpha OLAP показатели отображаются единым списком без привычной группировки по папкам, а для подключения требуется единоразовая установка плагина», — отметила Анастасия Третьякова, руководитель группы разработки BI‑направления Lasmart.
2. Архитектура «до»
Типовая схема на Microsoft‑стеке: DWH → SSAS Multidimensional → Excel / Reporting / Dashboards.
С визуализацией проблем нет — инструментов на рынке много. Но найти замену SSAS MDX + Excel… задачка нетривиальная. И в итоге Alpha OLAP подошёл лучше других.
3. Какие данные и модели переносили
Проект включал полный контур аналитики ритейла:
продажи;
маркетинг;
логистика и запасы;
закупки;
контроллинг.
Всего:
200–300 аналитических разрезов;
~400 показателей.
Несмотря на масштаб проекта, значительная часть расчётной логики переносилась достаточно предсказуемо.
«Приятно удивил высокий уровень совместимости MDX SSAS и Alpha OLAP. Такие расчёты, как ABC и LFL, при переносе в других системах часто вызывали сложности, тогда как в Alpha OLAP их удалось реализовать с минимальными корректировками вычисляемых показателей», — поделилась Евгения Аверкина, руководитель группы разработки BI‑направления Lasmart.
80% показателей — без сюрпризов:
маржа;
наценка;
средний чек;
оборачиваемость;
продажи по любым разрезам.
10–20% — «тяжёлая артиллерия»
Именно здесь началась настоящая инженерная работа:
ежедневные остатки на 150 млн строк;
прогнозирование спроса;
расчёт out‑of‑stock;
ABC/XYZ‑анализ;
показатели стабильности продаж;
RFM;
кросс‑продажи;
показатели по срокам годности;
анализ дефектуры.
Однако часть трудоёмких задач была связана не столько с самими расчётами, сколько с различиями в устройстве многомерной модели.
«При этом в процессе миграции выявились и архитектурные особенности, которые важно учитывать заранее. В SSAS измерение строится на наборе атрибутов, а иерархии формируются на их основе. В Alpha OLAP каждый атрибут по умолчанию является отдельной иерархией. Поэтому при создании иерархий вроде „Год‑Месяц‑Дата“ или „Год‑Квартал‑Месяц‑Дата“ каждый уровень становится самостоятельной сущностью, что необходимо учитывать в формулах со ссылками на периоды», — отметила Евгения Аверкина, руководитель группы разработки BI‑направления Lasmart.
Реальный пример: алгоритм расчёта «потерь out‑of‑stock»
Чтобы посчитать упущенный оборот, нужно:
Взять ежедневные остатки по каждому SKU в каждом магазине;
Определить дни, где остаток = 0;
Взять скорость продаж SKU в конкретном магазине;
Посчитать количество пропущенных продаж в днях out‑of‑stock.
На SSAS это реализовано через pre‑aggregations и вычисления.
В Alpha OLAP пришлось:
оптимизировать витрины хранения остатков,
вынести часть логики в СУБД,
адаптировать MDX.
Итог: после доработки логики производительность стала сопоставимой, а на ряде запросов — выше, чем в SSAS.
Самое интересное: какие показатели «переехали» легко, а какие — тяжело
Переехали легко
продажи по любым разрезам (SKU, категория, бренд, аптека, период);
средний чек;
глубина чека;
доходность;
доля продаж по программам лояльности (дисконтным картам).
Потребовали переработки
ежедневные остатки (из‑за объёма в сотни млн строк);
cross‑selling;
прогнозирование;
out‑of‑stock;
расчёты, завязанные на сложные иерархии.
Но в итоге всё, что было на SSAS, мы смогли реализовать на Alpha OLAP без потери производительности.
Что получили по итогам миграции
1. Инфраструктура и стек
Данные
Чеки, товародвижения, остатки
200 аптек, 12 тыс. SKU
3 года
~150 млн строк
2. Оптимизации, которые дали эффект
PostgreSQL
создание кластерных и покрывающих индексов — прирост производительности около 30%;
настройка параметров PostgreSQL — дополнительный прирост порядка 10%.
OLAP
использование пустой меры по умолчанию для сокращения времени отклика при работе с Excel;
разработка механики прогрева кэша.
3. Производительность: цифры, а не ощущения
Да, на холодном кэше SSAS в ряде сценариев быстрее. Но:
время не превышает минуты;
после прогрева кэша разницы нет;
прогрев можно автоматизировать.
4. Функциональные различия
По опыту аналитиков, поиск по показателям используется чаще, чем папки.
А веб‑интерфейс Alpha BI в ряде сценариев оказался бонусом.
5. Итоги миграции
80–90% пользовательских сценариев без изменений
Excel‑отчёты продолжают работать
Простые запросы: быстрее или так же
Сложные: требуют настройки, но укладываются в SLA
Полная импортонезависимость
Срок миграции всего контура ~3,5 человеко‑месяца
По итогам проекта команда сформулировала несколько практических рекомендаций, которые сегодня учитывает уже на этапе проектирования новых аналитических систем.
«При проектировании аналитической системы важно заранее учитывать особенности работы с измерениями: в Alpha OLAP каждый атрибут измерения фактически является отдельной иерархией. На производительность системы также заметно влияет настройка модели — например, существенный прирост скорости даёт добавление пустой меры по умолчанию. В качестве источника данных при этом оптимальнее использовать внешнее подключение», — рассказала Евгения Аверкина, руководитель группы разработки BI‑направления Lasmart.
Выводы: стоит ли мигрировать?
Если у вас:
SSAS Multidimensional;
Excel — основной инструмент аналитики;
витрины на 100+ млн строк;
требования по импортозамещению,
то Alpha OLAP реальная и рабочая альтернатива SSAS, а не «демо‑замена».
Да, миграция потребует инженерной работы. Полного переноса «один в один» здесь не будет, так как системы по‑разному реализуют одни и те же задачи. Поэтому основная цель — адаптировать логику так, чтобы для конечного пользователя эти различия остались незаметными. Все ключевые механики SSAS воспроизводимы, без потери производительности и привычных сценариев для аналитиков.
