Volume screener: де ламається саморобна розробка
Аномалії обсягу торгів живуть секунди, а перша версія скринера дізнається про них за хвилини.
Розробка volume screener найчастіше стартує з опитування публічного інтерфейсу біржі за десятками пар — і вже на сотні інструментів саморобний скринер біржі упирається в ліміти біржових запитів: виділена вага звернень з'їдається за десятки секунд, у відповідь приходить обмеження, потім тимчасове блокування адреси. Сигнал або запізнюється, або приходить уже по з'їденому руху.
Обхід очевидний — потік угод замість опитування.
Ламається він на обривах: канал відвалюється на хвилини, і якщо не зберігати курсор останньої обробленої події, не вставляти угоди ідемпотентно за їхнім ідентифікатором і не догравати пропущений інтервал з архіву, обсяг у вікні подвоюється. На графіку це сплеск, якого не було, а вхід — за хибною аномалією.
Третя тріщина — розходження метрик між джерелами. Обсяг у базовій і котирувальній валюті, спот і строковий ринок, різні межі вікна та часові пояси дають цифри, які не сходяться між собою.
Поки немає єдиної нормалізації та перерахунку в спільну одиницю, скринер обсягів криптовалют шумить спрацюваннями і втрачає довіру трейдерів — вони повертаються до ручного перегляду стаканів.
Усі три вузли — збір, відновлення після розриву та нормалізація — закриваються до того, як з'явиться перше спрацювання. Нижче розбираємо, як це влаштовано на практиці та де проходить межа між власним доопрацюванням і готовим контуром.
Що дає готовий скринер обсягів на біржових даних
Скринер обсягів для трейдингу рахує не абсолютний обсяг, а відхилення від власного профілю інструмента: медіана та медіанне відхилення за ковзним вікном замість середнього.
Середній обсяг ламається однією великою угодою, медіана — ні, тому сплеск на тонкому ринку не виглядає аномалією, поки він справді нею не є. Довідник пар та оцінку ліквідності підтягуємо з відкритих джерел, наприклад CoinGecko, і звіряємо з тим, що віддають самі біржі.
Моніторинг сплесків обсягу йде на потоці угод: сигнал формується в момент приходу угоди, а не на закритті свічки, тому затримка сигналу — частки секунди.
Обсяг нормується на волатильність інструмента і приводиться до порогу в сигмах, так що той самий поріг працює і на великих парах, і на низьколіквідних. Дедуплікація склеює серію угод одного заходу в одне повідомлення, щоб трейдер не отримав п'ять повідомлень про одну подію.
Точність сигналів скринера тримається на фільтрах, а не на підкручуванні порогу: мінімальна глибина стакана, максимальний спред, підтвердження другою хвилиною обсягу.
До трейдера доходить приблизно чверть від того, що дає «голий» поріг за обсягом, при цьому пропуск реальних аномалій залишається в межах похибки.
Клас відмов, який перестає доходити до трейдера, — аномалія на ринку, де ціну рухає одна заявка: вхід за нею дає прослизання більше за потенційний рух.
Ми логуємо, що саме відсіяв кожен фільтр, і за цими даними калібруємо пороги під конкретні інструменти та години торгів, а не під усереднений ринок.
Режими роботи скринера: потік, пакетний перерахунок, гібрид
Режим роботи скринера визначає, що замовник отримує раніше — сигнал про аномалію чи узгоджену картину по інструменту.
Потокова обробка угод читає стрічку з біржових каналів і накопичує обсяги в ковзних вікнах: сплеск видно через секунди після угоди, але при обриві з'єднання ділянка стрічки губиться безповоротно.
Пакетний перерахунок історії бере угоди та свічки за період з архіву і рахує метрики заново — дані сходяться до останньої угоди, але результат приходить із затримкою.
Гібридний режим скринера поєднує обидва: потік веде онлайн-метрики та подає сигнали, а перерахунок раз на кілька хвилин звіряє вікна з архівом і закриває пропуски.
Порівняння режимів
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потокова обробка угод | Реакція на сплеск обсягу в момент події, сигнали для ручної та алгоритмічної торгівлі | Затримка від часток секунди; обрив зв'язку залишає діру в історії; чутлива до пікового навантаження |
| Пакетний перерахунок історії | Аналітика, перевірка стратегій на історії, звіти, пошук аномалій заднім числом | Затримка від хвилин до годин; миттєвих сигналів немає; навантаження зростає з глибиною архіву |
| Гібридний режим скринера | Основний варіант для торгового продукту: онлайн-сигнали плюс вивірена історія | Дорожче в розробці та підтримці: узгодження вікон, дедуплікація, контроль розходжень |
Вибір диктує задача: для реакції на подію достатньо потоку, для аналітики — пакета, для робочого торгового контуру ставлять гібрид з автоперевіркою розходжень.
Розробка скринера обсягів: етапи від аудиту до передачі
Розробка скринера обсягів починається не з коду, а з аудиту джерел даних. На цьому кроці ми звіряємо майданчики між собою: однаково вони рахують обсяг, з якою затримкою віддають потік угод, чи є пропуски в історії, як поводитися з періодами, коли торги зупинялися.
Підсумок аудиту — перелік джерел, які дають зіставні дані, і явний список розходжень, які доведеться компенсувати на нашій стороні.
- Аудит джерел даних. Збираємо історію по кожному майданчику, звіряємо агрегований обсяг з незалежними зрізами, відзначаємо пропуски, дублі та розриви в часі.
- Схема потоків і зберігання. Описуємо шлях даних: приймання потокових каналів, нормалізація до єдиної шкали часу, відсів дублів, агрегація у вікна та свічки. Окремо вирішуємо, що зберігати в початковому вигляді, а що — лише в згорнутому.
- Налаштування порогів обсягу. Сплеск рахуємо не абсолютним числом, а перевищенням базової лінії за вікно: задаємо довжину вікна, множник спрацювання, мінімальний поріг ліквідності та відсічку за шириною спреду.
- Правила відбору та придушення деренчання. Визначаємо, які події потрапляють у видачу, як ранжуються і як один сплеск не перетворюється на десяток однотипних сигналів.
- Випробування на історичних даних. Прогоняємо правила по архіву, вимірюємо частку пропущених подій і хибних спрацювань, час від появи обсягу до сигналу, уточнюємо параметри.
- Приймання скринера. Звіряємо роботу на живому потоці з еталонною вибіркою, фіксуємо розходження, перевіряємо журнал сигналів і повернення до попередніх налаштувань.
- Передача. Віддаємо конфігурації, схеми потоків і регламент: як змінювати пороги, як додавати майданчик, за якими ознаками розуміти, що джерело почало віддавати неповні дані.
Після передачі пороги та правила змінюються без правок коду — налаштування винесені окремо, а рішення щодо кожної зміни спираються на історичні прогони, а не на відчуття.
Що залишається у вас: конфігурації, схеми, регламенти
Скринер обсягу марний, якщо правила відбору живуть у голові одного інженера і в парі скриптів на сервері. Тому кожен етап ми закриваємо артефактами, які можна відкрити, прочитати й передати іншій команді без довгих дзвінків. Нижче — що саме залишається у вас у репозиторії та в документації.
- Конфігурації алертів — файли з порогами за обсягом, вікном накопичення та коефіцієнтом відхилення від норми; правляться без перезбирання, версіонуються і відкочуються до попереднього набору.
- Схема потоків даних — шлях сигналу від джерела угод і стакана до розрахунку та сховища: де буферизація, де дедуплікація, яка затримка на кожній ділянці.
- Опис правил відбору — формули метрик (сплеск обсягу до ковзного середнього, дисбаланс покупок і продажів) і пороги окремо по інструментах з різною ліквідністю.
- Документація скринера — карта сервісів, змінні середовища, формат вхідних повідомлень, порядок перерахунку історії за минулі періоди.
- Регламент експлуатації — що перевіряти при пропуску сигналів, як перезапустити розрахунковий вузол, де дивитися журнали і куди йде повідомлення.
- Регламент чергування — три рівні подій (шум, підозра, інцидент), час реакції на кожен і порядок ескалації.
- Схема інтеграцій — точки підключення до біржових інтерфейсів, торгового термінала і звітності, розмежування прав доступу.
- Набір для перевірки — історичні вікна, на яких переграються правила, і тест, що зміна порогу не ламає відбір.
Кейс: як скринер обсягів прибрав хибні сигнали
До: потік сигналів, який нічим фільтрувати
Скринер працював на одній простій умові — надсилати все, де обсяг за останню годину відхилився від середнього. За понад сорок відстежуваних пар це давало 70–90 оповіщень на добу, з яких до справжнього сплеску належали одиниці.
Аналітик витрачав 3–4 години на ручний розбір: звіряв свічки, дивився глибину ринку і все одно часто не встигав увійти в рух.
Що змінили в механіці відбору
Потік угод з Binance та інших майданчиків зводили в єдиний нормалізований ряд, і обсяг порівнювався вже не із середнім, а з медіанним профілем за часом доби та днем тижня.
Сигнал вимагав підтвердження на сусідніх таймфреймах і відсікався, якщо сплеск давали одна-дві великі угоди без зростання числа учасників. Пари з тонкою ліквідністю пішли з вибірки за мінімальним порогом обороту.
Що стало після впровадження
Число оповіщень упало з 70–90 до 8–12 на добу, частка хибних — приблизно з 85% до 20%. Час реакції скоротився з 25–40 хвилин ручної перевірки до 1–2 хвилин: сигнал приходить уже з контекстом — таймфрейм, ліквідність пари, профіль обсягу.
Пропущених сплесків за перший квартал роботи — нуль проти 5–6 на тиждень до цього, а розбір сигналів перестав займати робочий день.
Пороги та вікна усереднення винесені в конфігурацію, тому під інший горизонт торгівлі правила перезбираються без переписування логіки.
Історія оповіщень зберігається з параметрами на момент спрацювання — будь-який сигнал можна переперевірити заднім числом і зрозуміти, чому він пройшов фільтр.
Чим потоковий скринер відрізняється від пакетного перерахунку?
Пакетний скринер працює за розкладом: бере зріз історії угод за вікно, перераховує об'ємні метрики по всіх парах і віддає готовий список. Той самий зріз завжди дає однаковий результат — розходження між прогонами пояснювані, а спірну ситуацію легко відтворити.
Обмеження в тому, що між перерахунками ринок живе своїм життям, і сплеск обсягу на початку вікна ви побачите тільки до наступного прогону.
Потоковий режим тримає метрики в пам'яті й оновлює їх на кожній угоді — затримка сигналу вимірюється секундами, а не інтервалом перерахунку.
Плата за швидкість: результат залежить від порядку та повноти подій, тому потрібні ковзні вікна з чіткою межею і правила дедуплікації повторів.
Порівняння режимів зводиться до трьох осей: затримка сигналу, повнота даних і поведінка при обриві зв'язку. Пакетний переживає розрив непомітно: наступний прогін бере історію заново і дораховує пропущений інтервал.
Потоковий втрачає шматок вікна — метрика занижується, і сигнал або не спрацьовує, або приходить на викривленому обсязі. Тому навколо потоку будують буфер подій, контроль відставання споживача та довантаження пропущеного відрізка з історії з перерахунком зачеплених вікон.
Вибір диктує торгова логіка. Потрібна відтворювана звітність і рішення на закритті інтервалу — вистачає пакетного перерахунку. Потрібна реакція в перші секунди та короткоживучий сигнал — беруть потоковий режим і окремо проєктують відновлення після розривів.
На практиці частіше збирають гібрид: потік дає миттєвий сигнал, а пакетний прогін раз на інтервал звіряє розходження і підчищає пропуски.
Технічні сумніви: затримки, ліміти бірж, хибні спрацювання
Більшість інженерних питань до скринера — про межу з майданчиками: частоту запитів, тонкий ринок, обриви зв'язку. Нижче — відповіді на те, що найчастіше перевіряють до старту.
Як обходите ліміти біржових даних?
Запити не дублюються: один збирач на майданчик, сигнали розходяться підписникам усередині системи. Угоди та стакан беремо потоковою підпискою, історію довантажуємо пакетами із запасом за лімітом, довідники монет кешуємо.
При упорі в стелю збирач сам знижує частоту за другорядними парами — пріоритетні залишаються на повній.
Звідки хибні спрацювання на тонкому ринку?
Фільтр відсікає пари, де обсяг одиничних угод викривляє картину: мінімальна глибина стакана, граничний спред, число угод за вікно. Сигнал підтверджується за кількома джерелами, а сплеск обсягу без руху ціни позначається як разовий.
Що відбувається при обриві зв'язку?
Перепідключення без втрати стану: буфер тримає останні тіки, після відновлення наздоганяємо пропущений інтервал і звіряємо зріз. Якщо розходження вище допуску, вікно позначається неповним і сигнали за ним не публікуються — краще пропустити, ніж видати викривлений. Стійкість перевіряємо регламентно: рвемо з'єднання і перезапускаємо збирач у тестовому середовищі.
Як вимірюєте затримки скринера?
Метрика — від появи угоди на майданчику до публікації сигналу, окремо для потоку і для опитування. Замір іде по кожному вузлу, тому видно, де накопичується час: збір, розрахунок чи доставка повідомлення. Поріг задаємо від торгової логіки замовника, а не «середній по ринку».
Обговоримо задачу: повернемося зі схемою та планом впровадження
Щоб оцінка розробки скринера спиралася на факти, а не на здогадки, до старту потрібен короткий набір ввідних. Від замовника чекаємо таке.
- Список бірж і пар: спотові, безстрокові контракти, окремі котирувальні пари — від нього залежить число потоків угод.
- Глибина історії: з якого моменту потрібні сплески обсягу і за який період рахуємо норму — це визначає спосіб довантаження та зберігання.
- Правило аномалії: зростання обсягу до середнього за вікно, частка від обороту пари або число угод за хвилину — яку ознаку вважаєте сигналом.
- Канали доставки сигналу та отримувачі: особистий кабінет, чат, виклик вашої системи.
- Доступи: ключі лише на читання, тестовий контур біржі, обмеження за частотою запитів.
- Критерій приймання: допустима затримка від угоди до сигналу і прийнятна частка хибних спрацювань.
У відповідь віддаємо не оцінку на словах, а робочий комплект за підсумками першого розбору задачі.
- Схему рішення: джерела даних, обробка, сховище, точки відмови та їхній обхід.
- Склад робіт за етапами й оцінку розробки скринера з планом впровадження.
- Правила фільтрації з параметрами: вікно усереднення, поріг, мінімальне число угод.
- Журнал метрик: свіжість даних, пропуски, число сигналів на пару та за днями.
- Інструкцію з експлуатації та порядок перевірки на історії перед запуском.
Опишіть задачу скринера та доступні дані — повернемося з оцінкою і планом впровадження.
