Чому більшість конвеєрів псуються

Саморобні скрепери забирають 90 % часу, відведеного на аналітику, і генерують неякісні дані

«Невеликий скрипт на Python» перетворюється на місяці циклічного оновлення файлів cookie, ротації проксі-серверів, виправлення селекторів, черг повторних спроб і викликів о 3-й ночі — лише тому, що у вихідному коді змінили назву класу. Команда з обробки даних витрачає весь квартал на перебудову «каркасу» замість того, щоб створювати інформаційні панелі. Ми пропонуємо чотири компоненти, які кожна команда перебудовує з нуля, — у готовому вигляді.

Якщо на вашому складі після реорганізації джерела даних nullрядків, ніж стовпців після реорганізації джерела даних — ця стаття саме для вас.

Крихкі саморобні скребки гниють за чверть

Проблема. Скрипт на Python, написаний за вихідні, перетворюється на нестабільний внутрішній механізм: тут черга, там рівень повторних спроб, відсутність можливості моніторингу, CSS-селектор, який перестає працювати щоразу, коли змінюється дизайн джерела. Команда вимушена підтримувати інфраструктуру, яку ніколи не хотіла створювати.

Як Yozh Scraper вирішує цю проблему. Готовий до використання в виробничому середовищі движок: паралельний пакетний виконавець, автоматичні повторні спроби з експоненційним відступом, структуровані коди помилок та функція самовідновлення LLM, яка відтворює пошкоджені селектори на основі актуального DOM. Один docker compose up замінює місяці написання «зв'язувального» коду.

самовідновлення LLM
Пакети + повтори
Структуровані помилки

HTML-хаос у всіх вихідних файлах

Проблема. Кожен сайт повертає свій унікальний набір вкладених елементів div, недокументованих блоків JSON та несумісних форматів дати. Вашим завантажувачам необхідний етап нормалізації перед надсиланням даних до сховища — і саме цей етап виходить з ладу першим щоразу, коли джерело оновлює дизайн.

Як Yozh Scraper вирішує цю проблему. Вбудовані пресети забезпечують однакову структуру JSON для всіх джерел — ті самі ключі, дати у форматі ISO, валюти, нормалізовані відповідно до локалі. Нестандартні джерела? POST /api/v1/presets/generate Достатньо вказати один приклад URL-адреси — LLM самостійно визначає схему та генерує селектори. Відразу інтегрується в COPY ... FROM stdin.

Однакова форма JSON
Дати в ISO
Пресети, згенеровані LLM

Боротьба з ботами забирає час на спринт

Проблема. Проксі-сервери в дата-центрах виходять з ладу вже за одну сесію, CAPTCHA-бар’єри блокують сканування посеред виконання завдання, а ідентифікація за відбитками TLS миттєво виявляє безголові браузери. В результаті інженери з обробки даних змушені займатися усуненням блокувань замість того, щоб створювати інформаційні панелі. Витрати на проксі-сервери стрімко зростають, тоді як обсяги роботи залишаються на тому ж рівні.

Як Yozh Scraper вирішує цю проблему. Вбудована інтеграція з CyberYozh App Proxy за допомогою CYBERYOZH_API_KEY — 5 типів проксі (резидентні ротаційні/стаціонарні, мобільні 4G/5G, дата-центри, провайдери) у 250 країнах. Стелс-версія Chromium із «теплим» відбитком автоматично підбирає походження проксі. Більшість запитів ніколи не стикаються з CAPTCHA.

5 типів проксі
250 кодів країн
Прогрітий відбиток

Організація індексації в режимі ad-hoc

Проблема. «Просканувати цей сайт, зібрати дані з кожної сторінки товару, відстежувати нові URL-адреси» — це одне логічне завдання, але в коді це черга, таблиця дублікатів, правила області дії, обмеження RPS, двоступеневе скасування. Якщо реалізувати це вручну, система виходить з ладу під час повторних спроб і непомітно повторно збирає дані з тієї самої URL-адреси.

