tl;dr data

How Rapport Labs Adopted StarRocks for Ad Performance Data

Rapport Labs рассказали, как перестроили систему аналитики рекламных кампаний после того, как MySQL-based pipeline перестал масштабироваться.

Изначально события хранились в двух MySQL-таблицах:

• ad_interaction_raw содержала показы, клики и другие пользовательские события, записываемые в реальном времени;

• ad_purchase_aggregated_events содержала покупки, связанные с рекламными показами или кликами, и обновлялась раз в пять минут.

Периодический batch job считывал новые строки по ID из global_pointer, агрегировал impressions, clicks, billed amount, purchase quantity и purchase amount по рекламной кампании, а затем публиковал инкременты в Kafka.

Kafka consumer обновлял агрегированные таблицы в MySQL и пересчитывал CTR, CVR и ROAS.
Campaign ID использовался как partition key, а transactional inbox pattern обеспечивал идемпотентность обработки.

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

Каждый новый уровень агрегации требовал отдельного batch job, Kafka consumer и MySQL-таблицы.

В результате:

• росло количество дублирующихся пайплайнов;

• увеличивалась write-нагрузка на MySQL;

• cursor-based обработка могла приводить к пропускам данных;

• изменения исторических данных не попадали в агрегаты автоматически;

Высокая нагрузка на MySQL была критична: та же база участвовала в формировании billing source data, поэтому задержки могли влиять на рекламную выручку.

Команда решила вынести обработку performance data в отдельную OLAP-систему и сравнила BigQuery, ClickHouse и StarRocks.

BigQuery уже использовался внутри компании, но не подошел для частых near-real-time запросов: on-demand pricing становился дорогим, а capacity-based модель требовала постоянно держать избыточные ресурсы.

При тестировании ClickHouse команда столкнулась с проблемами интеграции с Glue Catalog и Iceberg.
Таблицы с timestamp-колонками не появлялись в SHOW TABLES, а SQL-запросы через Glue Catalog завершались ошибкой S3 URI.

StarRocks выбрали по нескольким причинам:

• стабильная интеграция с Glue и Iceberg;

• возможность читать source data напрямую из S3 без повторной загрузки;

• Data Cache для кэширования удаленных блоков на BE-узлах;

• Materialized Views для предварительной агрегации часто запрашиваемых данных;

• Cost-Based Optimizer для выполнения JOIN;

• совместимость с MySQL wire protocol, позволившая переиспользовать существующие драйверы и query libraries backend-приложения.

Source of truth при этом оставили вне StarRocks: данные хранятся в Apache Iceberg на Amazon S3, а метаданные — в AWS Glue Catalog.

StarRocks читает исходные Iceberg-таблицы как external tables, но данные, которые непосредственно выдаются продавцам, формируются во внутренних Materialized Views.

Сначала кластер развернули в shared-data конфигурации с FE и stateless CN.
В этой архитектуре внутренние таблицы и MV также хранились в S3.

Для near-real-time аналитики Materialized Views обновлялись каждые несколько минут.
Это генерировало большое количество S3 PutObject и привело к более высоким расходам, чем ожидалось.

После перехода на shared-nothing архитектуру с FE и BE внутренние данные и Materialized Views стали храниться на локальных дисках BE-узлов.
Связанные с этой частью инфраструктуры расходы снизились примерно на 95%, а мониторинг refresh Materialized Views стал проще.

Поскольку исходные данные оставались в Iceberg, для миграции команде не пришлось переносить source data: они развернули новый кластер и заново построили Materialized Views.

В результате Rapport Labs получили масштабируемую систему near-real-time агрегации, снизили нагрузку на MySQL, устранили пропуски в агрегатах и сократили восстановление после инцидентов с более чем четырех часов до менее чем 30 минут.

Этот кейс хорошо показывает архитектуру, в которой Iceberg используется как независимый storage layer и source of truth, а StarRocks — как OLAP-движок и serving layer для пользовательской аналитики.

@tldr_data

Medium

How Rapport Labs Adopted StarRocks for Ad Performance Data

By Junhyun Ko, Software Engineer, and Byeongwoo Lee, Data Engineer, at Rapport Labs.

🔥1

129 viewsedited 07:50