Разработка контент-агрегатора: где ломается сбор данных
Разработка контент-агрегатора начинается не с интерфейса, а со сбора данных с источников: десятки площадок отдают карточки разной структуры, и на стыке приёма и нормализации ломается большинство проектов. Пока источников пять, схема работает при любой логике; на пятом десятке каталог начинает расходиться с реальностью, и это уже не правится настройками.
Источники редко сообщают об ошибке — вместо сбоя приходит ответ с пустыми полями, и агрегатор записывает карточку без описания или ключевой характеристики. Такая запись выглядит валидной, попадает в индекс и уходит пользователю, а обнаруживается только по жалобе. Рядом живут лимиты источника: расписание обхода, рассчитанное на равномерную нагрузку, упирается в суточную квоту, и часть площадок молча выпадает из цикла до следующего окна.
Дубликаты карточек расползаются незаметно: один и тот же объект приходит от поставщика и от дистрибьютора, названия различаются служебным словом и порядком слов, ключ сопоставления не срабатывает. В каталоге появляются три похожие записи с разными характеристиками, поиск теряет релевантность, а ручная чистка перестаёт успевать за потоком.
Устаревшие данные в каталоге копятся ещё быстрее: полный обход не успевает пройти все площадки, обновление отстаёт на сутки, и состояние карточки расходится с источником. Ниже разбираем, как это закрывается — от приоритезации обхода и очереди повторов до сведения дублей и контроля полноты полей.
Что даёт управляемый агрегатор: эффект в измеримых величинах
Обзор строится на инженерных величинах, которые измеряются на работающем каталоге: задержка публикации, доля дублей, устойчивость к отказам источников, наполненность карточек.
Свежесть каталога и частота обновления
Обход источников идёт по расписанию с разной частотой для разных типов лент: там, где записи появляются каждую минуту, интервал короткий, где обновления редкие — длинный. Разрыв между публикацией у источника и появлением в каталоге сокращается до минут вместо часов. Инкрементальный обход по указателям изменений обновляет только новое и правленое, а полный проход остаётся страховкой раз в сутки.
Сокращение доли дублей
Сравнение идёт в два уровня: точное совпадение по нормализованному тексту и идентификаторам источника, затем нечёткое — по сигнатурам заголовка и тела. Доля дублей в выдаче падает с десятков процентов до единиц, а переизданные материалы собираются в одну карточку со ссылкой на первоисточник.
Терпимость к сбоям источника
Изменённая разметка, ограничение частоты запросов, недоступность на несколько часов — на каждый случай своя реакция: повторы с нарастающей паузой, сохранённые последние успешные ответы, запасной способ разбора. Каталог продолжает наполняться по остальным источникам, а вернувшийся догоняется без потерь — уходит класс отказов «выдача встала целиком из-за одного сайта».
Релевантность выдачи и подборки для пользователя
Карточки обогащаются признаками: тематические метки, сущности, поведение просмотров и переходов. Ранжирование опирается на их сочетание, поэтому доля релевантных карточек в первых строках растёт, а полнота — заполненность обязательных полей — удерживается выше 90% за счёт проверок на приёмке.
Разработка контент-агрегатора: режимы сбора и обновления
Режим сбора задаёт две вещи сразу: через сколько минут новый материал попадает в каталог и какую долю запросов к источникам мы тратим впустую. Полная выгрузка раз в сутки предсказуема, но на источниках с плотным потоком публикаций почти все ответы возвращают уже известные записи.
Периодический обход источников
Инкрементальный обход запрашивает только то, что появилось после последней синхронизации — по метке времени и контрольной сумме материала. Окно перекрытия закрывает правки на границе интервалов, а курсор по каждому источнику хранится отдельно: сбой на одном ресурсе не сдвигает остальные. Свежесть — от десятков минут, объём выборки — в разы меньше.
Событийное обновление по сигналу источника
Источник сам сообщает о публикации — лентой изменений или изменившейся картой сайта. Задержка падает до минут, но появляется класс отказов: пропущенный сигнал. Поэтому событийный режим дополняют сверкой раз в сутки, иначе каталог тихо расходится с источником.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Полная выгрузка | Разовые сверки, восстановление после сбоя | Часы на цикл, много уже известных записей |
| Инкрементальный обход | Регулярный поток с датой публикации | Нужен курсор и окно перекрытия |
| Событийное обновление | Быстрые ленты, биржи, маркетплейсы | Зависит от сигнала, нужна страховочная сверка |
| Обход через очередь заданий | Много источников с разной частотой и лимитами | Приоритеты, повторы, ограничение скорости |
| Ручная загрузка срезов | Закрытые партнёры, разовые наборы | Не масштабируется, свежесть зависит от человека |
На практике режимы комбинируют: очередь заданий распределяет приоритеты, инкрементальный обход работает по умолчанию, событийный включают там, где важна минута. По отраслевым замерам Ahrefs значительная часть страниц не обновляется годами — таким источникам редкого обхода достаточно, и бюджет запросов уходит туда, где изменения реальны.
Как идёт внедрение: этапы инженерной работы
Перед стартом фиксируем, что уже есть: источники, их форматы, ограничения по частоте обращений, объём и условия использования контента. Ниже — порядок работ, по которому видно, на каком шаге мы находимся и что заказчик может проверить.
Что делаем на этапе разбора источников
- Разбор источников: инвентаризируем ленты, партнёрские выгрузки и файловые экспорты, отмечаем лимиты обращений, стабильность идентификаторов записей и условия использования контента.
- Схема обмена данными и модель сущностей: описываем, как запись приходит, нормализуется и связывается с автором, рубрикой и медиа, чтобы дубликаты и обновления ложились в одну карточку.
- Настройка обхода и правила слияния: расписание и глубина обхода, приоритет источников при конфликте полей, пороги схожести текста и логика объединения версий записи.
- Проверка качества данных на срезах: прогоняем исторические выборки, считаем долю найденных дублей, полноту полей и число ложных слияний.
Как проверяем результат перед передачей
- Мониторинг и оповещения: метрики по каждому источнику — доля ошибок, задержка появления записи, пустые выборки; оповещение при падении источника или смене структуры ответа.
- Передача проекта: доступы, конфигурации, регламент подключения нового источника, разбор инцидентов с поддержкой и период сопровождения.
Артефакты проекта: схемы, конфигурации, регламенты и доступы
Проект закрывается не презентацией, а комплектом артефактов, по которому систему можно эксплуатировать и развивать без нас. Каждый документ привязан к действию: что запустить, где посмотреть, кому выдать доступ, что делать при сбое.
Документация и инструкции
- Конфигурации сборщика и расписаний — частота обхода источников, паузы между запросами, повторы при ошибках, приоритеты очередей. Меняются правкой файла, без пересборки сервиса.
- Схема потоков данных — путь от источника до карточки в выдаче: где нормализация, где обогащение, где ручная модерация очереди.
- Правила дедупликации и сопоставления сущностей — какие признаки сравниваются, какая доля совпадения считается дублем, как разводятся похожие записи.
- Регламент обновления и реакции на сбои — периодичность релизов, порядок отката, пороги уведомлений и дежурные действия.
- Инструкции для поддержки — типовые инциденты и первые шаги: источник не отвечает, выросла очередь, дубли прошли в выдачу.
Права и разграничение доступа
- Матрица доступов и роли — кто правит список источников, кто меняет правила дедупликации, у кого есть доступ к боевому контуру.
- Порядок выдачи и отзыва прав — заявка, подтверждение, фиксация в журнале; при уходе сотрудника доступ закрывается одним действием.
- Журнал изменений — какая правка конфигурации что поменяла в выдаче и когда, чтобы разбор расхождений занимал минуты, а не дни.
Комплект остаётся у вас: команда поддержки вводится в проект по этим документам, без пересказа «на словах».
Кейс: как сократили дубли и время обновления каталога
Проект — агрегатор контента: десятки источников, сотни тысяч карточек, ежедневная переиндексация. Замеры снимали с логов службы сбора и очереди заданий до переработки и через месяц после — исходные данные лежат в отчёте по нагрузке.
Что было до переработки сбора
Каждый источник опрашивался по своему расписанию, полный обход каталога занимал около шести часов, а карточка появлялась в поиске с задержкой до суток. Дедупликация искала точное совпадение адреса страницы и заголовка, поэтому 28–34% выдачи составляли дубли: один и тот же товар приходил от нескольких источников и жил отдельными карточками.
Обход пагинации никто не контролировал: при смене разметки источник молча отдавал первую страницу, и до 11% позиций не попадало в индекс. Оператор сводил по 150–200 карточек за смену вручную, правки нигде не фиксировались, а расхождения всплывали уже в выдаче.
Что изменили: сбор перевели на единый конвейер — нормализация полей, сравнение по вектору признаков вместо точного совпадения строк, автоматическое слияние и разбор вручную только для спорных пар. Сверку и поиск держим на актуальной ветке Elasticsearch, за схему источника отвечает валидатор разметки.
После переработки доля дублей — 3–4%, и это реально разные комплектации. Полное обновление каталога занимает минуты вместо часов, задержка появления позиции сократилась с суток до десятков минут. Пропуски ушли в доли процента: при изменении разметки приходит уведомление, а не тихая деградация. Ручных правок осталось несколько десятков в неделю — только пограничные случаи, которые конвейер помечает сам.
Чем отличается обход по расписанию от событийного обновления
Обход по расписанию и событийное обновление решают одну задачу — доставить в каталог свежую версию позиции, но платят за это разными ресурсами. Первый вариант опрашивает источник через равные промежутки и не требует от него ничего, кроме стабильного ответа. Второй — источник сам сообщает об изменении, и позиция обновляется почти сразу.
Главная разница — задержка появления позиции. При расписании она равна половине интервала в среднем и полному интервалу в худшем случае: товар изменился через минуту после прохода, а каталог узнает об этом лишь на следующем. Событийная схема сокращает задержку до времени обработки сигнала, но упирается в готовность источника такие сигналы отдавать: часть поставщиков отдаёт только пакетные выгрузки, и событийный режим там не построить.
Вторая разница — нагрузка на источник. Расписание даёт предсказуемый пик: задачи стартуют синхронно, источник получает залп запросов, который размазывают окнами и ограничением параллелизма. Событийное обновление разносит нагрузку во времени, но делает её неравномерной: при массовом пересчёте каталога поставщика сигналы приходят пачкой, и принимать их нужно с запасом по ёмкости очереди.
Третья — сопровождение. Расписание отказывает тихо: пропущенный проход оставляет в каталоге старую версию, и заметно это только по метрике свежести, поэтому нужен контроль отставания и оповещение о срыве цикла. Событийная схема требует идемпотентной обработки повторных доставок, дедупликации по хешу содержимого и сверочного обхода: без него один потерянный сигнал оставляет позицию устаревшей бессрочно.
Выбор прозрачен: расписание достаточно там, где опоздание дешевле инфраструктуры, — цены, остатки, наличие. Событийное обновление нужно, когда позиция обязана совпадать с источником в пределах минут и источник готов сигнализировать. Рабочая схема обычно гибридная: сигналы дают свежесть, сверочный обход — гарантию полноты.
Технические сомнения: нагрузка, дубли, правомерность сбора
Обход источников строим так, чтобы нагрузка на них не превышала обычный пользовательский трафик: лимит частоты запросов на домен, паузы между сериями, суточный потолок на источник. При отказе источник уходит из ротации, необработанные адреса возвращаются в очередь, и каталог не теряет позиции.
Что будет при смене разметки источника?
Сборщик сохраняет сырой ответ и разбирает его отдельным слоем. Меняется вёрстка — падает разбор, а не загрузка: видно долю неуспешных карточек, правило правится, уже собранное остаётся в каталоге.
Сохранится ли каталог, если обход остановить?
Да. Запись идёт порциями, состояние очереди и курсоры фиксируются. После перезапуска обход продолжается с места остановки, без повторного прохода по источнику; дубли отсекает дедупликация по ключу и отпечатку содержимого.
Как подключается новый источник?
Отдельным описанием: адреса, схема разбора, частота обхода, правила дедупликации. Источник включается в общий поток, не затрагивая работающие, а стартовать можно с одного и добавлять остальные постепенно.
Сбор данных правомерен?
Работаем с открытыми данными, сверяясь с Директива о правовой охране баз данных: учитываем условия использования источника, ограничиваем объём выборки, храним ссылку на первоисточник и метку времени. Персональные данные без основания не собираем и с каталогом не смешиваем.
Обсудим задачу: что нужно, чтобы вернуться с оценкой и планом
Чтобы оценка проекта была предметной, а не «вилкой на глаз», нам нужен вход от вас — и это не формальность: на входе мы считаем число источников, объём дедупликации и нагрузку. Ниже — что полезно прислать и о чём договориться до старта, чтобы мы вернулись с планом работ по этапам.
- Перечень источников и их типов: программные интерфейсы, фиды, страницы под разбор, файловые выгрузки. По каждому важно понимать, отдаёт ли он структурированные данные или только разметку — от этого зависит трудоёмкость.
- Доступы к источникам или тестовые срезы: ключи, лимиты, разрешённые частоты обращений. Если доступов нет, достаточно выгрузки за несколько дней — на реальных данных сразу проверяем, как работает дедупликация.
- Текущая схема каталога: сущности, правила связывания одного объекта из нескольких источников, обязательные поля и то, что уже накоплено. Это задаёт состав работ по слиянию и хранению.
- Требования к частоте обновления и правилам слияния: как быстро новый объект должен попадать в каталог, какой источник приоритетен при конфликте полей, что делать с исчезнувшими предложениями.
- Ограничения по инфраструктуре: размещаем у вас или у нас, требования к логам и персональным данным, есть ли запрет на внешние сервисы.
- Кто сопровождает после сдачи: ваша команда или наша, нужны ли регламент реакции на сбой источника, доступ к мониторингу и обучение.
- Ожидаемая нагрузка и персонализация: число пользователей, признаки для рекомендаций, есть ли история поведения.
Опишите задачу в свободной форме — вернёмся с оценкой и планом работ, разбитым по этапам со сроками.