Як це вирішує Yozh Scraper. Yozh Crawler обходить сайт на стороні сервера, видаляє дублікати за допомогою хеш-функцій SHA1 для кожного завдання, передає нові URL-адреси через SSE та при кожному збігу передає їх до скрепера. Двоступеневе скасування (м’яке → примусове). Потік даних передається безпосередньо в Airflow / dbt / cron — оркестрування залишається в тих інструментах, якими ви вже користуєтеся.

Стрімінг через SSE
Дедуплікація на завдання
Airflow / dbt / cron

Як це працює

Від сирої веб-сторінки до ряду на складі — у 3 кроки

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

1 Заведіть двигун

Склонуйте репозиторій і docker compose up. Скрейпер на :8000, сканер увімкнено :8001. Ніяких облікових записів SaaS, ніяких майстрів створення API-ключів — працює у вашій VPC.

# one-time setup
git clone 
  github.com/CyberYozh-data/yozh-scraper
cd yozh-scraper
docker compose up -d

2 Пакетне вилучення даних зі списку URL-адрес

Надішліть свій пакет URL-адрес через POST (до 200 за один виклик). Воркери працюють паралельно, повторні спроби та проксі обробляються на стороні сервера. Однакова структура JSON для кожного джерела.

curl 
  localhost:8000/api/v1/scrape/batch 
  -X POST 
  -d '{"urls": ["…", "…"],
       "preset": "auto",
       "concurrency": 8}'

3 Передавайте дані безпосередньо у ваше сховище

Результати виводяться у вигляді рядків у форматі JSON. Передайте їх через jq в COPY ... FROM stdin у Postgres або завантажуйте безпосередньо через клієнт Snowflake / BigQuery. Без проміжного програмного забезпечення.

# postgres example
curl :8000/api/v1/scrape/batch 
  -d @urls.json 
| jq -c '.results[]' 
| psql -c "COPY raw FROM stdin"

Приклад у дії

Що ви отримаєте натомість — одна форма, всі торгові майданчики

Виберіть пресет, щоб побачити, як виглядає відповідь. Набір полів залежить від джерела, але структура запиту залишається однаковою.

Рецепти

Як команди, що працюють з даними, це реалізують — по 10 рядків кожна

Три конкретні конвеєри від сторінки до складу, готові до вставки. Yozh займається зчитуванням даних — ваш оркестратор відповідає за графік.

1 Щоденний знімок → Postgres

Cron завантажує список URL-адрес, виконує пакетне вилучення даних і передає рядки у форматі JSON безпосередньо до проміжної таблиці. dbt отримує ці дані на наступному етапі.

# crontab: every day at 06:00
0 6 * * * /usr/local/bin/snapshot.sh

# snapshot.sh
curl -s :8000/api/v1/scrape/batch 
  -d "@urls.json" 
| jq -c '.results[]' 
| psql -c "COPY raw_scrape FROM stdin"

# dbt build runs next in Airflow DAG
dbt build --select staging.raw_scrape+

200 URLs/пакет COPY FROM stdin ваш cron / Airflow

2 Індексація Discovery → BigQuery

Провести сканування сайту, додавати нові URL-адреси по мірі їх виявлення. Виконати дедуплікацію порівняно з даними за вчора, зібрати лише зміни, вносити рядки до BigQuery по мірі їх надходження.

# stream discovered URLs over SSE
curl -N :8001/api/v1/crawl/start 
  -d '{"seed_url":"site.com",
       "scope":"same-domain",
       "max_pages":1000}' 
| jq -r 'select(.event=="found") | .url' 
| comm -13 yesterday.txt - 
| bq insert dataset.urls --source_format=NEWLINE_DELIMITED_JSON

Стрімінг через SSE дедуплікація на завдання (SHA1) вставки лише дельти

3 Потік новин → Kafka

