Разработка volume screener для криптовалютного трейдинга

Volume screener: где ломается самописная разработка

Аномалии объёма торгов живут секунды, а первая версия скринера узнаёт о них через минуты. Разработка volume screener чаще всего стартует с опроса публичного интерфейса биржи по десяткам пар — и уже на сотне инструментов самописный скринер биржи упирается в лимиты биржевых запросов: выделенный вес обращений выедается за десятки секунд, в ответ приходит ограничение, затем временная блокировка адреса. Сигнал либо запаздывает, либо приходит уже по съеденному движению.

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

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

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

Что даёт готовый скринер объёмов на биржевых данных

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

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

Точность сигналов скринера держится на фильтрах, а не на подкрутке порога: минимальная глубина стакана, максимальный спред, подтверждение второй минутой объёма. До трейдера доходит примерно четверть от того, что даёт «голый» порог по объёму, при этом пропуск реальных аномалий остаётся в пределах погрешности.

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

Режимы работы скринера: поток, пакетный пересчёт, гибрид

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

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

Сравнение режимов

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

Разработка скринера объёмов: этапы от аудита до передачи

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

1. Аудит источников данных. Собираем историю по каждой площадке, сверяем агрегированный объём с независимыми срезами, отмечаем пропуски, дубли и разрывы во времени.
2. Схема потоков и хранение. Описываем путь данных: приём потоковых каналов, нормализация к единой шкале времени, отсев дублей, агрегация в окна и свечи. Отдельно решаем, что хранить в исходном виде, а что — только в свёрнутом.
3. Настройка порогов объёма. Всплеск считаем не абсолютным числом, а превышением базовой линии за окно: задаём длину окна, множитель срабатывания, минимальный порог ликвидности и отсечку по ширине спреда.
4. Правила отбора и подавление дребезга. Определяем, какие события попадают в выдачу, как ранжируются и как один всплеск не превращается в десяток однотипных сигналов.
5. Испытания на исторических данных. Прогоняем правила по архиву, измеряем долю пропущенных событий и ложных срабатываний, время от появления объёма до сигнала, уточняем параметры.
6. Приёмка скринера. Сверяем работу на живом потоке с эталонной выборкой, фиксируем расхождение, проверяем журнал сигналов и возврат к предыдущим настройкам.
7. Передача. Отдаём конфигурации, схемы потоков и регламент: как менять пороги, как добавлять площадку, по каким признакам понимать, что источник начал отдавать неполные данные.

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

Что остаётся у вас: конфигурации, схемы, регламенты

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

• Конфигурации алертов — файлы с порогами по объёму, окну накопления и коэффициенту отклонения от нормы; правятся без пересборки, версионируются и откатываются к предыдущему набору.
• Схема потоков данных — путь сигнала от источника сделок и стакана до расчёта и хранилища: где буферизация, где дедупликация, какая задержка на каждом участке.
• Описание правил отбора — формулы метрик (всплеск объёма к скользящему среднему, дисбаланс покупок и продаж) и пороги отдельно по инструментам с разной ликвидностью.
• Документация скринера — карта сервисов, переменные окружения, формат входящих сообщений, порядок пересчёта истории за прошлые периоды.
• Регламент эксплуатации — что проверять при пропуске сигналов, как перезапустить расчётный узел, где смотреть журналы и куда уходит уведомление.
• Регламент дежурства — три уровня событий (шум, подозрение, инцидент), время реакции на каждый и порядок эскалации.
• Схема интеграций — точки подключения к биржевым интерфейсам, торговому терминалу и отчётности, разграничение прав доступа.
• Набор для проверки — исторические окна, на которых переигрываются правила, и тест, что смена порога не ломает отбор.

Кейс: как скринер объёмов убрал ложные сигналы

До: поток сигналов, который нечем фильтровать

Скринер работал на одном простом условии — присылать всё, где объём за последний час отклонился от среднего. При сорока с лишним отслеживаемых парах это давало 70–90 оповещений в сутки, из которых к настоящему всплеску относились единицы. Аналитик тратил 3–4 часа на ручной разбор: сверял свечи, смотрел глубину рынка и всё равно часто не успевал войти в движение.

Что изменили в механике отбора

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

Что стало после внедрения

Число оповещений упало с 70–90 до 8–12 в сутки, доля ложных — примерно с 85% до 20%. Время реакции сократилось с 25–40 минут ручной проверки до 1–2 минут: сигнал приходит уже с контекстом — таймфрейм, ликвидность пары, профиль объёма. Пропущенных всплесков за первый квартал работы — ноль против 5–6 в неделю до этого, а разбор сигналов перестал занимать рабочий день.

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

Чем потоковый скринер отличается от пакетного пересчёта?

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

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

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

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

Технические сомнения: задержки, лимиты бирж, ложные срабатывания

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

Откуда ложные срабатывания на тонком рынке?

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

Что происходит при обрыве связи?

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

Как измеряете задержки скринера?

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

Обсудим задачу: вернёмся со схемой и планом внедрения

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

• Список бирж и пар: спотовые, бессрочные контракты, отдельные котировальные пары — от него зависит число потоков сделок.
• Глубина истории: с какого момента нужны всплески объёма и за какой период считаем норму — это определяет способ догрузки и хранения.
• Правило аномалии: рост объёма к среднему за окно, доля от оборота пары или число сделок в минуту — какой признак считаете сигналом.
• Каналы доставки сигнала и получатели: личный кабинет, чат, вызов вашей системы.
• Доступы: ключи только на чтение, тестовый контур биржи, ограничения по частоте запросов.
• Критерий приёмки: допустимая задержка от сделки до сигнала и приемлемая доля ложных срабатываний.

В ответ отдаём не оценку на словах, а рабочий комплект по итогам первого разбора задачи.

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

Опишите задачу скринера и доступные данные — вернёмся с оценкой и планом внедрения.