Парсинг новинних стрічок для автонаповнення 1С-Бітрікс

Парсинг новин Битрикс: де ламається автонаповнення

Автонаповнення інфоблоку ламається не на етапі «взяли стрічку та розпарсили», а на експлуатації: джерело змінює формат, агенти Битрикс накопичують завислі процеси, база зростає від дублів.

Через місяць-два такий конвеєр починає вимагати ручного втручання частіше, ніж економить час редакції.

Найчастіша причина — дублі матеріалів. Стрічка віддає той самий текст з різними адресами, при повторному імпорті створюється новий запис, а не оновлюється наявний.

Без звірки за стійкою ознакою — хешу тексту, зовнішньому ідентифікатору джерела — інфоблок заростає копіями, і пошук по сайту починає видавати три однакові новини.

Друга точка відмови — кодування джерела. Частина стрічок надходить в однобайтовому кодуванні, частина в UTF-8; при змішуванні виходять «крякозябри» в заголовках і биті символи в анонсах.

Проблема не в самому парсері, а в тому, що нормалізація кодування не винесена в окремий крок до запису в інфоблок.

Обриви стрічок і завислі агенти б'ють по стабільності. Якщо джерело віддає відповідь повільніше за таймаут або рве з'єднання на середині, агент Битрикс залишається в робочому стані і наступний запуск нашаровується на попередній.

Навантаження на базу зростає, імпорт «залипає», а в логах — серія однакових помилок без зрозумілої причини.

Окремо варто відзначити зростання навантаження: кожен прогін без обмежень тягне повну стрічку і пише все підряд. При накопиченні десятків тисяч записів вибірка за датою та розділами починає гальмувати, а індекси не покривають реальні запити виведення новин.

Розбираємо, як це закривається: де ставити нормалізацію, як будувати перевірку дублів і що робити з завислими агентами, щоб автонаповнення працювало без щоденного нагляду.

Що змінюється після налаштування автонаповнення

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

Швидкість публікації та свіжість

Потік із джерел обробляється за розкладом: стрічка опитується, нові матеріали потрапляють у чергу, нормалізуються і йдуть у публікацію. Затримка між появою новини в джерела та її виходом на сайті скорочується з годин до хвилин — розділ перестає відставати від порядку денного.

Частка ручної роботи

Ручна модерація зберігається там, де вона створює цінність: редактор перевіряє заголовок, теги, прив'язку до рубрик і вирішує, публікувати чи відхилити.

Чорновий перенос, чищення розмітки, дедуплікація та розкладка за розділами автоматизовані — на них іде не час редакції, а робота конвеєра.

Стійкість до збоїв джерел

Джерело може віддати порожню стрічку, змінити верстку або піти в недоступність — конвеєр не публікує сміття і не падає. Матеріал із неповними полями йде в карантин, повтори відсікаються за відбитком, а при недоступності джерела черга чекає відновлення і наздоганяє пропущене.

Що видно в цифрах

Частка матеріалів, що йдуть у публікацію без правок редактора, зростає; час від появи новини до картки на сайті падає; кількість порожніх і дублюючих записів у розділі — до нуля. Свіжість контенту перестає залежати від завантаження редакції.

Схему розбору стрічок і правила публікації збираємо під ваш розділ — на 1С-Бітрікс це робиться штатними засобами без зовнішніх надбудов.

Способи збору стрічок: порівняння підходів

Джерело даних визначає не лише формат, а й режим оновлення: від нього залежить частота опитування, навантаження на сайт і стійкість до збоїв. Нижче — робочі варіанти, між якими реально обирають під час автонаповнення.

Порівняння підходів

Режим оновлення та частота опитування

Частота опитування підбирається під темп публікацій джерела, а не «що частіше, то краще». Для новинної стрічки розумний інтервал — від 15 хвилин до години: він ловить свіжий матеріал, але не створює зайвих запитів.

Якщо джерело віддає дату публікації, повторну вставку відсікає перевірка за унікальним ідентифікатором або посиланням — дублі не потрапляють до бази.

Для джерел із жорсткими лімітами запитів ставимо чергу й обробляємо стрічки послідовно, з паузою між зверненнями. У разі недоступності джерела завдання не падає, а переноситься на наступний цикл — сайт продовжує працювати на раніше зібраних даних.

Розбір HTML-сторінок потребує окремого контролю: селектори вибірки зберігаємо в конфігурації, щоб правка верстки виправлялася в одному місці, а не в коді завдання.

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

Як ми впроваджуємо парсинг: етапи робіт

Процес будуємо так, щоб на виході залишився робочий контур автонаповнення, а не разовий скрипт: спочатку розбираємося з джерелами, потім проєктуємо обмін, далі налаштовуємо регулярний запуск і захист від дублів.

