Spark Structured Streaming с веб-данными: принципы, сценарии и вопросы внедрения
TL;DR
Spark Structured Streaming обрабатывает новые записи инкрементально; он сам по себе не обнаруживает и не отображает веб-страницы.
Надежная веб-данных архитектура запускает ограниченный краулер выше по потоку, сохраняет неизменяемые события страниц в поддерживаемом источнике и позволяет Spark обрабатывать эти события.
Nstdata Crawl — это API веб-сканирования для данных, готовых к LLM: он может обнаруживать страницы в явных пределах, отображать JavaScript и возвращать Markdown, HTML, сырьевые данные, ссылки, PDF или скриншоты.
Рассматривайте успешную подачу краулинга как подтверждение работы, а не доказательство того, что каждая страница была успешно обработана; согласовывайте завершенные, неудачные, ожидающие и общие показатели.
Используйте стабильный ключ страницы, время наблюдения, контрольную точку и идемпотентный вспомогательный элемент, чтобы перезапуски не удваивали подсчет обновлений.
Оценивайте стоимость за принятую, своевременную запись, а не просто за запросы.
Что на самом деле означает Spark Structured Streaming с веб-данными?
Spark Structured Streaming с веб-данными означает непрерывную обработку новых собранных записей страниц через инкрементальный движок DataFrame Spark. Это полезно, когда команде продукта нужны изменяющиеся цены, страницы государственной политики, документация или рыночные сигналы для достижения склада или индекса AI без необходимости каждый раз перестраивать целый пакет данных. Обзор Structured Streaming Apache Spark описывает модель выполнения микро-пакетов и восстановление на основе контрольных точек.
Для сбора страниц Nstdata Crawl предоставляет API веб-сканирования, подходящий для LLM.
Различие имеет значение: URL не является источником потоковой передачи. Spark может читать файлы, Kafka и другие поддерживаемые источники, в то время как краулер управляет обнаружением, доступом, рендерингом и извлечением. Вызов HTTP API внутри foreachBatch является побочным эффектом обратного вызова потокового ; это не превращает этот API в поддерживаемый источник с источниками смещения. показывает более широкий шаблон от сбора до потребления.
Эта архитектура стоит использования, когда множество независимо изменяющихся страниц подают одни и те же преобразования вниз по потоку, и свежесть важнее, чем ежедневный полный экспорт. Розничный продавец может следить за разрешенными страницами товаров для изменений предложений; команда AI может обновить корпус RAG, когда изменяется государственная документация; команда по рискам может отслеживать изменения в государственной политике. Деловая ценность заключается в более мелких, отслеживаемых обновлениях и более быстрых решениях, при условии, что исходные наблюдения на самом деле свежие.
Для небольшого набора URL, обновляемых раз в день, запланированная пакетная работа обычно проще. Structured Streaming добавляет хранение контрольных точек, управление схемами, семантику вспомогательных элементов и непрерывные операции. Выбирайте его только если эти затраты приносят полезное улучшение свежести или пропускной способности. Обзор автоматизированного сбора данных помогает установить целевой уровень сервиса перед выбором режима обработки.
Какие компоненты составляют поток веб-данных в производстве?
Поток веб-данных в производстве имеет ограниченную задачу по приобретению, надежный уровень приземления, структурированное преобразование и наблюдаемую цель. Поток выглядит следующим образом:
Seed URLs or reviewed sitemap → Nstdata Crawl → job reconciliation → immutable JSON events → Kafka or object storage → Spark Structured Streaming → validated table or index
Nstdata Crawl может отправить сканирование сайта с начального URL с параметрами maxDepth, maxPages, includeUrls, excludeUrls и ignoreQuery. Эти управления помогают предотвратить расширение раздела каталога в поисковые страницы, маршруты учетных записей или бесконечные варианты запросов. Его рендеринг в браузере может захватывать содержимое, которое появляется после выполнения JavaScript, и его выходы служат различным потребителям: Markdown для RAG, HTML или сырьевые данные для извлечения полей, ссылки для обнаружения и скриншоты или PDF для расследования. Встроенная оркестрация прокси означает, что вызывающему не нужно настраивать отдельную конечную точку прокси. Это возможности сбора, а не обещание того, что бизнес-поля страницы уже нормализованы. См. документацию API Nstdata Crawl для текущего контракта запросов и ответов.
Посадочное событие должно включать source_url, observed_at, crawl_id, page_status, content_hash и ссылку на нормализованное содержимое или артефакт. Храните сырьевой ответ или надежную ссылку для отладки. Избегайте включения большого PDF или скриншота в сообщение Kafka; храните это отдельно и передайте ссылку. Если API возвращает ссылку на большой артефакт, извлеките его через документированную конечную точку чтения хранилища вместо того, чтобы догадываться о URL.
Как подключить Nstdata Crawl к Spark, не изобретая соединитель?
Подключите Nstdata Crawl к Spark через планировщик и долговечный источник, который уже поддерживает Spark. Приведенный ниже пример использует отправку ограниченного обхода сайта и каталог полученных JSON-файлов. Это шаблон интеграции, а не родной соединитель Nstdata Spark.
Шаг 1: Отправьте ограниченный обход
Создайте учетную запись Nstdata, получите ключ API Crawl, выберите разрешенный публичный начальный URL и установите область перед началом работы. Сохраните ключ в NSTDATA_API_KEY. Документированный конечный пункт обхода сайта — POST https://api.nstdata.io/api/v1/crawl с заголовком x-api-key.
curl-sS-X POST 'https://api.nstdata.io/api/v1/crawl'\-H"x-api-key: $NSTDATA_API_KEY"\-H'Content-Type: application/json'\--data'{"url":"https://docs.example.org/guide/","formats":["markdown","links"],"maxDepth":2,"maxPages":100,"includeUrls":["*docs.example.org/guide/*"],"excludeUrls":["*docs.example.org/guide/search*"],"ignoreQuery":true,"onlyMainContent":true}'
Замените пример хоста на URL, который вам разрешено собирать. Ответ должен содержать идентификатор обхода; запишите его вместе с запланированным запуском. Не предполагая, что отправка означает завершение сбора. Руководство по конвертации веб-сайтов в Markdown охватывает решения по началу и области.
Шаг 2: Соотнесите задачу и обработку событий полученной страницы
Запрашивайте GET /api/v1/crawl/status/{crawlId}, пока задача не достигнет конечного состояния, затем проверьте total, completed, failed, и pending. Получите страницы через GET /api/v1/crawl/pages/{crawlId}. Текущая документация показывает nextCursor в ответе, но не четко определяет параметр запроса курсора, поэтому проверьте контракт пейджинга с вашей учетной записью или SDK перед объявлением о полном извлечении в масштабе. Сохраняйте одно неизменяемое событие на каждую принятую страницу, разделенную по дате наблюдения и идентификатору запуска. Записывайте новые файлы атомарно, чтобы Spark никогда не видел частично записанный JSON.
Шаг 3: Обрабатывайте полученные события с контрольной точкой
Определите схему, а не просите поток выводить ее из изменяющихся страниц. Минимальный потребитель PySpark может читать файлы JSON с разделителями строки по мере их появления:
Код требует PySpark и директории, доступные для записи процессом Spark. Он демонстрирует поддерживаемую границу файлового источника; его нельзя запускать против службы Nstdata без вашего API-ключа и процесса доставки. Для производственного приемника добавьте валидацию, дедупликацию и стабильный ключ, такой как канонический URL плюс хеш содержимого или версия наблюдения. Храните состояние контрольной точки на надежном носителе. Руководство по API DataFrame Spark для потоковой передачи документирует приемники и семантику foreachBatch.
Как вы узнаете, что поток правильный и актуальный?
Поток является правильным и актуальным только тогда, когда краулер и Spark согласны по охвату, задержке и принятым записям. Сравните запрашиваемые и обнаруженные URL, завершенные и неудачные страницы, полученные файлы, строки ввода Spark и конечные строки. Пробуйте визуализированные страницы по сравнению с их Markdown или HTML; ответ 200 может всё еще содержать экран входа, пустую оболочку или неправильную локализацию. Отслеживайте observed_at до доступности назначения, а не только задержку обработки Spark.
Установите явные правила принятия: наличие обязательных полей, ненулевое основное содержимое, ожидаемая область URL, приемлемый язык, отсутствие дублирующей версии и бюджет ошибок для ненадежностей. Храните события "мёртвого письма" с указанием причины и URL источника. Для извлечения ИИ проверьте качество чанков и происхождение перед индексацией. Общий артефакт страницы автоматически не является точным фактом о продукте или политике.
Какие риски и предельные расходы вы должны учитывать?
Основные риски — это неконтролируемое расширение обхода, устаревшее или неполное содержание страниц, дрейф схемы, повторная обработка и скрытые эксплуатационные расходы. Ограничьте обнаружение глубиной, количеством страниц и фильтрами URL; отдельно ограничьте одновременность планировщика. Рендеринг JavaScript может увеличить задержку, а изменённый макет страницы может сломать сопоставление полей, даже если обход прошёл успешно. Не выстраивайте правила выставления счетов или фиксированную цену на основании количества запросов; проверьте свой план и измерьте стоимость за принятую страницу, включая отклонённые и повторно обработанные работы.
Также подтвердите, что сбор данных соответствует условиям сайта, применимому законодательству, обязательствам по соблюдению конфиденциальности и внутренней политике. Избегайте обхода аутентификации и непубличных страниц. Если требуется строгой уровневый SLA или поток с низкой задержкой, протестируйте задержку от источника до места назначения на репрезентативных сайтах перед привязкой к архитектуре.
Какой подход должен выбрать ваша команда?
Выберите запланированную пакетную обработку для небольшого, медленно изменяющегося набора URL, и выберите структурированное вещание, когда надежный поток страниц-событий и непрерывная обработка вниз по потоку оправдывают добавленные операции. Начните с одного ограниченного задания Nstdata Crawl, согласуйте каждую страницу и фиксируйте неизменяемые события; затем подключите хранилище событий к Spark. Тот же Markdown вывод также может стать основой для рабочего процесса веб-данных RAG, как только проверки качества будут установлены.
Q: Может ли Spark Structured Streaming напрямую обходить веб-сайт?
Spark Structured Streaming не предоставляет обнаружение веб-сайтов, рендеринг браузера или управление состоянием обхода. Используйте обходчик выше по потоку и передавайте данные в Spark через поддерживаемый надежный источник.
Q: Достаточно ли успешной отправки Nstdata Crawl для создания события Spark?
Успешная отправка подтверждает только то, что задание было принято. Дождитесь результатов страницы, проверьте статус и содержание, затем излучите принятые события.
Q: Должно ли каждое обновление страницы становиться новой строкой?
Каждое наблюдение может быть событием, но таблицы ниже по потоку должны применять задокументированное правило версии или дедупликации. Сохраняйте source_url, время наблюдения и хеш содержания, чтобы можно было объяснить повторные обходы.
Q: Заменяет ли Nstdata Crawl преобразования Spark?
Nstdata Crawl предоставляет доступные и обработанные веб-артефакты. Spark или другая система ниже по потоку по-прежнему обрабатывают сопоставление схем, специфичных для домена, объединения, правила качества и доставку.
Kai Watanabe
Nov. 3rd 2026
Сканируйте целые сайты одним API-запросом
Успешность 99,8% с рендерингом JavaScript
Получайте чистые данные для LLM в разных форматах
Преобразуйте любой сайт в Markdown, HTML, JSON, ссылки, PDF и другие форматы без управления инфраструктурой сканирования.
