Индикатор ликвидаций для криптотрейдинга: данные, визуализация, алерты

Разработка индикатора ликвидаций: где рвётся поток данных

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

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

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

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

Что даёт витрина рыночных данных: измеримый эффект

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

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

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

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

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

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

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

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

Этапы внедрения: от аудита данных до передачи в работу

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

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

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

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

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

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

Комплект передаётся в общем репозитории вместе с историей изменений — доработки дальше можно вести своими силами или с нами.

Кейс: убрали задержку сигнала и ложные срабатывания

Точка старта

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

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

Что изменили и что получилось

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

Сверку с независимым источником, CoinGlass, перевели в автоматический режим: сходимость проверяется раз в сутки, расхождения видны сразу. Задержка сигнала сократилась с десятков секунд до одной-двух, доля ложных срабатываний упала с трети до единиц процентов, восстановление после обрыва занимает меньше минуты и не требует человека. Ручная сверка ушла полностью.

Метрики до и после снимали на одном и том же наборе рыночных событий — сравнение корректное, а не «почувствовалось».

Чем отличается поток ликвидаций от расчётной оценки объёма

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

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

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

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

Технические сомнения: задержки, пропуски, устойчивость

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

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

Источники дают разные объёмы — какому верить?

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

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

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

Биржа поменяла формат событий?

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

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

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

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

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

Следующий шаг простой: вы описываете задачу и вводные, мы разбираем их и присылаем схему с оценкой и планом. Если по какому-то пункту данных пока нет — так и напишите, соберём варианты.