I'm available for business trips to other cities for projects lasting a month or longer.
Почему этот кейс важен для Data Lakehouse Селена
Далее вы познакомитесь с историей успеха на базе решения StarRocks Enterprise.
Для российского рынка это пример внедрения и использования интересен как практическая иллюстрация класса задач, на которые ориентирована Селена Data Lakehouse на базе StarRocks Enterprise: потоковая загрузка изменений, работа с часто обновляемыми транзакционными данными, высококонкурентные запросы, оперативная аналитика и постепенное упрощение разнородной аналитической архитектуры.
Все показатели ниже относятся к кейсу Suixingpayю. Они не являются результатами внедрения Селены.
Для российского рынка это пример внедрения и использования интересен как практическая иллюстрация класса задач, на которые ориентирована Селена Data Lakehouse на базе StarRocks Enterprise: потоковая загрузка изменений, работа с часто обновляемыми транзакционными данными, высококонкурентные запросы, оперативная аналитика и постепенное упрощение разнородной аналитической архитектуры.
Все показатели ниже относятся к кейсу Suixingpayю. Они не являются результатами внедрения Селены.
3×
рост производительности запросов
>10×
рост эффективности аналитики
<1 с
P99 задержки полного контура загрузки
-20%
избыточного хранения данных
30 млрд
записей в контуре точечных запросов
>3 ч
выигрыш по времени формирования отчётов
Задача: когда лямбда-архитектура перестала масштабироваться
Suixingpay - крупная китайская платформа платёжной инфраструктуры. По мере роста объёма транзакций её аналитическая система, построенная по Lambda-подходу, стала ограничивать развитие прикладных сервисов. Офлайн-контур на традиционных базах данных и Hive существовал отдельно от контура реального времени на Elasticsearch, HBase и Kudu. Для одного и того же бизнес-процесса данные приходилось перемещать, хранить и обслуживать в нескольких системах.
Проблема была не только в скорости отдельных запросов. Разделение контуров увеличивало длину цепочек обработки, усложняло сверку результатов и сопровождение, создавало дополнительное хранение и снижало предсказуемость системы в периоды пиковой нагрузки. Для части сценариев не обеспечивалось обновление данных в пределах текущего дня, а сложные многомерные запросы требовали слишком много времени.
Особенно чувствительными к этим ограничениям были платёжные и сервисные сценарии: работа с историей транзакций, сервисы для мерчантов и партнёров, операционные панели, риск-контроль в реальном времени, безопасность и регуляторные задачи.
(*) Мерчант (от англ. merchant) - это компания, магазин, сервис или индивидуальный предприниматель, который принимает платежи от клиентов за товары или услуги. В банковской и платёжной терминологии часто можно встретить близкий русский термин торгово-сервисное предприятие (ТСП).
(*) Мерчант (от англ. merchant) - это компания, магазин, сервис или индивидуальный предприниматель, который принимает платежи от клиентов за товары или услуги. В банковской и платёжной терминологии часто можно встретить близкий русский термин торгово-сервисное предприятие (ТСП).
Архитектура: CDC + потоковая обработка + StarRocks
Команда Suixingpay перестроила аналитический контур вокруг собственного инструмента Porter CDC, потоковой обработки Flink и StarRocks. Elasticsearch сохранился там, где поисковые и вторичные индексы давали практическое преимущество. В результате вместо набора слабо связанных технологий появилась более единая архитектура, в которой один аналитический движок обслуживает несколько типов нагрузки.
В рабочем контуре система принимает порядка миллиона записей в минуту и поддерживает оперативный ODS-слой для высококонкурентных бизнес-сервисов. Важным архитектурным решением стала модель таблиц с первичным ключом (Primary Key), рассчитанная на данные, которые не только добавляются, но и часто обновляются.
Ключевые сценарии
1. Высококонкурентные запросы к детальным данным
Типичные запросы - история возвратов, операции мерчантов и сервис-провайдеров, другие обращения к большим массивам транзакций. Ранее этот контур опирался на традиционную базу данных, Impala и Kudu: при росте истории данных такая связка становилась сложнее в сопровождении и не обеспечивала требуемую задержку.
- Таблицы с первичным ключом размещались на SSD для предсказуемой производительности при высокой конкуренции запросов.
- Асинхронные материализованные представления использовались как управляемый слой ускорения: на таблице объёмом около 30 ТБ точечные запросы выполнялись за миллисекунды, а по сравнению с полным просмотром таблицы ускорение достигало примерно 20 раз.
- Elasticsearch использовался как дополнительный индекс для сценариев со сложной фильтрацией и поиском по нескольким условиям.
2. Оперативная и произвольная аналитика
К этой группе относились правила риск-контроля, операционные панели и разовые аналитические выборки. Ранее часть показателей приходилось рассчитывать заранее и помещать в транзакционные базы данных. Это снижало актуальность информации и затрудняло работу с новыми срезами данных.
- Для объёмных аналитических наборов применялся StarRocks на HDD, что позволяло балансировать стоимость хранения и производительность.
- Агрегирующая модель данных переносила часть расчётов на этап загрузки и уменьшала вычислительную нагрузку во время запросов.
- Colocate Join соединял связанные факты (отражение операций) и измерения. Производительность соединений выросла примерно в 3 раза.
- Настройка стоимостного оптимизатора (CBO) и статистики сократила время построения планов сложных запросов примерно на 80%.
3. Периодические и сложные расчёты
Часть задач оставалась по своей природе пакетной: расчёт таблиц измерений, ежедневная отчётность и сложные агрегаты. Здесь цель состояла не в том, чтобы объявить пакетную обработку ненужной, а в том, чтобы выполнять её быстрее, стабильнее и на той же аналитической платформе.
- Динамическое отсечение разделов и проталкивание предикатов сократили объём чтения данных в типовых отчётных заданиях на 73%.
- Настройка компактизации и параметров BE снизила фоновую нагрузку и помогла стабилизировать выполнение длительных заданий.
- Механизмы разделения ресурсов между арендаторами изолировали пакетные задания от интерактивной нагрузки.
- Мониторинг StarRocks был интегрирован с Grafana. Для части эксплуатационных событий уведомление формировалось в пределах нескольких секунд.
Технические решения, которые дали основной эффект
1. Частичные обновления вместо лишнего трафика
Для транзакционных таблиц большого объёма Porter извлекает из журнала изменений только те поля, которые действительно изменились. Коннектор Flink был доработан для динамического обновления столбцов. Такой подход снижает давление на исходную базу данных и не заставляет каждый раз передавать полную строку.
2. Предварительное объединение CDC-событий
Последовательные изменения одной и той же записи предварительно объединяются в потоковом контуре до загрузки в StarRocks. В результате движок получает меньше отдельных операций обновления и меньше промежуточных состояний одной строки. По данным кейса, такая оптимизация вместе с изменениями конвейера снизила объём операций ввода-вывода при записи примерно на 30%.
3. Конфигурируемая синхронизация нескольких таблиц
Команда расширила стандартный коннектор Flink: синхронизация нескольких таблиц стала задаваться конфигурацией, а в поток добавили ограничение скорости и контроль состояния заданий. Это уменьшило объём ручной разработки и повысило управляемость контура загрузки.
4. Единый движок для разных профилей нагрузки
Вместо попытки подобрать отдельную технологию под каждый тип запроса команда использовала разные механизмы StarRocks внутри общей платформы: SSD и таблицы с первичным ключом для высококонкурентного доступа, HDD и предварительную агрегацию для массовой аналитики, материализованные представления для повторяющихся запросов, Colocate Join и CBO для соединений, а также федеративный доступ и озёрные механизмы для исторических данных.
Измеримый эффект
В совокупности эти изменения позволили Suixingpay перейти от архитектуры, где каждый класс задач обслуживался отдельным набором компонентов, к более унифицированной аналитической платформе. Это сократило число межсистемных связей, уменьшило объём дублируемых данных и снизило сложность восстановления: в кейсе время восстановления после части отказов указано на уровне менее пяти минут.
Что этот кейс показывает для Data Lakehouse Селена
Практическая ценность кейса не сводится к сравнению производительности отдельных СУБД. Он показывает несколько архитектурных принципов, которые особенно важны для Селены как Data Lakehouse на базе StarRocks Enterprise.
- Data Lakehouse может быть не только хранилищем для BI и отчётности. При наличии CDC и модели таблиц с первичным ключом он способен обслуживать оперативные сценарии, где данные меняются постоянно и должны становиться доступными через секунды.
- Один аналитический движок может одновременно поддерживать детальные запросы, агрегаты, периодические расчёты и часть сервисных обращений - за счёт разных моделей таблиц, материализованных представлений, оптимизатора и управления ресурсами.
- Поток CDC имеет смысл оптимизировать до записи (Merchant-on-Write): передавать только изменившиеся поля, объединять последовательные изменения одной записи и контролировать скорость загрузки. Это особенно актуально для АБС, карточного процессинга, платёжных систем, ERP и других источников с большим количеством UPDATE.
- Переход к Lakehouse не требует одномоментно отказаться от всех специализированных систем. В кейсе Elasticsearch и озёрные технологии остаются частью архитектуры там, где они дают пользу; StarRocks становится центральным вычислительным и аналитическим слоем.
- Главный экономический эффект возникает не только за счёт ускорения запросов, но и за счёт сокращения дублирующих контуров хранения, уменьшения числа интеграционных связей и переноса большего числа сценариев на единую платформу.
Дальнейшее развитие архитектуры
Следующий этап, обозначенный командой Suixingpay – дальнейшая унификация хранения и запросов вокруг StarRocks. Планируется использовать федеративные запросы и механизмы Catalog для доступа к Hudi, Elasticsearch и другим неоднородным источникам, чтобы пользователь меньше зависел от физического расположения данных. Целевая модель – единый путь от сбора и обработки до аналитики и предоставления данных через унифицированные сервисы.
Ключевой вывод
Для платёжной платформы переход на StarRocks оказался не локальной заменой одной аналитической СУБД другой, а способом пересобрать весь путь данных: от CDC и обновляемых транзакционных таблиц до высококонкурентных запросов, аналитики и пакетных расчётов. Именно этот переход от набора специализированных контуров к единой управляемой платформе делает кейс особенно показательным для позиционирования Data Lakehouse Селена.
Для платёжной платформы переход на StarRocks оказался не локальной заменой одной аналитической СУБД другой, а способом пересобрать весь путь данных: от CDC и обновляемых транзакционных таблиц до высококонкурентных запросов, аналитики и пакетных расчётов. Именно этот переход от набора специализированных контуров к единой управляемой платформе делает кейс особенно показательным для позиционирования Data Lakehouse Селена.
Источник и редакционная оговорка. Материал переработан на основе предоставленного Success Story команды Suixingpay. Числовые показатели и описание внедрения относятся к Suixingpay и StarRocks. Блоки о релевантности для Селены являются редакционной адаптацией для позиционирования Data Lakehouse Селена и не означают, что Suixingpay использует Селену.