Airflow-пайплайн для обучения и inference
Как устроить Airflow-пайплайн для регулярного переобучения и offline inference модели? Какие компоненты, артефакты и оптимизации нужны?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Разделите сбор данных, training, validation, inference и publish на отдельные idempotent tasks. CPU-heavy подготовку и GPU-heavy обучение держите в разных контейнерах, версионируйте артефакты и мониторьте freshness, длительность, ресурсы и качество.
Полный разбор
ML DAG лучше строить как набор явных стадий: extract, validate, feature/build dataset, train, evaluate, offline inference, publish и notify. Подготовка данных обычно CPU/Spark-heavy, а training или embedding inference требуют GPU, поэтому эти стадии не должны держать один и тот же дорогой ресурс.
Каждая стадия должна писать явный артефакт: датасет, feature snapshot, checkpoint, метрики, prediction file, manifest или publish marker. Это делает retries безопаснее и позволяет откатиться к предыдущей версии. Для регулярного переобучения важно не только запустить модель, но и проверить, что свежие данные реально дошли, схемы совместимы, а метрики не просели.
Оптимизация идет через partitioning, chunk-level parallelism, кэширование повторно используемых данных, контроль concurrency и устранение лишних shuffle/IO. Monitoring должен показывать duration по task, queue time, freshness, row counts, artifact sizes, GPU usage, failed publishes и model quality regression.
Теория
Airflow не делает ML надежным сам по себе; надежность появляется из idempotent tasks, явных артефактов, ресурсных границ и проверок качества.
Типичные ошибки
- Склеить data prep, training и publish в одну большую задачу.
- Занимать GPU во время чистой подготовки данных.
- Мониторить только green DAG, но не freshness и качество артефактов.
Как отвечать на собеседовании
- Разведите CPU и GPU стадии.
- Говорите через artifacts, retries, validation и rollback.