Сбор исторических свечных данных (OHLCV) с бирж для бэктестинга

OHLCV данные с бирж: где рвутся исторические ряды

Исторические свечи почти никогда не бывают непрерывными. Биржа уходит на техработы, останавливает торги по инструменту, меняет правила расчёта — и в ряду остаётся дыра. На графике её не видно: следующая свеча просто примыкает к предыдущей, а вопрос «была ли торговля в эти минуты» никто не задаёт.

Второе ограничение — рассинхрон между площадками. Разное время закрытия суток, разные торговые календари, разное время старта инструмента дают ряды, которые не сходятся по границам. Если склеить их как есть, стратегия «увидит» движение, которого на рынке не было.

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

Ручной сбор котировок с бирж не масштабируется. Площадки меняют лимиты запросов, добавляют пары и таймфреймы, требуют ключи; десятки инструментов на нескольких интервалах приходится сверять глазами. Любая правка теряется при следующей выгрузке — ряд больше не воспроизводим.

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

Выверенный ряд свечей: скорость проверки и меньше ложных сигналов

Бэктест ломается не на логике стратегии, а на входных данных. Свеча с потерянным объёмом, дубликат бара при слиянии двух площадок или выпавший интервал на обслуживании биржи — и проверка торговых стратегий показывает вход там, где в реальности сделки не было. Цена такой ошибки — переписанный торговый модуль и недоверие ко всем результатам проверки.

Выгрузку свечей делаем напрямую через торговые интерфейсы площадок, включая Binance: постранично по времени, с повторами на сетевых сбоях. Подготовка данных сводится к единой схеме — метка времени в UTC, open/high/low/close, объём, тикер, таймфрейм. Бары из разных источников сверяем по метке, дубликаты отбрасываем, а интервалы с нулевой ликвидностью помечаем флагом, чтобы они не попали в расчёт индикаторов как настоящие сделки.

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

На выходе подготовка истории занимает часы вместо недель ручной сборки, доля восстановленных пропусков доходит до 95–98%, а ложные сигналы на разрывах перестают считаться входами — на длинных периодах это заметно меняет профиль просадки. Ряд при этом воспроизводим: тот же запрос к хранилищу даёт тот же результат и через месяц.

Способы сбора OHLCV данных: полная выгрузка и догрузка

Источник данных определяет, сколько времени уйдёт на первое наполнение и как часто потом придётся возвращаться к обрывам связи. Биржевые архивы отдают историю пакетами за прошлые периоды — это самый быстрый способ получить многолетний ряд, но файлы публикуются с задержкой и требуют разбора формата. Публичный интерфейс биржи отдаёт свечи по запросу, ограничен частотой обращений и глубиной доступной истории.

Инкрементальная догрузка решает другую задачу: она забирает только свечи, закрывшиеся после последней сохранённой, и потому обходится несколькими запросами на инструмент. На практике схему собирают из двух частей — архив закрывает прошлое, расписание сбора держит актуальный край ряда.

Точки контроля одинаковы для любого варианта: дедупликация по времени открытия свечи, проверка пропусков в ряду и колоночное хранение, где догрузка дописывает партиции, а не перезаписывает весь набор. Такая схема сокращает первое наполнение с суток до десятков минут и убирает повторные полные проходы по истории.

Порядок сбора истории: от аудита источников до передачи

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

