Правильный подход к веб-парсингу начинается не с попытки получить как можно больше строк, а с проверяемой границы приёмки. Источники, товары, регионы, поля, ритм наблюдений, сопоставление и формат результата сначала согласуют, затем проверяют на небольшой выборке. После этого каждой строке можно назначить понятное состояние: готова, требует решения, содержит исключение или заблокирована до повторной проверки.
Ниже описана рекомендованная проектная модель. Она помогает согласовать приёмку для конкретной границы и не задаёт единые правила для всех проектов.
Перейти к разделу:
- согласованная граница
- тестовая выборка
- схема и ключ наблюдения
- измерения качества
- готовые строки и исключения
- изменения и повторная проверка
Начните с согласованной границы
До операционной приёмки должны быть известны выбранные источники, сущности и поля, регион или продавец, условия наблюдения, ритм, история и выходная структура. Если способ получения ещё не выбран, эту задачу стоит вынести отдельно: выбрать способ получения данных можно после фиксации требований к результату.
Граница нужна и для отрицательных состояний. Она отвечает, как записать отсутствующее поле, недоступную карточку, спорное сопоставление и изменение схемы. Без этих правил «готовый файл» легко смешивает наблюдение с догадкой.
Подтвердите границу на небольшой выборке
Выборка должна включать не только успешный случай. Полезны строка с отсутствующим обязательным полем, неоднозначное сопоставление, недоступная карточка, повтор ключа и конфликт версии схемы. Владелец приёмки видит, какие поля подтверждены, что осталось недоступным и какие решения нужны до регулярной передачи.
Выборка не устанавливает универсальную долю успеха. Она подтверждает конкретные источники, поля, условия, правила сопоставления и форму результата в согласованной границе.
Версионируйте схему и ключ наблюдения
Строка должна сохранять идентификатор товара, источник, регион, продавца или карточку, время проверки и версию схемы. Набор этих полей образует проектный ключ наблюдения. Если в ключ добавляется регион или меняется тип поля источника, затронутые строки нельзя продолжать сравнивать как будто контракт остался прежним.
Для каждого поля задают тип, обязательность и явное состояние отсутствия. Пустое наблюдение не равно нулю. Недоступная карточка не означает отсутствие товара, если такое состояние не наблюдалось непосредственно. Исходное значение и ссылка на доказательство сохраняются вместе с результатом проверки.
Определите проверки качества
Ниже — семь проектных измерений. Каждое правило получает версию, требуемые входы, код исключения, роль владельца и поле доказательства.
| Измерение | Что проверяется | Что служит доказательством | Что остаётся ограничением |
|---|---|---|---|
| Полнота | Обязательное поле заполнено либо имеет согласованное состояние отсутствия. | Словарь полей и результат проверки строки. | Нет общего процента полноты для всех проектов. |
| Валидность | Значение соответствует типу, формату или утверждённому набору текущей версии. | Версия правила и наблюдаемое значение. | Проверка формата не доказывает истинность значения за пределами наблюдения. |
| Уникальность | Активный ключ не повторяется, если версия или история не разрешают повтор. | Определение ключа и журнал проверки дубликатов. | Изменение ключа требует новой версии. |
| Сопоставление | Связь записана как точная, вариант, аналог, неоднозначная или несопоставленная. | Доказательство связи и решение владельца, когда оно требуется. | Неоднозначная запись не угадывается как точная. |
| Своевременность | Есть время проверки и сравнение с согласованным проектным окном. | Поле времени и версия проектного ритма. | Нет единого требования к свежести для всех источников. |
| Прослеживаемость | Сохранены источник, ссылка или класс, наблюдаемый контекст и время проверки. | Поля доказательства активной схемы. | Запись фиксирует наблюдение, а не абсолютную истину источника. |
| Работа с исключениями | У неготовой строки есть статус, объяснение, действие, владелец и следующая проверка. | Связанная запись журнала исключений. | Срок и результат исправления не предполагаются заранее. |
Числовое ограничение допустимо только как отдельное проектное правило с версией, обоснованием и одобрением ответственной роли. В этой рекомендованной модели нет общего значения по умолчанию.
Сохраняйте доказательство и состояние сопоставления
Для готовой строки одной метки exact недостаточно. Нужны активная версия правила и доказательство, по которому связь была принята. В этой модели состояния exact, variant и analogue могут быть допущены к готовым данным только при выполнении всех активных проверок.
ambiguous и unmatched остаются неготовыми. Они не могут стать ready без документированного изменения правила, одобрения ответственной роли, новой версии правила и повторной валидации. Простая повторная попытка этого условия не заменяет.
Для ценового примера граница полей и сопоставления раскрыта отдельно в материале спецификация мониторинга цен и сопоставления.
Разделяйте готовые строки и исключения
Ниже — полностью синтетический набор сценариев. Он показывает состояния строк и не является клиентским отчётом.
| Строка | Ситуация | Состояние | Обязательное действие |
|---|---|---|---|
| Строка 1 | Обязательные поля и доказательство есть, ключ уникален, сопоставление точное. | ready |
Сохранить версии схемы, правил и доказательств. |
| Строка 2 | Обязательное поле отсутствует и остаётся пустым. | exception |
Решить, поле недоступно или требуется изменение границы. |
| Строка 3 | Остаются два правдоподобных кандидата сопоставления. | review |
Запросить различающий атрибут у владельца каталога. |
| Строка 4 | Вымышленная карточка недоступна; наблюдаемые значения не получены. | exception |
Оставить значения пустыми и действовать по проектному правилу следующей проверки. |
| Строка 5 | Повторяется активный ключ наблюдения. | exception |
Изолировать повтор и проверить ключ вместе с версией схемы. |
| Строка 6 | Тип колонки изменился относительно активной схемы. | blocked_for_revalidation |
Версионировать отображение, получить одобрение и повторно проверить затронутые строки. |
Ведите журнал исключений
У каждой неготовой строки должен быть связанный issue ID. В записи нужны причина, статус, комментарий, действие, ответственная роль, условие следующей проверки, версия правила и доказательство решения. Исключение не удаляется молча и не закрывается только потому, что источник проверили ещё раз.
Типовой журнал исключений охватывает пять случаев: неоднозначное сопоставление, недоступный источник, отсутствующее обязательное поле, повтор ключа и изменение схемы. Для открытой или заблокированной записи указывают действие и роль владельца, но не придумывают срок восстановления.
Версионируйте изменения и повторно проверяйте затронутые строки
Добавление условного поля, изменение типа, пересмотр составного ключа, новое правило классификации или колонка передачи меняют контракт данных. Для каждого изменения в журнале связывают предыдущую и новую версии, причину, затронутые строки, роль одобрения и обязательность повторной проверки.
При конфликте активной схемы строка переходит в блокировку. После одобрения изменения появляется новая версия; затем запускаются проверки по новому контракту. Только успешный результат с доказательствами позволяет вернуть строку в готовые данные.
Используйте явную модель состояний
Базовый путь выглядит так: received → validated → ready. Если проверка не проходит, возможны exception, review или blocked; затем следуют документированное действие и recheck. Из повторной проверки строка переходит в ready только после прохождения всех активных правил, либо снова остаётся неготовой. Владелец границы может закрыть строку как closed_out_of_scope с причиной и доказательством.
Для коммерческого контекста похожие наблюдаемые поля используются в проектах мониторинг цен конкурентов и мониторинг продавцов и карточек бренда. Эти страницы описывают соответствующие предложения; рекомендованная модель приёмки на этой странице остаётся проектной и не расширяет их возможности.
Примите, пересмотрите или остановите передачу
Владелец приёмки рассматривает готовые строки, перечень исключений, активные версии и открытые риски. Решение должно быть явным: принять подтверждённую границу, пересмотреть её и повторить затронутые проверки либо остановить передачу до устранения блокирующего риска.
Проверить структуру данных на выборке — передайте пример файла, источники, поля, контекст наблюдения и ожидаемый формат. Проверка подтверждает только согласованную выборку и не превращает рекомендованные правила этой статьи в универсальную систему качества.
Применить к вашей задаче
Нужны регулярные данные, а не разовая выгрузка?
Покажите список товаров и источников. Проверим доступность данных и предложим структуру первого теста.
