Парсинг исторических данных свечей (OHLCV) с бирж
Сбор исторических OHLCV данных с криптобирж требует продуманной архитектуры. Мы сталкивались с этой задачей десятки раз: разные площадки, лимиты, форматы. «Ручной» парсинг через браузер — путь в никуда. Нужна система, которая соберёт данные с Binance, Uniswap и ещё 10+ площадок в единую TimescaleDB, не упираясь в rate limits. Один из наших проектов обрабатывал 50 инструментов в реальном времени — без единой блокировки IP.
Почему важен rate limiter для OHLCV парсинга?
Наивный sleep(100) между запросами — причина потери данных и блокировки IP. Binance даёт 1200 запросов в минуту на IP. Если собирать 100 инструментов одновременно, превышение случается за секунды. #rate limiter# с динамической регулировкой — единственный рабочий подход. Мы реализовали RateLimiter с отдельными bucket для каждой биржи. Он стабильно держит 20 req/s без превышений.
CEX vs DEX: разные источники, разная логика
| Характеристика | CEX (Binance, OKX) | DEX (Uniswap, Curve) |
|---|---|---|
| API | REST / WebSocket | Нет нативного OHLCV |
| Данные | Агрегированные свечи | Из swap-событий (on-chain) |
| Глубина | С момента запуска биржи | С момента деплоя контракта |
| Rate limits | 1200 req/min | Блокчейн — отсутствуют |
| Сложность | Средняя (ccxt) | Высокая (The Graph / RPC) |
CEX — стандарт: чистые свечи, минимальный gap. DEX — нужна индексация событий и пересчёт цены через sqrtPriceX96. Наш сборщик объединяет оба подхода под единым интерфейсом.
Как собирать OHLCV данные с DEX без нативного API?
Для DEX мы используем индексацию swap-событий через The Graph или прямой RPC. События содержат sqrtPriceX96, из которого вычисляется цена. Далее агрегируем их в свечи заданного таймфрейма. Это позволяет получать данные для любого пула Uniswap V3. Схема хранения в TimescaleDB с hypertables даёт возможность быстро агрегировать по времени.
Сбор исторических OHLCV данных: этапы работы
- Аналитика — определяем список бирж, инструментов, таймфреймов.
- Проектирование — схема БД (TimescaleDB hypertable), архитектура сборщика.
- Реализация — пишем скрипты парсинга, rate limiter, логирование.
- Тест — загружаем 1 млн свечей, проверяем gap-ы, скорость, дубликаты.
- Деплой — на ваш сервер или облако (AWS/GCP), настройка алертов.
Как мы это делаем: стек и реализация
Основной инструмент — библиотека ccxt для 100+ бирж. Поверх неё — собственный слой rate limiting, логирования и #инкрементальной загрузки#. Ключевые компоненты:
- Rate Limiter с #token bucket# (1200 req/min для Binance)
- Мультибиржевой сборщик на ccxt с поддержкой retry и fallback
- Хранилище на TimescaleDB с hypertables, compression и continuous aggregates
Код rate limiter и сборщика — в оригинальной статье. Данные пишутся в TimescaleDB, где автоматически создаются дневные агрегации через Continuous Aggregates. Наш сборщик в 3 раза быстрее стандартного подхода за счёт параллелизации и динамического управления лимитами.
Сравнение методов rate limiting:
| Метод | Пропускная способность | Сложность реализации |
|---|---|---|
| Token bucket | Высокая | Средняя |
| Sliding window log | Очень высокая | Высокая |
| Fixed window | Низкая | Низкая |
Для высоконагруженных сценариев используем sliding window log, записывая timestamp каждого запроса в Redis. Но для 95% задач достаточно нашего RateLimiter.
Пример конфигурации rate limiter
const rateLimiter = new TokenBucket({ capacity: 1200, fillRate: 1200, // per minute tokens: 1200 }); Что входит в работу
- Документация — описание схемы БД, API методов, инструкция по развертыванию
- Код — скрипты для сбора, обновления, агрегации (TypeScript + SQL)
- Доступы — настройка TimescaleDB, создание пользователей
- Обучение — 2 сессии по 1 часу для вашей команды
- Поддержка — 1 месяц после деплоя (ответы в течение 24 часов)
Сроки ориентировочно
От 1 до 3 недель в зависимости от количества бирж и размера истории. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект. Это избавляет от затрат на подписку сторонних API (до $500/мес) и сокращает время на инженерные изыскания. Получите готовое решение для вашего бэктестинга.
Типичные ошибки при сборе OHLCV
- Игнорирование rate limits — блокировка IP и потеря времени
- Хранение в CSV — невозможно эффективно агрегировать и искать
- Отсутствие алертов — gap в данных остаётся незамеченным неделями
Мы устраняем эти проблемы на этапе проектирования. 10+ проектов по сбору OHLCV — наш опыт гарантирует стабильный пайплайн. Понятие OHLCV восходит к традиционному биржевому анализу (Wikipedia). Закажите консультацию, и вместе спроектируем решение под ваши задачи. Свяжитесь с нами для оценки вашего проекта.