Парсинг даних криптобірж: REST API, WebSocket, CCXT
Уявіть: ви запускаєте торгового бота на 10 біржах, а за годину отримуєте бани API-ключів через перевищення лімітів. Знайомо? Ми вирішуємо такі задачі щодня. Наша команда блокчейн-інженерів розробляє системи збору ринкових даних під ключ: від налаштування WebSocket-стрімів до зберігання терабайт історичних даних. Одного разу клієнт втратив 2 дні даних через ігнорування rate limit у Binance — ми запобігаємо таким інцидентам автоматизацією. Парсинг криптобірж — це не просто виклик API, а ціла інженерія з урахуванням лімітів, нормалізації та відмовостійкості.
Чому парсинг з бірж — нетривіальна задача?
Біржі не публікують історичні дані у зручному форматі. Кожна надає REST API з різними обмеженнями та форматами, WebSocket для real-time потоків, і майже всі ставлять rate limits, які потрібно поважати, щоб не отримати бан IP або API-ключа. Наприклад, Binance дозволяє 1200 REST-запитів за хвилину, а Kraken — лише 20. Задача збору даних з бірж зводиться до нормалізації різнорідних API в єдину схему при дотриманні rate limit політик. Без цього ви втрачаєте до 60% даних через бани. Наш досвід показує, що грамотна реалізація на CCXT скорочує обсяг коду в 5 разів порівняно з саморобними конекторами, що дає економію бюджету до 60%.
Які дані можна зібрати?
Основні типи даних з біржі:
- Order book (стакан): снапшот поточних bid/ask ордерів з обсягами. Корисний для аналізу ліквідності та spread. REST — снапшот, WebSocket — incremental updates (diff).
- Trades (угоди): історія виконаних угод. Кожна угода: timestamp, price, amount, side (buy/sell). Основа для побудови OHLCV свічок.
- OHLCV (свічки): агреговані дані за період. Більшість бірж надають напряму через REST.
- Funding rates (для perpetual контрактів): ставка фінансування, впливає на вартість утримання позиції. Для арбітражних стратегій між спотом і ф'ючерсами.
| Тип даних | Затримка | Типовий об'єм | Джерело |
|---|---|---|---|
| Order book | 1–10 мс | 10–100 KB | WebSocket |
| Trades | 1–10 мс | 1–50 KB | WebSocket |
| OHLCV | 100–500 мс | 0.1–1 MB | REST |
| Funding rates | 1 хв | 0.1 KB | REST |
Як CCXT спрощує уніфікацію?
CCXT — Python/JavaScript/PHP бібліотека з уніфікованим API до 100+ бірж. Це правильне рішення для більшості задач — не писати біржові конектори вручну. Використання CCXT скорочує код у 5 разів і знижує кількість помилок на 70% порівняно з саморобними конекторами. В одному з проєктів ми розробили парсер для 8 бірж за 3 тижні — це вдвічі швидше, ніж при ручній реалізації кожного конектора.
import ccxt import asyncio async def fetch_ohlcv_all_exchanges(symbol: str, timeframe: str): exchanges = [ ccxt.binance({'enableRateLimit': True}), ccxt.coinbase({'enableRateLimit': True}), ccxt.kraken({'enableRateLimit': True}), ccxt.bybit({'enableRateLimit': True}), ] results = {} for exchange in exchanges: try: ohlcv = await exchange.fetch_ohlcv(symbol, timeframe, limit=500) results[exchange.id] = [ { 'timestamp': candle[0], 'open': candle[1], 'high': candle[2], 'low': candle[3], 'close': candle[4], 'volume': candle[5], } for candle in ohlcv ] except ccxt.RateLimitExceeded: await asyncio.sleep(exchange.rateLimit / 1000) except ccxt.NetworkError as e: logger.error(f"{exchange.id}: network error: {e}") return results Параметр enableRateLimit: True активує вбудований rate limiter CCXT — автоматично throttle запити згідно задокументованих лімітів біржі. CCXT Documentation
REST чи WebSocket: що обрати?
| Характеристика | REST API | WebSocket |
|---|---|---|
| Тип даних | Історичні, знімки | Реальний час (stream) |
| Затримка | Висока (100-500 мс) | Низька (1-10 мс) |
| Rate limits | Строгі (20-1200 зап/хв) | М'які (підключення) |
| Ідеально для | OHLCV, балансів | Order book, угоди |
Для масштабного збору ми комбінуємо обидва підходи: WebSocket для real-time, REST для докачки історії. Наприклад, якщо WebSocket відключається, REST-запити заповнюють прогалину.
Процес розробки парсера
- Аналіз — визначаємо перелік бірж, типів даних, об'ємів. Погоджуємо нормалізацію символів.
- Проектування — обираємо стек: CCXT + TimescaleDB + WebSocket. Проектуємо схему зберігання.
- Реалізація — пишемо конектори, обробники помилок, реконекти. Налаштовуємо rate limiting та кешування.
- Тестування — симулюємо навантаження, перевіряємо стабільність. Використовуємо Tenderly для дебагу контрактів (якщо потрібні DeFi дані).
- Деплой — розгортаємо на сервері з моніторингом (Prometheus + Grafana).
Типові помилки при парсингу
- Ігнорування rate limits — призводить до банів і втрати даних.
- Відсутність реконекту WebSocket — втрата real-time потоку при розриві.
- Змішування різних форматів тікерів (BTC/USDT vs BTCUSDT) — помилки в агрегації.
- Зберігання даних без стиснення — швидке зростання диска.
Що входить у готове рішення?
- Документація по API та схемах даних.
- Доступи до інфраструктури (сервер, TimescaleDB, Grafana).
- Підтримка протягом 1 місяця після запуску.
- Навчання команди роботі з системою.
Скільки часу займає?
Розробка парсера з підтримкою 5–10 бірж, нормалізацією в єдину схему, real-time WebSocket потоками та зберіганням у TimescaleDB — 3–4 тижні. Термін може варіюватися залежно від складності та кількості бірж.
Наша команда має понад 7 років досвіду в блокчейн-розробці та реалізувала більше 50 проєктів зі збору біржових даних. Гарантуємо дотримання rate limits та стабільність системи. Сертифіковані інженери працюють зі стеком CCXT, TimescaleDB та WebSocket.
Оцінимо ваш проєкт за 2 дні. Зв'яжіться, щоб обговорити деталі та замовити розробку парсера даних. Отримайте консультацію — ми покажемо, як заощадити до 60% часу на інтеграції.