Федеральная сеть дискаунтеров: автоматизация операционной отчетности и DWH, которое помогает объединить 15 ТБ данных из ERP и кассовых систем для 400 магазинов

Кратко о проекте

Клиент

FMCG-сеть дискаунтеров с 400+ магазинами

Проблема

Разноформатные данные низкого качества, низкая производительность аналитики и скорость сбора отчетности

Решение

Внедрение высокопроизводительного корпоративного хранилища данных DWH, которое стало единой точкой правды для дальнейшей аналитики

Срок внедрения

6 месяцев

Результат

1. Простой доступ к данным для всех заинтересованных лиц
2. Снижение нагрузки на операционные системы
3. Повышение производительности аналитических запросов
4. Обеспечение ретроспективного анализа на основе данных за 5 лет
5. Повышение качества данных и доверия к ним

О клиенте

Федеральная сеть из 400 + жестких дискаунтеров — магазинов самообслуживания с максимально простым оформлением торгового зала, представленных в 11 регионах России.

Задача и боль клиента

Бизнес клиента активно развивается: еще к началу 2023 года FMCG-сеть включала около 170 торговых точек, а к 2025 году были открыты уже более 400 магазинов.

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

Жесткий дискаунтер с прямыми поставками — это сложный логистический и торговый формат, где любые просчеты в прогнозах, планировании, запасах или ассортименте ведут к потере прибыли.

Динамический рост бизнеса и формат торговли усилили важность быстрой и точной аналитики, регулярной отчетности и прозрачности данных.

Для формирования отчетности по продажам, логистике, складскому учету компания использовала выгрузки из ERP-системы и кассовой системы.

При сборе данных для отчетности сотрудники компании сталкивались с трудностями:

1. Данные для анализа были разноформатными, специалисты тратили много времени на фильтрацию, выгрузки и связывание данных из систем-источников
2. Перед составлением отчетов данные приходилось перепроверять, так как их качество было низким для аналитики
3. Из-за большого объема данных нагрузка на текущую инфраструктуру была очень высокой, годовой отчет выгружался в течение нескольких десятков минут
4. Производительность аналитических запросов напрямую к системам-источникам была низкой

В связи этими факторами руководство сети приняло решение о построении корпоративного хранилища данных DWH, которое стало бы единым, высокопроизводительным и надежным источником данных для аналитики.

Решение

Для реализации проекта DWH клиент обратился к команде Qlever Solutions.

Источниками данных для корпоративного хранилища выступили:

• ERP-система на базе ​Oracle Symphony G.O.L.D — платформы для управления розничными операциями в продуктовом ритейле. Система стоит из трех схем-источников:

1. G.O.L.D. Central — основная система управления ресурсами предприятия, содержащая данные о розничных и оптовых продажах, заказах клиентов и поставщиков, возвратах, инвентаризации, остатках товаров, прайс-листах и т.д.
2. G.O.L.D. Stock — управление складскими операциями и запасами, маршрутами поставок/отгрузок и т.д.
3. G.O.L.D. GWR — модуль, содержащий информацию о недельных прогнозах продаж и автоматически сформированные суточные предложения по заказам

• Кассовая система Set Retail на PostgreSQL, включающая операционные данные по дню (смены/сессии/чеки/позиции), программам лояльности, ценникам и сотрудникам.

В России Oracle Symphony G.O.L.D используется крайне редко, у решения нет локализации и поддержки. Одним из вызовов будущего проекта стала документация на французском языке, потребовавшая перевода и тщательного изучения для грамотной интеграции.

Кроме того, источники данных генерировали значительные объемы информации — от 20 000 до 30 000 записей в минуту по 140 таблицам, что требовало от будущего хранилища высокой устойчивости без потери производительности.

На стадии обязательного предпроектного обследования эксперты Qlever выявили ключевые требования к системе:

1. Клиент использовал коммерческие продукты Oracle и хотел снизить расходы на КХД за счет open-source стека
2. Некоторые отчеты необходимо было реализовать в режиме live, для этого данные из Oracle должны появляться в витрине на слое детальных данных Data Detail Store (DDS) в течение 2 минут
3. Требовалось обеспечить историчность данных для некоторых таблиц Oracle без первичного ключа, так как стояла проблема обновления и определения актуальных записей в этих таблицах
4. Для синхронизации данных клиентом была выбрана и настроена шина данных Apache Kafka, одним из требований проекта стало использование инструмента при построении DWH

В процессе сбора требований были выделены следующие группы ключевых пользователей и потребности в отчетности:

