Чому Volume Profile розходиться з торговою стрічкою
Трейдер бачить у стрічці велику угоду за однією ціною, а профіль обсягу (Volume Profile) за інструментом малює концентрацію на кілька рівнів вище. Це не дефект відображення: розходження профілю обсягу означає, що рішення ухвалюється за рівнем, якого в реальних угодах не було.
Корінь зазвичай у джерелі даних для профілю. Стрічка — це потік окремих угод із ціною та розміром, а профіль обсягу на криптобіржі часто збирають з агрегованих свічок: свічка дає обсяг за інтервал, але не каже, як він розподілений усередині.
Якщо розподіл відновлюють за типовою ціною, профіль бреше саме там, де він потрібен — на рівнях з однією великою угодою.
Друга половина поломки — затримка в розрахунку профілю. Коли вікно перераховується цілком за розкладом, а не в міру надходження угод, відставання накопичується: на імпульсі рівень уже відпрацьовано, а графік лише домальовує його.
Сюди ж додаються різні правила агрегації угод у майданчиків, різні години торгів і угоди поза біржею — і профіль обсягу за інструментом перестає бути зіставним зі стрічкою.
Ми беремо профіль із того самого потоку угод, що й стрічка, оновлюємо його в міру надходження угод і тримаємо звірку зі стрічкою як критерій приймання: розходження — це баг, а не особливість графіка. Далі показуємо, як це влаштовано в нашій роботі.
Що дає Volume Profile платформі та трейдерам
Профіль обсягу розкладає потік угод за ціновими рівнями за вибране вікно і показує, де обсяг пройшов реально, а де рух тримався на тонкому стакані.
Для трейдера це рівні, від яких ціна відштовхується, для платформи — готовий агрегат, який віддається клієнту замість локального перерахунку свічок на кожному графіку.
Що змінюється для трейдера
Профіль обсягу для трейдерів рахується на сервері й приходить снапшотом із дельтами. Після сплеску активності відображення не деградує: замість повного проходу по вікну перераховуються лише зачеплені рівні, тому гістограма оновлюється за той самий час, що й на спокійному ринку. Зміна роздільності — повторне використання вже порахованих агрегатів, а не новий розрахунок з нуля.
Що змінюється для платформи
Аналітика обсягу на біржі тримається на одному розрахунковому модулі, який обслуговує всі клієнтські сесії: кількість підписників зростає, а навантаження на розрахунковий модуль — ні, вікно рахується один раз і роздається.
Частка перерахунків падає: дельти закривають більшість оновлень, повний прохід залишається для відновлення вікна та зміни роздільності.
Збіжність даних біржі перевіряється звіркою агрегату з незалежним снапшотом: розходження за рівнем позначається і не йде в інтерфейс, тому кількість звернень за некоректними даними скорочується — помилка видна в моніторингу, а не в терміналі трейдера.
За еталон подання беремо TradingView: ті самі зони цінності, але розрахунок цілком на стороні платформи.
Підходи до розрахунку профілю обсягу: порівняння
Агрегація угод у профіль спирається на одне з двох джерел: потік угод у реальному часі або вже збережені бари.
Перший дає деталізацію до окремої угоди, другий дешевший за навантаженням, але втрачає внутрішньобарний розподіл, якщо у сховищі лежать лише ціни відкриття, максимуму, мінімуму та закриття. Звідси й розвилка: яка точність потрібна трейдеру і що вже є в торговому ядрі платформи.
На сумісність із працюючою системою впливає не лише джерело, а й момент перерахунку. Профіль, який рахують онлайн, потребує стабільної та повної стрічки угод; профіль, який збирають пакетно, накочується на історію без змін у логіці матчингу. Нижче — чотири варіанти та їхні обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Онлайн-розрахунок із потоку угод | Потрібна деталізація до окремої угоди, профіль оновлюється на кожній угоді | Тримає гарячий буфер за інструментом; пропуск у стрічці заднім числом не відновлюється |
| Агрегація за збереженими барами | Історія котирувань уже є, навантаження на сховище мінімальне | Внутрішньобарний розподіл втрачається, профіль вироджується в гістограму за закриттями |
| Гібридний розрахунок профілю | Потрібна точність на свіжій ділянці та глибока історія без перерахунку всього масиву | Дві моделі даних мають сходитися на стику, потрібна регулярна звірка |
| Історичний перерахунок профілю | Змінюється методика групування ціни або глибина зберігання | Потребує вікна обслуговування або розрахунку на репліці, конкурує за ресурси з ядром |
Вибір фіксується в конфігурації до старту робіт: крок групування ціни, глибина зберігання, режим перерахунку та спосіб звірки на стику потоків. Наші інженери підбирають варіант під уже працююче ядро — профіль вбудовується без переписування торгової логіки.
Етапи впровадження профілю обсягу на платформі
Профіль обсягу — це не окрема панель, а розрахунковий контур: потік угод, агрегація за ціновими рівнями, зберігання та віддача в торговий інтерфейс.
Тому впровадження профілю обсягу йде фіксованою послідовністю — так розходження на виході локалізується до конкретного етапу, а не шукається по всьому ланцюжку.
- Розбір джерел даних. Дивимося, які потоки віддає біржа, як надходять угоди та стакан, де можливі дублі та розриви при перепідключенні, яка глибина історії доступна.
- Аудит схеми розрахунку. Фіксуємо крок групування цін, вікно накопичення, правила обробки аукціонів і великих позабіржових угод — до рівня формул, інакше результат нічим звіряти.
- Зберігання та перерахунок. Вибираємо між додаванням нових угод і повним перерахунком, задаємо глибину історії та набір інтервалів, щоб графік відкривався без очікування.
- Приймання на історичних даних. Прогоняємо розрахунок на вибраних періодах, включно з волатильними днями, і звіряємо з еталонною вибіркою: розходження має бути зрозумілим, а не «приблизно схоже».
- Навантажувальна перевірка розрахунку. Подаємо піковий потік угод і дивимося затримку віддачі та споживання пам’яті; фіксуємо поріг, після якого деградація стає помітною користувачу.
- Відмовостійкість. Перевіряємо перезапуск сервісу, відновлення після обриву зв’язку та повторний розрахунок без задвоєння рівнів.
- Передача контуру. Віддаємо конфігурації, метрики, регламент оновлення та порядок дій при розходженні.
Кожен етап закінчується артефактом: специфікація джерел, опис схеми розрахунку, протокол приймання, звіт за навантаженням. Команда замовника приймає роботу за цифрами, а не за враженням від графіка.
Склад артефактів: схеми, регламенти, конфігурації
Ми передаємо не лише працюючий розрахунковий контур, а й комплект документів, за яким його можна розвивати та супроводжувати власними силами. Артефакти прив’язані до етапів експлуатації: розгортання, повсякденний контроль, плановий перерахунок і розбір інцидентів. Нижче — що саме залишається в команди замовника.
- Схема потоків даних — шлях від джерела угод до агрегованого профілю обсягу: які контури беруть участь, де буферизація, де черга, яка точка вважається єдиною точкою відмови.
- Конфігурації розрахункового контуру — параметри агрегації (крок ціни, вікно накопичення, глибина історії), ліміти навантаження, правила авторестарту та поведінка при частковій втраті потоку.
- Регламент перерахунку даних — коли запускається перерахунок, які джерела обов’язково мають бути доступні, як перевіряється цілісність снапшота і що робити при розходженні з попереднім результатом.
- Документація щодо профілю обсягу — модель розрахунку, формати зберігання, одиниці та правила округлення, обробка пропусків і аномальних сплесків.
- Інструкція для чергової зміни — типові сигнали моніторингу, порядок діагностики, точки ескалації та порядок відкату на попередній снапшот.
- Схема доступу та ролей — хто має право змінювати параметри розрахунку, як фіксуються зміни та як розділені права на читання й запис.
- Методика приймання — набір контрольних сценаріїв і еталонних значень, за якими перевіряється коректність профілю після будь-якого доопрацювання.
Комплект пишеться під вашу інфраструктуру й оновлюється разом із кодом, тому не розходиться з фактичним станом системи. Якщо задача — опишіть її, повернемося з оцінкою та планом.
Кейс: розходження профілю обсягу та стрічки на біржі
Платформа будувала профіль обсягу за агрегованими барами з кількох джерел: потік ордерів, зведення свічок і кеш торгових пар.
Стрічка угод у побудову не входила, тому при обриві потоку або перезапуску вузла гістограма залишалася правдоподібною, але розходилася з фактичними угодами: трейдер бачив рівні, яких на ринку не було.
Розбір виявив дві причини. Агрегати склеювалися за часом сервера, а не за часом угоди, а повторно доставлений фрагмент враховувався двічі.
Ми перевели побудову на стрічку угод як єдине джерело правди: профіль збирається з потоку угод із дедуплікацією за ідентифікатором, вікно агрегації прив’язане до часу угоди, а еталоном для звірки служить публічна стрічка Binance за відповідними парами.
Що змінилося в цифрах
| Метрика | До | Після |
|---|---|---|
| Розходження профілю зі стрічкою | 4–6% торгових сесій | 2–3 випадки на місяць, кожен із повідомленням |
| Виявлення розходження | за зверненням трейдера, години розбору | автоматична звірка, хвилини |
| Відновлення після обриву потоку | повний перерахунок історії вручну | точковий перерахунок вікна розходження |
| Клас відмов | агрегат без стрічки, подвійний облік | закритий регресійними перевірками |
Ключовий результат — не окрема цифра, а усунений клас відмов: профіль більше не може розійтися зі стрічкою непомітно, розходження спливає на звірці всередині свого вікна.
Відкат на попередню версію агрегації залишається можливим, а історія перераховується зі стрічки угод без втрати даних.
Що робити, якщо профіль уже рахується за свічками?
Так, це вирішується без зупинки торгів — але не заміною одного розрахунку іншим. Профіль за агрегатами та профіль за угодами дають різні гістограми: свічка розкладає обсяг за ціною за евристикою, а угода несе точну ціну виконання. Тому змінюємо джерело, а не формулу — і робимо це паралельно.
Спочатку на платформі з’являється другий розрахунковий контур. Він читає потік угод із майданчиків, веде власну гістограму за заданою ціновою сіткою та наповнюється ретроспективно з історичних файлів угод.
Перший контур продовжує віддавати профіль за свічками, вітрина API та логіка відображення не змінюються.
Перехідний період — подвійний розрахунок: обидва профілі рахуються на одному вікні, а розходження вимірюється за стійкими метриками — точка контролю обсягу, межі зони вартості, розподіл за ціновими рівнями. Так видно, де евристика свічки спотворює картину, і є числовий критерій готовності до перемикання.
Зворотна сумісність тримається на схемі відповіді: наявні поля зберігаються, нові додаються як необов’язкові, а вибір джерела перемикається параметром конфігурації на рівні запиту. Відкат на попередній розрахунок займає хвилини й не потребує релізу клієнтських застосунків.
Майданчики на кшталт Coinbase віддають стрічку угод у реальному часі, тому догін за потоком сходиться із завантаженою історією без розривів.
Потік угод на порядки щільніший за агрегати, тому сирі записи зберігають обмежене вікно, а гістограму будують на льоту. Там, де історія майданчика вже проріджена, профіль за свічками залишається резервним джерелом.
Підсумок: платформа рахує Volume Profile за реальними виконаннями, а торгівля не зупиняється на жодному з етапів міграції.
Технічні сумніви перед початком робіт
Перед стартом робіт інженери та керівники напрямів ставлять майже один і той самий набір питань: як перевірити коректність розрахунку, що буде при збої зв’язку та чи сумісний новий розрахунок із тим, що вже працює в проді. Нижче — відповіді в тому вигляді, у якому ми даємо їх на технічній сесії.
Як переконатися, що профіль обсягу сходиться з біржовими даними?
Будуємо контрольні звірки: агрегуємо потік угод у ті самі інтервали та цінові рівні, що віддає джерело, і порівнюємо підсумкові обсяги за кожною зоною. Розходження вище заданого порогу підсвічується — це сигнал розібрати конвеєр обробки, а не «особливість ринку».
Що станеться при обриві потоку даних?
Вікно, у якому втрачено угоди, позначається як неповне — трейдер бачить це прямо в інтерфейсі й не приймає спотворений профіль за повноцінний зріз. Перепідключення йде автоматично, а пропущену ділянку добирають з історії угод при відновленні зв’язку.
Чи можна поставити профіль обсягу на чинну платформу без зупинки торгів?
Так. Новий розрахунковий модуль піднімається поруч із поточним, читає той самий потік і рахує в тіньовому режимі — результати порівнюються на живих даних. Перемикання робиться лише після того, як розходжень із попередньою логікою не залишається.
Як бути з історією угод за довгий період?
Історія зберігається агрегованими ціновими рівнями, а не сирим потоком, тому перерахунок за минулі періоди йде пакетно й не навантажує онлайн-контур. Глибина доступної історії обмежена тим, що віддає сам майданчик за кожним інструментом.
Хто налаштовує крок ціни та період профілю?
Параметри виносяться в конфігурацію: крок ціни та вікно накопичення задаються окремо під інструмент, спот і деривативи рахуються різними профілями. Значення змінюються без випуску нової версії — правка налаштування застосовується на наступному вікні.
Обговорімо задачу: що потрібно для оцінки та плану
Щоб повернутися з реалістичною оцінкою робіт із профілю обсягу, нам потрібен мінімум вступних — за ними видно обсяг, склад команди та порядок етапів.
Готувати технічне завдання заздалегідь не потрібно: достатньо відповідей на кілька питань, решту уточнимо в розмові та зафіксуємо письмово.
- Які майданчики та ринки в контурі — спот, ф’ючерси, деривативи: від цього залежить набір джерел даних і правила нормалізації угод.
- Що є з історії: глибина, наявність потоку угод або лише агреговані свічки, де дані лежать зараз і в якому вигляді.
- Режим використання: лише побудова профілю обсягу для аналізу або ще сигнали, оповіщення та виконання.
- Інтерфейси та навантаження: веб, десктоп або мобільний застосунок, скільки одночасних сесій і яка затримка відгуку прийнятна.
- Інфраструктура: розміщуємо у вашому контурі або в нас, які вимоги до доступів, зберігання та журналювання дій.
- Інтеграції: термінал, брокерський шлюз, ризик-модуль, звітність — що вже працює і за якими інтерфейсами обмінюємося.
- Строки та віхи: які дати критичні і в якому порядку зручно узгоджувати етапи.
Опишіть задачу у вільній формі — повернемося з оцінкою, планом впровадження та пропозицією щодо складу команди. Узгодження етапів розкладемо за віхами: з критеріями приймання та зрозумілим обсягом робіт на кожному кроці.
