Чому order book pipeline втрачає дані на піках
Order book pipeline ламається не на спокійному ринку, а в перші секунди сплеску: потік котирувань зростає на порядок, і вузьке місце проявляється там, де його не видно за рівномірного навантаження.
Втрата оновлень у цей момент не виглядає як помилка — процес живий, метрики зелені, просто книга заявок перестає відповідати біржі. Розрив сесії на піку коштує найдорожче: поки триває перепідключення, дельти накопичуються в буфері або губляться зовсім.
Другий клас збоїв — пропущені снапшоти й розсинхронізація відновлення. Якщо снапшот не збігся за номером послідовності з потоком дельт, книга заявок збирається з несумісних шарів, і далі жодна валідація не відрізнить таке складання від коректного.
Інженерно це лікується звірянням послідовностей, повторним запитом снапшота й відкатом вікна, але лише якщо конвеєр спроєктовано з урахуванням того, що оновлення надходять не по порядку й із різною затримкою від різних майданчиків.
Третій, найпідступніший збій — дрейф ознак між навчанням та інференсом. На історичних даних книга заявок збиралася одним способом нормалізації, у реальному часі — іншим, і модель бачить розподіл, якого не зустрічала.
Затримка даних додає до цього зсув: ознака, порахована за застарілим знімком, формально коректна, але описує ринок, якого вже немає. Зовні це виглядає як деградація якості передбачень без жодної помилки в логах.
Ми розбираємо, як це закривається: контролем цілісності на кожному переході, єдиним шаром розрахунку ознак для навчання та інференсу, контролем затримки даних на всьому шляху від майданчика до моделі.
Що дає вибудуваний конвеєр книги заявок
Конвеєр книги заявок — це не переміщення файлів, а контракт на дані: у кожного набору є версія, схема й набір перевірок, за яких він вважається придатним. Нижче — що саме змінюється, коли такий контракт зафіксовано.
- Відтворюваність. Будь-який набір збирається за версією вихідних записів і версією правил підготовки ознак. Повторний прогін дає ті самі значення метрик, а розбіжність між навчанням і перевіркою перестає бути загадкою.
- Якість даних на вході. Перевірки виявляють пропущені знімки, дублікати, розриви часового ряду та порушений порядок рівнів. Частка відбракованих сесій видна у звіті, а не з’ясовується за аномальними метриками моделі.
- Історичні дані. Знімки книги зберігаються в колонковому форматі Parquet з розбиттям за датами й інструментами: вибірка за потрібний період читається хвилинами, а не годинами повного перебору.
- Підготовка ознак. Дисбаланс сторін, спред, інтенсивність скасувань, швидкість відновлення після імпульсу рахуються одним проходом. Ручна підготовка скорочується з днів до хвилин і перестає залежати від конкретного аналітика.
- Єдиний формат. Розбіжності в одиницях, мітках часу й точності між майданчиками нормалізуються на вході — клас відмов «дані надійшли, але не в тому вигляді» зникає.
- Стійкість до сплесків. Буферизація й зворотний тиск утримують потік на піках активності: повідомлення не губляться, а черга розбирається після навантаження.
Способи збору та зберігання котирувань: порівняння
Режим збору котирувань визначає, що отримає модель: глибину книги ордерів на момент події, рівномірність часових міток і відтворюваність навчання. Варіанти нижче не конкурують між собою — їх комбінують за горизонтом: історія закривається пакетно, живий потік іде безперервно.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пакетне завантаження історії | Великий ретроспективний корпус для навчання та бектестів | Немає live-даних, розриви між файлами зшиваються вручну |
| Безперервна обробка потоку | Модель працює онлайн, критична затримка реакції | Розрив з’єднання безповоротно втрачає частину дельт |
| Гібрид: снапшоти + потік дельт | Потрібні історія, live і коректний рестарт | Складніша підтримка: порядок подій і дедуплікація |
| Буферизація у тимчасовому сховищі | Піки навантаження й нестабільний канал до холодного сховища | Затримка до запису, потрібен контроль витіснення буфера |
Для order book pipeline ключовий критерій — узгодженість часу. Пакетне завантаження дає обсяг, але втрачає мікроструктуру; потік зберігає її, але потребує механізму відновлення після збою.
Гібридна схема з буфером знімає цю суперечність: дельти накопичуються у швидкому сховищі, снапшоти фіксуються за таймером, рестарт не залишає розривів.
На стороні зберігання це колонкові файли, партиційовані за інструментом і датою, плюс журнал дельт — тоді вибірка для навчання збирається за один прохід.
Як ми будуємо конвеєр обробки котирувань
Порядок етапів упровадження однаковий для будь-якого джерела — біржового API, агрегатора або брокерського шлюзу. Починаємо з аудиту джерел: частота оновлень, формат снапшотів, поведінка під час розриву зв’язку, нумерація подій.
Від цих деталей залежить схема конвеєра — чи потрібен проміжний журнал, чи достатньо потокової обробки.
- Аудит джерел. Інвентаризуємо потоки: канали реального часу, снапшоти стакана, глибина, ліміти підключень. Окремо дивимося поля, які приходять не завжди, і те, як джерело сигналізує про пропуск.
- Схема конвеєра. Шари приймання, нормалізації, дедуплікації, збирання стакана зі снапшота й дельт, запису в колонкове сховище. Визначаємо точки буферизації, щоб не втрачати події на піках навантаження.
- Збирання й нормалізація. Єдина роздільна здатність часу, спільний довідник інструментів, узгоджені одиниці обсягу та сторони угоди; біржові ідентифікатори зводимо в одну таблицю відповідності.
- Перевірка даних. Прогін на історичних відрізках із відомими аномаліями: безперервність послідовностей, відсутність перевернутого стакана, частка відновлених пропусків. Розбіжності з еталоном розбираємо до причини.
- Спостережуваність у контурі. Лічильники дір, затримка доставки, частка подій поза порядком — з алертами. Конвеєр сам повідомляє про деградацію, а не віддає биті дані в модель.
- Передача рішення. Схеми потоків, конфігурації, регламент перезапуску й відновлення після збою, навчання команди — щоб запуск і правки йшли без нас.
На виході — відтворюваний order book pipeline: від сирих повідомлень до ознак для моделі. Будь-який етап перезапускається й звіряється з еталоном, а якість даних видно за метриками, а не за відчуттями.
Артефакти: схеми, регламенти та конфігурації
Пакет передачі — не тека з файлами «для пам’яті», а робоча документація, за якою команда замовника сама розгортає й веде конвеєр обробки книги заявок. Нижче — перелік того, що залишається у вас після здачі та чим ви користуєтеся без нас.
- Схема даних: опис полів подій книги заявок — рівні, сторони, обсяг, мітки часу, ідентифікатори інструмента, правила нормалізації та обробки пропусків.
- Конфігурації збору: параметри підключення до джерел, частота знімків, глибина книги заявок, правила перепідключення й буферизації під час розривів зв’язку.
- Схема потоків даних: шлях від приймання сирих повідомлень до вітрини ознак, з точками контролю якості та місцями, де потік можна переграти заново.
- Політики доступу: ролі на читання й запис, розмежування за інструментами та середовищами, порядок видачі й відкликання ключів.
- Регламенти супроводу: що перевіряємо щодня, які пороги затримок і втрат вважаємо відхиленням, кому й як ескалювати.
- Моніторинг: набір метрик — лаг обробки, частка пропущених інтервалів, розсинхрон годинників, зростання черги — з прив’язкою до правил оповіщення.
- План відновлення: точки збереження, порядок перезапуску з останнього цілісного зрізу, перевірка повноти відновлених даних.
Документація живе в тому самому сховищі, що й код, тому регламенти не розходяться з фактичною конфігурацією. Під час зміни джерела або формату повідомлень оновлення опису полів входить у той самий цикл робіт — інакше схема даних застаріває за пару тижнів.
Кейс: відновлення потоку котирувань після збою
Збої на стороні джерела даних і обриви підписки ламали потік котирувань: після перепідключення частина оновлень приходила знову, частина не приходила взагалі.
Частка втрачених оновлень сягала 5–7% на добу, у книзі заявок з’являлися дірки в порядкових номерах, а повторна підписка додавала дублі — на навчання потрапляла історія, якій не можна довіряти.
Що було до
Відновлення після розриву робили вручну: інженер перезапускав сесію, запитував повний знімок книги заявок із Databento, зіставляв його з накопиченим потоком і вичищав перетини.
Одна така операція займала 30–40 хвилин, за добу їх набиралося до десяти, а звірка наборів даних розходилася в трьох запусках із десяти. Модель навчалася на зміщеній вибірці, і деградація була непомітною: метрики на валідації плавали від прогону до прогону.
Що зробили
Кожне оновлення отримало порядковий номер і контрольну суму попереднього стану, тому розрив видно одразу — за безперервністю номерів, а не за непрямими ознаками.
Буфер тримає вікно останніх секунд, знімок довантажується автоматично й накладається на дельти, а записи, що збіглися, відкидаються за ключем «номер + мітка часу» до запису в сховище.
Що стало
Частка втрачених оновлень — 0,02%, пропуски в порядкових номерах закриваються в тому самому вікні, де виявлені. Відновлення після розриву зв’язку займає 1,5 хвилини проти 30–40 хвилин ручної роботи, ручних операцій на добу — нуль.
Звірка наборів даних перестала розходитися: розбіжності ловляться на вході й не доїжджають до навчальної вибірки, тому метрики на валідації стали відтворюваними.
Причина збою тепер видна в журналі разом із моментом розриву й ділянкою потоку — розбір займає хвилини, а не півдня. Такий контур стійкості закладаємо на етапі проєктування потоку, а не після першого інциденту.
Чим відрізняється order book від потоку угод?
Order book — це стан лімітних заявок: ціна, обсяг, сторона, момент зміни. Подання, зняття, часткове й повне виконання породжують окремі повідомлення, тому стрічка книги на порядок об'ємніша й оновлюється помітно частіше, ніж потік угод.
Потік угод фіксує лише вже виконане, тоді як книга показує глибину ринку: ліквідність на віддалених рівнях, спред, дисбаланс попиту й пропозиції.
Звідси різні класи ознак — з угод видно ініціативу й агресивність виконання, з книги — опір ціни та запас до прослизання під час входу великим обсягом.
Для моделей мікроструктури важлива саме ця різниця. Книга дає ознаки ліквідності й тиску на межі, потік угод — ознаки виконання й короткострокового імпульсу.
Агреговані котирування, згорнуті за рівнями ціни та інтервалами, зменшують обсяг зберігання, але стирають частину мікроструктури — вибір точності тут завжди компроміс.
Вибір джерела — це питання горизонту прогнозу й типу ознак, а не смаку. Для частини задач потрібні обидва джерела разом: окрема угода без стану книги не піддається поясненню, а книга без угод не показує, хто саме зрушив ціну.
Тому обидва потоки синхронізують за часом, а розсинхрон і пропуски обробляють окремо — інакше ознаки на виході розійдуться.
На вході обидва джерела записуються роздільно, з мітками часу та ідентифікаторами інструмента, щоб ознаки можна було перерахувати заднім числом на історичному вікні.
Технічні сумніви перед початком робіт
Сумніви перед стартом зазвичай ті самі: як вбудувати свої джерела, що робити з історичними розривами і чи не доведеться ламати працююче сховище. Нижче — короткі відповіді щодо кожного пункту.
Конвеєр будується навколо нормалізованої схеми події: інструмент, мітка часу, сторона, рівень ціни, обсяг.
Будь-яке джерело приводиться до неї адаптером, тому контроль якості, відновлення книги заявок і вітрини для моделей працюють однаково — незалежно від того, чиї дані надходять.
Чи можна підключити наші джерела, а не лише ваші?
Так. Пишемо адаптер під ваш канал або вивантаження й фіксуємо контракт нормалізованої схеми. Далі джерело живе на рівних правах з іншими: ті самі перевірки цілісності, той самий моніторинг свіжості, ті самі вітрини. Якщо у вас є історичний архів у власному форматі — розберемо його окремим проходом.
Що робити з пропусками в старих даних? Відновлюємо книгу заявок зворотним проходом: беремо найближчий цілісний знімок і накочуємо дельти до наступного. Там, де відновити не можна, вікна позначаються як неповні й не потрапляють у навчання — модель не вчиться на дірах. Усі правки записуються в журнал, щоб було видно, яку ділянку історії перезібрано.
Чи не дублюватимуться дані під час повторного оброблення? Ні. Запис ідемпотентний: ключ — джерело, інструмент і мітка часу події. Повторний прохід оновлює ті самі рядки, а не додає нові, тому вітрини не роздуваються й метрики не «пливуть». Це ж дає змогу безпечно перезапускати ділянку після збою.
Чи доведеться перебудовувати чинне сховище? Зазвичай ні. Конвеєр підключається до наявного сховища й пише в окремі партиції, не торкаючись робочих таблиць. Якщо потрібно — піднімаємо паралельну вітрину, звіряємо результати й лише потім перемикаємо споживачів.
Що з підтримкою після здачі? Залишаємо моніторинг розривів і затримок, алерти на аномалії та регламент дозаливання пропущених вікон. Передаємо документацію й розбір інцидентів, щоб команда могла супроводжувати конвеєр самостійно.
Обговоримо вашу задачу обробки котирувань
Оцінка обсягу робіт по конвеєру обробки order book залежить не від кількості бірж, а від того, як влаштовані первинні дані та що потрібно отримати на виході.
Якщо одразу бачити приклад вивантаження та опис цільової ознаки, ми повертаємося з розбивкою за етапами та вимогами до даних, а не з діапазоном «від і до».
Що корисно надіслати заздалегідь:
- Джерела: біржі, інструменти, глибина історії та потрібна частота знімків книги заявок.
- Формат потоку: лише знімки або знімки плюс дельта-оновлення, як позначаються розриви та повтори послідовностей.
- Вимоги до даних: схема подій, робота з мітками часу, синхронізація, правила відновлення пропущених інтервалів.
- Цільові ознаки: дисбаланс сторін, спред, інтенсивність скасувань, профіль ліквідності — і горизонт, на якому модель має працювати.
- Режим роботи: історичне відтворення, потік у реальному часі або обидва варіанти, яка затримка допустима.
- Інфраструктура: де розміщуємо обробку, які доступи та обсяги сховища є, чи потрібна відтворюваність збирання набору даних.
Склад команди збираємо під профіль задачі: інженер з потокової обробки, фахівець зі сховищ і аналітик, відповідальний за узгодження ознак. Опишіть задачу у вільній формі — повернемося з оцінкою робіт, планом впровадження та уточнювальними питаннями.