1. Аудит источников данных. Смотрим, какие биржи и пары нужны, какова реальная глубина истории, как источник отдаёт пропуски и паузы торгов, какие лимиты на частоту запросов и где исторические выгрузки обрываются.
2. Схема сбора. Фиксируем единый формат OHLCV, набор таймфреймов, приведение времени к одному поясу, правила агрегации младших интервалов в старшие и округление объёмов.
3. Настройка сбора. Настраиваем постраничные выгрузки по временным окнам, повторные попытки при обрывах, докачку недостающих участков и идемпотентную запись, чтобы повторный запуск не плодил дубли.
4. Сверка свечей. Сравниваем пересекающиеся участки с эталонным источником, отлавливаем расхождения цен открытия и закрытия, аномальные объёмы и разницу в границах интервалов.
5. Контроль разрывов. Проверяем непрерывность ряда, отдельно обрабатываем технические паузы, делистинг и смены тикеров, помечаем участки, где данные восстановлены из альтернативного источника.
6. Валидация и упаковка. Прогоняем проверки на монотонность времени, нулевые и дублирующие свечи, раскладываем массив по парам и месяцам для быстрой выборки.
7. Передача данных. Отдаём массив в согласованном формате с описанием полей, журналом источников по каждому участку и скриптом повторного сбора — команда может обновлять историю самостоятельно.

Что остаётся у вас: схемы, регламенты, готовые выгрузки

После сдачи проекта у вашей команды остаются не только сами данные, но и всё, что нужно для их самостоятельного воспроизводства: описанные источники, правила обработки и рабочие скрипты загрузки. Мы не оставляем решение в состоянии «работает, но непонятно как» — инженер сопровождения сможет поднять контур заново и получить те же ряды.

• Схема источников. Перечень площадок и инструментов с интервалами, приоритет при расхождении цен и правило выбора эталонного ряда.
• Документация по данным. Словарь полей OHLCV, таймзоны, единицы объёма, правила обработки пропусков, дублей и разрывов торгов.
• Регламент пересборки. Что и в каком порядке запускать при добавлении инструмента, смене формата выгрузки или найденной дыре в истории.
• Выгрузки в хранилище. Ряды в партиционированных таблицах и плоских файлах, пригодные к загрузке в аналитический контур без дополнительной чистки.
• Отчёты контроля качества. Сверки между источниками, список аномальных свечей и покрытие по датам — видно, где данных нет и почему.
• Передача решения. Доступы, развёртывание на вашей стороне, разбор инцидентов и передача знаний команде сопровождения.
• Журнал версий обработки. Что менялось в правилах нормализации и как это влияет на сопоставимость результатов прошлых тестов.

Кейс: восстановление пропусков в истории по 40 парам

Клиент — команда алгоритмической торговли: ей нужна была история по 40 парам с минутными свечами за несколько лет, иначе тестирование стратегий на истории давало ложные результаты. Собирали OHLCV из трёх источников, включая Binance, и сразу увидели проблему: около 3,4% свечей отсутствовали. Разрывы приходились на технические работы площадок и периоды, когда сделок по паре не было вовсе.

Каждый пропуск классифицировали, а не закрывали догадкой: реальное отсутствие сделок, сбой выгрузки или расхождение меток времени между площадками. Для настоящих дыр пересобирали свечи из архивов сделок, для мнимых — писали нулевой объём с явной пометкой, чтобы модель не принимала тишину за движение. Контроль непрерывности работал автоматически: разрыв длиннее одного интервала уходил в карантин до подтверждения.

Цифры до и после. Доля пропусков упала с 3,4% до 0,02% по всем торговым парам. Подготовка ряда занимала около шести часов ручной сверки — теперь это прогон на несколько минут, и человек просматривает только спорные участки. Перепроверок результата было по три круга на каждую пару — осталась одна сводка расхождений.

Каждый ряд версионируется: у пары есть опись с контрольными суммами и датой срезки, поэтому повторный сбор воспроизводит тот же файл. Это убрало класс отказов, когда тест расходился с живой торговлей из-за незамеченной дыры, и дало возможность сравнивать стратегии на одном и том же наборе данных.

Чем отличается инкрементальная догрузка от полной перезагрузки?

Инкрементальная догрузка OHLCV-данных запрашивает только те свечи, которых ещё нет в хранилище — от метки времени последней записанной свечи. Ночной добор по десяткам инструментов занимает минуты и не упирается в ограничения на частоту запросов к бирже.

