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