Розробка індикатора ліквідацій: де рветься потік даних
Дані про примусові закриття надходять від біржі окремим каналом, у якого своя затримка ринкових даних — від часток до кількох секунд у момент пікового навантаження.
Поки подія доходить до розрахункового контуру, ціна вже пройшла більшу частину руху, і індикатор малює сплеск там, де ринок його давно відпрацював. Мітка часу при цьому ставиться двічі — на боці джерела й на боці отримувача, — і розбіжність між ними майже ніхто не вимірює.
Друге вузьке місце — склеювання подій за часом. Потік про примусові закриття збирається з кількох місць: біржової стрічки, агрегатора, власного збирача котирувань.
Якщо зводити їх за моментом отримання, а не за біржовою міткою, один і той самий сплеск або розмазується по кількох інтервалах, або подвоюється. Дедуплікація за ідентифікатором угоди та єдина шкала часу обов'язкові, інакше обсяг в індикаторі перестає відповідати реальності.
Третій і найдорожчий розрив — пропуски в потоці угод у години високої волатильності. Частота подій у такі моменти зростає кратно, джерело починає різати вибірку, буфер переповнюється, і частина примусових закриттів просто не доходить до індикатора.
Виходить інверсія: сигнал показує затухання там, де йде каскад, і рішення ухвалюється за заниженим обсягом. Виявляється це лише звіркою з незалежним джерелом і контролем розривів у реальному часі.
Тому розробка індикатора ліквідацій починається не з відмальовування графіка, а з оцінки якості ринкових даних: повнота потоку за добу, частка дублів, розбіжність міток часу, поведінка під час обриву з'єднання.
Без цих вимірювань візуалізація та алерти будуються на цифрах, яким не можна вірити. Розбираємо, як це закривається на кожному шарі — від приймання подій до логіки сигналу.
Що дає вітрина ринкових даних: вимірюваний ефект
Швидкість реакції задається тим, як події потрапляють у систему. Коли ліквідації надходять підпискою на потік, а не опитуванням за таймером, шлях від угоди до оповіщення займає секунди — трейдер встигає відпрацювати каскад, а не читати про нього постфактум.
Хибні спрацювання — причина, через яку оповіщення зазвичай вимикають. Правило будується не на одиничній угоді, а на кластері: поріг за сумарним обсягом у ковзному вікні, дедуплікація повторів і антифлуд під час надсилання. Частка хибних спрацювань падає в рази, значущі сплески при цьому не губляться.
Повнота історії угод тримається на звірці: архівні снапшоти підвантажуються зворотним заповненням, а розриви за часом шукає регулярна перевірка. Запис ідемпотентний за ключем події — повторна доставка не створює дублів, перезапуск збирача не залишає пропусків.
Стійкість до обривів зв'язку — окремий шар. Перепідключення відбувається з інтервалом, що зростає, буфер тримає не надіслані події, а після відновлення каналу система довантажує пропущене вікно і звіряє його з джерелом. Збір продовжується без ручного втручання інженера.
Зменшення ручної звірки приходить із єдиною зведеною панеллю: агрегати за біржами, інструментами та годинними інтервалами збираються самі, регламентний звіт формується за розкладом, а розбіжності піднімаються як окрема подія.
Способи отримання даних: потік біржі, агрегатор, власний вузол
Індикатор ліквідацій будується не на свічках, а на потоці подій: примусові закриття позицій, сплески ставки фінансування, зміни глибини книги замовлень.
Джерела різняться повнотою, затримкою та вартістю підтримки — універсального варіанта немає, вибір залежить від задачі та від того, наскільки критичний розрив у потоці.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потік біржі напряму | одна-дві площадки, потрібна мінімальна затримка й повний склад подій | власна схема повідомлень і ліміти на підписки в кожної площадки; під час обриву з'єднання події губляться, відрізок доводиться надолужувати з історії |
| Агрегатор ринкових даних | зведення за десятками площадок в єдиному форматі | затримка вища за біржову; глибина історії та частота оновлень залежать від рівня підписки, рідкісні події відфільтровані |
| Власний вузол | потрібні події з мережі блокчейну: транзакції ліквідацій у протоколах, комісії | потребує синхронізації та обслуговування, відстає від реального часу на кілька блоків, внутрішні ліквідації бірж не бачить |
На практиці схема підключення будується на двох джерелах: основний канал дає мінімальну затримку, резервне джерело даних підхоплює під час обриву — індикатор продовжує рахувати, а пропущений відрізок надолужується з архівних вивантажень.
Події приводяться до єдиного формату (площадка, інструмент, сторона, обсяг, час) і дедуплікуються за ідентифікатором угоди: без цього після перепідключення лічильник ліквідацій подвоюється і алерт спрацьовує хибно.
Етапи впровадження: від аудиту даних до передачі в роботу
Впровадження починається не з візуалізації, а з перевірки, звідки надходять дані про ліквідації. Площадки віддають їх по-різному: одні — потоком подій, інші — лише агрегованими інтервалами із затримкою.
Поки не ясно, яка частота оновлення та глибина історії доступні, будь-який графік будується на здогадах.
- Аудит джерел даних. Звіряємо по кожній площадці, що доступно: потік подій, додатковий запит історії, обмеження на частоту звернень, пропуски в окремі години. Фіксуємо, де дані повні, а де метрику доведеться відновлювати опосередковано.
- Схема потоку даних. Будуємо шлях від джерела до графіка: приймання, приведення до єдиного формату, буферизація, запис у сховище часових рядів, розрахунок, віддача в інтерфейс. Схема одразу показує, де ставити чергу, щоб сплеск ліквідацій не валив приймання.
- Налаштування збору та зберігання. Піднімаємо приймач з автоперепідключенням і відсіканням дублів, пишемо в базу часових рядів з різними політиками зберігання: сирі події окремо, агрегати окремо.
- Розрахунок метрики. Рахуємо обсяг ліквідацій за інтервал, розбивку на лонги та шорти, накопичення й згладжування, пороги для сигналів. Формула живе окремим модулем — її можна змінювати, не перезбираючи збір і графік.
- Перевірка на історичних даних. Прогоняємо розрахунок на кількох місяцях реальної історії та звіряємо з тим, що показували площадки. Дивимося поведінку в моменти різких рухів — там проявляються пропуски й подвійний рахунок.
- Передача в експлуатацію. Віддаємо регламент: як підключити нову площадку, що робити при розриві потоку, як перезапустити перерахунок, де дивитися стан збору. Плюс оповіщення про деградацію.
Кожен етап закінчується артефактом: переліком джерел, схемою, конфігурацією, описом формули, звітом звірки та регламентом.
Комплект поставки: конфігурації, схеми, регламенти
Замовник отримує не лише працюючий індикатор, а комплект, за яким внутрішня команда зможе супроводжувати рішення без нас. Нижче — що саме входить у поставку і в якому вигляді.
- Конфігурації збору даних — перелік джерел, частота опитування, правила зіставлення угод за ринками й часовими поясами, пороги, за яких угода вважається ліквідацією. Змінюються правкою файла налаштувань, без перезбирання.
- Схема потоків даних — шлях від отримання угоди до розрахунку метрики й відмальовування графіка: де накопичується буфер, де відсікаються дублі, що відбувається при обриві каналу і як відновлюється пропущений інтервал.
- Правила доступу та ролі — хто бачить лише агрегати, хто може змінювати пороги, хто керує підписками на оповіщення; кожна зміна порогу пишеться в журнал з автором і часом.
- Документація щодо рішення — формули метрик, словник полів, розбір типових розбіжностей з даними біржі, інструкція з локального запуску на тестовому наборі.
- Регламент експлуатації — порядок оновлення джерел, щоденний контроль повноти даних, дії чергового, коли сплеск ліквідацій не підтверджується ринковою подією.
- Налаштування оповіщень — тексти повідомлень, пороги спрацювання та «тихі години», щоб індикатор не виснажував увагу команди.
Комплект передається в спільному репозиторії разом з історією змін — доопрацювання далі можна вести своїми силами або з нами.
Кейс: прибрали затримку сигналу та хибні спрацювання
Точка старту
Трейдерська команда отримувала сигнал про сплеск ліквідацій із затримкою в десятки секунд — рух на той момент уже відпрацьовував, і вхід за таким оповіщенням був запізнілим.
Дані йшли з кількох джерел, і зводити їх доводилося вручну: на звірку йшло дві-три години на день, а розбіжності за обсягом сплеску все одно залишалися.
Поріг спрацювання був один на всі режими ринку. На спокійному ринку він ловив шум — частка хибних сигналів сягала третини. Під час обриву з'єднання стрічка просто зупинялася: відновлення потребувало ручного перезапуску й повторного завантаження історії.
Що змінили і що вийшло
Приймання даних і розрахунок розділили: потік іде через буфер із підтвердженням доставки, агрегація рахується за часовими вікнами, а поріг підлаштовується під волатильність за останні години.
Перепідключення й довантаження пропущеної ділянки виконуються автоматично, тому обрив більше не означає втрату даних.
Звірку з незалежним джерелом, CoinGlass, перевели в автоматичний режим: збіжність перевіряється раз на добу, розбіжності видно одразу.
Затримка сигналу скоротилася з десятків секунд до однієї-двох, частка хибних спрацювань упала з третини до одиниць відсотків, відновлення після обриву займає менше хвилини й не потребує людини. Ручна звірка зникла повністю.
Метрики до і після знімали на одному й тому самому наборі ринкових подій — порівняння коректне, а не «відчулося».
Чим відрізняється потік ліквідацій від розрахункової оцінки обсягу
Плутанина виникає тому, що обидва числа описують одне явище — примусове закриття позицій, — але отримуються різними способами. Потік ліквідацій — це фактичні дані біржі: запис надходить від площадки з ціною, стороною та номіналом закритої позиції.
Розрахункова оцінка обсягу — відновлення тих самих подій за непрямими ознаками, коли прямого потоку за інструментом немає.
Фактичний потік майже ніколи не буває повним. Велика позиція рідко закривається одним виконанням — вона йде серією угод, а частина обсягу гаситься через страховий фонд або аукціон, і в потік такі закриття не потрапляють.
Біржі публікують дані з різною деталізацією: одні віддають кожну подію, інші — зведення за інтервал, за частиною інструментів потоку немає зовсім.
Методика розрахунку спирається на зв'язку «різкий рух ціни плюс падіння відкритого інтересу швидше за звичайне»: різницю приписують примусовим закриттям, напрямок свічки задає сторону.
Усередині завжди є припущення — яка частка скорочення відкритого інтересу прийшла саме від ліквідацій, а яка від ручного закриття позицій. Звідси розбіжність у рази: оцінка рахує номінал позиції, потік — виконаний обсяг.
Розбіжність джерел посилюють різні вікна агрегації та визначення ліквідації в кожної площадки. Публічні агрегатори на кшталт CoinGlass складають різнорідні дані в одну цифру, і вона рідко збігається з тим, що трейдер бачить у терміналі своєї біржі.
В індикаторі ці шари розведені: потік і оцінка йдуть окремими серіями, у точки є ознака джерела, а де потоку немає — значення позначене як розрахункове.
Технічні сумніви: затримки, пропуски, стійкість
Затримка в потоці ліквідацій, пропуск події, розбіжність між джерелами — для публічних ринкових даних це штатний режим, а не аварія. Питання в тому, чи помічає це індикатор: мовчки згладжений пропуск небезпечніший за явну помилку, бо на його основі ухвалюють рішення.
Тому контроль повноти закладено в сам конвеєр — у кожної події є номер послідовності, і розрив у нумерації фіксується до потрапляння цифри на графік. Нижче — розбори питань, які найчастіше виникають під час приймання.
Що буде, якщо частина подій не дійшла?
Вікно недоступності надолужуємо запитом історії, дублі відсікаємо за ідентифікатором угоди. Склеєну ділянку позначаємо на графіку окремою міткою — пропуск видно, а не розчиняється у згладженій лінії.
Джерела дають різні обсяги — якому вірити?
Базовим вважаємо джерело з найбільшою повнотою, решта працюють для звірки. Розбіжність вище заданого порогу підсвічуємо окремою подією, а не усереднюємо мовчки.
Що відбувається під час обриву зв'язку?
Перепідключення з паузою, що зростає, буфер подій на диску, стан розрахунку не скидається. Алерт про розрив іде в той самий канал, що й торгові сигнали, — мовчазних провалів не залишається.
Біржа змінила формат подій?
Схема описана конфігом, тому новий формат підключається правкою адаптера без перезбирання логіки розрахунку. Перед випуском прогоняємо записаний набір подій і звіряємо підсумкові значення з еталоном.
Обговоримо задачу: зберемо схему та план робіт
Щоб повернутися з оцінкою та планом робіт, а не із загальними словами, нам потрібен від вас короткий ввід по задачі. Нижче — що достатньо підготувати, решту уточнимо на розборі.
- Список бірж і торгових пар, за якими потрібен індикатор ліквідацій, і пріоритет між ними.
- Визначення події: з якого обсягу позицію вважати ліквідованою і за яке вікно сумувати дані.
- Глибина історії: за який період піднімати дані і чи потрібне перезавантаження пропущеної ділянки після збою зв'язку.
- Формат візуалізації: кластери обсягів, теплова карта, стрічка подій — і на якому екрані це дивляться.
- Канали алертів: месенджер, лист, звук у терміналі або ваш власний приймач сигналів; правило спрацювання та захист від дублів.
- Доступи: права на читання ринкових даних, у якому контурі працює система і куди дозволено складати історію.
- Навантаження: скільки користувачів і скільки подій у піку схема має тримати без втрати знімків.
За підсумками розбору повернемо схему рішення: джерела даних, шар обробки, сховище, інтерфейс та алерти, — плюс етапи робіт з оцінкою та порядком запуску.
Наступний крок простий: ви описуєте задачу та ввідні, ми розбираємо їх і надсилаємо схему з оцінкою та планом. Якщо за якимось пунктом даних поки немає — так і напишіть, зберемо варіанти.
