Збір trades з бірж: де розривається потік угод
Збір trades у постановці звучить як «підключитися до API і писати в базу». На практиці це два незалежні джерела: потік угод у реальному часі та історичне дозавантаження за період. Перший дає низьку затримку, другий — повноту, і розбіжності виникають саме на їхньому стику.
Найчастіший збій — обрив з'єднання з біржею. Поки канал відновлюється, угоди не надходять: у майданчиків є вікно, у якому потік не буферизується, тому після перепідключення історію дозавантажують за ідентифікаторами угод, а не за часом.
Якщо дозавантаження йде «із запасом» за годинами, у базі з'являються дублі угод; якщо без запасу — пропуски угод. Контроль за номером останнього прийнятого запису, як, наприклад, на Binance, закриває і те, і інше, але потребує зберігання стану по кожному потоку.
Розсинхрон вітрин проявляється пізніше й тихіше. Вітрина аналітики, вітрина звітності та кеш оповіщень оновлюються з різною періодичністю і на одному інтервалі дають різні обсяги — розбіжність зі звітністю майданчика випливає на звірці, коли відновити пропущене вже дорого.
Розбираємо, як це закривається: контроль цілісності на прийманні, постійна звірка вітрин між собою та регулярна перевірка проти звітних даних біржі.
Що дає налагоджене приймання угод: повнота, швидкість, звірка
Приймання угод виглядає простою задачею: підписка на потік і запис у таблицю. Ламається воно на перепідключеннях — у вікно розриву з'єднання губляться угоди, а повторна підписка приносить дублікати й спотворює обсяги. Тому потік проєктується як відновлюваний журнал, а не як «запис того, що встигло прилетіти».
| Клас збою | Що відбувається | Як закриваємо | Метрика |
|---|---|---|---|
| Розрив потоку | пропуск угод за вікно відключення | дозавантаження за діапазоном часу та ідентифікаторів | відновлено > 99,9% угод |
| Повтор після перепідключення | дублі у вітрині | вставка за ключем угоди відкидає повтори | дублів — нуль |
| Затримка надходження | вітрина відстає від ринку | буферизація та пакетний запис | до аналітичної вітрини — секунди |
| Розбіжність зі звітом | обсяг за інструментом не сходиться | щоденна звірка зі звітністю біржі | розбіжність локалізується того ж дня |
Звірка зі звітністю йде окремим контуром: агрегати за інструментами та годинами порівнюються з вивантаженнями майданчика — відкриті дані віддають Binance та інші біржі у зіставному вигляді.
Розбіжність вище порогу автоматично ставить задачу на відновлення пропусків за конкретне вікно, а не на повне перекачування історії.
У результаті зникає цілий клас відмов — «дірка в історії». Ручні дозавантаження замінюються регламентом, повнота ринкових даних підтверджується цифрами звірки, а не довірою до логу застосунку.
Способи збору trades: потокові підписки та пакетні вивантаження
Обидва режими вирішують різні задачі, і спроба закрити одним із них обидві майже завжди впирається в ліміти. Потокова підписка віддає угоди в міру появи — її беруть для онлайн-моніторингу, розрахунку котирувань, контролю ризику та арбітражних сценаріїв.
Пакетне вивантаження історії потрібне там, де важливий повний ряд за минулі періоди: аналітика, перевірка стратегій на історичних даних, звірка звітності з біржовою.
Обмеження в режимів теж різні. У потоці ключове — утримати з'єднання і не втратити події при розриві: потрібен автоматичний перепідключ і добір з останнього підтвердженого ідентифікатора угоди.
У пакетному режимі все впирається в ліміти запитів і глибину історичних даних: майданчик віддає вікно назад, далі — лише архіви.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Потокова підписка на події | Онлайн-моніторинг, розрахунок котирувань, контроль ризику, арбітраж | Працює лише «вперед»; розриви потребують добору; глибокої історії не віддає |
| Посторінкове вивантаження через API | Догін пропущеного інтервалу, точкова вибірка за інструментом | Ліміти запитів, пагінація, обмежене вікно зберігання на боці майданчика |
| Архівні дампи угод | Перевірка стратегій на довгій історії, аналітика за періоди, аудит | Затримка публікації, свій формат у кожної площадки, обсяг і розпакування |
На практиці режими комбінують: архів закриває минуле, потік — поточне, а на стику ставлять дедуплікацію та перевірку безперервності ряду за ідентифікатором угоди. Тоді набір даних залишається повним і без дір після перезапусків сервісу.
Від аудиту джерел до передачі конвеєра угод
Збір trades з бірж починається не з коду, а з розбору джерел. Порядок робіт зафіксований: аудит майданчиків, схема конвеєра, налаштування, перевірка на історії, приймання.
Така послідовність економить тижні — правка на етапі схеми дешевша, ніж перезбирання вже накопиченого архіву.
- Аудит джерел даних. Розбираємо, що віддає майданчик: потік угод у реальному часі, архівні вивантаження, програмний інтерфейс з обмеженням частоти запитів. Фіксуємо глибину доступної історії, стабільність каналів і правила майданчика щодо подальшого використання цих даних.
- Схема конвеєра. Проєктуємо єдину модель угоди: нормалізоване ім'я інструмента, сторона, ціна, обсяг, мітка часу в одному часовому поясі, ознака джерела. Тут же визначається, як різні написання одного інструмента зводяться до одного запису.
- Налаштування збору та зберігання. Підписка на потік плюс завантаження історії, дедуплікація, буфер на випадок обриву зв'язку та повторні спроби. Запис у сховище з розбивкою за датами — вибірка за потрібний період не потребує повного перебору.
- Перевірка на історичних даних. Прогонимо конвеєр на відновленому відрізку та звіряємо з еталонною вибіркою: число угод, ціни, обсяги, частка пропусків і дублів, затримка між угодою та її появою в нас.
- Контроль і приймання рішення. Налаштовуємо метрики та оповіщення про зупинку потоку, зростання затримки та розбіжність обсягів. Приймання йде за узгодженими сценаріями: доступи, схема зберігання, регламент перезапуску.
- Передача й навчання. Показуємо команді, як підключити новий майданчик або інструмент, як читати метрики і що перевіряти при обриві потоку.
Комплект передачі: конфігурації, схеми, регламенти
Здаємо не «доступ до сервера й контакти інженера», а комплект, за яким ваша команда зможе підняти збір заново або прийняти його на супровід без нас. Нижче — що саме залишається у замовника і навіщо кожен елемент потрібен у роботі.
- Матриця джерел. За кожною біржею: які пари та канали включені, потокова підписка чи періодичне опитування, глибина історичного завантаження, ліміти частоти запитів і запас до них.
- Схема потоків даних. Шлях угоди від підписки до запису: де нормалізація, де буфер на випадок обриву зв'язку, де точка відмови і як запускається повторне вивантаження пропущеного інтервалу.
- Модель даних. Словник полів угоди — ідентифікатор, час біржі та час приймання, ціна, обсяг, сторона — плюс правила дедуплікації та ідемпотентного запису, щоб повторний прохід не подвоював обсяги.
- Розмежування доступу до даних. Ролі сервісів і людей, окремі облікові записи на читання та запис, ключі бірж у сховищі секретів, журнал звернень до архіву угод.
- Конфігурації контурів. Описи стенда й промислового середовища, повтори при збоях, відсічки за обсягом і правила зберігання «гарячих» та архівних даних.
- Документація рішення. Карта сервісів і залежностей, порядок дій при типових відмовах, відновлення з архіву, контактні точки ескалації.
- Регламент супроводу. Що перевіряється щодня — лаг приймання, пропуски інтервалів, розбіжності обсягів з еталонною вибіркою — хто реагує, у які терміни і коли перемикаються на резервне джерело.
- Приймальні матеріали. Контрольні суми за еталонний період, звірка вибірки з вивантаженням біржі та протокол перевірки, за яким можна повторити приймання.
Комплект передаємо разом із розбором: проходимо за схемою потоків і регламентом з вашими інженерами, відповідаємо на питання щодо конфігурацій. Опишіть задачу — повернемося з оцінкою та планом передачі.
Кейс: прибрали пропуски угод і розсинхрон вітрин
Збір угод (trades) на Kraken ішов потоковим каналом, і кожен розрив з'єднання залишав діру в історії: після перепідключення підтягувалися лише свіжі записи, а середина інтервалу зникала.
Вітрини розходилися з майданчиком на десятки хвилин, обсяги та кількість угод у звітах не билися, і черговий інженер вручну дозавантажував пропущені інтервали за вивантаженнями.
Ми перебудували контур збору: потік пишеться в буфер із збереженням порядку, кожна угода отримує ідентифікатор біржі та мітку часу майданчика, а запис робиться ідемпотентно — повторна доставка не створює дублів.
Паралельно йде звірка з історичними зрізами майданчика за інтервалами, і розбіжність автоматично ставить інтервал у чергу на повторний добір.
Метрики до та після
- Частка втрачених угод: 0,3–0,5% записів → нуль розбіжностей на контрольних звірках.
- Час збіжності вітрин із майданчиком: 40–60 хвилин → 2–3 хвилини.
- Частка ручних дозавантажень: 12–15% інтервалів → менше 1%, і лише з ініціативи аналітика.
- Збіжність за кількістю та обсягом угод: розбіжність у межах 0,01% на добовому вікні.
Далі контур живе в режимі супроводу: контрольні звірки за розкладом, оповіщення при виході відхилення за поріг, оновлення розбирачів при зміні формату відповідей майданчика.
Замовник отримує історію угод, на яку можна спиратися в розрахунках, без ручних дозавантажень і «довіри на око».
Що робити, якщо своє вивантаження вже працює, але дані розходяться?
Розбіжність майже ніколи не в самому зборі, а в тому, що вважається джерелом істини.
Своє вивантаження даних писалося під одну задачу — звіт, сигнал, перевірку торгової ідеї — і непомітно накопичило припущення: локальний час замість біржового, округлення обсягу, відкидання частково виконаних заявок.
Поки споживач один, це не видно; щойно їх стає два, цифри перестають сходитися, і суперечка йде не про дані, а про те, чий розрахунок правильний.
Аудит поточного рішення починається зі звірки, а не з читання коду. Беремо еталонний інтервал, зіставляємо записи за ключем «символ + час угоди + ідентифікатор» і розбираємо, де рядки зайві, де пропущені, де зміщені за часом.
Потім дивимося журнали: розриви з'єднання, повтори після перепідключення, відсутність дедуплікації на межі вікна. На практиці дві-три такі причини пояснюють основну частку розбіжностей.
Далі — паралельний запуск. Новий контур пише в окрему схему і нічого не змінює в робочому процесі: обидва потоки йдуть одночасно, щодня звіряються, а розбіжності розкладаються за категоріями — втрата вікна, дубль, різна нормалізація.
Поки частка розбіжностей не зійде до нуля на кількох повних торгових днях, перемикати споживачів сенсу немає.
Поетапна заміна йде від країв до центру: спочатку на новий контур переводяться другорядні читачі — звіти, аналітика, — потім основні.
Старе вивантаження залишається доступним лише на читання як страховка і вимикається після того, як новий контур відпрацював спірні ситуації: делістинг пари, дроблення символу, рестарт біржового рушія.
Збір trades при цьому не зупиняється ні на день, а кожна розбіжність закривається підтвердженням, а не на око.
Технічні сумніви: затримки, дублі, ліміти запитів
Три речі ламають збір угод із біржі: обрив з'єднання, дублі при перепідключенні та ліміти на число звернень до майданчика. Усі три закриваються на рівні приймання даних, а не постфактум при розборі звіту — інакше у вітрині залишаються діри, про які дізнаються через тиждень.
Приймання будується двома каналами: потоковий віддає угоди в реальному часі, періодичне опитування добирає пропущене за вікно. Кожен запис отримує складений ключ — майданчик, інструмент, ідентифікатор угоди — і потрапляє у сховище строго один раз.
Повторна видача угод після перепідключення не створює дублів, а розбіжність між каналами закриває звірка.
Що відбувається при обриві зв'язку?
З'єднання піднімається автоматично з наростаючою паузою, щоб не бити по майданчику.
Після відновлення збір іде не з поточного моменту, а з останньої обробленої позиції — пропущений інтервал доганяється історичними даними, а розбіжність між потоком та історією звіряється за обсягом і часом угод.
Як ви тримаєтеся в лімітах запитів біржі?
На кожен напрямок рахуємо вагу звернення й обмежуємо частоту квотами, живий потік завжди пріоритетніший за добір історії. При відповіді про обмеження збір іде в паузу й продовжує з тієї самої позиції, а не перезапускається — дані не губляться й не дублюються.
Як ви розумієте, що дані точні?
Працює детектор розривів: він позначає інтервали, де потік мовчав довше звичайного, і запускає звірку з незалежним джерелом. На виході — вимірювані показники: частка пропущених угод, затримка між угодою та записом, частка відсічених дублів.
Обговоримо задачу: джерела, обсяги, режим надходження
Щоб повернутися з оцінкою проєкту та планом робіт за етапами, потрібні ввідні — не у форматі «потрібні угоди з бірж», а достатні, щоб порахувати навантаження на приймання, зберігання й обробку.
Нижче чек-лист: чим точніше відповісте за пунктами, тим менше припущень закладемо в розрахунок і тим менше розбіжностей випливе на прийманні.
- які майданчики в пріоритеті: централізовані біржі, децентралізовані пули або обидва класи одразу;
- які інструменти та пари потрібні: спотові, строкові, стейблкоїнові;
- глибина історії: разове завантаження архіву за період або безперервне приймання з поточного моменту;
- режим надходження даних: потік у реальному часі, періодичні вивантаження або змішаний сценарій;
- очікуваний обсяг: скільки пар і подій на добу, які години дають пік навантаження;
- поля угоди: час, ціна, обсяг, напрям агресора, ідентифікатори, комісія;
- як плануєте забирати дані: база, файлові вивантаження, програмний інтерфейс, готові звіти;
- вимоги до якості: дедуплікація, обробка пропусків, звірка з історією біржі, зберігання сирих відповідей.
Якщо частина ввідних поки відкрита — це нормально: сформулюємо припущення і винесемо їх окремим блоком, щоб вони обговорювалися на проєктуванні, а не випливали при запуску.
Після розбору складу джерел надсилаємо схему збору, вимоги до сховища та план робіт за етапами із зазначенням, що саме робиться на кожному кроці. Опишіть задачу — повернемося з оцінкою та планом.
