Парсинг даних криптобірж: REST API, WebSocket, CCXT

Чому парсинг криптобірж зривається на пікових навантаженнях

Пікове навантаження на біржі — це не лише зростання кількості угод. Потокова підписка на стакан у такі хвилини віддає в рази більше повідомлень, і канал рветься: з'єднання закриває сама майданчик, а клієнт дізнається про це за таймаутом, втрачаючи все, що не встиг зберегти. Обрив потоку даних майже ніколи не виглядає як помилка — він виглядає як тиша.

Другий частий збій — ліміти на запити. Публічні методи рахують частоту звернень за ключем і адресою, і при перевищенні майданчик не просто відмовляє, а блокує доступ на зростаючий інтервал.

Опитування історії цін і свічок у цей момент зупиняється повністю, а вікно, що потрапило на блокування, вже не переграти.

Навіть коли канал живий, стакан встигає розійтися з реальністю. Знімок стакана і потік оновлень приходять різними шляхами, і при втраті одного повідомлення локальна копія тихо розходиться з біржовою.

Такий розсинхрон стакана не видно до першої угоди за неправильною ціною — а на цей момент у торговій логіці вже ухвалено рішення.

Найдорожче коштують пропуски в історії цін. Після перепідключення потік відновлюється з поточного моменту, а пропущений інтервал ніхто не віддає — його потрібно запитувати окремо і зшивати вручну.

Свічки збираються з провалами, і на них ламається все далі по ланцюжку: розрахунок вартості портфеля, індикатори, перевірка стратегій на минулих даних.

Розбираємо, як це закривається на практиці: звірка знімка з потоком, буфер на час перепідключення і повторне вивантаження пропущеного інтервалу.

Що дає налагоджений збір ринкових даних

Єдиний формат даних знімає головний біль — кожна біржа віддає свою схему: в однієї обсяг у базовій валюті, у другої в котируваній, у третьої час у мілісекундах замість секунд.

Нормалізація приводить котирування, угоди і стакани до однієї моделі зі спільним набором полів, тому аналітика і торгові модулі читають одне джерело і не тягнуть логіку конкретного майданчика всередину стратегії.

Стійкість збору будується на кількох контурах.

Потокові канали тримають постійне з'єднання з автоматичним перепідключенням і зростаючою паузою, пропуски за час розриву добираються з історії через опитувальні точки, а повторні і позачергові записи відсікаються за ідентифікатором угоди і міткою часу.

Частка втрачених оновлень знижується з відсотків до часток відсотка, причому на кожному каналі вона вимірюється окремо — видно, де деградує конкретний майданчик, а не «збір зламався повністю».

Скорочення ручних перезапусків — прямий наслідок спостережуваності. Процес сам стежить за свіжістю останнього оновлення і глибиною стакана, при застої піднімає з'єднання знову, а оператору пише тільки тоді, коли автоматика не впоралася.

Час відновлення після збою скорочується до десятків секунд, а кількість втручань людини падає з кількох за добу до поодиноких за місяць — черговий перестає бути частиною конвеєра.

Частина класів відмов зникає зовсім: розсинхрон локального стакана з біржовим, дублі угод при повторній підписці, тихе відставання котирувань, яке раніше знаходили за розходженням з майданчиком постфактум.

Бібліотека CCXT закриває типові відмінності між інтерфейсами майданчиків, а власний шар поверх неї відповідає за нормалізацію, контроль цілісності і перепідключення — те, що для збору котирувань важливіше за сам доступ до API.

Парсинг криптобірж: періодичні запити чи потокові підключення

Режим збору визначає, що взагалі можна побудувати поверх даних: розрахункову звітність чи живу картину ринку. Періодичні запити віддають зріз на момент виклику — стакан, історію угод, баланс рахунку. Потокові підключення надсилають кожну зміну в міру появи і тримають стан без опитування.

Вибір режиму збору майже ніколи не бінарний. Робоча схема — гібрид: потік відповідає за актуальність, а періодичний запит довантажує пропущений інтервал після розриву і слугує незалежною звіркою для контролю розходжень.

Уніфіковані адаптери

Відмінності майданчиків зручніше гасити на вході, а не в бізнес-логіці.

Уніфікований адаптер приводить поля до спільної схеми — інструмент, сторона, обсяг, час, — сам обробляє пагінацію, повтори і ліміти частоти звернень, а також переводить потокові повідомлення в той самий формат, що й відповіді опитування.

Тоді додавання нової біржі зводиться до опису відповідностей, а не до переписування збору і зберігання.

Один і той самий модуль розрахунку починає працювати з кількох майданчиків без правок — саме це і робить парсинг криптобірж передбачуваною частиною системи, а не набором приватних скриптів.

