Чому грабінг order book scraping зривається на пікових навантаженнях
Пікові навантаження в order book scraping — це момент, коли біржа віддає в рази більше повідомлень, ніж на спокійному ринку: стакан на десяток рівнів перетворюється на сотні оновлень за секунду.
Збір стакана заявок у реальному часі перестає вкладатися в бюджет за затримкою — обробник не встигає застосовувати зміни, черга зростає, і дані приходять уже неактуальними.
Перше, що ламається, — з’єднання. На волатильності потік зростає, буфери переповнюються, і розрив припадає на найпотрібніший момент.
Після перепідключення потік продовжують «як є», без звірки снапшота й номера послідовності, — і в локальній книзі залишаються рівні, яких на біржі вже немає.
Друге — глибина. Багато джерел віддають лише верхні рівні, тому на різкому русі потрібної глибини просто немає, а агреговані зрізи не дають відновити її заднім числом.
Третій збій — розсинхрон між джерелами: різні мітки часу, різний порядок застосування змін, і арбітражні сигнали рахуються за двома незбіжними станами книги.
Тому грабінг ордербука — це передусім про коректність стану, а не про швидкість читання: звірка снапшота, буферизація оновлень на час реконекту, контроль відставання й явна фіксація втрат. Розбираємо, як це закривається.
Безперервний збір ринкових даних: швидкість і повнота картини
Збір стакана заявок (order book) — це безперервний потік, а не разовий запит: десятки оновлень за секунду по кожній парі, і один пропущений пакет робить подальшу картину неправильною.
Найгірше те, що втрата виявляється не в момент збою, а під час розбору історії, коли дані вже лежать у сховищі з дірою.
Ми звіряємо послідовність оновлень з періодичним повним зрізом стакана й фіксуємо розрив у той момент, коли він виник.
Джерела підключаємо паралельно — майданчики рівня Binance та альтернативні канали — і порівнюємо їх між собою: розбіжність одразу показує, який канал втрачає дані. Частка втрачених оновлень зменшується з десятих часток відсотка до нуля.
Стійкість збору тримається на автоматичному перепідключенні, довантаженні пропущеного вікна зі зрізу й дедуплікації повторів під час обриву зв’язку. Так зникає цілий клас відмов — тиха втрата оновлень, коли система формально працює, але віддає дані, що вже не відповідають ринку.
Затримку доставки ми вимірюємо на всьому шляху — від події на біржі до запису й до підписника. Буферизація та пакетний запис скорочують час реакції на ринкову подію до часток секунди, а заповненість хвилинних інтервалів в історії сягає 100% замість колишніх 70–80%.
Безперервний збір тут не самоціль: на повноті даних тримаються стратегії, ризик-контроль і звітність.
Порівняння підходів до збору котирувань: що вибрати під задачу
Збір котирувань з книги заявок вкладається в три режими: потокова підписка, опитування за розкладом та їх комбінація. Вибір визначає не «просунутість» каналу, а вимоги до повноти даних, допустимої затримки й вартості підтримки.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потоковий збір | Потрібні всі зміни книги заявок і мінімальна затримка | Тримає постійне з’єднання, потребує перепідключення й довантаження змін після обриву |
| Періодичне опитування | Достатній зріз раз на кілька секунд, джерел багато | Пропускає сплески між опитуваннями, упирається в ліміти запитів |
| Гібридна схема | Потрібна повнота потоку й стійкість до обривів | Складніше узгодження двох каналів і усунення розбіжностей між ними |
Потоковий збір дає повну картину подій, але будь-який розрив зв’язку залишає «діру» в історії — її закривають повторним вивантаженням знімка й підтягуванням змін за пропущений інтервал.
Опитування за розкладом простіше й надійніше в підтримці, зате втрачає мікроструктуру: сплески ліквідності між тактами просто не потрапляють у накопичені дані.
Гібридна схема бере знімок опитуванням і далі веде потік, а при обриві відновлюється за опорною точкою. Ми проганяємо режими на реальному потоці замовника — рахуємо частку пропущених змін і час відновлення після розриву, і лише потім фіксуємо схему.
Етапи впровадження системи збору й нормалізації даних
Збір стакана заявок (order book scraping) ламається не на старті, а через тижні роботи — коли майданчик змінює формат, рветься з’єднання або розходиться нумерація оновлень.
Тому впровадження йде послідовністю етапів, і кожен закривається перевірюваним артефактом: без нього наступний крок не має сенсу.
- Аудит джерел. По кожному майданчику фіксуємо склад полів, глибину стакана, частоту оновлень, ліміти підключень і правила перепідключення. На виході — таблиця джерел із пріоритетами й застереженнями.
- Схема потоків. Розмічаємо шари: сирі повідомлення, нормалізовані записи, сховище історії. Сировину тримаємо окремо, щоб переграти обробку без повторного збору.
- Налаштування збору. Конектори з автовідновленням після розриву: снапшот плюс програвання дельт від останнього підтвердженого номера, контроль лагу й синхронізація годинників.
- Нормалізація. Єдина схема — інструмент, сторона, рівень, обсяг, точність ціни, час в UTC. Розбіжності в тікерах і форматах чисел закриваємо словником відповідностей.
- Перевірка повноти даних. Звіряємо потік з контрольним зрізом, шукаємо пропущені послідовності й розриви. Частка відновлених розривів і час реакції йдуть у моніторинг.
- Передача в експлуатацію. Регламенти перезапуску, дашборди, алерти на пропуски й зростання лагу, доступи, розбір типових збоїв — із гарантійним періодом супроводу.
Що передаємо в експлуатацію: конфігурації, схеми, регламенти
Після запуску збирач залишається у вас, а не на нашому супроводі. Передаємо все, що потрібно для самостійної експлуатації потоку: конфігурації джерел, схеми руху даних, правила доступу, документацію й регламенти супроводу.
Артефакти закриваємо на прийманні: ваш інженер розгортає збір на своєму контурі, підключає нове джерело й відновлює дані після розриву без нашої допомоги. Нижче — що саме входить у комплект.
- Конфігурації джерел — біржі та канали, ліміти за частотою запитів, схеми авторизації, пріоритети при обривах; нове джерело додається правкою одного файлу.
- Схеми потоків — топологія підписок, буферизація на піках навантаження, порядок повторного підключення й збирання снапшота з подальшими оновленнями.
- Правила доступу — ролі, розділення ключів, ротація, журнал звернень; історичні архіви ізольовані від бойового контуру.
- Словник даних — єдині імена полів, прив’язка тікерів до інструментів, правила дедуплікації та обробки неповних снапшотів.
- Документація — формат повідомлень, порядок розбору збоїв, типові сценарії діагностики, перелік метрик здоров’я потоку.
- Регламенти супроводу — цільові часи відновлення після розриву, порядок підключення й відключення джерел, політика зберігання архівів.
Кейс: як збір стакана перестав втрачати дані на піках
Замовник — команда маркет-мейкера, яка виставляє котирування на кількох майданчиках, включно з Bybit. Збір стакана заявок (order book) вели чотири незалежні скрипти: кожен писав у свій файл, запускався вручну й нічого не знав про сусідів.
На спокійному ринку дані сходилися, але в моменти різких рухів потоки роз’їжджалися, і частина подій зникала безслідно.
Що було до
Пропущений фрагмент ламав не лише графік: він спотворював розрахунок спреду й перекосів, на яких будувалися торгові рішення, а помічали це вже постфактум. Звірити втрати не було з чим — повного зліпка книги за момент збою не зберігалося.
Розбір кожного випадку займав години ручної роботи й усе одно не давав упевненості, що втрачено рівно одну ділянку, а не три підряд.
Що змінили і що отримали
Зібрали єдиний конвеєр: снапшот книги плюс потік змін, буфер на диску на випадок обриву зв’язку, автоматичне перепідключення з надолуженням пропущеної ділянки й звірка контрольних сум після кожного відновлення.
Дедуплікація йде за ідентифікатором події, тому повторна доставка не псує історію, а розбіжність зі снапшотом перетворюється на сигнал, а не на сюрприз під час розбору.
| Метрика | До | Після |
|---|---|---|
| Повнота даних на піках | 60–70% подій | 99,9% |
| Відновлення після обриву | вручну, десятки хвилин | автоматично, секунди |
| Перевірка цілісності | вибірково, постфактум | після кожного відновлення |
Чим потоковий збір order book відрізняється від періодичного опитування?
Періодичне опитування бере знімок стакана за розкладом: клієнт запитує глибину із заданим кроком, отримує зріз і на цьому все. Між двома запитами життя стакана не видно — заявка, поставлена й знята всередині вікна, у даних не залишається.
Чим рідше опитування, тим дешевший збір і тим сильніше вибірка розходиться з реальним потоком подій.
Потоковий збір тримає постійний канал і приймає кожну зміну: приходить початковий снапшот, далі — лише дельти з порядковими номерами. Номери дають наскрізну перевірку: розрив послідовності означає втрату даних, з’єднання перезбирається, снапшот запитується заново.
Так виходить відновлюваний стакан, придатний для розрахунку мікроструктури, а не лише середніх рівнів.
Режими по-різному впираються в інфраструктуру. Опитування обмежене лімітами майданчиків на частоту звернень — у публічних джерел на кшталт Coinbase вони прив’язані до ключа й адреси, тому збір за сотнями інструментів потребує шардування запитів.
Потік дешевший за кількістю з’єднань, але дорожчий в обробці: потрібен шар, який переживає обриви й не втрачає дельти.
Вибір режиму визначається задачею: там, де важливий порядок подій і час життя заявки, працює тільки потік, а регулярні зрізи ліквідності закриває опитування. Тому ми частіше збираємо гібрид і описуємо, як він розгортається під ваш набір інструментів.
Технічні сумніви: розриви, дублі, ліміти джерел
Потік ордербука — снапшот стакана плюс дельти з номерами послідовності. Варто з’єднанню розірватися, і частина змін губиться: локальна книга розходиться з джерелом, а торгові сигнали починають спиратися на неіснуючу ліквідність.
Тому збирач будується навколо звірки послідовностей і контрольних точок, а не навколо простої підписки.
Нижче — відповіді на інженерні заперечення, які виникають на етапі оцінки архітектури.
З’єднання розірвалося — як відновлюєте стан?
Кожен потік пише снапшот і позицію в послідовності в постійне сховище. Після перепідключення сервіс піднімає останню контрольну точку, дочитує дельти від неї й звіряє номер із джерелом.
Якщо розрив ширший за вікно зберігання змін, книга збирається заново зі свіжого снапшота, а пропуск фіксується в журналі явною міткою.
Як виключаєте дублі записів?
Ключ ідемпотентності — джерело, інструмент і номер зміни. Запис іде як вставка з оновленням за унікальним індексом, тому повторна доставка після перепідключення не створює других рядків. Для угод той самий прийом працює за ідентифікатором угоди.
Джерело обмежує кількість запитів — що тоді?
Обмеження закладаються заздалегідь: запити йдуть через чергу з бюджетом на інтервал, при відмовах вмикається адаптивна пауза між повторами, інструменти діляться на пріоритетні й фонові. Історичні вивантаження виносимо в окреме вікно, щоб вони не конкурували з потоком у реальному часі.
Як зрозуміти, що дані не розійшлися?
Стежимо за лагом до джерела, часткою перезбирань книги, числом пропущених послідовностей і швидкістю наповнення черги. Поріг за будь-якою метрикою піднімає оповіщення раніше, ніж розбіжність дійде до торгової логіки.
Обговоримо задачу і повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою строків і робочим планом, а не із загальними міркуваннями, нам потрібен мінімум ввідних по задачі. Збір стакана в реальному часі тримається на деталях: набір майданчиків, глибина історії, вимоги до затримки й правила відновлення після розривів. Нижче — що варто підготувати до старту робіт.
- Майданчики та інструменти. Які біржі й пари потрібні, що важливіше за пріоритетом — від цього залежить число паралельних потоків і обсяг зберігання.
- Глибина й склад даних. Тільки найкращі ціни чи задане число рівнів, чи потрібні знімки стакана цілком і подальші зміни, угоди й мітки часу події.
- Вимоги до затримки. Від появи зміни в стакані до запису у ваше сховище — і допустима частка пропущених оновлень.
- Доступи. Публічні канали або приватні ключі з обмеженими правами, обмеження майданчиків за частотою звернень і числом з’єднань.
- Куди віддавати дані. Потік у вашу шину, запис у базу, файли, вітрина для аналітики; чи потрібен перерахунок історії та звірка з біржовими даними.
- Інфраструктура. Свої сервери або хмара, регіони розміщення, запас за каналом зв’язку й диском під історію.
- Відмови й спостереження. Що робимо при розриві з’єднання, як ловимо розсинхрон стакана, кому йде сигнал і хто реагує.
Опишіть задачу у вільній формі — повернемося з оцінкою строків, планом робіт і схемою збору, де позначені точки контролю, порядок відновлення та склад звітності.
