Отклонённая запись нуждается в причине, ответственном и понятном пути возврата. Разбираем карантин данных на условном примере ежедневной загрузки заказов.
Проблему нужно сохранить заметной
Представим условную ежедневную загрузку заказов. Большинство записей содержит понятные номера и суммы, но у нескольких отсутствует обязательное обозначение магазина. Если молча отбросить их, итог станет неполным. Если без проверки пропустить дальше, сведения могут попасть не в тот отчёт. Для таких случаев команда может предусмотреть отдельный маршрут разбора.
Карантином данных называют изоляцию записей, которые не прошли выбранные проверки, с возможностью разобраться в причине. Это не медицинский термин и не универсальная кнопка любой системы. В документации Databricks показан пример раздельных путей для корректных и некорректных записей. Для нашей задачи используем эту идею как основу условного процесса.
Основание отклонения должно быть понятным
Для нашего магазина запишем правило словами: заказ должен иметь обозначение магазина, по которому его можно отнести к нужному подразделению. Причину отклонения сохраним рядом с исходной записью и сведениями о загрузке. Тогда ответственный увидит, чего именно не хватает, а не получит безымянную папку «ошибки», где перемешаны совершенно разные ситуации.
Важно отличать отсутствующее исходное поле от сбоя его преобразования. Об этом различии рассказывает материал о строгой обработке значений в Spark. Здесь нужен следующий шаг: кто рассматривает выявленное нарушение и что должно произойти до возвращения записи в основной результат. Само обнаружение ещё не исправляет данные.
Разные нарушения могут требовать разной реакции
В описании проверок качества Databricks различаются варианты сохранения записи с наблюдением, отбрасывания и остановки обновления при нарушении. Это поведение конкретного инструмента. Карантинный маршрут выбирается под задачу и не означает, что основная загрузка обязательно должна продолжаться при любой ошибке.
В нашем условном отчёте несколько неизвестных магазинов могут сделать итог непригодным для принятия решения. Тогда пользователю нужен статус неполноты, а команда отдельно решает, допустим ли предварительный выпуск. Для другого результата можно согласовать ограниченное использование корректной части. Такое решение требует понимания последствий, а не только подсчёта числа отклонённых строк.
У карантина должен быть ответственный
Предложим назначить человека, который получает задачу на разбор, и определить ожидаемое следующее действие. Иногда нужно уточнение у источника, иногда исправление договорённости о поле, иногда выяснение ошибки обработки. Без такого порядка изоляция легко превращается в постоянное хранение забытых проблемных записей, которые больше никто не считает частью результата.
Для учебного процесса полезно видеть, какие записи ещё ждут решения, какие подтверждены как ошибочные и какие готовы к повторной обработке. Не нужно автоматически придумывать недостающий магазин по похожему названию. Если подтверждения нет, неопределённость должна оставаться явной. Пользователям отчёта важно понимать, какие сведения пока не вошли и почему.
Возврат в обработку требует повторной проверки
Допустим, источник сообщил правильное обозначение магазина. Для нашего примера сохраним исходную запись и объяснение исправления, затем повторим нужные проверки. Отдельно убедимся, что заказ попадёт в результат один раз. Если часть записи уже была использована ранее, простая повторная отправка может создать дубликат вместо завершения исправления.
После возврата сравним число принятых, изолированных и окончательно исключённых записей. При этом категории должны быть определены без пересечений. Проверка полноты переноса помогает обсудить итог. Уменьшение карантина само по себе ничего не доказывает, если записи просто удалили из очереди, не выяснив их дальнейшую судьбу.
Изоляция отличается от обычной подготовки данных
Промежуточная зона может принимать данные до общего преобразования, а карантин выделяет случаи с определённым нарушением. Название места хранения менее важно, чем понятный статус и маршрут записи. Для учебного разбора проследите один заказ от отклонения до согласованного результата.
Продолжить изучение загрузок можно на программе Data Engineer для начинающих. Первый полезный результат — описать правило отклонения, владельца разбора, основание исправления и проверку однократного возврата.