1. Топ-менеджемент — контроль ключевых показателей, анализ общей динамики продаж, рентабельности бизнеса
2. Финансовый отдел — анализ маржинальности и окупаемости, балансовых остатков
3. Отдел продаж и маркетинга — анализ продаж по точкам и сегментам, управление акциями и скидками, изучение покупательской динамики (поведения), возвратов
4. Склад и логистика — управление запасами, анализ уровня остатков, оптимизация процессов пополнения и логистики, контроль скорости доставки
5. Закупочный отдел — анализ потребностей в товарах, работы с поставщиками, управление ассортиментом, оптимизация заказов
6. Менеджеры розничных точек и по регионам — оценка эффективности работы конкретной точки, оптимизация управления запасами, реализация локальных маркетинговых кампаний
7. Аналитики данных — непосредственная работа со слоями данных в DWH, подготовка детальных аналитических отчетов, прогнозирование продаж, выявление тенденций и аномалий

Для достижения высокой скорости передачи данных из источников был выбран инструмент Debezium, который читал данные из логов Oracle и Postgres, отправлял сообщения в Kafka и записывал их в Greenplum.

Но Debezium не мог справиться с 5000 сообщений за 1–2 секунды на 1 таблицу, и ситуация потребовала разработки альтернативного решения — собственного консюмера на базе Kafka.

В разработанном решении Airflow инициирует выполнение Python-скрипта, который сериализует сообщения из Kafka в бинарную строку и пишет их во внешние External web tables. Такой механизм позволяет повысить производительность хранилища за счет распределения задач загрузки между сегментами Greenplum.

Благодаря консюмеру данные на DDS появляются уже через 30–40 секунд после формирования в источнике.

Для реализации первичного копирования и обеспечения репликации с версионностью была применена технология PXF (Platform Extension Framework), которая не нагружает базы источников и позволяет гарантировать целостность данных — в случае сбоя одной из сессий повторяется загрузка тех же данных.

Для таблиц без ключа из Oracle необходимо было реализовать полную репликацию с версионностью, чтобы отслеживать истории изменений напрямую в Greenplum.

В таких таблицах присутствуют несколько одинаковых строк заказов с одним набором атрибутов — заказ, палета, товар, но с разной себестоимостью. При этом товары могут быть указаны как одной строкой по пять штук, так и пятью строками по одной штуке в каждой.

Первичное обновление данных загружает всю комбинацию заказ-палета в Greenplum. В дальнейшем при обновлении любой из строк заказа в ERP-системе заказ еще раз полностью выгружается в хранилище через PXF с новой датой обновления, а старые строки отмечаются как неактивные.

В некоторых таблицах источников также присутствовали шестизначные ключи, которые переполнялись и сбрасывались в ноль примерно раз в 2–3 месяца. Для сохранения данных специалисты Qlever реализовали обогащение ключей во всех таблицах, где эти ключи используются.

Помимо этого, от клиента поступила дополнительная задача сохранения в DWH истории изменений справочников, включая удаленные записи.

Для реализации всех доработок в процессе проекта несколько раз был пересмотрен сайзинг и произведено расширение конфигурации узлов DWH на уровень, достаточный для текущего объема данных (15 ТБ), полной нагрузки по репликации всех таблиц и дальнейшего масштабирования.

При такой высокой нагрузке на хранилище важно предупредить возможные риски потери данных и разработать процедуры и стратегии для восстановления инфраструктуры DWH в случае аварий.

Для этого специалисты Qlever составили и протестировали Disaster recovery plan — план аварийного восстановления DWH. В процессе разработки Плана были запущены и отработаны разнообразные сценарии сбоев и восстановление каждого компонента хранилища.

Полученные результаты

В результате работы команды Qlever Solutions клиент получил настроенное корпоративное хранилище данных, которое стало единой точкой правды для дальнейшей аналитики операционной деятельности и принятия эффективных решений.Реализация DWH позволила достигнуть ключевые цели компании в области управления данными:

1. Построить модель данных, охватывающую все требования к формам отчетности и расчету ключевых показателей
2. Упростить доступ к информации для всех заинтересованных лиц компании, от топ-менеджмента до отделов продаж и закупок
3. Снизить нагрузку на операционные системы компании и повысить производительность аналитических запросов даже при большом объеме данных — более 15ТБ
4. Обеспечить ретроспективный анализ благодаря сохранению исторических данных за последние 5 лет
5. Повысить общее качество данных для принятия эффективных управленческих решений

DWH как один из ключевых элементов цифровой трансформации бизнеса позволит не только оптимизировать процессы анализа, но и повысить эффективность всех операционных процессов сети дискаунтеров: продаж и маркетинга, закупок и логистики, складских и финансовых процессов.

Используемые технологии

Debezium, Kafka, Arenadata DB (Greenplum), PXF, DBT, Python, Airflow, собственный Kafka консюмер, Open Metadata, Oracle Symphony G.O.L.D., PostgreSQL

Функциональные области

Продажи, Маркетинг, Запасы, Логистика, Финансы, Топ-менеджмент

Данные и отчеты работают против вас?

Свяжитесь с нами. Наведем порядок в данных, спроектируем и внедрим DWH в соответствии с вашими аналитическими задачами