Doris вместо Spark ускорила A/B-метрики в 145 раз

Kwai перенесла расчёт метрик A/B-экспериментов со Spark на Apache Doris и получила ускорение до 145 раз на типичном пути при снижении потребления ресурсов на 72 %. Задача была жёсткой: ежедневно обрабатывать сотни тысяч пакетных заданий по двум большим таблицам, где ключ соединения — всегда UID, а результат нужен к середине дня. Переход позволил сократить время с 21 минуты до 8,7 секунды на основном пути и с 65 минут до 2,12 минуты на самом длинном. При этом кластер вырос до 2000 BE-узлов и 100 000 CU, став крупнейшим production-кластером Doris в мире. A/B-эксперименты позволяют сравнивать варианты продукта на реальных пользователях, а метрики показывают, какой вариант работает лучше. Spark — универсальный движок для больших данных, часто применяемый для тяжёлых пакетных расчётов. Apache Doris — аналитическая СУБД, ориентированная на быстрые запросы к большим объёмам. BE-узлы отвечают за хранение и обработку данных, а CU — условные единицы вычислительных ресурсов. Такие цифры важны при выборе платформы: они показывают, насколько сильно можно сократить время получения результатов и расходы на железо, если нагрузка похожа на описанную.

Как перестроили данные и вычисления

Команда отказалась от универсального движка и переписала пайплайн под фиксированный шаблон запроса. Данные разместили по хешу UID с colocate-группами, чтобы join выполнялся локально на каждом BE без пересылки. Colocate-группы — это способ разместить связанные данные на одних узлах, что снижает сетевой трафик. Для distinct-агрегаций ввели Local Distinct, который считает уникальные значения внутри шарда до глобальной свёртки. Local Distinct позволяет избежать полной пересылки всех данных при подсчёте уникальных элементов. UDF переписали на нативные функции Doris, а планировщик задач настроили так, чтобы все A/B-задания шли по одному скелету из четырёх стадий: scan assignment, pre-aggregate metrics, join с агрегацией по бакетам и финальная свёртка. Эти изменения убрали основные источники overhead — shuffle и повторные сканирования — и дали основную часть ускорения. При принятии решения о миграции важно понять, готова ли команда переписать запросы под жёсткий шаблон и поддерживать colocate-группы при изменениях схемы. Если большинство заданий не укладывается в один шаблон, выигрыш по времени и стоимости может оказаться существенно меньше.

Управление метаданными и отказоустойчивость

Отдельной работой стала оптимизация frontend-узлов. FE-узлы управляют метаданными и планированием запросов. Объём метаданных в памяти сократили с 4,16 до 1,49 ГБ за счёт более компактного хранения партиций и оптимизации кэша. Время восстановления FE после сбоя упало с 27 до 10 минут. На кластере из пяти FE это позволило держать 400 000 вставок в сутки без просадок, несмотря на пик в шесть с половиной раз выше минимума. Для российских команд, где часто приходится совмещать пакетные и интерактивные нагрузки на одном кластере, такие цифры важны: они показывают, что Doris может держать одновременно и real-time serving, и тяжёлые nightly-задания без отдельного Spark-кластера. При оценке стоит проверить, насколько критична для бизнеса скорость восстановления после сбоев и способна ли команда обслуживать кластер такого размера без простоев.

Ограничения и что нужно проверять

Не все оптимизации доступны из коробки в открытой версии Doris. Colocate join и Local Distinct требуют точной настройки бакетов и партиционирования; при изменении схемы экспериментов их придётся пересчитывать. Кроме того, сравнение проводилось на конкретной версии Spark и конкретной схеме данных Kwai — в других контурах ускорение может оказаться меньше. Перед миграцией стоит проверить, действительно ли 80-90 % заданий укладываются в один SQL-шаблон, иначе выигрыш по latency и стоимости будет заметно скромнее. Также нужно оценить зрелость инструментов мониторинга и алертинга для 2000-узлового кластера в своей инфраструктуре. Эти факторы напрямую влияют на решение: если в компании часто меняются схемы экспериментов или нет опыта тонкой настройки партиционирования, затраты на поддержку могут превысить выгоду от ускорения.

Что даёт такой подход российским командам

В российских компаниях A/B-платформы часто остаются на Spark или ClickHouse с ручными доработками. Переход на Doris позволяет убрать отдельный слой для пакетных расчётов и обслуживать и витрины, и эксперименты на одном движке. При этом важно заранее заложить colocate-группы и протестировать восстановление FE на объёмах, близких к production. Если нагрузка имеет стабильный шаблон и ключ соединения не меняется, выигрыш по времени и железу может быть сопоставим с цифрами Kwai. В остальных случаях лучше оставить Spark для тяжёлых ETL и использовать Doris только для serving и лёгких агрегаций. Командам стоит оценить собственную экспертизу в настройке Doris и готовность отказаться от универсальности Spark ради специализированной производительности.

Источник

Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Doris вместо Spark ускорила A/B-метрики в 145 раз.

Курс по теме — Каталог курсов Школы Больших Данных