Парсер новин: де ламається збір стрічки на масштабі
На десятку джерел парсер новин здається робочим: стрічка читається, матеріали з’являються. На сотнях видань з різною періодичністю збір новинних стрічок дає збої, про які команда дізнається від читачів, а не від системи.
Частина джерел віддає час публікації у своєму часовому поясі, частина — лише дату без години, а порядок елементів під час повторного опитування змінюється, тому «останні N записів» не збігаються з тим, що реально вийшло за добу, — так з’являються пропущені публікації.
Окремий головний біль — дублікати під час оновлення стрічки. Видавець змінює структуру посилання, дописує службові параметри адреси, переносить матеріал до іншої рубрики, — і та сама новина заходить у базу вдруге.
Поки ключ запису залежить від порядку полів і прикрас у посиланні, дедуплікація спирається на заголовок, а його правлять уже після виходу матеріалу.
Вузьке місце збору зазвичай одне: єдиний цикл опитування за всіма джерелами. Повільна відповідь одного видання затримує решту, інтервал зростає, а на піках завдання відпадають за часом очікування — найактивніші стрічки залишаються неопитаними саме тоді, коли новин найбільше. Далі починається ручне довантаження: редактор відкриває сайти й копіює матеріали вручну.
Розбираємо, як це закривається: окрема черга на джерело, свій інтервал опитування замість спільного кола, стійкий ключ запису й повторний прохід за вікном часу після збою.
Який ефект дає керований збір новин
Повнота збору публікацій перестає залежати від того, як джерело віддає стрічку.
Частина матеріалів губилася на посторінковій навігації та в розмітці — до 10–15% пропусків; після переведення збору на кілька каналів одразу (стрічка, видача, архів) пропуски падають до часток відсотка й підтверджуються звіркою з джерелом.
Затримка появи матеріалу вимірюється хвилинами. Інтервал опитування адаптивний: активні джерела перевіряються частіше, спокійні рідше, а під час сплеску публікацій черга не зростає — новий запис опиняється в системі протягом кількох хвилин, а не до наступного ручного прогону.
Частка ручних довантажень скорочується з 10–15% випусків до поодиноких випадків. Редактор втручається лише там, де джерело віддало неповний текст або бите посилання, і такий запис приходить із позначкою про причину, а не з’ясовується вже на верстці.
Окремий ефект — зниклий клас відмов на зміні верстки джерела. Правила розбору винесено в конфігурацію поряд із шаблонами типових платформ на кшталт WordPress: переїзд на нову тему ламає лише один адаптер, інші джерела продовжують збиратися, а розходження видно в журналі розбору.
Загалом це стабільність збору стрічки: передбачувана повнота, коротка затримка появи запису й короткий список місць, куди дивиться інженер.
Формати збору: парсер новин за розкладом і за подією
В одного джерела зазвичай кілька точок доступу до контенту, і вибір між ними визначає і повноту вибірки, і вартість підтримки. Нижче — режими, які ми комбінуємо в одному збирачі, та чесні обмеження кожного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Розбір відкритої стрічки (RSS, Atom, JSON Feed) | Джерело саме публікує стрічку | У стрічці часто лише анонс і обрізаний текст, дати в різних зонах, у частини видань затримка публікації |
| Обхід розділів джерела | Стрічки немає або вона неповна | Прив’язка до розмітки ламається під час редизайну, потрібні пагінація, обхід дзеркал і ліміт запитів |
| Розбір повного тексту статті | Потрібен текст цілком, а не анонс | У вибірку потрапляють навігація, реклама та блоки «читайте також», потрібні правила очищення й канонізація посилань |
| Подієве опитування джерел | Важлива швидкість реакції | Не всі джерела віддають повідомлення, потрібен запасний шлях за розкладом і захист від повторної доставки |
| Збір за розкладом | Базовий режим для всього масиву | Інтервал — компроміс між свіжістю та навантаженням, є добові вікна публікацій та обмеження на кількість запитів |
Як комбінуємо режими
На практиці ми не обираємо один варіант: збір за розкладом закриває весь список джерел, а подієве опитування вмикається там, де затримка критична.
Обов’язкові елементи будь-якого режиму — дедуплікація за ідентифікатором запису й хешем тексту, глибина вікна публікації та передбачувана поведінка при недоступності джерела: пропуск із позначкою й повтор у наступному циклі замість зупинки всього збору.
Якщо джерело посилює обмеження збору, частину джерел переводять на рідший обхід — вибірка залишається повною, а навантаження на видавця знижується.
Етапи впровадження парсера: від аудиту джерел до передачі
Парсер новин рідко ламається на коді — частіше відмовляє джерело: змінюється розмітка, вмикається обмеження частоти звернень, частина публікацій іде в архів. Тому робота йде послідовно, від аудиту джерел до передачі, і кожен наступний крок спирається на результат попереднього.
- Аудит джерел. Розбираємо список стрічок: які віддають повний текст, які лише анонс, у якому вигляді надходять дати, чи є архів і ліміти на частоту запитів. На виході — перелік джерел із пріоритетом і режимом обходу.
- Схема нормалізації полів. Публікації з різних стрічок приводимо до єдиного набору: заголовок, дата, тіло, посилання, автор, рубрики. Окремо описуємо приведення дат до одного часового поясу й розбір кодувань — інакше у сховищі з’являються дублі та записи без змісту.
- Правила обходу стрічки. Задаємо періодичність опитування, глибину дозабору під час першого запуску, дедуплікацію за посиланням і відбитком тексту. Тут же описуємо поведінку при недоступності джерела й повторний дозабір пропущеного вікна.
- Перевірка на еталонній вибірці. Збираємо вручну розмічений набір публікацій за період і звіряємо з ним результат: частка правильно вилучених полів, кількість хибних дублів, втрачені записи. Правила й розбір розмітки правляться до стабільного результату.
- Передача рішення замовнику. Віддаємо конфігурації джерел, опис схеми полів, інструкцію з підключення нової стрічки та оповіщення про збої, які спрацьовують раніше, ніж проблему помітить читач.
Далі йде супровід: оновлення правил під змінену розмітку, додавання стрічок і контроль якості вивантаження тримають потік публікацій безперервним без переписування ядра.
Комплект передачі: конфігурації, схеми обходу, регламенти
Комплект збирається так, щоб збір можна було вести й розвивати своїми інженерами, а не лише силами авторів рішення. Кожен артефакт прив’язаний до конкретного джерела й відповідає на питання «що робити, якщо він зміниться» — це відрізняє робочу передачу від папки з документами.
- Опис джерел: карта стрічок і розділів — формат видачі, частота публікацій, часовий пояс, перелік полів, які забираються.
- Правила обходу стрічок: інтервали опитування, порядок обходу, ліміт паралельних запитів, пауза при обмеженні частоти, інкрементальний збір за датою та ідентифікатором.
- Політики доступу до даних: де допустимий автоматичний збір, як зберігається й ротується авторизація, що робимо на запит правовласника.
- Схеми обходу обмежень: резервні маршрути через дзеркала й офіційні інтерфейси, пули проксі, повтори зі зростанням паузи.
- Журнали збору: по кожному джерелу — скільки записів надійшло, скільки відсіялося на валідації, затримка щодо публікації, частка помилок.
- Модель даних: ключі дедуплікації, правила нормалізації тексту й дат, терміни зберігання та архівації.
- Регламент супроводу: пороги оповіщень, терміни реакції на джерело, що впало, чек-ліст при зміні розмітки на боці майданчика.
- Інструкція з розширення: як додати джерело конфігурацією й прогнати його на тестовій вибірці.
Артефакти лежать поряд із кодом і покриті перевірками: зміна розмітки ловиться тестом, а не зверненням до нас. Додавання нового джерела зводиться до правки конфігурації.
Кейс: як збір стрічки перестав падати на пікових навантаженнях
Історія про редакцію галузевих новин: стрічка збиралася вручну, обхід джерел — раз на добу, тому анонси й релізи виходили у вікно із затримкою, а частину матеріалів довантажували вночі в аварійному режимі.
На піках публікацій — велика подія, конференція, сезон звітності — черга джерел не розбиралася, і випуск зсувався на години.
Що було до
Збір тримався на ручних операціях: редактор обходив джерела, копіював матеріали й звіряв їх з уже опублікованими очима.
Вимірювання за місяць: до третини записів — повтори одного й того самого релізу, 5-7 аварійних довантажень на тиждень, на піковій хвилі губилося до 15% публікацій. Стрічки опитувалися цілком, без урахування змін, тому навантаження на джерела зростало разом з обсягом архіву.
Що змінили і що вийшло
Збір рознесли на два контури: стрічки партнерів за RSS і канали в Telegram, у кожного — свій інтервал опитування та свої правила розбору.
Ключем запису став хеш вмісту, тому повторний матеріал не створює нову картку, а оновлює наявну; недоступне джерело йде в чергу повторів із наростаючою паузою, а не валить випуск.
Окремо винесли спостережуваність: затримка по кожному джерелу, кількість нових записів, частка відхилених — усе видно в панелі, і збій джерела перестав бути сюрпризом для редакції.
Після переходу пропуски на піках — нульові, частка дублів — нижче половини відсотка, пікова хвиля розбирається за хвилини, аварійні довантаження зникли як клас робіт.
Чим відрізняється збір за RSS від розбору сторінок джерела
Збір за RSS — це робота з контрактом: джерело саме віддає структурований документ, де для кожної публікації вже розмічено заголовок, посилання, дату й текст або анонс. Парсер читає такий потік цілком, не залежить від верстки й дедуплікує записи за ідентифікатором і адресою.
Звідси головна властивість: канал швидкий, стабільний і майже не потребує супроводу — ламається він у рази рідше, ніж розбір розмітки.
Повнота відкритої стрічки — не гарантія, а питання політики редакції. Частина рубрик у потік не віддається, замість повного тексту надходить анонс, мітки, автори й розділи губляться, а історія урізана до останніх записів: під час першого запуску архів зібрати нізвідки. Саме тут закінчується зона RSS і починається розбір сторінок джерела.
Розбір сторінок іде за обходом: розділи, пагінація, стрічка архіву за датами, карта сайту. Селектори прив’язуються до блоків публікації, дата витягується з розмітки або адреси й нормалізується, тексти чистяться від навігації.
Повнота вища — видно все опубліковане, включно з матеріалами поза стрічкою, — але з’являється крихкість: зміна шаблону або перехід на підвантаження вмісту скриптами ламає вибірку, тому потрібні рендеринг, контроль збоїв і звірка з еталоном.
На практиці порівняння способів збору закінчується гібридом.
Стрічка працює основним каналом із малим інтервалом опитування, розбір дозабирає архів і закриті для стрічки рубрики, а перетин двох множин показує, скільки унікальних матеріалів дає кожен шлях і що саме губиться без обходу.
Вибір режиму збору визначається наявністю та повнотою стрічки, потрібною глибиною архіву, частотою публікацій і допустимою затримкою появи матеріалу в системі. Далі розбираємо, як із цього виростає розклад опитування й правила дедуплікації.
Технічні сумніви, які варто зняти до старту
Сумніви, які варто зняти до старту, стосуються не «чи прочитає парсер стрічку», а меж самих джерел.
RSS і Atom віддають урізане вікно — лише останні записи, закриті джерела потребують авторизації та лімітів на звернення, а одна новина надходить із кількох стрічок із різними заголовками й посиланнями.
Нижче — питання, які найчастіше ставлять інженери замовника перед стартом.
Джерело віддає лише останні записи — старі новини загубляться?
Так, якщо перший запуск іде за урізаною стрічкою. Тому на старті робимо первинний обхід архіву: пагінація за розділами, індексні сторінки, карта сайту.
Далі зберігаємо ідентифікатор останнього обробленого запису й на кожному циклі читаємо лише нове — пропуск можливий лише при збої, який ширший за вікно стрічки, тому обхід ставимо частіше, ніж стрічка встигає переповнитися.
Як підключаються закриті джерела?
Через штатний доступ за підпискою: облікові дані зберігаємо в захищеному сховищі, дотримуємося ліміту звернень на джерело, при відмові авторизації зупиняємо обхід цього джерела й подаємо сигнал — замість повторів, які можуть призвести до блокування.
Як контролюються дублікати?
Новина порівнюється за канонічним посиланням, нормалізованим заголовком і відбитком тексту в ковзному вікні часу. Збіги зводяться в один запис зі списком джерел — у базі немає «трьох однакових новин», а видно, хто опублікував першим.
З якою частотою оновлюються дані?
Інтервал налаштовується для кожного джерела: від хвилин для новинних стрічок до годин для аналітичних. Запитуємо з умовою «чи змінилося з минулого разу», тому незмінені сторінки не перекачуються, а паралельні звернення обмежені на рівні домену.
Що відбувається, якщо джерело недоступне?
Повтори з наростаючою паузою, потім тимчасове відключення джерела. Відмови ізольовані: падіння одного не зупиняє решту, накопичене дочитується після відновлення, а інженер отримує повідомлення з історією помилок.
Обговоримо задачу й повернемося з планом робіт
Щоб оцінка була точною, а не «середньою по ринку», нам потрібен прикладний зріз задачі: що збираємо, звідки й з якою регулярністю. Нижче — перелік вхідних, за якими ми рахуємо обсяг робіт, схему зберігання й плануємо запуск. Чим конкретніші вихідні дані, тим менше припущень у кошторисі.
- Перелік джерел: адреси стрічок і розділів, відкриті програмні інтерфейси, звичайні сторінки, карти сайту. Позначте, де потрібна авторизація і де джерела віддають дані нестабільно.
- Очікувана частота оновлення: раз на хвилину, раз на годину або щоденно — від цього залежить режим опитування, навантаження й запас часу до появи матеріалу в системі.
- Цільові поля: заголовок, дата й час публікації, автор, повний текст або анонс, рубрика, посилання на оригінал, зображення. Укажіть, які поля обов’язкові, а які допустимо залишити порожніми.
- Правила обробки: чи потрібні переклад, переказ, приведення дат до єдиного часового поясу, розмітка тем і видалення повторів одного матеріалу з різних джерел.
- Вимоги до зберігання: строк життя записів, глибина архіву, чи потрібна історія змін матеріалу при правці на боці джерела.
- Правила доступу: хто і як читає дані — внутрішня система, вивантаження у файл, окремий інтерфейс; які потрібні ролі та обмеження.
- Критерії приймання: які джерела й поля вважаємо закритими, як перевіряємо пропуски і як швидко джерело має відновлюватися після збою на його боці.
Надішліть ці вхідні в будь-якому вигляді — списком, таблицею або посиланнями на наявні вивантаження. Ми розберемо їх, уточнимо спірні місця й повернемося з оцінкою, планом робіт і порядком запуску.
