---
title: Оркестрация данных
questionDates:
  q-transfer-0300: '2026-10-01'
  q-transfer-0301: '2026-10-01'
  q-transfer-0322: '2026-10-01'
  q-transfer-0323: '2026-10-01'
seo:
  description: >-
    Тема «Оркестрация данных» для собеседования Data Engineer. Когда Airflow DAG
    нужен sensor? Как Airflow исполняет задачи в Kubernetes?
  title: Оркестрация данных — Data Engineer
---

[Все темы Data Engineer](/prep/data-engineer)

## Когда Airflow DAG нужен sensor? [#q-transfer-0300]

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

:::note[Ссылки для изучения]

1. [Сенсоры Airflow 2: ожидание файла или внешней задачи, poke/reschedule и timeout](https://docs.arenadata.io/ru/ADO/current/sensors.html)
   :::

---

## Как Airflow исполняет задачи в Kubernetes? [#q-transfer-0301]

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

:::note[Ссылки для изучения]

1. [Airflow в Kubernetes: KubernetesExecutor, KubernetesPodOperator и хранение логов](https://habr.com/ru/companies/vk/articles/564680/)
   :::

---

## Какие задачи решать через Airflow REST API? [#q-transfer-0322]

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

:::note[Ссылки для изучения]

1. [REST API v1 в Airflow 2: запуск DAG с conf и получение метаданных](https://docs.arenadata.io/ru/ADO/current/airflow-rest-api.html)
   :::

---

## Когда оправдан кастомный Airflow operator? [#q-transfer-0323]

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

:::note[Ссылки для изучения]

1. [Когда расширять Airflow operator: общий запуск задач, метрики и интеграции на примере Купера](https://habr.com/ru/companies/kuper/articles/950988/)
   :::