Настройка промышленного парсинга крипто-данных по расписанию (cron)

Настройка парсинга крипто-данных: где рвётся сбор

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

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

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

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

Ниже разбираем, как это закрывается: идемпотентные проходы, контроль полноты окон и сверка с источником на каждом цикле.

Что даёт регулярный сбор биржевых данных

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

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

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

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

Режимы получения данных: сравнение подходов

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

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

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

Этапы настройки регулярного сбора данных

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

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

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

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

• Схема данных — описание сущностей: свечи, сделки, стакан, ставки финансирования; типы полей, точность округления, таймзона и ключ дедупликации (инструмент + метка времени + тип свечи).
• Конфигурация сборщика — перечень заданий, интервал запуска, глубина запроса, лимиты обращений к источнику, пауза при отказах, список бирж и торговых пар в одном файле.
• Правила доступа — ключи только на чтение, хранение секретов вне кода, порядок ротации, разделение ролей для рабочего и тестового контура, кто видит сырые данные.
• Регламент перезапуска — пошаговый порядок после падения: проверка состояния, добор пропущенного окна, повторный запуск без дублей, критерии остановки.
• Журнал сбора — статусы заданий, число записанных записей за окно, ошибки источника, задержка от метки времени до записи, оповещения о пропусках.
• Схема размещения — где выполняются задания, как хранятся сырые данные и архивы, какие сроки хранения заданы по слоям.
• Инструкция по расширению — как добавить новый инструмент или поле без правки ядра: что менять в конфигурации, как проверить результат на тестовом контуре.

Комплект рассчитан на инженера, который не участвовал в разработке: по документации сбор поднимается с нуля, а расхождение в данных разбирается по журналу, без обращения к нам.

Кейс: вернули полноту сбора данных по 14 источникам

Заказчик собирал рыночные данные по 14 источникам: биржевые интерфейсы, агрегаторы вроде CoinGecko, публичные узлы сетей. Запуски по расписанию выполнялись, но 12% окон терялись: источник отвечал ошибкой лимита, задача падала, и данные за этот интервал не доезжали до следующего цикла. Расхождения между каналами достигали 7% — на них ломались сверка позиций и отчётность.

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

Что стало: полнота данных выросла с 88% до 99,7%, расхождения между каналами — с 7% до 0,4%. Время восстановления после отказа источника сократилось с 40 минут ручной перезагрузки до 90 секунд автоматического добора — следующий цикл стартует уже с полными данными.

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

Чем отличается парсинг по расписанию от потока в реальном времени

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

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

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

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

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

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

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

Как исключаются дубли записей?

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

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

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

Источник сменил формат ответа — что тогда?

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

Обсудим задачу: что уточнить перед началом работ

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

• Предметная область: какие пары, сети и площадки в фокусе, нужен ли срочный рынок и внебиржевые сегменты или только спот.
• Перечень источников: биржевые интерфейсы, агрегаторы, узлы сети, собственные источники цен — с пометкой, какие отдают историю, а какие только текущее состояние.
• Требования к полноте: допустимая доля пропусков, что делать с расхождениями между площадками, нужна ли переобработка задним числом и за какой горизонт.
• Глубина и частота: период первичной загрузки и расписание опроса — минутное, часовое или по событию.
• Формат выдачи: сырые ответы, нормализованная схема или агрегаты по интервалам; куда складываем данные.
• Доступы и лимиты: ключи, ограничения по числу запросов, требования к сетевому доступу и размещению узлов.
• Регламент сбоев: кому и как сообщаем о простое источника, сколько ждём восстановления, по каким метрикам считаем данные достоверными.

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