Розробка системи парсинга веб-сайтів
Парсинг—це не просто «скачати HTML та витягти теги». Промислова система збору даних включає управління чергами запитів, ротацію прокси, обхід антибот-захисту, нормалізацію даних та надійне зберігання. Один раз написаний скрипт на Beautiful Soup—це не система, це скрипт. Різниця стає очевидною через тиждень роботи.
З чого складається повноцінна система
Планувальник та черга завдань. Celery з Redis або RabbitMQ у якості брокера. Кожен URL—окремне завдання з пріоритетом, retry-політикою та TTL. Scrapy-cluster або власний оркестратор координує кілька воркерів.
Загрузчик сторінок. Два режими:
- Статичні сторінки—httpx з async, connection pooling, keep-alive
- JavaScript-рендеринг—Playwright (бажано) або Puppeteer, headless Chromium з управлінням профілями браузера
Ротація ідентифікаторів. Пул прокси (резидентні або датацентр залежно від мети), зміна User-Agent з реальних fingerprint-датасетів, випадкові затримки з нормальним розподілом, управління куки-сесіями.
Витяг даних. CSS-селектори або XPath—для стабільних структур. Для складної логіки—parsel (обгортка над lxml). Якщо структура нестабільна—LLM-екстракція через OpenAI або локальну Ollama з few-shot промптами.
Зберігання та нормалізація. Raw HTML в S3/MinIO для повторної обробки. Витягнуті дані—PostgreSQL або ClickHouse (якщо потрібна аналітика по мільйардам записів). Дедупликація по URL-хешу + content-hash.
Антибот-захисти та як з ними працювати
| Захист | Метод обходу |
|---|---|
| Rate limiting | Адаптивні затримки, розподіл по IP |
| CAPTCHA (reCAPTCHA v2/v3) | 2captcha/Anti-Captcha API або навчання власної моделі |
| Cloudflare Bot Management | Playwright з реальним fingerprint, TLS fingerprint (циклічна ротація) |
| JavaScript challenges | Headless browser з повним виконанням JS |
| Honeypot-ссилки | Фільтрація невидимих елементів перед обходом |
| IP reputation blocks | Резидентні proxy (BrightData, Oxylabs, Smartproxy) |
Cloudflare з налаштуванням «Bot Fight Mode»—найскладніший кейс. Рішення: Playwright з настоящим Chromium, обхід через puppeteer-extra-plugin-stealth або playwright-stealth, імітація мишиних рухів через CDP.
Архітектура для високонаванного парсинга
[Scheduler] -> [Redis Queue] -> [Fetcher Workers x N]
|
[Parser Workers x M]
|
[Raw Store S3] + [DB Writer]
|
[Monitor / Dashboard]
Fetcher та Parser—різні воркери з різними вимогами до ресурсів. Fetcher—I/O bound, можна 100+ async завдань на одному процесі. Parser—CPU bound, один процес на ядро.
Мониторинг якості даних. Great Expectations або самописні перевірки: відсоток непустих полів, діапазони числових значень, унікальність ідентифікаторів. При деградації якості—алерт у Slack/Telegram та пауза воркерів.
Правові та етичні аспекти
Перед запуском системи: перевірка robots.txt, аналіз ToS сайту, оцінка навантаження на цільовий сервер. Для публічних даних це зазвичай прийнятно. Для закритих розділів—потрібне явне дозвіл.
Стек та терміни реалізації
Python-стек: Scrapy / httpx + parsel, Playwright, Celery, PostgreSQL/ClickHouse, MinIO.
Терміни по етапах:
- Базовий парсер одного сайту—3-5 днів
- Черга + ротація прокси + retry—5-7 днів
- JS-рендеринг + антибот-обхід—7-14 днів
- Мониторинг, нормалізація, зберігання—5-10 днів
- Повна система під 10+ джерел—4-8 тижнів
Сценарії використання
Мониторинг конкурентів. Ціни, асортимент, наявність товарів—збір раз на годину з історією змін.
Агреґація оголошень. OLX, Avito-подібні площадки: десятки тисяч записів на добу, дедупликація, геокодування адрес.
Дослідницькі задачі. Збір датасетів для ML, мониторинг тональності згадувань бренду, аналіз SEO-позицій конкурентів.
Контентні проекти. Синдикація новин, агреґація вакансій, збірка каталогів з відкритих джерел.
Обслуговування системи
Веб-сайти змінюються—парсер ломається. Потрібна стратегія виявлення поломок: порівняння схеми сторінки з еталоном, мониторинг відсотка успішних витягань, автоматичні тести на фіксturах. Типовий показник: 95%+ успішних витягань при стабільній роботі системи.
Добре спроектована система парсинга—це не одноразова розробка, а інфраструктура з життєвим циклом. Закладайте час на підтримку: приблизно 20% від часу першочергової розробки на рік.