Создание простого алгоритма для поиска вилок в лайве: основы архитектуры данных

Введение

В лайв-ставках вилки возникают быстро и живут недолго. Для их обнаружения нужна простая и надёжная архитектура, способная работать с потоковыми котировками и принимать решения в миллисекунды.

Эта статья описывает ключевые компоненты такой системы: сбор данных, нормализацию, представление рынков, алгоритм матчинга и расчёт ставок. Коммерческие детали опускаются — акцент на инженерных и аналитических задачах.

Анализ команд и игроков

Структура матча и стиль команд влияют на вероятность появления вилок. Команды с большой вариативностью результата и резкими изменениями темпа чаще создают расхождения котировок между букмекерами.

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

В данных целесообразно хранить метрики волатильности: среднее число голов за 15 минут, долю голевых моментов в таймах, склонность к рискованной игре при отставании. Эти показатели помогают динамически менять пороги обнаружения.

Ключевые факторы

Задержка данных. Система должна учитывать латентность поступления котировок и время обработки. На входе фиксируются метки времени и оценка задержки для каждого источника.

Нормализация рынков. Букмекеры используют разные обозначения событий и типов ставок. Нормализация включает сопоставление идентификаторов матчей, типов рынков и сторон ставки в единую модель.

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

Комиссии и лимиты. Комиссии обменных платформ, ограничения счёта и максимумы ставок у букмекеров меняют реальную выгоду. Система должна хранить параметры лимитов и быстро пересчитывать ожидаемую прибыль.

Архитектура данных и представление

Ядро системы — приём потоковых котировок и их нормализация. Для простоты используются очереди сообщений и процессоры, которые проставляют метки времени и приводят поля к общей структуре: match_id, market_type, selection_id, odd, volume, source_ts, received_ts.

Хранение — в in-memory key-value для минимальной задержки. Ключ — комбинированный идентификатор матч+рынок, значение — актуальная книга котировок по каждому источнику. При обновлении вычисляется дифф и генерируется событие изменения.

Модель котировок содержит лучшие уровни и агрегированный объём по ограниченному числу ступеней. Для простого алгоритма достаточно двух уровней на каждую сторону: best и second_best — компромисс между полнотой и скоростью.

Алгоритм матчинга вилок

Алгоритм сканирует пары противоположных исходов между источниками в реальном времени. Для двухисходного рынка условие вилки: 1/oddA + 1/oddB < 1, где oddA и oddB — котировки на противоположные исходы у разных букмекеров.

Учитываются объёмы. Считается максимальная сумма каждой ставки по доступным объёмам и лимитам. Проверяется прибыльность только по реально ставимым суммам.

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

Сценарий матча

Пример: 65-я минута, счёт 1:1, повышенная волатильность из‑за замены. Букмекер A повышает коэффициент на хозяев, букмекер B пока держит линию на гостей.

Поступают котировки: bookmaker_A — хозяева 2.40, гости 1.70; bookmaker_B — хозяева 2.05, гости 1.95. Алгоритм подбирает хозяева у A и гости у B. По формуле получается вилка с положительной маржой при допустимых объёмах.

Далее система рассчитывает оптимальные ставки с учётом лимитов и комиссий и отправляет запросы через API. Если одна ставка подтверждается частично, механизм резервирования корректирует вторую ставку или закрывает позицию хеджем на ближайшем доступном рынке.

Система также реагирует на отмены и откаты котировок. При значительном отклонении подтверждённых ставок или при превышении времени реакции предусмотрен автоматический откат по порогу X% или по времени Y миллисекунд.

Тестирование и мониторинг

Перед продакшном алгоритм тестируют на исторических потоках и синтетических сценариях. Бэктесты по реальным данным показывают долю реализованных вилок и распределение прибыли по объёмам и времени.

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

Вывод

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

Инвестиции в качественные потоки данных и в мониторинг обычно окупаются быстрее, чем попытки оптимизировать мелкие элементы матчинга. Вилка — это не только арифметика коэффициентов, но и дисциплина обработки потоков и управления рисками.