1. Аудит джерел. Збираємо перелік стрічок і розділів, які реально потрібні редакції, перевіряємо доступність, стабільність віддачі та структуру матеріалів. Фіксуємо, які поля переносимо — заголовок, анонс, дату, автора, зображення — і які рубрики їм відповідають.
2. Схема обміну. Проєктуємо, як дані потрапляють в інфоблоки: зіставлення розділів, правила перетворення тексту, прив'язка зображень, поведінка за відсутності обов'язкових полів. На цьому кроці узгоджуємо, що робити з матеріалом, який не пройшов перевірку — відкидати чи складати в окремий розділ для ручного розбору.
3. Налаштування агентів. Реалізуємо регулярний обхід джерел із заданим інтервалом, обробкою помилок і повторними спробами при збоях мережі. Логуємо кожен прохід, щоб було видно, скільки матеріалів надійшло, скільки відхилено і з якої причини.
4. Перевірка на дублі. Налаштовуємо зіставлення за зовнішнім ідентифікатором і контрольними ознаками тексту, щоб повторний обхід не створював копії. Окремо перевіряємо поведінку при оновленні матеріалу в джерелі — правка має оновлювати наявний запис, а не плодити новий.
5. Тестовий прогін. Запускаємо контур на обмеженому наборі джерел, звіряємо результат із ручною вибіркою, дивимося навантаження на сайт у момент обходу. Правки вносимо до виведення на всі стрічки.
6. Передача регламентів. Віддаємо опис джерел, правила зіставлення рубрик, порядок додавання нової стрічки та інструкцію з розбору відхилених матеріалів. Редакція отримує зрозумілий набір дій без звернення до розробника щодо кожної правки.

Такий порядок дає передбачуваний результат: контур наповнення працює за розкладом, дублі не накопичуються, а супровід не потребує постійної участі інженера.

Що замовник отримує на руки

Передаємо не «скрипт, який десь крутиться на сервері», а комплект, за яким обмін можна експлуатувати, розширювати й передавати іншому підряднику без розкопок у чужому коді.

• Конфігурація обміну — файли налаштувань джерел: список стрічок, періодичність опитування, мапінг полів джерела на властивості інфоблока, прив'язка до розділів і типів новин.
• Схема потоків даних — звідки забираємо, де нормалізуємо, в який інфоблок і з якою періодичністю потрапляє матеріал, де стоять точки ручної модерації.
• Правила обробки — дедуплікація за канонічним посиланням і заголовком, фільтри за рубриками й стоп-словами, обрізання та очищення тексту, поведінка при неповному або битому фіді.
• Регламент супроводу — що робити при зміні формату стрічки, як додати нове джерело, як відкотити помилково залитий масив, за ким залишається моніторинг черги.
• Документація — опис структури обміну, призначення кожного поля й параметра, інструкція для редактора: як виправити правило, не ламаючи сусідні.
• Доступи та ролі — які облікові записи потрібні обміну, які права в редактора, що закрито від публікації без підтвердження.
• Журнал і моніторинг — де дивитися статистику імпорту, скільки матеріалів пройшло й відсіялося, як надходить повідомлення про збій джерела.

Усе це фіксується в репозиторії разом із кодом, а не залишається в листуванні. Через місяць після запуску ви або ваш штатний розробник відкриваєте документацію й змінюєте правило самі — без звернення до нас.

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

Кейс: автонаповнення новинної стрічки без дублів

Замовник — регіональний галузевий портал на 1С-Бітрікс з редакцією з двох осіб. Новини збиралися вручну: редактор обходив десяток джерел, копіював текст, чистив розмітку та публікував.

За добу виходило 8-12 матеріалів, при цьому третина часу йшла на механічну роботу, а стрічка все одно відставала від подій на кілька годин.

Що було до

Публікації залежали від зайнятості редактора: у дні термінових завдань стрічка зупинялася. Дублі з'являлися постійно — один і той самий сюжет надходив з кількох стрічок з різними заголовками, і відстежити повтори вручну не вдавалося.

Частина матеріалів ішла в архів із битими посиланнями на зображення, бо картинки залишалися на стороні джерела.

Що змінили

Налаштували збір із узгоджених стрічок за розкладом, із приведенням заголовків і тексту до єдиного вигляду.

Ключовий елемент — дедуплікація: матеріал звіряється з уже опублікованим за канонічним посиланням і відбитком тексту, тому повторний сюжет з іншої стрічки не створює другого запису.

Зображення переносяться до медіабібліотеки порталу під час публікації, щоб стрічка не залежала від джерела.

Що стало

Щоденний обсяг зріс до 40-60 матеріалів без розширення редакції, затримка від події до публікації скоротилася до хвилин. Частка дублів упала практично до нуля, а редактор переключився на перевірку та правку замість копіювання. Стабільність публікацій перестала залежати від того, чи вільна людина в конкретну годину.

1С-Бітрікс у цій схемі залишається системою публікації та зберігання — логіка збору та перевірок живе окремо і не заважає оновленням платформи. Якщо у вас стрічка наповнюється вручну і ви впираєтесь у ту саму стелю — опишіть задачу, повернемося з оцінкою та планом.