Етапи впровадження: від аудиту джерел до передачі регламентів

Порядок робіт вибудуваний так, щоб на виході був потік зі зрозумілими межами відмов, а не набір розрізнених скриптів.

Починаємо з джерел: де достатньо періодичного опитування, де потрібна потокова підписка, які ліміти за частотою запитів і глибиною історії діють на кожному майданчику.

1. Аудит джерел і лімітів. Звіряємо список бірж і торгових пар, дивимося фактичні обмеження за частотою і вагою запитів, доступну глибину історії і формати відповідей. На виході — карта джерел з пріоритетами і переліком розходжень між майданчиками.
2. Схема потоків даних. Вирішуємо, що забираємо підпискою, що опитуванням, де точки агрегації і зберігання. Фіксуємо єдину модель події, щоб дані з різних бірж лягали в одну структуру, а не в зоопарк форматів.
3. Налаштування черг і розв'язок. Приймання і обробку розділяємо: черга згладжує сплески навантаження і дозволяє перезапустити обробник без втрати даних. Тут же — повторні спроби, дедуплікація і відновлення після обриву з'єднання.
4. Звірка і валідація. Порівнюємо вибірки з еталоном, розбираємо пропуски і розходження за обсягами і часом. Пропуск в історії небезпечніший за розрив зв'язку — його помічають уже за підсумковими розрахунками.
5. Приймальна перевірка на збоях. Відключаємо канал, даємо сплеск навантаження, вводимо затримки відповідей майданчика і дивимося, як система наздоганяє пропущене. Фіксуємо час відновлення і частку втрачених подій.
6. Передача регламентів. Віддаємо карту джерел, політики лімітів, інструкції з експлуатації, набір метрик і пороги оповіщень — супровід не залежить від автора коду.

Підсумок етапу — потік, який переживає штатні збої майданчиків без ручного втручання, і документація, за якою його можна розвивати.

Конфігурації, схеми потоків і документація: що залишається у вас

Проєкт здається не звітом, а працюючим контуром, який продовжує жити на вашій інфраструктурі. Конфігурації, схеми, правила доступу й інструкції лежать у вашому репозиторії і не потребують нашої участі, щоб змінити список бірж або додати торгову пару. Нижче — повний перелік того, що залишається у вас після запуску парсингу криптобірж.

• Конфігурації підключень. Перелік бірж і торгових пар, гранична частота запитів, час очікування відповіді, правила повторів і порядок перемикання на резервне джерело — правляться у файлі, без перезбирання і викладки.
• Схеми потоків даних. Шлях від джерела до сховища з точками буферизації, дедуплікації і скидання: видно, де потік може стати і з якої підтвердженої позиції він продовжиться.
• Політики доступу до ключів. Розділення ключів лише на читання, ротація за розкладом, зберігання в захищеному сховищі, заборона на потрапляння ключів у репозиторій і журнали роботи.
• Схема черг і відмовостійкості. Що відбувається при обриві зв'язку: скільки даних тримається локально, як працюють повтори, за яких умов вмикається оповіщення чергового.
• Документація і регламенти. Довідник полів, правила нормалізації різних джерел у спільну модель, інструкція для чергової зміни: що і в якому порядку перевіряти при розходженні.
• Порядок відновлення. Покрокова процедура підйому потоку після збою, перегравання пропущеного інтервалу і звірка обсягів з біржею.
• Набір еталонних відповідей. Збережені приклади відповідей для перевірки розбору: зміна на боці біржі ловиться до викладки, а не за порожніми таблицями.

Кейс: розсинхрон стакана на трьох майданчиках і як його прибрали

Клієнт збирав дані з трьох майданчиків одразу: стакан, угоди, ставки фінансування. Частина джерел віддавала зріз через REST-опитування, частина — через потокові підписки, і кожен формат доводилося приводити до спільного вигляду вручну.

Саме на стику потоків і снапшотів і виліз розсинхрон стакана: після короткого обриву зв'язку потік продовжував іти, а відновлення історії не відбувалося — снапшот підтягувався заново, і розрив між ним і першими дельтами ніхто не звіряв.

До переробки картина виглядала так: на активних парах губилося 4–6% оновлень, вікно відновлення після обриву займало до 30 секунд, сумарний простій збору сягав пари годин на добу. Чергова зміна отримувала 6–8 звернень за ніч і щоразу розбиралася вручну.

Зібрали єдиний шар збору: CCXT закрив опитування через REST і уніфікацію довідників, потокові підписки підключили напряму, щоб не втрачати чергу повідомлень на проміжній ланці.

Ключове — контроль безперервності послідовностей: кожна дельта несе номер, буфер тримає останні повідомлення, і при розриві запитується тільки снапшот, а черга наздоганяється з буфера, а не починається з нуля.

