Бренд всероссийских государственных лотерей «Национальная лотерея» реализует проект по созданию современного хранилища данных и внедрению практик Data Governance. Его основной целью стало объединение разрозненных данных в единую платформу и обеспечение высокой производительности аналитических процессов. О реализации проекта рассказывает Евгений Жилов, руководитель департамента аналитики и управления данными «Национальной лотереи» и номинант на премию Data Award.

- В каком состоянии подошла компания к реализации проекта? Что собой представляла инфраструктура для работы с данными?

На начальном этапе это была небольшая база данных в неоптимизированном хранилище ClickHouse и несколько источников данных для нее. У нее было четыре пользователя, при этом количество цепочек задач (DAG) в Airflow было уже более 100, а объектов — более 130.

Инфраструктура представляла собой три отдельных виртуальных сервера в гипервизоре VMware: Airflow, ClickHouse и один на Windows. На них работали ETL-процессы по загрузке и обработке данных с нескольких источников Postgres и API, реализованные на Python. Сервер ClickHouse был раздут до 96 ядер, 400 Гбайт оперативной памяти и 4,5 Тбайт SDD.

- В чем заключались основные проблемы?

Отсутствие единого хранилища усложняло доступ к данным, а разрозненные методики расчетов приводили к ошибкам и недочетам в отчетности. Благодаря переходу к архитектуре Data Lakehouse и полномасштабному внедрению каталога данных мы надеялись сделать процессы сбора, хранения и анализа информации гораздо прозрачнее и эффективнее. Это должно было повысить стабильность получения данных, качество хранения и накопления, а также сократить время их получения дата-аналитиками и бизнесом.

Несмотря на большое количество качественных ресурсов в инфраструктуре, процессы ETL работали нестабильно, медленно, а данные могли быть недоступны для бизнеса в течение рабочего дня по два-четыре часа. Команда не успевала создавать новые и обслуживать имеющиеся ETL-процессы, а также необходимую аналитическую отчетность в том количестве, которое требовалось бизнесу. Отсутствовала какая-либо стандартизация хранилища данных, процессов ETL, написания кода, отчетности и методик расчетов. Не было возможности безопасной разработки и тестирования в отдельных средах. Отказоустойчивость была доступна только на уровне гипервизора. Ролевая модель доступов к данным и сервисам была организована локально в каждом сервисе, процессов CI/CD не было вовсе. Отсутствовал мониторинг ETL-процессов и качества данных.

- Почему это стало критичным для «Национальной лотереи»?

Компания приняла решение переходить на data-driven подход. Для того чтобы его реализовать, нужно было организовать и работу самого хранилища, и загрузку данных, и обработку, и, самое главное, скорость и доступность этих данных, не говоря уже о качестве. Data-driven подход подразумевает развитие как самой команды аналитики, так и практик self-service, внедрение BI. Та инфраструктура, которая была создана на период начала проекта, не соответствовала даже базовым нормам для того, чтобы масштабироваться. Основной проблемой перехода к data-driven была в том числе скорость доставки данных и стабильность работы системы, в которой их можно было получать.

По доверию к данным тоже были вопросы, насколько они актуальны и консистентны. Их требовалось решить в том числе с помощью средств мониторинга, которые рассказывают о качестве и в виде уведомлений, и в виде дашбордов.

- Из-за чего выбрана именно концепция Data Lakehouse?

Эта концепция выбиралась, исходя из результатов исследования бизнеса и бизнес-подходов, применяемых в компании как в моменте, так и с точки зрения стратегического развития. Мы ориентировались на количество источников и их объемы. На этапе становления компании источников было три-четыре, а сейчас их уже 20, и число будет расти. Объем информации, накапливаемый в этих источниках, исчисляется миллионами записей в день. Очевидно, что все это загружать в хранилище — это просто растить объемы. А Lakehouse позволяет обращаться к «сырым» данным, сложенным в правильной области с нужной скоростью.

Важно отметить, что мы выбрали еще и подход Data Mesh, который как раз таки разделяет и позволяет управлять бизнес-ценностью данных для каждого подразделения. У каждого бизнес-подразделения есть свой набор данных, за которые оно отвечает, которые оно потребляет. Их можно гарантировать и использовать в качестве доставки, при этом не смешивая между собой бизнес-стримы, что для нас является достаточно серьезным по текущей бизнес-схеме компании.

- Какие платформы были выбраны для построения новой структуры для работы с данными?

Целевое хранилище и аналитическая система управления отношениями с клиентами (aCRM) развернуты на базе СУБД СlickHouse и Arenadata DB. Они обладают высокой производительностью при работе с большими объемами транзакционных, операционных и аналитических данных.

В проекте задействованы различные данные о клиентах, бонусной программе, тиражах, розыгрышах и продажах. Подключено более 12 операционных источников, в том числе относящихся к финансовым и маркетинговым сервисам. Действует BI-система с мощным модулем self-service, предоставляющая инструменты для визуализации данных, создания интерактивных дашбордов и формирования отчетности.

Каталог данных Arenadata Catalog выступает в роли единого хранилища метаданных. В нем описываются метрики, показатели, содержатся бизнес-глоссарий и различные взаимосвязи (lineage), а также все базы данных в рамках подхода Data Mesh и полный каталог дашбордов с описаниями и ссылками.

- Какие работы были проведены в рамках проекта?

