Збір Long/Short Ratio з криптобірж: технічний розбір

Трейдеру потрібна річна історія Long/Short Ratio по 50+ інструментах для бектестування стратегій. Біржі зберігають максимум місяць даних — Binance віддає тільки останні 500 записів (близько 30 днів з максимальною деталізацією 5-хвилинних свічок), Bybit — 200, OKX — 100. Збирати вручну через UI — сотні людино-годин, а один пропуск даних руйнує backtest. Ми побудували систему на async Python, яка безперервно стягує дані з трьох бірж одночасно, нормалізує та складає в TimescaleDB. Тепер історія доступна за будь-який період, а додавання нового символу займає 5 хвилин — достатньо прописати його в конфігу. У підсумку трейдер отримує безперервний потік даних із затримкою менше хвилини, придатний для real-time індикаторів та сентимент-аналізу криптовалют. Нижче — архітектура, підводні камені та готове рішення.

Офіційні API для L/S ratio

Починати потрібно з офіційних endpoints — вони стабільні та не вимагають браузерної автоматизації. Ось доступні джерела:

Згідно з документацією Binance Futures API, дані доступні тільки за останні 30 днів. Для довгострокового аналізу необхідний постійний збір.

Binance Futures — найповніші дані, кілька ендпоінтів:

# Top trader long/short account ratio GET https://fapi.binance.com/futures/data/topLongShortAccountRatio?symbol=BTCUSDT&period=5m&limit=30 # All accounts ratio (retail sentiment) GET https://fapi.binance.com/futures/data/globalLongShortAccountRatio?symbol=BTCUSDT&period=1h&limit=30 

Відповідь: масив [{symbol, longShortRatio, longAccount, shortAccount, timestamp}]. Історичні дані обмежені: limit=500 максимум, period від 5m до 1d. Дані старші ~30 днів недоступні через API — потрібно збирати самостійно.

Bybit — endpoint /v5/market/account-ratio:

GET https://api.bybit.com/v5/market/account-ratio?category=linear&symbol=BTCUSDT&period=1h&limit=50 

OKX — /api/v5/rubik/stat/contracts/long-short-account-ratio:

GET https://www.okx.com/api/v5/rubik/stat/contracts/long-short-account-ratio?ccy=BTC&period=1H 

OKX не вимагає аутентифікації для публічних market data endpoints. Rate limit: 20 req/2 сек.

Чому без своєї бази не обійтися?

Дані потрібно збирати регулярно — біржі зберігають історію обмежено, тому власна база даних необхідна для аналізу довгих періодів. PostgreSQL з розширенням TimescaleDB — оптимальний вибір для time-series даних: вона дає автоматичне партиціонування за часом та continuous aggregates, що прискорюють range-запити в 3 рази порівняно зі звичайним PostgreSQL. InfluxDB швидше на запис, але програє в гнучкості JOIN. Плоскі CSV-файли дешеві, але не підтримують індекси та не захищають від дублікатів. Саме тому ми зупинилися на TimescaleDB — гарантія унікальності через ON CONFLICT та швидкість вставки до 1000 записів/сек на одному вузлі.

import httpx import asyncio from datetime import datetime import asyncpg ENDPOINTS = { "binance_top_account": "https://fapi.binance.com/futures/data/topLongShortAccountRatio", "binance_global": "https://fapi.binance.com/futures/data/globalLongShortAccountRatio", "bybit": "https://api.bybit.com/v5/market/account-ratio", } async def collect_ls_ratio(symbol: str, period: str, db: asyncpg.Connection): async with httpx.AsyncClient() as client: resp = await client.get( ENDPOINTS["binance_global"], params={"symbol": symbol, "period": period, "limit": 1}, timeout=10.0, ) data = resp.json()[0] await db.execute(""" INSERT INTO ls_ratio (exchange, symbol, period, long_ratio, short_ratio, ts) VALUES ($1, $2, $3, $4, $5, $6) ON CONFLICT (exchange, symbol, period, ts) DO NOTHING """, "binance", symbol, period, float(data["longAccount"]), float(data["shortAccount"]), datetime.fromtimestamp(data["timestamp"] / 1000)) 