Здійснювати сканування та витяг даних із новинних джерел, публікувати кожну статтю у вигляді події в Kafka. Наступні споживачі (інформаційні панелі, моделі аналізу настроїв, системи оповіщення) підписуються на теми.

# 1. continuous crawl of source list
curl -N :8001/api/v1/crawl/start 
  -d "@sources.json" 
| jq -c 'select(.event=="scraped") | .result' 
| kcat -P -t news.raw -b kafka:9092

# 2. consumers subscribe downstream
kcat -C -t news.raw | your-pipeline

ланцюг скрейпінг + публікація Продюсер Kafka топік на джерело

FAQ

Поширені запитання щодо скрейпінгу в сховище даних

З яких джерел можна збирати дані?

Будь-яка публічна сторінка. Вбудовані пресети охоплюють найпопулярніші ресурси — торгові майданчики, пошукові системи, YouTube, профілі в LinkedIn (із сесіями). Для власних джерел скористайтеся POST /api/v1/presets/generate за допомогою одного зразкового URL-адреси — LLM визначає схему та створює селектори, і ви отримуєте готову до повторного використання пресет за лічені секунди. Для одноразових сторінок POST /scrape/page з явно вказаною extract: {...} схемою працює без будь-яких пресетів. Файл robots.txt враховується за замовчуванням; дотримуйтесь його для джерел, які вам не належать.

Як завантажити дані в Snowflake / BigQuery / Postgres?

Скрепер повертає рядки у форматі JSON для кожного пакета та потоки SSE для кожного проходження. Направте дані безпосередньо до завантажувача вашого сховища: jq -c '.results[]' | psql -c "COPY raw FROM stdin" для Postgres, bq insert для BigQuery, snowsql --query "PUT ..." + COPY INTO для Snowflake, або записуйте дані в S3/GCS і дозвольте вашому існуючому Snowpipe / зовнішній таблиці їх завантажити. Не потрібно підтримувати спеціальні коннектори — це просто JSON через HTTP.

Чи можу я запустити це всередині моєї VPC?

Так — Yozh працює на власному хостингу. docker compose up Він розміщує два контейнери (скрейпер + краулер) у будь-якій мережі, яку ви їм надаєте: VPC, локальна мережа, ізольована мережа. Без зв’язку з сервером-базою, без залежності від SaaS. Вихідний трафік надходить до об’єктів, з яких ви збираєте дані (а також, за бажанням, до проксі-сервера CyberYozh App Proxy, якщо ви його увімкнете). Журнали, траси та метрики залишаються там, де ви їх розмістили — на кінцевій точці Prometheus за адресою /metrics, структуровані журнали у форматі JSON — у stdout.

Як працюють повторні спроби, помилки та спостережуваність?

Кожен запит отримує ліміт повторних спроб з експоненційним відстроченням (настроюється для кожного виклику). У разі невдачі повертаються структуровані коди помилок — BLOCKED, CAPTCHA, SELECTOR_FAIL, UPSTREAM_TIMEOUT — тож ваш завантажувач може розгалужуватися на їх основі, замість того щоб розбирати рядки. Коли селектор перестає працювати після переробки джерела, функція самовідновлення LLM миттєво регенерує його (передаючи llm: {model: "..."}) та позначає відповідь тегами self_heal: true для подальшого аудиту. Метрики Prometheus щодо глибини черги, рівня успішності та затримки проксі надаються «з коробки».

Як це поєднується з Airflow / dbt / Temporal?

Yozh відповідає за збір даних; ваш оркестратор — за розклад. Найпростіший шаблон: Airflow BashOperator (або PythonOperator із requests) викликає /scrape/batch, передає результати в проміжну таблицю, а потім запускає завдання dbt у ланцюжку. Скрейп повертає потік SSE — використовуйте довготривале завдання або розбийте його на частини, які можна відновити, за допомогою job_id. Відсутність вбудованого планувальника означає відсутність прив’язки до одного постачальника: використовуйте те, що вже працює на вашій платформі даних.

Публічні веб-дані, структуровані для SQL