Букмекер видит вашу ставку через 10 секунд: что real-time-аналитика делает с данными пользователей

В беттинге данные о действиях нужны почти сразу — не через час и даже не через полчаса. В нашем случае — в течение 10–15 секунд. Иначе продуктовая команда рискует поздно заметить проблему, а бизнес — потерять деньги и время, за которое конкурент уже запустит свою механику. Поэтому на связи Владимир Медников — директор по данным в PARI. Я расскажу, что происходит с событием пользователя после нажатия кнопки, зачем здесь Kafka с ClickHouse и почему именно 10–15 секунд, а не три минуты.

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

Наша архитектура целиком выглядит так: клиент → backend → Kafka → Kafka Engine → Materialized view → ClickHouse → агрегированные таблицы → аналитика.

Если вы не технарь, ниже — простое объяснение перечисленных «штук». А если всё же технарь — не раскрывайте эту сноску. 

А теперь пройдём этот путь подробнее по шагам и посмотрим, что происходит на каждом этапе. 

Шаг № 1. Клиент совершает действие

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

Шаг № 2. Kafka принимает событие

События попадают в определённый топик — логический канал, куда записываются сообщения определённого типа. Данные становятся доступны в Kafka почти сразу после того, как бэк их туда отправил.

При объёмах данных PARI, постоянное хранение всего потока быстро заняло бы дисковое пространство, поэтому сообщения хранятся ограниченное время (оно зависит от топика — от 7 до 30 дней). После этого данные можно переносить в другие системы для дальнейшей работы.

Шаг № 3. Kafka Engine забирает данные

Дальше в дело вступает Kafka Engine в ClickHouse. Движок подключается к Kafka как консьюмер и непрерывно вычитывает поток событий из нужного топика. Чтобы не нагружать диск микрозаписями, ClickHouse не сохраняет каждое событие отдельно: Kafka Engine накапливает сообщения небольшими батчами и записывает их либо после накопления заданного количества строк, либо по истечении таймаута kafka_max_wait_ms. В итоге новые данные появляются в ClickHouse примерно каждые 5–7 секунд.

Шаг № 4. Materialized views превращает поток в данные для ClickHouse

Сам Kafka Engine данные не хранит. Чтобы перенести их из Kafka в ClickHouse, используется связка Kafka Engine и Materialized view. Materialized view здесь можно представить как инструкцию по обработке входящих сообщений. Она говорит системе, что делать, например распаковать сырое событие, привести значения к нужным типам или (для AggregatingMergeTree) сразу преобразовать данные в промежуточные состояния с помощью агрегатных функций: sumState, uniqExactState, avgState. Эти состояния записываются на диск и уже доступны для аналитики. А фоновые процессы при слиянии частей данных (parts) на диске дособирают и объединяют промежуточные состояния между собой.

Шаг № 5. ClickHouse агрегирует данные

В зависимости от задачи используются разные движки таблиц. Например, AggregatingMergeTree позволяет агрегировать данные по заданным ключам. Ключом может быть клиент и конкретное событие, маркет или другая комбинация признаков.

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

В ClickHouse объединение данных происходит непрерывно в процессе фоновых merge-операций. Для разных движков семейства MergeTree эта логика отличается: обычный MergeTree просто объединяет куски данных на диске (parts), ReplacingMergeTree отвечает за дедупликацию, а AggregatingMergeTree — за свёртывание промежуточных агрегатных состояний. В результате фонового слияния база постепенно дособирает сохранённые состояния между собой, экономя место на диске и ускоряя итоговые выборки.

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

Время — деньги, поэтому правильно не «скорострел», а «бизнесмен»

Real-time-аналитика и детектор аномалий — связанные, но разные вещи. Оперативная аналитика отвечает на вопрос «Что происходит сейчас?», а детектор добавляет следующий уровень: «Происходит ли сейчас что-то необычное?» В этой связке мы и работаем.

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

Локализация проблемы тоже могла занимать много времени. Нужно было понять, где именно возник сбой — в конкретном экране, на платформе или в платёжном сценарии? После этого ещё нужно было воспроизвести проблему и подтвердить гипотезу.

