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