Volume Profile: чому кластерний аналіз обсягів ламається
Профіль обсягу — це гістограма розподілу обсягу угод за рівнями ціни за вибране вікно: за нею читають зони набору позиції та рівні, від яких ціна відштовхується.
Вважається профіль не зі свічок, а з потоку угод, тому якість результату цілком залежить від того, як цей потік оброблено на вході.
Основна поломка трапляється на піковому навантаженні біржі.
Коли приходить хвиля ліквідацій або відкривається сесія, інтенсивність потоку зростає в рази за секунди, а обробник залишається послідовним: черга зростає, розрахунок профілю обсягу відстає, і трейдер бачить гістограму, якої на ринку вже немає.
При відставанні агрегатор починає відкидати або склеювати події — пік у бакеті ціни або розмазується, або зникає зовсім.
Друге джерело — розбіжність даних між каналами. Угоди йдуть потоком, а історичні зрізи та глибини ринку підтягуються окремо, у джерел різні мітки часу та правила округлення ціни до тіка.
На стику вікна це дає різні гістограми для одного періоду в терміналі, у програмному інтерфейсі та у звіті: трейдер не розуміє, якому значенню вірити.
Окрема проблема — повторна доставка. При перепідключенні каналу частина угод приходить заново, і без дедуплікації обсяг враховується двічі: у бакеті виростає хибний пік, який читається як сильна зона.
Плюс повний перерахунок вікна на кожному оновленні: його вартість зростає разом із вікном, і в пік обробник не встигає.
Правильний устрій — інкрементальний агрегат за бакетами ціни з періодичними знімками стану та відтворюваним журналом сирих угод, щоб будь-яку гістограму можна було перезібрати й звірити.
Далі розбираємо, як це закривається: схема розрахунку, контроль розбіжностей і поведінка під навантаженням.
Що дає кластерний аналіз обсягів на криптобіржі
Кластерний аналіз обсягів перестає бути картинкою і стає інженерним контуром, коли в кожної його властивості є вимірювана величина.
Ці величини ми фіксуємо до впровадження і переперевіряємо після — за журналами перерахунку та звіркою з незалежним джерелом, наприклад TradingView, а не за відчуттями від графіка.
| Показник | До впровадження | Після | Чим перевіряємо |
|---|---|---|---|
| Час перерахунку кластерів | хвилини, перерахунок усього діапазону за запитом | секунди, добудовується на кожному оновленні | мітка часу в журналі перерахунку |
| Частка розбіжностей з еталоном | пропуски та «діри» в гістограмі | збіжність за обсягом і ціною | щоденна звірка вибірки угод |
| Клас відмов при розриві потоку | вітрина мовчки віддає застарілий зріз | період позначено як неповний | спостереження за затримкою та оповіщення |
| Зіставність даних | у кожного постачальника своя агрегація | єдина схема приведення угод | тести на історичних зрізах |
Що це дає на практиці: аналітик бачить, де справді пройшов великий обсяг, а не де домалював рівень наздоганяючий перерахунок. Вітрина аналітики залишається стійкою — випадіння потоку з однієї біржі звужує покриття, але не ламає розрахунок і не підміняє історію заднім числом.
Режими розрахунку Volume Profile: порівняння підходів
На біржі профіль обсягу перезбирається постійно: угоди йдуть, свічки закриваються, а трейдер чекає на актуальну картину.
Режим розрахунку задає компроміс між свіжістю даних, навантаженням на інфраструктуру та відтворюваністю історії — універсального варіанта немає, тому порівнюємо три підходи за тим, які обмеження кожен накладає на систему.
| Варіант | Коли підходить | Обмеження підходу |
|---|---|---|
| Потоковий розрахунок | Онлайн-графіки, віджети поточної сесії, оповіщення про пробій зон | Стан живе в пам'яті: перезапуск сервісу потребує швидкого відновлення зі знімка, пропуск або перестановка угод у стрічці спотворює гістограму, результат не переграється заднім числом |
| Пакетний перерахунок | Аналітика за минулі періоди, звіти, перевірка стратегій на історії | Профіль відстає від ринку — від хвилин до завершення вікна; пікові задачі завантажують сховище і конкурують за ресурси з онлайновим розрахунком |
| Гібридна схема | Робочий режим за замовчуванням: живий профіль плюс фонова звірка | Дорожче в супроводі: потрібні знімки стану, регламент звірки, розбір розбіжностей і політика повторних спроб |
Ключова метрика за будь-якого режиму — розбіжність між онлайновим і перерахованим профілем. Поки вона тримається в узгодженому допуску, рівням можна довіряти; щойно розбіжність зростає, аналітика вищого рівня та оповіщення починають працювати за невірними зонами.
Гібридна схема зазвичай стає кінцевою точкою: потоковий розрахунок закриває свіжість, пакетний — історію та перевірку. Перехід на неї плануємо так, щоб розрахунок не зупинявся, а старі періоди доїжджали фоном.
Як будується розрахунок кластерів: етапи впровадження
Кластерний аналіз обсягів ламається не на формулі, а на вхідних даних і порядку перерахунків. Тому впровадження йде від джерел до розрахункового контуру і лише потім до налаштування відображення. Нижче — порядок робіт, за якого результат відтворюється на історії, а не лише на живому потоці.
-
Аудит джерел даних. Розбираємо, що фактично віддає майданчик: стрічку угод, глибину історії, розбивку за сторонами, стакани. Перевіряємо повноту, затримки, пропуски, поведінку на низьколіквідних парах і в хвилини різких рухів. Підсумок — перелік джерел з їхніми обмеженнями та рішення, які дані добираємо другим каналом.
-
Схема розрахункового контуру. Фіксуємо, де дані осідають, як агрегуються за інтервалами і як перераховуються при уточненні історії. Задаємо крок ціни, вікно профілю, правила об'єднання сусідніх рівнів. Схема узгоджується до написання коду: правка в розрахунку коштує дорожче, ніж в інтерфейсі.
-
Налаштування розрахунку під задачу. Визначаємо набір параметрів, розділення покупок і продажів, роботу з тонкими та широкими інтервалами, значення за замовчуванням для різних типів інструментів. Користувацькі набори зберігаються, щоб трейдер повертався до своєї картини, а не збирав її заново.
-
Звірка розрахунків. Беремо еталонну добу і звіряємо обсяги за рівнями з незалежним джерелом і біржовими агрегатами. Розбіжність вище заданого порога розбираємо до причини: округлення кроку, втрачені угоди, різне трактування часу.
-
Перевірка під навантаженням і на збоях. Проганяємо потік високої інтенсивності, обриви з'єднання, повторне довантаження історії. Кластери не повинні дублюватися або обнулятися після перезапуску — інакше картина бреше в найневдаліший момент.
-
Передача в супровід. Віддаємо схему контуру, опис параметрів, журнали, метрики розрахунку та регламент оновлення при зміні формату майданчика. Домовляємося про звірку після запуску нових інструментів.
Реєстри, схеми та регламенти: комплект документації
Роботу з кластерного аналізу обсягів здаємо не лише запущеним сервісом, а й комплектом документації. Інакше за пів року ніхто не згадає, чому вікно агрегації вибрано саме таким, а підключення нової біржі перетворюється на перебір гіпотез.
Комплект збирається під час проєкту й оновлюється разом із кодом, а не відновлюється з пам'яті перед здачею.
- Реєстр сервісів і контурів: що розгорнуто, зв'язки між збирачем угод, агрегатором Volume Profile і сховищем, межі середовищ.
- Схеми контурів: шлях даних від потоку угод до готового профілю, точки відмови, поведінка при розриві зв'язку та перепідключенні.
- Конфігурації з коментарями: крок ціни, вікно агрегації, глибина історії, пороги фільтрації аномальних угод — і те, як кожен параметр впливає на підсумкову картину.
- Політики доступу: ролі, видача та ротація ключів до біржових сервісів, розподіл прав між середовищами.
- Регламент обслуговування: планові оновлення, звірка розрахунків з біржовими свічками, резервне копіювання та перевірка відновлення на стенді.
- Інструкції для команди: підйом локального оточення, розбір інциденту за логами, підключення нового інструмента або біржі.
- Журнал інженерних рішень: чому вибрано такий метод агрегації, які варіанти відхилено, якими перевірками підтверджено коректність.
Такий комплект скорочує введення нового інженера в контур: правки та доопрацювання вносяться за інструкцією, а не з пам'яті, і обслуговування залишається передбачуваним навіть при зміні команди.
Кейс біржі: кластерний аналіз обсягів до і після
До нас прийшла біржа з власним терміналом: профіль обсягу розходився з історією при перебудові вікна агрегації, і аналітики перестали довіряти вивантаженням.
Заміри до старту: розбіжність онлайн- і архівного профілю — 1,2 % угод, доба історії перераховувалася близько 40 хвилин, до 30 звернень на місяць до підтримки аналітики.
Що було причиною
Онлайн-потік оброблявся одним модулем агрегації, історія — іншим: різний крок цінової сітки та різні правила віднесення угоди до рівня. Частина даних доїжджала із затримкою, і профіль добудовувався заднім числом уже після відрисовки. Клієнти звіряли картину з еталоном на кшталт TradingView і бачили розбіжність.
Що змінили і що вийшло
Звели обидва потоки до єдиного правила: одна сітка цінових рівнів, один крок, явна політика обробки запізнілих угод і повторюваний перерахунок вікна. Профіль збирається за закритими інтервалами, повний перерахунок запускається лише при зміні параметрів графіка.
Розбіжності між онлайн- і історичним профілем упали з 1,2 % до 0,03 % угод. Доба історії перераховується приблизно за хвилину замість 40, час відгуку графіка на зміну вікна — менше секунди, звернення аналітиків до підтримки — одиниці на місяць замість трьох десятків.
Ми закрили не окрему помилку, а сам клас відмов: будь-який спірний випадок тепер відтворюється за журналом і дає однаковий результат на обох контурах — і на живому потоці, і на архіві.
Чим відрізняється кластерний аналіз обсягів від стрічки угод?
Стрічка угод — це потік виконаних угод: ціна, обсяг, сторона ініціатора та мітка часу.
Вона відповідає на питання «що відбувається прямо зараз» і осмислена у вікні від секунд до хвилин; на довгому горизонті щільність потоку згладжує структуру, а поодинокі сплески створюють хибне враження переваги покупців або продавців.
Профіль обсягу будується інакше: угоди розкладаються за ціновими рівнями за вибраний інтервал, і на виході виходить гістограма розподілу.
Усередині неї дві опорні точки — рівень максимального обсягу, де пройшла найбільша частка угод, і зона вартості, в яку потрапляє близько 70% обсягу інтервалу. Вони показують, де ринок погодився з ціною, а не хто був активнішим в останню хвилину.
Різниця підходів — в одиниці аналізу. Стрічка оперує подіями й потребує обробки в реальному часі, тому чутлива до пропусків у каналі даних і до дроблення великих заявок на дрібні.
Профіль оперує накопиченою статистикою за інтервалами: сесія, день, тиждень або складений профіль за кількома періодами.
Метод прийшов із ф'ючерсної торгівлі — Чиказька торгова палата застосовувала його для аналізу біржових сесій, — і на криптовалютних інструментах працює так само, лише інтервали задаються за безперервним ринком.
У торговому сервісі ці шари не замінюють, а доповнюють один одного: стрічка дає точку входу, профіль — контекст, у якому сигнал має сенс.
Ми збираємо обидва подання з одного очищеного потоку даних, щоб розбіжності між ними не виникали через різну фільтрацію та різне округлення цін.
Часті технічні питання щодо впровадження та супроводу
Чотири питання найчастіше спливають, коли розрахунок профілю обсягів передають команді замовника: повнота історії, збіжність із зовнішнім джерелом, навантаження на ядро та відповідальність після запуску. Коротко — по кожному.
Що робити, якщо історія угод неповна?
Пропуски в потоці — обрив зв'язку, рестарт вузла — закриваємо довантаженням за архівними зрізами та агрегованими свічками. Ділянки, де тикову картину відновити неможливо, позначаємо флагом достовірності: на графіку вони видно окремо і не видаються за еталон. Обсяги на ціновому рівні перераховуються повністю, а не дораховуються частково.
Як проходить звірка з постачальником даних?
Порівнюємо сумарний обсяг і розподіл за ціновими рівнями на еталонних вікнах з тим, що віддає постачальник. Розбіжність вище порога йде в моніторинг із прив'язкою до конкретного інтервалу — так відразу видно, це збій на нашій стороні чи затримка в джерела.
Яке навантаження лягає на ядро?
Профіль за рівнями вважається інкрементально в потоці угод, тому вартість операції не зростає з глибиною історії. Повний перерахунок вікна виконується пакетами в окремому пулі обробників з обмеженням паралелізму; графік віддається з готового зрізу і не конкурує з перерахунком.
Хто відповідає за розрахунок після передачі?
Залишається регламент супроводу: метрики лагу агрегації, частка відхилених пакетів, журнал перерахунків. При зміні формату даних біржі оновлюємо нормалізацію і проганяємо звірку на історичних вікнах до викату в робочому контурі.
Обговоримо задачу: підберемо режим розрахунку та план робіт
Розбір задачі за профілем обсягу починається не з вибору інструментів, а з вихідних даних: від їхньої повноти залежить, який режим розрахунку взагалі реалізуємо.
Якщо історія угод є, а знімків стакана немає, профіль будується за агрегованими угодами та дельтою; якщо є і те й інше, додаємо розподіл ліквідності за рівнями. Тому перший крок — короткий перелік того, що у вас уже є.
- Майданчики та інструменти: спот, ф'ючерси, кількість пар, за якими потрібен Volume Profile.
- Вивантаження: історія угод із ціною та обсягом, знімки стакана, період і глибина зберігання.
- Режим розрахунку: перерахунок за запитом на закритті бару або безперервний потік у реальному часі.
- Параметри профілю: крок ціни або об'ємний бар, розмір вікна, поділ за сесіями, облік дельти.
- Спосіб віддачі результату: програмний інтерфейс, файли, панель, вбудовування у ваш термінал або кабінет.
- Навантаження: скільки інструментів рахується паралельно і які піки за частотою оновлення.
- Поточний контур: сховище, схеми, уже написані розрахунки — щоб не дублювати зроблене.
Далі ми розбираємо ці дані, перевіряємо повноту та розриви і повертаємося з оцінкою обсягу: який режим розрахунку закриває задачу, що робимо на вашій стороні, що на нашій.
Після узгодження — старт проєкту за етапами: спочатку ядро розрахунку на історичних даних, потім звірка з еталонними значеннями, далі виведення у ваш інтерфейс. Опишіть задачу — повернемося з оцінкою та планом робіт.
