Егор Попов, ведущий разработчик хранилищ данных, и Никита Целищев, инженер по данным сети ресторанов Rostic’s, рассказывают о влиянии проекта реорганизации платформы работы с данными и открывающихся возможностях для бизнеса. Проект компании номинирован на премию Data Award 2024.
Что собой представляла аналитическая платформа Rostic’s?
Аналитическая платформа российской сети ресторанов быстрого питания состоит из платформы данных и BI-отчетности. Изначально загрузка данных строилась согласно классическому ETL-подходу с использованием самописного Python-фреймворка на основе PySpark и SQL UDF (user-defined function) для загрузки слоев внутри хранилища данных. Интеграция с основными источниками данных была выстроена на прямых подключениях к базам данных и инкрементальной загрузке путем фильтрации SQL-запросов по дате. У такого подхода было много недостатков: высокая нагрузка на систему-источник тяжелыми «спам»-запросами, потери данных при изменении источника, отсутствие аудитных полей, указывающих на изменения, и пр. Реализация ETL имела ряд недостатков: каждый конвейер обработки данных требовалось разрабатывать вручную, под каждую загрузку создавая пользовательскую функцию, расставлять зависимости.
Что привело к необходимости построения новой платформы данных?
Наша компания — один из лидеров на рынке ресторанов быстрого обслуживания. В сети более 1,1 тыс. ресторанов в 74 регионах России, работающих под брендом Rostic’s и генерирующих большой объем данных. Правами на бренд владеет компания «Юнирест», выполняющая ряд бизнес-функций, включая финансовое планирование, маркетинг, HR, управление поставками и пр. Эффективность всех подобных процессов непосредственно зависит от качества данных. Кроме того, бизнес Rostic’s строится по модели франчайзинга — партнерам также необходимо предоставлять актуальную информацию о работе их ресторанов, отдавать им данные и служить для них «единым источником правды» о работе всего бизнеса. Мы предоставляем для ресторанов доступ к информации о бизнес-показателях в его точках присутствия. Такая аналитика помогает партнерам быстрее принимать управленческие решения, опираясь на BI-отчетность и аналитику данных. Важная функция платформы — наполнение и ведение озера данных, единого хранилища для всей компании, куда стекаются сведения из множества источников: реляционные базы данных, FTP и API, файлы, поступающие на почту. Для ускорения обработки данных и облегчения работы аналитиков требовалось пересмотреть архитектуру хранилища и перевести его на более современный стек технологий.
Егор Попов: «Новая платформа позволила существенно повысить прозрачность при работе с данными: каждое утро в телеграм-бот приходит отчетность о ходе ночной загрузки; высвечиваются идентификаторы записей, не прошедшие проверки, что помогает оперативно исправлять ошибки и обеспечивать качество данных» |
Во-первых, хранилище данных должно иметь архитектуру «звезда» и обладать полным слепком всех данных со всех источников. При этом загрузка должна осуществляться ежедневно, актуальность данных — не ранее T-1 (данные за предыдущий день), а данные должны обновляться в хранилище до 9:00 по московскому времени. Платформа должна включать в себя озеро данных для холодного хранения, хранилище детальных данных и витрины данных для быстрого доступа к очищенным данным. Важно было изменить ETL-подход на ELT. Иначе говоря, надо было сначала извлекать и загружать данные, а уже потом их преобразовывать. Кроме этого были необходимы инструменты управления качеством данных и обеспечения их наблюдаемости (Data Observability).
Как эти требования повлияли на стек технологий?
Обновленная платформа данных строится на Greenplum, а инструмент командной строки с открытым исходным кодом dbt отвечает за трансформацию данных. Apache Airflow — открытое программное обеспечение для создания, выполнения, мониторинга и оркестровки потоков операций по обработке данных — оркестрирует dbt, который загружает сами данные из S3, куда они попадают с помощью открытой платформы интеграции данных Airbyte.
Обработка начинается со сбора данных из всех источников и их отправки на платформу. Хранилище организовано на базе облачного объектного хранилища Amazon S3, в котором размещается озеро данных и исторические данные. Из S3 с помощью формата PXF удобно считывать данные Greenplum без дополнительных фреймворков. Кроме этого S3 позволяет оптимизировать затраты на обслуживание Greenplum. Все исторические данные, которые не нужны оперативно, попадают в S3, где происходит их «охлаждение».
От концепции пакетной загрузки мы перешли на CDC (Change Data Capture — «захват изменения данных») — механизм загрузки данных, при котором учитываются только измененные данные и нет необходимости отправлять прямые SQL-запросы в базы данных. Это позволило снизить нагрузку на систему-источник, заметно повысить производительность, сократить время разработки, сохранив всю историю в первозданном виде, имея полный слепок данных с источников.
Никита Целищев: «Переход на dbt с самописного ETL-фреймворка себя оправдал: аналитики теперь сами создают объекты, что позволило вдвое сократить трудозатраты на постановку объекта на регламент, не привлекая разработчиков» |
После того как данные из S3 поступили в «сырой» слой, необходимо построить детальный слой витрин. Классический подход к этой трансформации — самописный ETL-фреймворк на Python, оперирующий YML-файлами: обрабатывает их и загружает в хранилище. Для загрузки слоев хранилища многое необходимо было делать вручную — дата-аналитик не мог этого сделать без опыта работы с Airflow. Инструмент dbt позволил оперировать знакомым всем аналитикам языком SQL, а зависимости и загрузка данных были реализованы автоматически.
Переход на dbt с самописного ETL-фреймворка себя полностью оправдал — аналитики стали сами создавать объекты, в два раза сократив трудозатраты на постановку объекта на регламент и исключив разработчиков из построения детального слоя витрин. Теперь аналитики быстрее создают модели, чем это делал разработчик.
Для построения быстрых слоев хранилища в платформе используется Greenplum, а СУБД ClickHouse используется как система обработки источников для бизнес-аналитики, подготовки данных для отчетности и др. Часто противопоставляют Greenplum и Clickhouse, но мы их используем в связке. Оба сервиса управляются с помощью Yandex Cloud, однако самостоятельно поддерживать два кластера — дорого, а в Yandex Cloud это выполняется автоматически, что существенно ускорило обработку.
Почему было выбрано облако Yandex Cloud?
Компания Yandex предлагает множество управляемых сервисов, что помогает снизить нагрузку на нашу команду — все рутинные задачи выполняет облачный провайдер, в частности, в Managed Service for Greenplum и ClickHouse, отвечая за управление кластерами и мониторинг работоспособности сервисов. Кластерами можно управлять через интерфейс, используя множество метрик, логов, уведомлений, дашбордов, что помогает обеспечивать оперативный мониторинг работы хранилища. Кроме того, мы используем возможности резервного копирования — есть возможность восстановить кластер Greenplum из резервной копии за заданный период времени.
Что сегодня собой представляет платформа работы с данными?
В хранилище аккумулируются и обрабатываются данные из 12 источников, в том числе из программы R_Keeper для предприятий общественного питания, «1С», банковских приложений, сервисов заказа быстрой доставки, таких как «Яндекс Еда», сервиса для треккинга и аналитики мобильных приложений AppMetrica, платформы для автоматизации маркетинга Mindbox и других.
Для организации хранилища данных используются ClickHouse и Greenplum, отечественная система бизнес-аналитики «Форсайт», Python Airflow DBT в качестве оркестратора пополнения данных. Все инструменты развернуты на платформе Yandex Cloud в Kubernetes. Классическая «тяжелая» ETL-загрузка происходит раз в сутки, ночью. Днем перегружаются небольшие объекты, требующие оперативной аналитики. Managed Kubernetes как ETL-платформа в Yandex Cloud позволяет разграничить ресурсы и автоматически масштабировать кластер ночью, а днем не платить за него. Имеются удобные средства мониторинга и понятные средства настройки (рисунок).
Платформа данных Rostic’s |
Что, на ваш взгляд, удалось особенно удачно?
В первую очередь это автоматизация трансформации данных в слоях хранилища с помощью инструмента dbt и автоматически генерируемая документация объектов хранилища. Кроме того, появился процесс отслеживания перемещения данных (Data Lineage), позволяющий визуализировать связи между информационными активами и проследить происхождение и историю потоков данных. Реализован механизм загрузки данных CDC как полноценная замена ETL-процесса — сейчас в процессе загрузки выполняется автоматическое тестирование данных на их качество. Благодаря использованию dbt разработку всех объектов хранилища теперь можно доверить аналитикам, что существенно снижает трудозатраты и сокращает время.
Каких значимых результатов удалось достичь?
Cущественно повысилась прозрачность в работе с данными. Каждое утро в телеграм-бот приходит отчетность о том, как прошла ночная загрузка. Высвечиваются идентификаторы записей, которые не прошли проверки — например, обнаружилось дублирование по каким-то идентификаторам, что помогает оперативно исправлять ошибки и следить за качеством данных.
Большинство отчетов для бизнеса формируются на основании данных, загруженных в систему. У аналитиков появился инструмент самообслуживания, помогающий бизнес-специалистам самим проверять различные гипотезы и создавать новые срезы данных без привлечения разработчиков. Благодаря реализации проекта ускорилось внедрение новых технологий в помощь бизнесу, например, в два раза быстрее стали готовится аналитические отчеты по продажам позиций из меню.
Сегодня платформа помогает оперативно реагировать на изменение ключевых показателей, видеть отклонения и аномалии в данных, принимать взвешенные решения на основании достоверных данных и более гибко управлять бизнесом, оперативно реагируя на изменения рынка.
Что ожидается в перспективе?
Платформа работает с 2022 года, став неотъемлемой частью бизнеса компании. У нас большие планы по развитию. Например, дальнейшее развитие self-service BI — концепции, при которой бизнес может сам строить аналитику по необходимым параметрам. Мы планируем использовать данные для их использования в системах искусственного интеллекта, в частности — внедрить прогнозирование спроса и предложения, развивать персонализированные сервисы для гостей.
Продолжится уход от пакетной в сторону потоковой загрузки, что позволит еще больше сэкономить время на обработку данных. Будет внедрен полноценный каталог данных. А главное, в компании формируется культура работы с данными и принятия решений на основе актуальных достоверных данных.
Николай Смирнов (nsmirnov@osp.ru) — независимый автор (Москва).