Пакетный сбор данных с тысячами URL-адресов асинхронно

TL;DR

• Пакетное сканирование тысяч URL — это проблема управления очередями, прежде всего это проблема HTTP.
• Используйте ограниченную конкуренцию, таймауты на запросы, повторные попытки с джиттером, контрольные точки и идемпотентный ключ результата.
• asyncio и aiohttp хорошо работают для простых публичных страниц; рендеринг браузера или обнаружение сайта следует перенести на сервис обхода.
• Nstdata Crawl лучше подходит, когда пакет требует рендеринг страниц, артефакты страниц или контролируемый сбор на уровне сайта, а не простые получения.

Почему большие пакеты URL терпят неудачу

Начните с Nstdata Crawl, когда сбор данных требует рендеринга или состояния задачи.

Пакетный сканер терпит неудачу, когда скорость отправки, ограничения целевого сайта, повторы попыток и хранение результатов рассматриваются как один цикл. Тысяча URL может привести к дублированию записей, бурям повторных попыток, открытым соединениям и отсутствию надежного способа возобновления после остановки работника или процесса. Начните с Nstdata Crawl, когда пакет является задачей обхода, а не списком простых HTTP-запросов.

Первое проектное решение — это идентичность записи. Используйте канонический URL плюс хеш конфигурации получения, а не позицию во входном файле. Запишите состояния queued, running, succeeded, failed, и dead_letter, с последней ошибкой и количеством попыток. Это делает частичный запуск восстанавливаемым.

Асинхронный дизайн, который остается ограниченным

Самый безопасный шаблон — это производитель, ограниченный пул рабочих процессов и надежный вывод результатов. aiohttp документирует шаблон ClientSession для асинхронных HTTP-запросов; официальное руководство aiohttp является правильным ориентиром для жизненного цикла сеанса и таймаутов.

Рабочий асинхронный шаблон

Следующий блок иллюстративен для авторизованных публичных HTML-страниц. Он не обходит аутентификацию, CAPTCHA или политику роботов.

import asyncio
import hashlib
import time
import aiohttp

TIMEOUT = aiohttp.ClientTimeout(total=30)

async def fetch(session, sem, url):
    async with sem:
        for attempt in range(4):
            try:
                async with session.get(url, allow_redirects=True) as response:
                    body = await response.text(errors="replace")
                    если response.status >= 500:
                        raise RuntimeError(f"retryable status {response.status}")
                    return {"url": str(response.url), "status": response.status,
                            "sha256": hashlib.sha256(body.encode()).hexdigest(),
                            "body": body, "fetched_at": time.time()}
            except (aiohttp.ClientError, asyncio.TimeoutError, RuntimeError):
                если attempt == 3:
                    return {"url": url, "status": "failed", "attempts": attempt + 1}
                await asyncio.sleep((2 ** attempt) + 0.2 * attempt)

async def run(urls):
    sem = asyncio.Semaphore(25)
    async with aiohttp.ClientSession(timeout=TIMEOUT) as session:
        return await asyncio.gather(*(fetch(session, sem, url) для url в urls))

Замените список в памяти на базу данных или объектное хранилище перед производством. Не храните тысячи полных тел ответов в одном процессе. Храните тело только тогда, когда его статус и политика содержимого проходят, и храните компактный журнал ошибок для остального.

Когда управляемый уровень обхода лучше

Сырые асинхронные HTTP подходят, когда URLs известны, страницы в основном рендерятся сервером, и ваша команда владеет парсингом и сохраняемостью. Nstdata Crawl становится более актуальным, когда пакет требует рендеринга JavaScript, ограниченного обнаружения, артефактов Markdown/HTML/JSON/link/PDF, состояния задачи или повторно используемой границы извлечения. Его страница цен на Crawl отделяет использование URL от использования прокси и различает одноразовое использование баланса от подписок; считайте стоимость за принятую страницу, а не за отправленный URL.

Для рабочих нагрузок RAG руководство по Crawl for RAG объясняет, почему метаданные источника и политика обновления принадлежат в pipeline. Для рабочих нагрузок агентов руководство по доступу к MCP в вебе охватывает ограниченный доступ к инструментам. Парсер все еще нужен для вашей схемы, валидации схемы, дедупликации и политики законного использования. Для получения сопутствующего контекста реализации, смотрите руководство по веб-доступу MCP, руководство по базе знаний RAG, словарь по веб-сканированию и словарь ETL.

RFC 9309 и RFC 9110 предоставляют соответствующий контекст по HTTP и политике сканирования.

Заключение

Начните с небольшого примера URL, измерьте коэффициент принятых страниц и коэффициент повторных попыток, затем увеличивайте параллелизм только когда источник и приемник остаются здоровыми. Используйте асинхронный клиент для простых известных URL-адресов; используйте Nstdata Crawl, когда рендеринг, обнаружение или управление артефактами становятся узким местом. Следующий шаг — выполнить одну ограниченную партию и проверить сбои перед планированием тысяч страниц.

FAQ

Q: Сколько параллельных запросов должен использовать парсер батчей?

Нет универсального числа; начните с осторожностью, соблюдайте целевые указания и увеличивайте параллелизм только после наблюдения за скоростью ответа, ошибками и задержкой в очереди.

Q: Как мне возобновить неудавшийся пакет?

Сохраните состояние для канонического URL и повторите только записи, которые не являются окончательными успешными, используя идемпотентный ключ результата.

Q: Достаточно ли асинхронного HTTP для страниц с тяжелым JavaScript?

Нет. Асинхронный HTTP загружает ответ сервера; он не выполняет JavaScript браузера, который создает контент, отрисованный клиентом.

Q: Могу ли я парсить частные или авторизованные URL?

Только с явным разрешением и одобренным процессом обработки учетных данных; этот рабочий процесс не охватывает обход контроля доступа.

Q: Как мне измерить стоимость партидной обработки?

Измерьте стоимость за принятый, валидированный запись, включая повторные попытки, трафик прокси, рендеринг, хранение и последующий разбор, а не только количество запросов.