Розробка парсера контактних даних з відкритих джерел

Розробка парсера контактних даних з відкритих джерел

Уявіть: потрібно зібрати 10 000 контактів з сайтів компаній для холодної розсилки. Вручну — це кілька тижнів виснажливого копіювання. Готові сервіси збирають лише 60% даних, решта — сміття. Ми розробляємо парсери контактних даних, які автоматично вилучають email, телефони, адреси та профілі з відкритих джерел: бізнес-каталогів, сайтів компаній і галузевих довідників. Технічна складність у тому, що структура джерел відрізняється кардинально. Дані можуть бути в нестандартному HTML, приховані за JavaScript-рендерингом або захищені від автоматичного збору. За 5+ років ми реалізували понад 30 таких проєктів, тому знаємо всі підводні камені.

Готові рішення часто не працюють. Хмарні сервіси дають поверхневий збір, а самописні скрипти ламаються при зміні верстки. Ми будуємо адаптивні парсери, стійкі до структурних змін. Комбінація селекторів та fallback-стратегій гарантує стабільність збору. На відміну від конкурентів, наш парсер обробляє 1000 сторінок за 15 хвилин, що в 10 разів швидше за ручний пошук. Це знижує витрати на збір контактів у 5–10 разів.

Як влаштований архітектурно надійний парсер контактних даних?

Типовий стек включає кілька рівнів:

• Playwright або Puppeteer — для сторінок з динамічним завантаженням контенту (SPA, lazy load)
• Cheerio (Node.js) або BeautifulSoup (Python) — для статичного HTML
• Scrapy з мідлварами — коли потрібна висока продуктивність і паралельний обхід
• Redis — черга URL для обходу, дедуплікація вже відвіданих сторінок
• PostgreSQL — зберігання результатів з повнотекстовим пошуком

Для вилучення контактів використовуємо регулярні вирази з урахуванням регіональних форматів. Російські номери у форматах +7 (XXX) XXX-XX-XX та 8-XXX-XXXXXXX. Міжнародні — за E.164. Email — стандартна RFC 5322 regex з постфільтрацією технічних адрес (noreply@, no-reply@, mailer-daemon@).

Середній час парсингу 1000 сторінок — 15 хвилин при 10 потоках. Типова помилка — використовувати лише один двигун. Для надійності ми комбінуємо Playwright для JS-сайтів і Cheerio для статики. Це знижує втрати даних на 40%.

Як ми нормалізуємо та валідуємо зібрані контакти?

Сирові дані проходять кілька етапів обробки:

1. Нормалізація телефонів через libphonenumber (Google) — приведення до єдиного формату E.164
2. Валідація email — DNS MX-запит до домену для перевірки існування поштового сервера
3. Дедуплікація — порівняння за нормалізованими значеннями, а не за вихідними рядками
4. Геокодування адрес — через Nominatim (OpenStreetMap) або Яндекс.Геокодер

Після обробки якість даних досягає 95% точності. Це підтверджено на проєктах з обсягом збору понад 10 000 контактів. Наші сертифіковані інженери налаштовують парсер під будь-які джерела.

Характеристики парсингу

Джерела даних та складність

Для кожного типу джерела розробляються окремі spider-класи або обробники з власною логікою навігації та вилучення.

Типові помилки при розробці парсерів

Ми часто зустрічаємо такі проблеми в проєктах клієнтів:

• Використання одного User-Agent призводить до блокування за IP після кількох запитів.
• Відсутність обробки капчі зупиняє збір.
• Ігнорування robots.txt веде до юридичних ризиків.
• Зберігання даних без нормалізації плодить дублі та сміття. Ми враховуємо всі ці аспекти, тому наші парсери стабільно працюють роками.

Вивантаження та формати

Результати доступні в кількох форматах:

• CSV/XLSX — для імпорту в CRM
• JSON API — для інтеграції з внутрішніми системами
• Прямий запис у PostgreSQL/MySQL з нормалізованою схемою

{
  "source": "2gis.ru",
  "company": "ТОВ Ромашка",
  "phones": ["+7(495)123-45-67"],
  "emails": ["[email protected]"],
  "address": "м. Москва, вул. Леніна, буд. 1"
}

Терміни та обсяг робіт

На парсер одного-двох джерел з нормалізацією та базовим сховищем потрібно 5–8 робочих днів. Якщо потрібна масштабована система під 10+ джерел з веб-інтерфейсом управління — від 3 тижнів. Ми оцінюємо проєкт безкоштовно і надаємо фіксований кошторис.

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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.