Чому парсинг крипто-новин ламається на десятках джерел
Одиночний скрипт, який раз на хвилину забирає заголовки з одного джерела, працює роками. На тридцяти джерелах збір даних із джерел розсипається: частина стрічок віддає RSS і Atom, частина — лише JSON через закритий інтерфейс, частина — готову розмітку без явних дат.
Джерело змінює структуру відповіді — парсер мовчки віддає порожню видачу, і це помічають не через помилку в журналі, а через актив, що зник зі стрічки.
Далі розходяться час та ідентифікатори. Позначки надходять у різних часових поясах і форматах, ідентифікатори унікальні лише всередині джерела, а перепублікація надходить з іншою адресою та трохи зміненим заголовком.
Без нормалізації часу й зіставлення за нечітким збігом тексту агрегатор крипто-новин показує один матеріал тричі й водночас втрачає першоджерело.
Основна ціна помилки — пропуски публікацій.
У моменти високої волатильності частота публікацій зростає в рази, а обмеження на частоту запитів залишаються незмінними: джерело відповідає відмовою, черга опитування зростає, і вікно між публікацією та потраплянням у стрічку крипто-новин розтягується із секунд до хвилин. Саме в ці хвилини новина й має вагу.
Є й тихий збій: джерело віддає лише останні записи, і при сплеску понад сотню публікацій старі витісняються раніше, ніж їх устигли забрати. Нижче розбираємо, як будується парсинг крипто-новин, щоб стрічка не рвалася на піках.
Що дає єдиний потік даних: швидкість, повнота, відмовостійкість
Єдиний потік даних — це не один парсер, а шар приймання, куди незалежно сходяться RSS-стрічки, публічні API бірж і медіа на кшталт CoinDesk.
Кожна публікація отримує нормалізоване подання: джерело, мітка часу, посилання й відбиток вмісту, за яким знімаються дублі — та сама новина, що надійшла з трьох місць, потрапляє у стрічку один раз.
Затримка появи новини складається з частоти опитування та часу обробки.
Джерела з щільним потоком публікацій опитуються з пріоритетом, рідкісні — рідше, щоб не витрачати квоти API; у результаті новина опиняється у стрічці через десятки секунд після виходу, а не через години очікування ручного вичитування.
Повнота охоплення джерел тримається не на кількості підключених стрічок, а на контролі пропусків.
Частка пропущених публікацій вимірюється звіркою архіву джерела з тим, що дійшло до стрічки: розбіжності йдуть у дозбір, а типові причини — зміна схеми відповіді, редирект, нестандартний формат дати — закриваються окремими правилами розбору й оповіщенням при падінні частки успішних розборів.
Відмовостійкість стрічки будується на ізоляції: кожне джерело — окремий обробник зі своїм станом, повторами та зростаючою паузою між спробами.
При відмові одного джерела інші продовжують наповнювати потік, а після відновлення сервіс дозбирає пропущене вікно за міткою часу — видимого простою стрічки не виникає, втрата обмежується одним інтервалом опитування.
Порівняння способів збору: прямі підключення, готові стрічки, розбір сторінок
Способи збору даних різняться не якістю, а тим, які обмеження джерела ви готові прийняти. Пряме підключення до джерела віддає повний потік з мінімальною затримкою, але потребує ключів, квот і власної обробки лімітів по кожному вузлу.
Готові стрічки новин дають нормалізований потік одразу — ціною чужої частоти опитування та складу полів.
Розбір сторінок видань закриває джерела без програмного доступу, але він найкрихкіший: зміна верстки ламає вибірку, а захист від автоматичних запитів обмежує частоту звернень.
На практиці агрегатор поєднує режими: стрічками закривають широке коло видань, прямими підключеннями — ключові, розбором — решту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до джерела | Потрібен повний потік, власні фільтри та низька затримка | Ключі доступу, квоти, ліміти запитів, свій формат відповіді в кожного джерела |
| Готові стрічки новин | Потрібне швидке охоплення широкого кола видань | Залежність від чужої нормалізації, затримка у видачі, обрізані поля, зміна умов постачальником |
| Розбір сторінок видань | Матеріал є на сайті, але без програмного доступу | Крихкість до зміни верстки, захист від автоматичних запитів, нижча швидкість оновлення |
Вибір режиму фіксується за кожним джерелом окремо й переглядається, коли постачальник змінює умови або верстку.
Етапи впровадження парсингу: від аудиту джерел до передачі
Порядок робіт вибудувано так, щоб кожен наступний крок спирався на перевірений попередній: спочатку фіксуємо, які джерела взагалі дають придатні дані, і лише потім будуємо навколо них потік.
На виході виходить не набір разових скриптів, а підтримуваний сервіс із передбачуваними точками відмови та зрозумілою вартістю доопрацювань.
- Аудит джерел. Інвентаризуємо стрічки та точки доступу: повнота видачі, частота публікацій, обмеження на кількість звернень, правила використання. Окремо позначаємо джерела-дублікати й ті, що віддають лише заголовки.
- Схема потоків даних. Узгоджуємо маршрут запису: забір, нормалізація, дедуплікація, збагачення, зберігання, видача споживачам. Фіксуємо набір полів, правила зіставлення монет і поведінку системи при відмові будь-якого вузла.
- Налаштування збору. Розклад обходу з урахуванням часових поясів і піків публікацій, повторні спроби з наростаючою затримкою, збереження позиції читання — перезапуск не втрачає й не дублює записи.
- Очищення та збагачення. Приводимо тексти до єдиного вигляду, вирізаємо розмітку й рекламні вставки, зіставляємо проєкти за довідником синонімів, проставляємо тему й тональність.
- Перевірка на живому потоці. Кілька діб на реальних джерелах: рахуємо частку дублів, затримку появи новини, пропуски, поведінку при недоступності стрічки. Вибірку звіряємо з ручним переглядом.
- Моніторинг. Оповіщення про падіння частки успішних заборів і зростання дублів; при відмові одного джерела потік продовжує працювати на інших.
- Передача проєкту. Віддаємо схему потоків, конфігурацію джерел, інструкцію з підключення нової стрічки, дашборди й розбір типових збоїв — плюс навчання команди, яка далі веде сервіс самостійно.
Артефакти проєкту: схеми потоків, правила нормалізації, регламенти
Після здачі в команди замовника залишається комплект, за яким систему можна розвивати без нас: він відповідає на три питання — звідки надходять дані, як приводяться до єдиного вигляду і що робити, коли джерело перестало віддавати стрічку. Нижче — базовий набір, який ми передаємо в кожному проєкті.
- Схема потоків даних — джерела RSS і API, черга, шари нормалізації та зберігання, точки видачі; з позначками, де стоять запобіжники при недоступності фіду.
- Конфігурації джерел — списки стрічок і ендпоінтів, частота опитування, ліміти запитів, таймаути, повторні спроби з наростаючою паузою.
- Правила нормалізації — мапінг полів різних стрічок у єдину модель, приведення часу до UTC, канонізація тикерів і категорій, поведінка при частково заповнених записах.
- Правила дедуплікації новин — порівняння за канонізованою адресою та відбитком заголовка, вікно звірки, поріг схожості тексту, порядок розв'язання конфліктів між джерелами.
- Регламент експлуатації — як вимкнути шумний фід, підключити новий, переграти пачку записів після збою, кого оповіщати при відставанні потоку.
- Спостережуваність — дашборд за свіжістю даних, часткою відкинутих дублів і помилками розбору, алерти на мовчання джерела довше заданого інтервалу.
- Інструкції та тести — порядок локального запуску, збережені відповіді стрічок, перевірки на биту розмітку та зміну формату, щоб правка одного парсера не ламала сусідні.
Кейс: як стрічка агрегатора перестала втрачати публікації
Замовник — редакція галузевого медіа КриптоВестник: стрічка збиралася з кількох десятків джерел, частина віддавала дані потоком, частина — через публічні інтерфейси бірж і аналітичних сервісів.
Опитування за розкладом не було: джерела підключалися хаотично, а стрічка жила завдяки ручному доопрацюванню редактора.
Що було до
На замірі потоку за два тижні до стрічки не доїжджало 8–14% публікацій: дублі витісняли свіжі записи, а збій одного джерела тихо залишав затор у спільній черзі.
Затримка від публікації до появи у стрічці трималася в межах 20–40 хвилин, у дні різких рухів ринку розтягувалася до години. Збирач падав 3–4 рази на тиждень — розрив з'єднання він не переживав і продовжував віддавати порожні відповіді, поки оператор не помічав зникнення.
Що стало після
Переписали збір: єдина черга з підтвердженням обробки, ключ унікальності за заголовком і часом публікації, окремий буфер для повторного розбору збійних відповідей і контроль відставання за кожним джерелом. Втрати впали нижче 0,5% — це шум від видалених на боці джерела матеріалів.
Медіанна затримка стрічки — 40–90 секунд, включно з розбором і перевіркою на дублі. За квартал спостереження простоїв немає: розрив зв'язку призводить до повторної постановки завдань, а не до зупинки стрічки, відновлення займає хвилини.
Редакція перестала дописувати стрічку вручну й повернулася до роботи з текстами: пропуски видно в моніторингу за кожним джерелом, а не за скаргою читача.
Чим відрізняється збір за RSS від роботи з біржовим API?
Це різні класи джерел, і плутати їх — типова помилка при проєктуванні агрегатора. Стрічка віддає вже написані матеріали, біржовий інтерфейс — первинні ринкові дані: угоди, котирування, обсяги за інтервал. Вибір між ними визначає затримку даних і те, що взагалі потрапить у сховище.
Збір за RSS закриває текстовий потік одним модулем: формат Atom та його попередник читаються однаково, сотні видань підключаються правкою списку адрес, без ключів і угод.
Обмеження — вікно видачі: стрічка віддає 10-50 останніх матеріалів і не зберігає архів, тому глибина історії публікацій починається з моменту запуску збору.
Затримка даних — від кількох хвилин до пів години, у частини видань більше, а розмітку кожного джерела доводиться розбирати окремо.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Збір за RSS | Новинний потік, огляди й аналітика від десятків видань | Вікно 10-50 матеріалів, затримка до пів години, своя розмітка в кожного джерела |
| Робота з біржовим API | Котирування, угоди, обсяги, події лістингу та делістингу | Публікацій немає взагалі, ліміти запитів, потрібен ключ і посторінкова видача |
Біржовий інтерфейс дає те, чого немає у стрічках: точний час події та цифри, за якими будуються метрики й сигнали. Натомість — квоти на запити, обмежена глибина за історичними свічками та залежність від доступності конкретного майданчика.
Порівняння джерел даних майже завжди закінчується гібридною схемою: ринкові показники йдуть напряму, тексти — через стрічки, а повний текст документа додається зі сторінки видавця.
Технічні питання: ліміти, дублікати, затримки, відмови джерел
Агрегатор ламається не на розборі однієї стрічки, а на крайових ситуаціях: джерело закриває доступ при частих запитах, та сама новина надходить кількома каналами, публікація з'являється пізніше за першоджерело. Нижче — як влаштована поведінка системи в цих сценаріях.
Джерело обмежує частоту запитів — що тоді?
Опитуємо не за жорстким розкладом, а через накопичувальну чергу з пріоритетом: частота оновлення джерела визначає черговість, а ознака «повтори пізніше» з відповіді зсуває наступний запит. При стійкій відмові канал переводиться на резервний шлях отримання — розсилку або дзеркало стрічки.
Як відрізнити дублікат від повторної публікації?
Порівнюємо за трьома ознаками: канонічне посилання, нормалізований заголовок і відбиток тіла тексту. Збіг за посиланням і відбитком — дублікат: склеюємо в одну картку й зберігаємо перелік джерел.
Збіг лише за заголовком при правках у тілі — розвиток новини, оновлюємо запис, а не створюємо другий.
Новина надійшла із затримкою — як не видати застаріле?
Зберігаємо два часи: момент виходу в джерела й момент виявлення в нас. Стрічка сортується за першим, а розбіжність показує, наскільки канал запізнюється — той, що систематично відстає, знижується в черговості опитування. Матеріали, старші за задане вікно, йдуть в архів і не потрапляють у видачу.
Джерело змінило формат стрічки або недоступне?
Кожна відповідь проходить перевірку за очікуваною схемою: якщо поля зникли або перейменовані, канал іде в карантин і не пише сміття в базу, інженер отримує оповіщення й править схему розбору. На час правки агрегатор працює на інших каналах — потік деградує, але не зупиняється.
Обговоримо задачу: що потрібно для оцінки вашого агрегатора
Оцінка проєкту агрегатора спирається на ввідні, а не на здогадки. Чим точніше описано потік матеріалів і вимоги до результату, тим менше припущень потрапить у план робіт зі збору даних — і тим швидше ми повернемося з розрахунком.
- Перелік джерел: відкриті стрічки, програмні інтерфейси бірж і медіа, сторінки без офіційного доступу. За кожним важливо розуміти, чи віддає джерело дані штатно чи потрібен розбір розмітки.
- Обсяг і частота: скільки матеріалів надходить за добу і як швидко вони мають з'являтися в базі. Від цього залежить розклад опитування та запас за навантаженням.
- Схема нормалізації: які поля потрібні на виході — заголовок, джерело, час публікації, тикери, тональність — і в якому вигляді агрегатор віддає їх споживачу.
- Правила дедуплікації: як зводити один і той самий сюжет з десятка джерел і яке з них вважати першоджерелом.
- Зберігання та історія: глибина архіву, чи потрібні знімки минулих версій тексту, вимоги до пошуку за накопиченими даними.
- Доступи й обмеження: ключі, ліміти запитів, умови використання джерел, обов'язкове маркування даних.
- Підтримка після запуску: хто стежить за обривом стрічок, як швидко потрібна реакція і що вважаємо деградацією.
Опишіть задачу — повернемося з оцінкою та планом, де окремо проговоримо етапи, ризики й супровід після запуску.