В рамках проекта нами внедрен децентрализованный гибкий подход к работе с данными — Data Mesh. Создано хранилище на архитектуре Data Lakehouse на базе СУБД СlickHouse, аналитической MPP-СУБД Arenadata DB и системы управления корпоративными данными.

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

Вместо отдельных автономных серверов внедрены кластеры Kubernetes, куда и были размещены необходимые сервисы по работе с данными. Базы данных были развернуты в кластерном исполнении. Созданы среды разработки и тестирования, настроены процессы CI/CD, внедрена единая система аутентификации пользователей AD и проработана ресурсно-ролевая модель для каждого сервиса и БД согласно Data Mesh принципам.

- Какими силами реализован проект?

Это самая большая гордость. Проект за шесть месяцев выполнили три человека, при этом совмещая от трех до пяти ролей каждый: дата-архитектор (пять ролей), BI-инженер данных (три роли) и администратор баз данных (три роли, включая роль РМ), причем совершенно молодой специалист, осваивавший свою профессию. Поддержку в бизнес-части им оказывал наш нынешний лидер команды дата-аналитиков. При этом не обошлось без обучения и слаженной командой работы, то есть самое сложное было — оперативно разобраться в бизнес-контексте.

- Что получилось особенно удачно?

Нам удалось реализовать комплексный подход, совместив построение хранилища и внедрение современных практик Data Governance. При этом выяснилось, что при поддержке команды из нескольких дата-инженеров и аналитиков можно организовать оптимальную архитектуру данных, выбрать и настроить эффективные инструменты. Также удалось минимизировать работы команды ИТ за счет глубокой проработки ТЗ и self-service в направлении DevOps и SA.

Построенное решение обслуживает более 390 моделей преобразования данных, 45 DAG Airflow, 750 таблиц и порядка 170 регулярных отчетов и дашбордов. Более 100 из этих дашбордов созданы бизнес-пользователями за два месяца с помощью инструментов self-service.

Создано централизованное пространство знаний для всех ключевых подразделений. Мы объединили и синхронизировали в рамках самостоятельной работы с данными пять департаментов и порядка 60 бизнес-пользователей, работающих с данными. Потенциальных пользователей инструментов self-service гораздо больше — их число должно вырасти до более десятка департаментов и примерно 150 человек.

По сути, за девять месяцев от идеи до реализации проекта произошла полная оптимизация процессов работы с данными.

- Каких эффектов удалось достичь?

Уже по итогам первого этапа проекта среднее время выполнения запроса сократилось в 75 раз. Количество ошибок при выполнении запросов уменьшилось в 7,5 раза, вдвое сократилось количество ошибок переполнения памяти при аналитических операциях. Время загрузки данных сократилось в шесть раз, а регулярные обновления аналитической отчетности теперь возможны каждые 20 минут.

Расчет показателей, необходимых в режиме времени, близком к реальному, ускорился в 15 раз. Показатель доступности данных (time-to-data) в отчетности сократился до 5–10 минут, а при работе с аналитическими моделями — до одного дня.

Теперь полностью автоматизировано создание семи ключевых отчетов, которые ранее готовились вручную, и более 20 уникальных, специфичных для нашего бизнеса практик автоматического анализа. Приведены к единым подходам более 131 элемента глоссария и устранены расхождения в понимании более 30 ключевых терминов и определений.

Оптимизировано более 70 регулярных отчетов. Большая часть из них сейчас переводится в дашборды в рамках подхода self-service. Перестроено несколько ключевых общекорпоративных дашбордов, которые влияют на бизнес-решения в режиме времени, близком к реальному.

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

- А чего добились с точки зрения бизнеса?

В процессе работы найдены уникальные дата-кейсы, которые раньше не учитывались для оценки эффективности и принятия решений.

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

Еще один важный проект связан с планированием производства. Проанализировав результаты процесса планирования, мы поняли, как оптимизировать заказ, печать и доставку, чтобы повысить эффективность реализации товара и снизить процент утилизации. Это дало правильное планирование, причем наши прогнозы сбываются практически рубль в рубль и по количеству, и по финансовым результатам. Эти три параметра дали возможность бизнесу в 2024 году максимально эффективно использовать бюджет и вообще управлять ожиданиями и бизнеса, и акционеров.

- Какую роль сыграл этот проект для развития компании?

В первую очередь нам удалось повысить прозрачность бизнес-процессов и обеспечить централизованный доступ к информации. При кратном увеличении скорости и количества решений, принимаемых на основе данных, удалось максимально удержать рост расходов, в том числе на штат. Теперь бизнес-подразделения, финансовый отдел и продуктовые команды работают с согласованными терминами и имеют актуальные данные в режиме одного окна. Это снижает риски, связанные с ошибочными расчетами, и ускоряет принятие управленческих решений, что для государственных лотерей имеет особое значение, учитывая высокие требования к прозрачности и соблюдению нормативных актов. По сути, сегодня, работая с дата-платформой, бизнес компании перешел от формата «что случилось» к формату «известно заранее, что будет».

- В каких направлениях планируется развитие?

Предполагаем дальнейшее развитие архитектуры данных с углублением практик Data Governance, особенно в направлении мониторинга и контроля качества данных. Для этого проводим масштабную оценку Data Maturity по централизованной методологии. Планируем масштабирование под растущий парк аналитических запросов и продуктов. Наконец, ведем подготовку к внедрению экономически эффективного применения машинного обучения.