Для решения классических аналитических задач в банке дата‑специалисты обрабатывают миллиарды транзакций. Поэтому создание единого информационного пространства для работы с большими объёмами данных потребует решить как задачи оптимизации производительности и обеспечения безопасности, так и задачи удобства для пользователей — и найти баланс между ними.
Сергей Виноградов на конференции Data&ML2Business рассказал про разработку и построение DWH для задач Яндекс Пэй. В этой статье — дополненный рассказ о том, как устроена аналитическая платформа на базе Greenplum® и ClickHouse®, которую решили строить на базе managed‑сервисов в облаке. А также о том, как жизнь аналитиков облегчает связка Apache Spark™ и Jupyter‑ноутбуков в Yandex DataSphere.
Посмотреть видеозапись доклада
Какие запросы у пользователей и как развивался продукт для их решения
Яндекс Пэй — это платёжный сервис Яндекса. Его аналитические подразделения занимаются во многом типовыми для банка направлениями работы:
Банковская отчётность.
Финансовая отчётность.
Анализ рисков.
Аналитика по банковским продуктам.
В большинстве своём это не realtime‑задачи, а скорее интерактивные нагрузки на систему — когда важно исследовать какие‑то данные, посмотреть на них в различных разрезах. Среди основных пользователей платформы:
команда, которая занимается построением бухгалтерской отчётности для аудиторов Яндекса;
команда, которая занимается кредитным скорингом;
команды, занимающиеся финансовым мониторингом;
ML‑инженеры и продуктовые аналитики, а также дата‑инженеры DWH.
Текущая DWH‑система для этих задач развивается с 2022 года. Её сразу запускали в облаке и по максимуму ориентировались именно на управляемые ресурсы с разделённой ответственностью. Для службы безопасности также было важно, что это позволяет завязать всю ролевую модель доступа к сервисам и данных на единый сервис IAM.
Важно сказать, что до этого вся команда проекта имела дело в большей степени с on‑premise, а значит регулярно сталкивались с особенностями облака при построении новой платформы.
Источники данных. Поскольку система активно используется для продуктовых задач, а банковских сервисов в Яндекс Пэй уже довольно много, то и данные поступают из разных баз. Чаще всего это инстансы PostgreSQL, ClickHouse или YDB, но иногда встречается и кое‑где живущий Oracle. Сбор данных осуществляется с помощью Change Data Capture (CDC): для PostgreSQL, ClickHouse это собственная инсталляция Debezium с некоторыми доработками, для YDB помогает Data Transfer. Для Oracle потребовалось написать собственный инструмент, который инкрементально собирает нужные фрагменты данных.
Схема поставки данных целиком выглядит так:
Все данные заливаются через Managed Service for Apache Kafka и в конечном итоге попадают в объектное хранилище. Для предварительной подготовки данных перед заливкой в Object Storage команда использует собственный инструмент для сборки потоковых данных, который позволяет подготовить датасет к быстрой обработке в многопоточном режиме. Таким образом в сутки прокачивается в среднем до 10–12 ТБ.
Слои данных. В объектном хранилище первоначально оказываются «сырые данные». Сейчас в Object Storage находится порядка 1 Пб. А дальше формируется довольно знакомый многим «пирог данных».
Операционные данные (ODS) хранятся в объектном хранилище.
Детальный слой (DDS) построили на базе якорной модели с несколькими модификациями. Построенные инкременты детального слоя переносятся в Greenplum.
Затем идёт слой коммунальных витрин и слой пользовательских витрин данных — они тоже строятся уже на Greenplum.
Структура хранения и обработки данных. По факту есть два основных хранилища данных: Object Storage и Greenplum.Также используется ClickHouse — в основном для сервисных процессов и перегрузки туда тяжелых витрин, построенных в Greenplum.
Для оркестрации данных используется Apache Airflow®, а данные внутри объектного хранилища обрабатываются с помощью Apache Spark в рамках Yandex DataProcessing.
В качестве BI‑инструмента используется DataLens, в котором пользователи строят свои дашборды.
При этом пользователи, которые работает с SQL‑запросами, обращаются к облаку через решение CloudBeaver. Это облачная версия DBeaver, Web IDE для управления базами данных, в нашем случае Greenplum и ClickHouse.
Если же нужно заниматься именно какой‑то аналитикой с кодом на Python, то используется Yandex DataSphere, которая предоставляет облачную имплементацию JupyterLab. А аналитики данных в команде как раз любят использовать Python в качестве основного языка программирования
Как эти инструменты используются в типовых сценариях. Вот несколько классических задач, которые часто решают аналитики в банке:
При разработке отчётности для аудиторов может потребоваться, например, создать форму, состоящую из десятков тысяч строк кода. В этом случае нужно сначала написать прототип работы с данными в объектном хранилище. Далее эти данные можно загрузить в Greenplum и уже использовать их.
Для различных банковских продуктов, например для вклада или накопительного счета, часто создаются воронки, которые затем выводятся на продуктовые дашборды.
В системе риск‑менеджмента есть скоринговый движок, который обрабатывает запросы по пользователям, в том числе проводит их оценку для принятия решений и одобрения тех или иных операций.
В этих случаях инженеры и аналитики пишут различные обработчики данных и строят дашборды и отчёты в разных разрезах. Часто требуется объединение данных из нескольких источников, а также распределённые вычисления — MapReduce, потому что речь, как мы помним, может идти о миллиардах транзакций, когда нужно перебрать порядка 100 Тб за сутки. С этим как раз очень хорошо справляется Apache Spark, который хорошо распределяет вычисления, даже при скромных ресурсах. Вот только не всегда можно решать эти задачи эффективно из коробки.
И здесь помогает связка Spark и ноутбуков в Yandex DataSphere, которые выступают в качестве интерфейса к MapReduce‑движку и позволяют решать три основных задачи:
Прототипирование. Созданный прототип работы с данными затем с помощью других инструментов ставится на выполнение.
Исследование данных. Все ситуации, когда есть несколько гипотез, для проверки которых хочется всячески повертеть данные, понять их структуру, сопоставить с чем‑то ещё.
Регламентные работы дата‑инженеров. Например, учения на случай аварийного восстановления данных.
Дальше чуть подробнее о том, каких трудностей это позволяет избежать.
Какие проблемы возникли и как их решали
Интеграция Spark. Изначально, когда возможность работать с Apache Spark только появилась в сервисе Yandex Data Processing, работа строилась только через Apache Livy. Этот инструмент позволяет работать с кодом на Python, но сильно усложняет жизнь аналитика: сначала создаём сессию Livy, отдельной операцией создаём Spark‑контекст (подключение к кластеру Spark), загружаем данные в выборку, которая в Spark называется dataframe, проводим дополнительную обработку этих данных, но затем не можем затянуть их обратно для последующей визуализации, поскольку нет подходящей библиотеки и так далее. Также есть сложности с синхронизацией окружений.
С развитием Yandex DataSphere получилось через коннектор сразу цепляться к Spark‑контексту. Сам Jupyter‑ноутбук становится частью кластера Spark в DataProcessing. Это даёт возможность быстрее запускать сами DataSphere Jobs, синхронизировать окружения, а также загружать данные сверх лимита в 10 Мб напрямую в ноутбук и на их основе строить отчётность. Далее с этими зависимостями могут работать исследователи и дата‑инженеры.
Важная особенность работы с данными в банковской сфере — это повышенные требования к информационной безопасности. Аналитики не могут просто получить доступ ко всем данным напрямую, необходимо учитывать политики доступа, построенные на сложной ролевой модели. Все пользователи распределяются по комьюнити — проектам, в рамках решаемых задач. У команды есть консольная DWH‑утилита, с помощью которой дежурный может управлять правами пользователей и автоматизировать некоторые другие свои задачи через API DataSphere.
Сейчас DataSphere — по сути, единственное окно, которое предоставляет доступ к данным из банковских продуктов с учётом имеющихся разрешений в IAM. С помощью такого инструмента аналитики могут забирать порядка сотен терабайт агрегированных данных из продуктов и объединять их с данными из других источников, например, из хранилищ. Потом можно собирать с помощью Python или SQL витрины, на которых в свою очередь можно с помощью DataLens строить комплексные аналитические дашборды. За счёт этого мы получаем прототипы, которые уже можно использовать для создания итогового продукта в будущем.
Также это среда для автоматизации задач дата‑инженеров, связанных с поддержанием работоспособности хранилищ и продуктов банка. У дежурного инженера есть достаточно информации, которая позволяет видеть, что происходит со сборками данных. В том числе можно мониторить Data Quality по тысяче различных параметров.
Устаревание версий в DataProcessing. Когда команда только начинала работать с этим сервисом, там были устаревшие версии Apache Spark, и это влияло на архитектуру распределения Jobs по Spark. Потребовалось создать свою систему деплоя, которая позволила создавать нужное окружение с необходимой производительностью и объёмами. Команде было важно добиться утилизации кластера, близкой к 100%.
Сейчас с появлением отдельного управляемого сервиса на базе Spark эта особенность всё менее актуальна — команда уже протестировала Yandex Managed Service for Apache Spark и надеется, что в скором будущем это полностью закроет все запросы.