ETL преобразует схемы источников: агенты пишут маппинг полей и очередь отвергнутых строк

Схема описывает имена, типы и обязательность полей. ETL извлекает данные, приводит их к целевой схеме и загружает результат: так процесс определяет Сбер2В.

В учебном прайсе поставщик А пишет «Код» и цену в рублях. Поставщик Б пишет sku и цену в копейках. Скопировать оба файла в одну таблицу недостаточно.

Контракт фиксирует, что означает цена, какая у неё валюта и учтён ли налог. Задача для агента должна содержать этот результат до написания загрузчика.

Маппинг связывает поле источника с полем результата и правилом преобразования. Агент пишет эту связь в коде, инженер утверждает единицы и допустимые значения.

Пропущенное поле может исчезнуть без ошибки. Документация AWS Glue говорит прямо: apply_mapping не включает в результат поля, которых нет в маппинге.

Агенту хватит искусственного прайса с теми же форматами и ошибками. Данные клиентов у агента не нужны для написания такой проверки.

Очередь отказов нужна для исправления, а не для счётчика ошибок. Запись должна позволять найти исходную строку и понять, какое правило она нарушила.

Цена «по запросу» не превращается в ноль. В учебном контракте это отказ INVALID_PRICE; коммерческий отдел просит у поставщика числовую цену.

AWS Glue умеет выдавать записи ошибок отдельно через errorsAsDynamicFrame. Сохранить их, назначить владельца и организовать повторную обработку нужно в вашем процессе.

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

Ошибка значения касается отдельной строки. Сбой записи касается доставки результата: он требует повторения операции, а не объявления данных поставщика бракованными.

Потеря поля на нескольких путях стала техническим долгом загрузчика нашей машины. Проверка и откат защищают выпуск кода, но ETL ещё должен объяснять, на каком этапе отказались данные.

Повтор того же файла должен дать тот же результат. Apache Airflow рекомендует фиксировать вход и использовать UPSERT вместо INSERT, который при повторе может создать дубли.

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

В завершённом учебном импорте 1 000 строк = 980 принятых + 20 отвергнутых. Дубли и строки в обработке должны учитываться отдельно, если они предусмотрены вашим контрактом.

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

Код завершения запуска не заменяет сверку результата. Сторож сравнивает ожидаемые файлы, принятые строки и отказы, затем зовёт того, кто может исправить причину.

В курсе агентной разработки это объясняет урок «Руль, окно и сторож». Для ETL перенос тот же: правила задают поведение, очередь показывает работу, сигнал требует действия.

Подписка на разработку «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Инженер ведёт машину агентов; одна задача в работе, пауза в любой месяц.

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

Если некому утвердить смысл полей, код эту неопределённость не снимет. Начать стоит с разбора задачи ETL и списка данных, за которые отвечает ваша команда.

1. До кода утвердите смысл, типы и обязательность целевых полей.

2. Для каждого формата зафиксируйте маппинг и версию правил.

3. Отказ сохраняйте с причиной, исходной записью и владельцем.

4. Принимайте повтор файла и восстановление после сбоя без дублей.

5. Закрывайте исправленный отказ повторной обработкой и сверкой результата.