Но и всё это нам не подсказывало, что пора менять подход. Необходимость перейти на новое решение появилась после крупной миграции и запуска нового iOS-приложения. В апреле 2026-го команда заметила расхождение фактических показателей с плановыми, но в моменте не было ни real-time-аналитики, ни детектора аномалий. Для PARI контроль онлайн-показателей особенно важен, потому что цифровой канал — это ключевая часть бизнеса и команде необходимо своевременно видеть изменения в воронке и понимать, что на них влияет.

Это стало одним из сигналов к тому, что мониторинг продуктовых метрик нужно развивать внутри компании и делать его автоматическим. Так появился детектор аномалий, работающий с real-time-данными, событиями кликстрима и продуктовыми данными.

Но факт отклонения ещё ничего не значит: показатель может меняться изо дня в день по вполне нормальным причинам. Поэтому детектору нужно сначала понять, что считать нормой, а затем — насколько быстро реагировать на изменение показателя:

• С чем сравнивать текущее значение. Для этого используется история за 90 дней. Такой подход позволяет учитывать цикличность поведения бизнеса и сезон. При этом сравнивается не абстрактное среднее значение за день. Система смотрит на сопоставимые временные интервалы. Например, показатель за 15 минут в пятницу в 16:30 сравнивается с соответствующим интервалом в предыдущие сопоставимые дни, ведь количество регистраций или ставок в пятницу в 16:30 может сильно отличаться от того же показателя в понедельник утром. 

• Как искать компромисс между скоростью реакции и количеством ложных срабатываний. Сами данные для аналитики появляются почти сразу: от попадания события в Kafka до его появления в агрегированных таблицах ClickHouse проходит около 10–15 секунд. А 15 минут — это уже интервал проверки детектора: если смотреть на метрики каждую минуту, система будет чаще реагировать на кратковременные колебания и генерировать лишние алерты, из-за которых сложнее будет заметить важные сигналы.

Что происходит после алерта: от цифры к расследованию 

Первое действие команды аналитики и команды продукта — проверить качество самих данных. Представим, что проблема связана с платежами. Тогда проверяют доступность платёжных систем и конкретные платёжные сценарии. Если речь идёт, например, об СБП, команда может дополнительно проверить, нет ли инцидента на стороне поставщика.

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

Старый подход увеличивал риск слишком поздно заметить сбой, а для диджитал-продукта это означает потерянное время и потенциально потерянных пользователей. Но и real-time — не волшебная палочка: сама по себе быстрая доставка данных не исправляет проблемы. Она помогает раньше начать разбираться и сделать реакцию на инциденты предсказуемее. А дальше возникает новый вопрос: как не утонуть в сигналах? По предварительной оценке, детектор уже выдал около 6 900 срабатываний. Теперь важна не только скорость алертов, но и их полезность: команде должны приходить действительно значимые сигналы, а не каждый случайный чих метрики. 

Куда развивается real-time и что хотим улучшить

Сейчас real-time-аналитика позволяет быстро ответить на вопрос: «Что происходит с продуктом прямо сейчас?» Но мы хотим получать ответ и на вопрос: «Что, скорее всего, произойдёт дальше и что мы можем сделать сейчас?» Нам важно прийти к предиктивности, и мы видим перед собой две задачи: 

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

• Приоритизация. У real-time есть и обратная сторона: чем больше данных и сценариев мы переводим в оперативный режим, тем больше сигналов получаем. Даже если речь идёт о тысячах срабатываний, далеко не каждое требует срочно собирать команду. Если сообщать обо всём подряд, алерты быстро превратятся в фоновый шум — примерно как чат, где тысяча непрочитанных сообщений и непонятно, какое из них важно. Поэтому следующая ключевая задача — научиться выделять действительно значимые отклонения: какие метрики требуют реакции прямо сейчас, кому отправлять сигнал, а что может подождать. 

Всё это мы делаем для одной понятной цели: выигрывает тот букмекер, в чьём продукте пользователь проводит больше времени. Чем больше вовлечённость, тем больше триггеров для удержания, а предиктивность — следующий логичный уровень для этого.

Мы уверены: продукт должен работать стабильно. В диджитал-бизнесе пользователь не обязан разбираться, почему у него не прошёл платёж или не открылся экран. Он просто уйдёт туда, где всё работает. Поэтому вдолгую выигрывает не тот, кто собрал больше всего дашбордов и алертов, а тот, кто быстрее замечает проблемы и реже заставляет пользователя с ними сталкиваться.

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

Если вам это близко, загляните на наш карьерный сайт или напишите о себе пару слов в комментариях :)