Вибирати open-source краулер простіше, якщо розділити систему на чотири ролі: загальний збір, автоматизацію браузера, планування й черги, а також парсинг і зберігання. Тут розглянуто задачі кожного шару, типові помилки інтеграції та чотири практичні критерії.
Пошук краулерів на GitHub може показати сотні або навіть тисячі репозиторіїв. Багато хто вибирає проєкт за кількістю зірок і починає з найпопулярнішого.
Популярність і відповідність вашому сценарію — різні речі. Навіть дуже відомий проєкт створюватиме зайву роботу, якщо його призначення не збігається з вашими потребами. Найпростіше почати з розподілу відповідальностей: система збору даних, яка має стабільно працювати довгий час, зазвичай складається з кількох компонентів із різними функціями. Коли зрозуміло, що робить кожен із них, порівнювати конкретні реалізації значно легше.
Загальні crawler framework: для сторінок зі стабільною структурою
Такі framework керують плануванням запитів, паралельним завантаженням і конвеєрами даних. На вхід вони отримують набір URL, а на виході дають структуровані результати. Зрілі екосистеми та middleware дозволяють додавати власну логіку й підтримувати довготривалі завдання великого масштабу.
Вони не можуть самостійно обробляти сторінки, де вміст з'являється лише після виконання JavaScript. У такому разі початкова відповідь є лише порожньою оболонкою, тому потрібен окремий рушій рендерингу. Це добре підходить для стабільних цілей, як-от сторінки списків, сторінки деталей і відкриті API.
Автоматизація браузера: для рендерингу та взаємодії
Сторінки, яким потрібен справжній рендеринг, авторизована сесія або кілька кліків до появи вмісту, слід обробляти автоматизацією браузера. Такі інструменти можуть працювати з різними рушіями, мають зрілі механізми очікування й дають змогу напряму перехоплювати запити та відповіді сторінки.
Ціна — значно більше споживання ресурсів, ніж у звичайних HTTP-запитів. Межа паралельності здебільшого залежить від локальної пам'яті та CPU. Крім того, автоматизація залишає ознаки, які можуть розпізнати сайти зі суворими перевірками.
Планування та черги: потрібні, коли завдань стає багато
За невеликої кількості цілей достатньо простої петлі. Коли завдань тисячі й потрібно контролювати частоту та повторні спроби, корисний окремий шар планування: як ставити завдання в чергу, скільки виконувати одночасно, скільки чекати перед повтором після помилки та які завдання припиняти. Якщо всю цю логіку помістити в crawler framework, код швидко стане складним для підтримки.
Типова помилка під час самостійного створення цього шару — черга лише в пам'яті процесу. Після перезапуску процесу всі завдання, що очікують, зникнуть. Щонайменше черга має бути постійною й дозволяти перевіряти стан.
Парсинг і зберігання: визначають, чи можна одразу використовувати дані
Ми отримуємо HTML, а потрібні конкретні поля. Шар парсингу має керувати правилами вилучення, перевіряти поля, усувати дублікати й записувати дані у сховище. Для сайтів, що часто змінюють структуру, варто розглянути адаптивне вилучення, яке знаходить дані за ознаками сторінки, а не за жорстко заданими селекторами, і таким чином зменшує обсяг обслуговування.
На стороні сховища важлива ідемпотентність. Повторні спроби — нормальне явище, тому записи слід дедуплікувати за унікальним ідентифікатором; інакше дублікати забруднюватимуть подальший аналіз.
Проблеми, які часто виникають після об'єднання компонентів
Окремо кожен компонент досить простий. Проблеми зазвичай з'являються на стиках.
- Шар планування повторює завдання, але шар парсингу не виконує дедуплікацію, тому виникають дубльовані рядки
- Браузерний шар не має обмеження паралельності, вичерпує локальні ресурси й спричиняє падіння всієї партії
- Правила парсингу жорстко записані в коді, тому кожна зміна сайту потребує нового випуску
- Компоненти використовують різні ідентифікатори для одного завдання, стани не узгоджуються й відновлення з точки зупинки стає неможливим
Чотири критерії оцінювання
Після визначення потрібної категорії використовуйте ці чотири критерії для відбору конкретних проєктів.
Для оцінювання активності підтримки дивіться на частоту commit і швидкість відповіді на issues за останні місяці, а не на загальну кількість зірок. Проєкт, який більше не підтримується, може одразу перестати працювати після зміни цільового сайту.
Документація та приклади визначають вартість освоєння. Якщо документація нечітка або приклади охоплюють лише найпростіші випадки, час навчання часто перевищує очікування.
Для розширюваності перевіряйте, які точки підключення передбачено: чи можна змінити proxy, підключити власний рушій рендерингу або замінити сховище. Проєкти з чіткими точками розширення дозволяють надалі адаптувати систему без змін у вихідному коді.
Ризики ліцензування та відповідності вимогам легко пропустити. Перед комерційним використанням перевірте тип ліцензії та уникайте ліцензій, несумісних із вашим застосуванням. Також оцінюйте обсяг збору, частоту запитів і умови цільового сайту; ці питання не залежать від технічної якості framework.
Шар середовища — це окремий рівень
Framework вирішує, як збирати дані, але не питання ідентичності та масштабу. Якщо завдання потребують входу в обліковий запис, регіонального розділення або паралельної роботи кількох акаунтів, запуск усього в одному браузерному середовищі створює дві проблеми: сесії впливають одна на одну через перетин cookie та локального сховища, а цільовий сайт може сприймати незалежні завдання як одну групу звернень.
Зрілий підхід — зробити браузерні середовища незалежним шаром ресурсів. Завдання отримують середовище з пулу й звільняють його після використання. У такій архітектурі PurpleMark займає саме цей шар і надає ресурси середовища, які можна створювати пакетно, прив'язувати до незалежних мережевих виходів і перевіряти за станом.
Межі відповідності вимогам
Дотримуйтеся правил robots і умов використання цільового сайту, не збирайте персональну інформацію, не обходьте технічні заходи захисту й контролюйте частоту запитів, щоб не порушувати нормальну роботу сервісу. Вибір проєкту вирішує питання ефективності; ці оцінки визначають, чи варто взагалі виконувати такий збір.
