Замовник звернувся із задачею: щодня збирати ціни та залишки з 20 сайтів конкурентів. Через тиждень після запуску першого скрипта на requests всі IP заблокувала захист Cloudflare, а ще через місяць змінилася верстка — дані перестали збиратися взагалі. Так виглядає типовий провал без промислового підходу. Ми розробляємо системи, які не ламаються: планувальник з пріоритетами, ротація резидентних проксі, обхід антибот-захистів, нормалізація та моніторинг. Наш досвід — 15+ проектів для e-commerce, агрегаторів та дослідницьких задач. Економія бюджету на зборі даних досягає 60%, окупність системи — 2-3 місяці. Якщо вам потрібна надійна система збору даних, зв'яжіться з нами для консультації.
Як обійти Cloudflare Bot Management?
Найскладніший кейс — Cloudflare з Bot Fight Mode. Рішення: Playwright з реальним fingerprint браузера, обхід через puppeteer-extra-plugin-stealth, імітація мишачих рухів через CDP. Для особливо стійких — ротація IP через резидентні проксі від BrightData або Oxylabs.
| Захист | Метод обходу |
|---|---|
| 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 | Residential proxy (BrightData, Oxylabs, Smartproxy) |
Чому парсер ламається через місяць?
Веб-сайти змінюють структуру кожні 3-4 тижні. Без системи моніторингу ви дізнаєтеся про поломку тільки коли дані перестануть оновлюватися. Ми вбудовуємо автоматичні перевірки: порівняння DOM-схеми з еталоном, відсоток успішних вилучень, тести на фікстурах. Типовий показник стабільної роботи — 95%+ успішних парсингів.
Архітектура масштабованої системи парсингу
Планувальник і черга завдань
Celery з Redis або RabbitMQ — перевірений вибір. Кожен URL — завдання з пріоритетом, retry-політикою та TTL. Scrapy-cluster або власний оркестратор координує воркери. Використовуємо Python 3.12, Celery 5.3, Redis 7.
Завантажувач сторінок
Два режими:
- Статичні —
httpxз async, connection pooling, keep-alive - JavaScript-рендеринг — Playwright 1.40 (переважно) або Puppeteer, headless Chromium з управлінням профілями
Ротація ідентифікаторів
Пул проксі (residential або datacenter), зміна User-Agent з реальних fingerprint-датасетів, випадкові затримки з нормальним розподілом, управління кукі-сесіями.
Вилучення даних
CSS-селектори або XPath для стабільних структур. Для складної логіки — parsel (обгортка над lxml). Якщо структура нестабільна — LLM-екстракція через OpenAI або локальну Ollama з few-shot промптами.
Зберігання та нормалізація
Raw HTML в S3/MinIO для повторної обробки. Вилучені дані — PostgreSQL 16 або ClickHouse (для аналітики по мільярдах записів). Дедуплікація за URL-хешем + content-hash.
Порівняння підходів: Celery vs Argo Workflows
| Критерій | Celery | Argo Workflows |
|---|---|---|
| Простота налаштування | Низька (Python-стек) | Середня (Kubernetes) |
| Масштабування | 100+ воркерів | 1000+ воркерів |
| Час відгуку на збій | Хвилини | Секунди |
| Спільнота | Велика | Зростаюча |
Для більшості проектів Celery — оптимальний вибір: швидше впроваджується, легше підтримувати. Argo — для Kubernetes-інфраструктур з жорсткими SLA.
Архітектура для високонавантаженого парсингу
[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 (1 процес на ядро).
Як налаштувати парсер за 5 кроків
- Аналіз джерел: вивчіть структуру цільових сайтів, визначте обсяг даних та частоту оновлення.
- Вибір стеку: визначте, чи потрібен JS-рендеринг, який тип проксі, яку СУБД.
- Реалізація вилучення: напишіть селектори або XPath для кожного поля, протестуйте на фікстурах.
- Налаштування моніторингу: додайте алерти на падіння відсотка успішних парсингів та зміну DOM.
- Деплой та обкатка: розгорніть систему на сервері, проганяйте тестовий період 2-3 дні.
Правові та етичні аспекти
Перед запуском: перевірка robots.txt, аналіз ToS сайту, оцінка навантаження. Для публічних даних це зазвичай прийнятно. Для закритих розділів — потрібен дозвіл. Ми завжди консультуємо з legal-ризиків.
Процес роботи та терміни
Що входить в роботу
- Архітектура системи під ваші джерела
- Реалізація коду з документацією
- Налаштування моніторингу та алертів
- Навчання вашої команди
- Підтримка 1 місяць після запуску
- Гарантія стабільної роботи (згідно з SLA)
Терміни реалізації
| Етап | Термін |
|---|---|
| Базовий парсер одного сайту | 3-5 днів |
| Черга + ротація проксі + retry | 5-7 днів |
| JS-рендеринг + антибот-обхід | 7-14 днів |
| Моніторинг, нормалізація, зберігання | 5-10 днів |
| Повна система під 10+ джерел | 4-8 тижнів |
Сценарії використання та обслуговування
Моніторинг конкурентів. Ціни, асортимент, наявність — збір раз на годину з історією. Економія до 60% часу ваших аналітиків.
Агрегація оголошень. OLX, Avito-подібні майданчики: десятки тисяч записів на добу, дедуплікація, геокодування.
Дослідницькі задачі. Збір датасетів для ML, моніторинг тональності, аналіз SEO-позицій. Контентні проекти. Синдикація новин, агрегація вакансій, каталоги з відкритих джерел.
Обслуговування системи
Добре спроектована система — не разова розробка, а інфраструктура з життєвим циклом. Закладайте 20% часу від розробки на рік на підтримку. Ми гарантуємо швидку реакцію на поломки.
Оцінимо ваш проект за 1 день — напишіть нам. Замовте розробку системи парсингу під ключ та отримайте консультацію з архітектури.