Парсинг крипто-новостей: агрегатор данных из RSS и API

Почему парсинг крипто новостей ломается на десятках источников

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

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

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

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

Что даёт единый поток данных: скорость, полнота, отказоустойчивость

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

Задержка появления новости складывается из частоты опроса и времени обработки. Источники с плотным потоком публикаций опрашиваются с приоритетом, редкие — реже, чтобы не расходовать квоты API; в результате новость оказывается в ленте через десятки секунд после выхода, а не через часы ожидания ручной вычитки.

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

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

Сравнение способов сбора: прямые подключения, готовые ленты, разбор страниц

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

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

Выбор режима фиксируется по каждому источнику отдельно и пересматривается, когда поставщик меняет условия или вёрстку.

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

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

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

Артефакты проекта: схемы потоков, правила нормализации, регламенты

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

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

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

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

Что было до

На замере потока за две недели до ленты не доезжало 8–14% публикаций: дубли вытесняли свежие записи, а сбой одного источника тихо оставлял пробку в общей очереди. Задержка от публикации до появления в ленте держалась в пределах 20–40 минут, в дни резких движений рынка растягивалась до часа. Сборщик падал 3–4 раза в неделю — разрыв соединения он не переживал и продолжал отдавать пустые ответы, пока оператор не замечал пропажу.

Что стало после

Переписали сбор: единая очередь с подтверждением обработки, ключ уникальности по заголовку и времени публикации, отдельный буфер для повторного разбора сбойных ответов и контроль отставания по каждому источнику. Потери упали ниже 0,5% — это шум от удалённых на стороне источника материалов. Медианная задержка ленты — 40–90 секунд, включая разбор и проверку на дубли. За квартал наблюдения простоев нет: разрыв связи приводит к повторной постановке задач, а не к остановке ленты, восстановление занимает минуты.

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

Чем отличается сбор по RSS от работы с биржевым API?

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

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

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

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

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

Как отличить дубликат от повторной публикации?

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

Новость пришла с задержкой — как не выдать устаревшее?

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

Источник сменил формат ленты или недоступен?

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

Обсудим задачу: что нужно для оценки вашего агрегатора

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

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

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