Опыт миграции аналитики для ритейла Retail Analytics с MS SSAS на Alpha OLAP

В этой статье рассказываем о реальном опыте переноса решения 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»

Чтобы посчитать упущенный оборот, нужно:

1. Взять ежедневные остатки по каждому SKU в каждом магазине;

2. Определить дни, где остаток = 0;

3. Взять скорость продаж SKU в конкретном магазине;

4. Посчитать количество пропущенных продаж в днях 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 воспроизводимы, без потери производительности и привычных сценариев для аналитиков.