Сбор данных CoinGecko и CoinMarketCap: парсинг, API, кеширование

Почему парсинг CoinGecko падает на пиковых нагрузках рынка

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

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

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

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

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

Что даёт выстроенный сбор рыночных данных

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

Выстроенный сбор закрывает этот класс отказов целиком: CoinGecko и второй источник опрашиваются по расписанию, ответы ложатся в хранилище до обработки, а не после. Что это даёт на практике:

• Целостность истории. Каждый интервал закрыт точкой данных; доля пропусков видна в отчёте и измеряется в десятых долях процента, а не выясняется через месяц.
• Единый контур данных. Котировки, объёмы и капитализация из обоих источников сведены к общим меткам времени — сверка идёт внутри одного набора, без сшивания таблиц вручную.
• Предсказуемая нагрузка на источник. Частота опроса и глубина кеша рассчитаны так, чтобы укладываться в лимиты и не уходить в блокировку при пиковых движениях рынка.
• Отказ от ручных выгрузок. Ноль операций «скачать и переименовать»: сбор, нормализация и запись идут без участия человека по расписанию.
• Автоматическая сверка источников. Расхождение цены или объёма выше порога уходит в журнал с контекстом запроса — аномалия видна до того, как попадёт в расчёты.

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

Форматы сбора: парсинг CoinGecko, официальный API, вебхуки

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

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

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

Этапы внедрения: от аудита источников до регламентов

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

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

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

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

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

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

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

Кейс: как агрегатор котировок перестал терять историю цен

Где терялась история

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

Что изменили

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

Метрики до и после

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

Чем CoinMarketCap отличается от биржевого агрегатора

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

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

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

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

Технические сомнения: лимиты, блокировки, расхождения

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

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

Почему цены у двух источников отличаются на доли процента?

Разные методики расчёта и разное время снимка. Для решений важна не «истинная» цена, а согласованность: считаем отклонение и фиксируем его динамику по каждому инструменту.

Что будет, если источник сменит формат ответа?

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

Можно ли пересчитать историю за прошедший период?

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

Обсудим задачу: с чего начнём сбор ваших данных

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

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

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