Історію стакана пишемо в локальне сховище, тому відновлення більше не залежить від того, чи встиг потік наздогнати сам себе.

Після цього частка втрачених оновлень пішла нижче 0,1%, вікно відновлення скоротилося до одиниць секунд, регулярні простої збору зникли, а звернення чергової зміни звелися до одного-двох за тиждень — і то через зовнішні збої майданчиків, а не через нашу частину.

Окремо заклали звірку агрегованих обсягів між майданчиками: розходження вище порогу піднімає сигнал до того, як воно поїде в торгову логіку.

Чим потокові підключення відрізняються від періодичних запитів?

Періодичний запит — це опитування за розкладом: клієнт сам питає біржу, чи не змінилося щось. Затримка даних не може бути меншою за інтервал опитування, а навантаження на джерело постійне — навіть коли ринок стоїть і відповіді приходять порожніми.

Учащати опитування безглуздо: впираєшся в ліміти звернень і отримуєш відмову рівно на волатильній ділянці.

Потокове підключення перевертає схему: сервер сам надсилає зміни, щойно вони з'явилися. Затримка даних падає до часу передавання, а навантаження на джерело перестає залежати від частоти наших звернень.

Плата — повнота історії: потік віддає події тільки з моменту підключення, а розрив з'єднання залишає діру, якої ззовні не видно.

На практиці робоча схема змішана: потік дає реакцію, періодичні запити — повноту історії і відновлення пропущеного вікна після обриву. Відмінності форматів майданчиків приводить до одного вигляду CCXT — замість окремого клієнта під кожну біржу.

При обриві недостатньо перепідключитися: потрібно запитати пропущений інтервал за свічками й угодами і відкинути повтори за ідентифікатором. Інакше в базі залишаються задвоєні угоди, а розрив у даних випливає вже в готовому звіті.

Що уточнюємо до старту: ліміти, блокування і зберігання історії

Перед оцінкою проганяємо сценарій на ваших майданчиках: дивимося ліміти за частотою запитів, глибину видачі історії і правила повторних звернень.

Від цього залежить режим збору — періодичні REST-запити, потокові WebSocket-підписки або комбінація обох, — і скільки вузлів потрібно, щоб укластися в ліміти без блокувань.

Що робити, якщо підписка розірвалася вночі?

Розрив ловиться перевіркою живучості каналу: якщо джерело мовчить довше за очікуване, підписка перестворюється, а пропущений інтервал добирається з історії. Розходження останньої записаної мітки часу з поточною вище порогу піднімає повідомлення — пауза не залишиться непоміченою.

Наскільки глибоко зберігається історія?

Глибину задаємо на старті: повна історія угод і свічок з моменту запуску плюс добір ранніх періодів настільки, наскільки віддає сам майданчик. Сирі відповіді лежать окремо від агрегатів, тому метрики перераховуються без повторного звернення до джерела.

Як підключається новий майданчик?

Джерело стає окремим модулем за спільним інтерфейсом: свій розбір відповіді і своя схема лімітів, решта — нормалізація, зберігання, віддача — не змінюється. Розширення списку майданчиків не перетворюється на окремий проєкт, і ядро системи правити не потрібно.

Обговоримо вашу задачу і повернемося з планом впровадження

Щоб оцінка обсягу робіт спиралася на факти, а не на здогади, достатньо ввідних щодо вашої задачі — у відповідь надсилаємо документ з планом, а не загальні міркування.

Починаємо з обговорення задачі: які майданчики і які дані потрібні — угоди, стакан, свічки, ставки фінансування, довідники інструментів.

Що помітно прискорює оцінку:

• перелік джерел: біржі, агрегатори, внутрішні сервіси, звідки забираємо дані
• глибина історії і гранулярність — з якого моменту відновлюємо минуле і з яким кроком
• режим роботи: разове вивантаження, безперервний потік або регулярна синхронізація
• схема розгортання: ваш контур, хмара або ізольований сегмент без зовнішньої мережі
• вимоги до зберігання і доступів: термін життя даних, розмежування прав, робота з ключами
• точки приймання: які звірки обсягів і звіти про розходження вважаємо доказом коректності

Отримавши ці ввідні, збираємо план впровадження: етапи, що робимо на кожному, на якому кроці потрібні ваші доступи і хто приймає результат.

Терміни запуску називаємо разом з планом — спочатку контур приймання на одному-двох майданчиках, потім розширення на решту і переведення в постійну експлуатацію. Якщо щодо даних або доступів випливають неясності, ставимо запитання до старту, а не в середині робіт.

Опишіть задачу — повернемося з оцінкою обсягу робіт, термінами і планом впровадження за етапами.