Воспроизводимый ETL-конвейер для параметризованной загрузки

Вы — старший инженер по данным, специализирующийся на {pipeline_tool}. Создайте полный, воспроизводимый, production-ready конвейер данных для извлечения {data_type} из {source_system} в формате {data_format}, трансформации данных в соответствии с {transformation_requirements} и загрузки в {target_platform} с периодичностью {frequency}. Используйте фигурные скобки {…} как именованные параметры; в выходном материале всё, что зависит от этих параметров, должно быть явно параметризовано (чтобы можно было заменить значения без изменения логики).

Сформируйте итоговый ответ по контракту ниже.
- Не выдумывайте значения для пустых полей и placeholders.
- Если входных данных не хватает, явно перечислите допущения.
- Сохраняйте технические идентификаторы, SQL, JSON, DDL, команды, пути, URL и названия систем без искажений.
- Не задавайте уточняющих вопросов.
- Не добавляйте разделы вне заданного формата.

Верните результат по следующему контракту (строго соблюдайте порядок разделов):

1) Краткое архитектурное описание (1–2 абзаца)
   - Цель конвейера.
   - Основные компоненты (extract, transform, load, scheduler, monitoring, secrets).
   - Поток данных и гарантия единоразовой обработки/идемпотентности.

2) Список артефактов, которые вы предоставляете (репозиторий/файлы), с путями и кратким назначением каждого файла.

3) Полная структура репозитория (дерево файлов) с содержимым всех файлов:
   - Исходный код (включая все модули, скрипты).
   - Конфигурационные файлы (YAML/JSON/INI), с шаблонами, где нужно вставлять секреты через переменные окружения/менеджер секретов.
   - Файлы для развертывания (Dockerfile, docker-compose, systemd unit или манифесты Kubernetes / Helm — в зависимости от {pipeline_tool}).
   - Файлы для планировщика/оркестратора (если применимо для {pipeline_tool}, например, DAG для Airflow, pipeline для Prefect, job для Dataproc/Dataflow).
   - Файлы логирования и ротации логов, конфигурация мониторинга.

   Каждый файл должен быть приведён полностью (полный код/контент).

4) Технические детали реализации
   - Язык(и) программирования и версии; зависимости и файл управления зависимостями (requirements.txt, pyproject.toml и т.п.).
   - Подробное объяснение шагов извлечения, трансформации и загрузки: последовательность операций, агрегаты, преобразования, обогащения, сохранение типов/форматов.
   - SQL/скрипты схемы целевой таблицы/индексов/партиционирования (если целевая платформа — база/хранилище).
   - Описание контрактов данных (схема входного формата и схема выходных данных). Приведите примеры: минимум 5 строк примерных входных записей и соответствующих выходных записей после трансформации.

5) Обработка ошибок и надёжность
   - Стратегии обработки ошибок на каждом этапе (ретраи, дедупликация, откат увязанных операций).
   - Политики повторов (количество, backoff), idempotency-методы и гарантии доставки.
   - Что делать при частичной неудаче (перезапуск только failed tasks, dead-letter storage).

6) Проверка качества данных (Data Validation)
   - Перечень контрольных проверок (nulls, типы, диапазоны, уникальность, ссылочная целостность) с порогами и действиями при нарушении.
   - Примеры правил в форме кода (assertions/unit checks) или конфигураций (Great Expectations, dbt tests и т.п.), если применимо.

7) Логирование, мониторинг и оповещения
   - Список метрик, которые должны отслеживаться (throughput, lag, error_rate, success_rate, latency и т.д.).
   - Примеры правил оповещений (точные выражения/alert rules для Prometheus/Grafana/CloudWatch/Datadog или текст правил для выбранной платформы), уровни критичности и шаги реагирования.
   - Формат логов (структура полей), уровни логирования и хранение логов.

8) Управление секретами и безопасность
   - Как хранить и передавать креденшелы (environment vars, Vault, Secrets Manager).
   - Политики доступа (минимальные привилегии), шифрование при хранении/пересылке данных.
   - Рекомендации по обрезке/анонимизации чувствительных полей при логировании и при хранении.

9) Инструкции по развертыванию и запуску (пошагово)
   - Требования по инфраструктуре (CPU/RAM/disk, привязка к услугам).
   - Команды/скрипты для развертывания и инициализации (локально и для production).
   - Примеры переменных окружения/секретов, которые нужно задать.
   - Как запустить вручную и как наблюдать за выполнением (логи, UI оркестратора).

10) Тестирование и валидация развертывания
   - Как локально прогнать pipeline на небольшом наборе данных; команды и ожидаемый результат.
   - Набор smoke/integration тестов и инструкции по их запуску.

11) Поддержка и эксплуатация
   - Описать рутинные операции (очистка, ре-синк данных, откат).
   - Рекомендации по масштабированию и оптимизации производительности.
   - Ожидаемые точки отказа и способы их устранения.

12) Оценка затрат и ресурсы
   - Примерные оценки используемых ресурсов и возможные статьи затрат (compute, storage, network).

Дополнительные строгие требования к оформлению ответа:
- Используйте русский язык.
- Укажите, в каком формате предоставлены файлы (например: plain text файлы с указанными именами).
- Для всех конфигураций укажите точные места, где нужно подставить реальные значения вместо {…} (перечислите переменные окружения / параметры конфигов).
- Всю сгенерированную программуемую логику предоставьте так, чтобы пользователь мог скопировать файлы и сразу развернуть (последовательность команд для инициализации и деплоя).
- Если {pipeline_tool} поддерживает определённый синтаксис/конвенции — следуйте им (например, структуры DAG для Airflow, flow для Prefect). Если инструмент допускает выбор языка, предпочитайте Python 3.9+; если он не поддерживает Python, используйте нативный язык инструмента и укажите причину.
- Не добавляйте в ответ общие рассуждения; только чёткие артефакты и инструкции по указанным разделам.

Если некоторые параметры в {…} неоднозначны для реализации (например, тип источника данных или ограничения платформы), сделайте разумные допущения и явно перечислите эти допущения в начале секции "Краткое архитектурное описание".

- Улучшения: 1) уточнил структуру и обязательные разделы вывода; 2) потребовал полные файлы и репо-структуру; 3) добавил строгие требования к обработке ошибок, мониторингу и секретам; 4) определил требования к формату и возможным допущениям; 5) зафиксировал язык и условие параметризации.