Оркестрация данных

Все темы Data Engineer

Когда Airflow DAG нужен sensor?

Sensor нужен, когда DAG должен дождаться внешнего файла, partition, API-состояния или другого условия. В poke worker slot занят между проверками; reschedule освобождает его, а deferrable sensor переносит ожидание в triggerer. Выбор зависит от частоты и длительности ожидания. Обязательно задают timeout, разумный интервал, обработку окончательного отсутствия и по возможности event-driven запуск вместо постоянного polling. Операцию проектируют идемпотентной и наблюдаемой, чтобы retry или повторный запуск не создавал второй бизнес-эффект.

Как Airflow исполняет задачи в Kubernetes?

KubernetesExecutor создает отдельный pod для каждой task instance, а KubernetesPodOperator запускает выбранную работу в pod независимо от основного executor. Scheduler передает спецификацию, Kubernetes размещает pod, контейнер выполняет команду, после чего Airflow получает статус и логи. Service account, secrets, image, requests/limits, cleanup и log persistence задают явно; рестарт pod не должен дублировать неидемпотентный эффект. Операцию проектируют идемпотентной и наблюдаемой, чтобы retry или повторный запуск не создавал второй бизнес-эффект.

Какие задачи решать через Airflow REST API?

Stable REST API Airflow используют, чтобы внешняя система запустила DAG run с conf, получила состояние и прочитала метаданные, не обращаясь напрямую к БД. Внешний request ID связывают с dag_run_id, чтобы retry не создал дубликат. API защищают аутентификацией и минимальными правами, задают timeout и polling/backoff. Бизнес-данные передают ссылкой, а не огромным payload в metadata DB. Операцию проектируют идемпотентной и наблюдаемой, чтобы retry или повторный запуск не создавал второй бизнес-эффект.

Когда оправдан кастомный Airflow operator?

Кастомный operator оправдан для повторяемой интеграции с устойчивой семантикой выполнения, templating и observability. Сам operator оставляют тонким: параметры и orchestration, а клиентский протокол выносят в Hook или обычный тестируемый класс. Он должен уважать retries, timeout, cancellation и идемпотентность. Для одного простого вызова TaskFlow-функция или существующий provider обычно дешевле собственного API поддержки. Операцию проектируют идемпотентной и наблюдаемой, чтобы retry или повторный запуск не создавал второй бизнес-эффект.