ON CONFLICT DO NOTHING — захист від дублікатів при повторному зборі. Унікальний індекс за (exchange, symbol, period, ts).

Як бути, якщо біржа не дає API?

Деякі біржі (Gate.io, Bitfinex) не публікують L/S ratio через офіційний API, але показують його на веб-сторінці. Для таких випадків використовуємо headless браузер через Playwright:

from playwright.async_api import async_playwright async def scrape_gateio_ls(symbol: str) -> float: async with async_playwright() as p: browser = await p.chromium.launch(headless=True) page = await browser.new_page() # Перехоплюємо XHR запити до internal API ls_data = {} page.on("response", lambda r: capture_ls_response(r, ls_data)) await page.goto(f"https://www.gate.io/futures/{symbol}") await page.wait_for_timeout(3000) await browser.close() return ls_data.get("longShortRatio") 

Офіційне API в 10 раз стабільніше, ніж headless-парсинг. Браузерний парсинг нестабільний: верстка змінюється, з'являються anti-bot заходи (Cloudflare, PerimeterX). Для production використовуємо тільки як fallback, з моніторингом успішності збору.

Практичні зауваження та типові помилки

Rate limiting: при зборі даних по 20+ символам з кількох бірж легко отримати HTTP 429. Використовуємо asyncio.Semaphore для обмеження одночасних запитів та exponential backoff при помилках. Binance Futures: 1200 weight в хвилину, кожен запит = 1 weight для market data.

Нормалізація даних: Binance повертає longAccount як частку (0.65 = 65% long), OKX — як ratio (1.86 = 1.86:1 long/short). Нормалізуємо до єдиного формату перед записом в БД.

Часові зони: всі timestamps конвертуємо в UTC. Binance повертає Unix milliseconds, Bybit теж, OKX — ISO 8601 рядок.

Як ми будуємо систему збору

Наш процес включає:

1. Аналітика: виявляємо всі необхідні символи та періоди. Визначаємо, які біржі дають L/S ratio через API, а де потрібен парсинг.
2. Проектування архітектури: вибираємо стек (async Python, httpx, asyncpg) та схему зберігання в TimescaleDB.
3. Розробка парсерів: пишемо асинхронні функції для кожної біржі з урахуванням rate limiter.
4. Інтеграція з БД: створюємо гіпертаблицю з партиціонуванням по днях та continuous aggregates для прискорення запитів.
5. Моніторинг та алерти: налаштовуємо сповіщення при падінні успішності збору нижче 95%.

Кожен етап тестуємо на невеликому наборі даних, потім масштабуємо.

Що входить у наше рішення під ключ

Ми пропонуємо готову систему збору та зберігання L/S даних:

• Налаштування парсерів під 3+ біржі (Binance, Bybit, OKX) з можливістю додавання нових.
• Зберігання в TimescaleDB з автоматичним партиціонуванням та retention policy.
• Моніторинг збору з алертами при падінні успішності нижче 95%.
• API для доступу до зібраних даних (фільтрація за біржею, символом, періодом).
• Документація та навчання команди.

Оцінимо ваш проект за 2 робочих дні — напишіть нам. Гарантуємо доставку даних з моменту запуску. Вартість рішення — від $1500 до $5000 залежно від кількості символів та бірж. Економія на інфраструктурі зберігання може досягати $2000 на місяць. Вже реалізували для 10+ проектів із загальним обсягом зберігання понад 500 млн записів. Зв'яжіться з нами для консультації — обговоримо вашу задачу без зобов'язань.

Чому варто довірити збір нам?

5 років досвіду в блокчейн-розробці, десятки проектів з парсингу та аналізу даних. Використовуємо production-стек: async Python, httpx, asyncpg, TimescaleDB. Всі рішення покриті моніторингом та мають резервні канали збору. Середня економія для наших клієнтів — $1000-3000 на місяць. Отримайте консультацію — зв'яжіться з нами.