Чим відрізняється разовий збір від постійного оновлення?

Разовий збір — це завантаження наявного масиву: ви надаєте список джерел і глибину (наприклад, матеріали за останні два роки), інженер налаштовує розбір сторінок, приводить поля до структури інфоблоків і виконує один прогін.

На виході — наповнений розділ, який далі живе сам: нові записи з'являються тільки тоді, коли хтось із редакції додасть їх вручну.

Такий режим закриває стартову задачу — сайт перестає виглядати порожнім, пошукові системи отримують готовий архів матеріалів, а редакція працює з уже зібраною базою, а не з нуля.

Постійне оновлення влаштовано інакше: той самий розбір, але запущений за розкладом опитування — раз на годину, раз на добу, залежно від того, як часто джерело публікує нове.

Ключова частина тут не сам збір, а захист від дублів і сміття: кожен запис перевіряється за канонічним посиланням і хешем тексту, повторні попадання відсікаються, оновлені матеріали перезаписуються, а не створюються заново. Без цього через місяць в інфоблоці опиниться три копії однієї новини з різними датами.

Різниця проявляється в супроводі. Разовий збір — це робота з фіксованим результатом: джерело змінило верстку, прогін зламався, але наступний запуск планується вручну, і до нього розділ просто не поповнюється.

Постійне оновлення — це сервіс із журналом прогонів, оповіщенням про збої та адаптацією розбору під зміни джерела. Архів матеріалів при цьому залишається цілим: старі записи не перезаписуються, а доповнюються новими, тому відкат до попереднього стану можливий на будь-якому етапі.

Практичний критерій вибору простий. Якщо задача — швидко підняти розділ і далі вести його силами редакції, достатньо разового збору.

Якщо потік новин має йти без ручної участі і ви готові тримати розклад опитування та моніторинг, потрібен постійний режим — він і дає безперервне наповнення без простоїв.

Часті технічні сумніви

Перед стартом замовники зазвичай перевіряють не «чи вміє парсер тягнути новини», а що буде із системою на дистанції: чи витримає база, чи не зламається верстка, що при повторному запуску і що якщо джерело впало. Нижче — відповіді на ті сумніви, які найчастіше виникають на етапі оцінки.

Чи сумісно це з поточною версткою і шаблонами сайту?

Матеріал приходить у ті самі поля і типи властивостей, що й при ручній публікації, тому шаблони виведення, ЧПУ і розділи каталогу не переписуються. Зображення підтягуються в медіабібліотеку зі збереженням пропорцій, а розмітка чиститься від чужого коду до вставки.

Якщо структура джерела змінюється, правиться лише шар розбору — публічна частина залишається недоторканою.

Що станеться при повторному запуску задачі?

Задача ідемпотентна: кожен запис позначається ідентифікатором джерела, і повторний прохід пропускає вже завантажене. Перерваний імпорт продовжується з останньої обробленої позиції, а не з початку. Це знімає ризик задвоєних публікацій і зайвих звернень до зовнішнього сайту.

Як система поводиться, коли джерело недоступне?

Збій джерела не валить обмін: спрацьовують повтори з наростаючою паузою, а після кількох невдач задача позначається і йде повідомлення відповідальному. Уже зібрані матеріали залишаються в базі, нічого не втрачається. Коли джерело повертається, імпорт наздоганяє пропущене за датами.

Обговоримо ваше завдання автонаповнення

Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібен від вас мінімум вхідних даних за п'ятьма пунктами. Нижче — що саме з'ясовуємо на старті: цього достатньо, щоб спроєктувати збір, нормалізацію та публікацію під ваш контур.

• Перелік джерел — конкретні стрічки та розділи, які наповнюють сайт: відкриті новинні потоки, галузеві майданчики, партнерські розсилки, внутрішні бази. За кожним джерелом важливо зрозуміти, чи віддає він дані машинно чи лише сторінками, чи є авторизація та ліміти на звернення.
• Вимоги до контенту — які поля обов'язкові (заголовок, дата, автор, тіло, зображення, теги), що робимо з дублями та повторами, чи потрібна переробка тексту під ваш стиль чи публікуємо як є, які теми відсікаємо.
• Схема розділів — куди розкладати матеріали: прив'язка до інфоблоків, категорій і тегів, правила вибору розділу, чи потрібна ручна модерація перед публікацією чи матеріал іде на сайт автоматично.
• Режим оновлення — як часто перевіряємо джерела, публікуємо одразу чи пачками за розкладом, що робимо при збої джерела і як відкочуємо помилково залитий запис.
• Доступи — облікові дані до джерел, права на запис в інфоблоки, тестовий контур для прогону, доступ до логів і моніторингу, щоб збої було видно до того, як вони дійшли до відвідувачів.

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