Плата за такую экономию — накопление расхождений. Если свеча не догрузилась из-за обрыва соединения или биржа позже уточнила объём, в середине ряда останется пропуск или устаревшее значение — и всплывёт он только на сверке данных, уже после прогона стратегии.

Полная перезагрузка перезапрашивает весь диапазон и перезаписывает партиции целиком. Она снимает вопрос консистентности: уточнения объёмов, восстановленные пропуски и смена состава инструментов подтягиваются сами, а результат не зависит от того, как отработали предыдущие запуски. Цена — время и число запросов растут линейно по глубине истории.

Для уже развёрнутого хранилища чаще берут смешанный режим: ежедневная инкрементальная догрузка по расписанию плюс периодическая полная перезагрузка скользящего окна — последних недель. Обрывы соединения не страшны: прогресс фиксируется по времени последней записанной свечи, а вставка идемпотентна по ключу «инструмент + интервал + время открытия», поэтому повторный запуск продолжает с того же места без дублей.

Итог: инкрементальная догрузка — для оперативного обновления истории, полная перезагрузка — страховка консистентности на ограниченном окне, смешанный режим — когда хранилище живёт долго и обновляется каждый день.

Технические сомнения: глубина истории, пропуски, форматы

Перед стартом сбора почти всегда всплывают одни и те же сомнения: хватит ли глубины истории, что делать с дырами в ряду и как потом сверить наши свечи с тем, что видит стратегия. Мы собираем OHLCV из нескольких источников — от Binance до региональных площадок — и по каждому пункту ниже отвечаем до начала работ, а не после первой выгрузки.

Что делать с пропусками и биржевыми выходными?

Пропуск в ряду — не всегда ошибка: на выходных и в дни остановки торгов свеча не существует физически. Мы различаем три случая — отсутствие торгов, сбой сбора и реальный пробел в источнике — и закрываем их по-разному: нулевым объёмом, повторным запросом или отдельным флагом в данных. Иначе стратегия принимает остановку торгов за нулевую волатильность и показывает на истории результат, которого не было.

В каком часовом поясе и формате храните свечи?

Всё приводим к единому поясу с сохранением исходной метки времени источника, иначе свечи разных площадок не стыкуются по открытию и закрытию сессии. Хранение — колоночное, с разбивкой по дате и инструменту, плюс выгрузка в табличном виде для ручной проверки. Сверка идёт повторным запросом и сличением объёмов: расхождение между источниками выше порога помечаем как подозрительное и разбираем до передачи данных.

Обсудим задачу: соберём историю под вашу стратегию

Чтобы оценка опиралась на факты, а не на догадки, для старта достаточно нескольких вводных. Пришлите перечень площадок и инструментов, таймфрейм и глубину истории, а также формат, в котором данные должны лечь в ваше хранилище, — этого хватает, чтобы посчитать объём запросов и ограничения по частоте обращений к каждой бирже.

• Перечень бирж и инструментов: спотовые пары, фьючерсы, отдельные тикеры.
• Таймфрейм и глубина истории — минутки за несколько лет или часы за месяцы: от этого напрямую зависит число запросов.
• Формат выгрузки: набор колонок, часовой пояс, округление, CSV или Parquet.
• Как стратегия работает с OHLCV данными: индикаторы, скользящие окна, правила обработки пропусков и разрывов ликвидности.
• Место хранения и периодичность обновления: файлы, объектное хранилище или база.
• Критерии приёмки: сколько контрольных точек сверить с первоисточником и какое расхождение считать значимым.

План работ строим от проверяемого результата: сначала пробная выборка по одному инструменту за короткий интервал, сверка с эталоном, затем полная загрузка по всем площадкам и настройка регулярного обновления. Так расхождения в часовых поясах и пропущенные свечи всплывают в начале, а не после выгрузки всего объёма. Оценка сроков приходит вместе с планом и разбивкой по этапам, чтобы порядок запуска был понятен до начала работ.

Опишите задачу в свободной форме — вернёмся с оценкой и планом под вашу стратегию.