95 lines
9.2 KiB
Markdown
95 lines
9.2 KiB
Markdown
# Управление временем
|
||
|
||
В этом практическом руководстве вы освоите ключевые аспекты работы со временем в Airflow. Вы узнаете, как правильно настраивать расписания для ваших DAG, понимать внутреннюю логику временных меток и эффективно управлять историческими данными. Поскольку бизнес-процессы часто напрямую зависят от временных параметров запуска, понимание этих механизмов критически важно для любого дата-инженера.
|
||
|
||
# Настройка автоматических запусков
|
||
|
||
Когда вы создаете свой первый пайплайн, вы уже сталкивались с возможностью запускать DAG по расписанию через параметр `schedule_interval`. По умолчанию этот параметр равен `None`, что означает ручной запуск без автоматического расписания. Начиная с Airflow 2.2 (и, конечно, в 2.9) можно использовать более современный алиас `schedule`, который полностью эквивалентен `schedule_interval`; в этом пособии мы продолжаем использовать `schedule_interval`, чтобы сохранить единый стиль примеров.
|
||
|
||
В приведенном примере создается DAG с идентификатором "daily_data_processing", который будет запускаться ежедневно. DAG использует дату начала 1 января 2020 года и параметр catchup=False, что означает, что пропущенные запуски обрабатываться не будут. Владелец DAG - команда data_team, и для задач в DAG установлена одна попытка повторного запуска при ошибках.
|
||
|
||
```python
|
||
dag = DAG(
|
||
dag_id="daily_data_processing",
|
||
schedule_interval="@daily",
|
||
start_date=dt.datetime(2020, 1, 1),
|
||
catchup=False,
|
||
default_args={
|
||
'owner': 'data_team',
|
||
'retries': 1,
|
||
}
|
||
)
|
||
```
|
||
|
||
Важно понимать, что Airflow требует указания даты начала работы (`start_date`) для любого DAG с расписанием. `start_date` задаёт начало первого интервала данных (логическую дату запуска), а фактический старт выполнения происходит после окончания этого интервала. Например, при `@daily` первый запуск с логической датой `2020-01-01` фактически произойдёт около полуночи `2020-01-02` по временной зоне DAG. В продакшен‑практике рекомендуется использовать для `start_date` даты с явной временной зоной (timezone-aware), например на базе библиотеки `pendulum` с таймзоной UTC.
|
||
|
||
## Готовые шаблоны расписания
|
||
|
||
Airflow предоставляет удобные встроенные шаблоны для самых распространенных сценариев:
|
||
|
||
- `@once` — однократный запуск
|
||
- `@hourly` — каждый час
|
||
- `@daily` — ежедневно
|
||
- `@weekly` — еженедельно
|
||
- `@monthly` — ежемесячно
|
||
- `@yearly` — ежегодно
|
||
|
||
Для более сложных сценариев можно использовать стандартный cron-формат, например: `"0 12 * * 1-5"` для запуска в 12:00 по будням.
|
||
|
||
# Работа с историческими данными
|
||
|
||
## Механизм "догонки" (catchup)
|
||
|
||
Когда вы создаете DAG с исторической датой начала, Airflow предлагает мощный механизм автоматического пересчета пропущенных периодов через параметр `catchup`.
|
||
|
||
В этом примере создается DAG с идентификатором "historical_data_processing", который запускается ежедневно и имеет дату начала 1 января 2021 года. Параметр catchup=True означает, что Airflow будет автоматически запускать DAG для всех пропущенных дней с указанной даты начала до текущего момента. Владелец DAG - команда analytics_team, и для задач установлено две попытки повторного запуска при ошибках.
|
||
|
||
```python
|
||
dag = DAG(
|
||
dag_id="historical_data_processing",
|
||
schedule_interval="@daily",
|
||
start_date=dt.datetime(2021, 1, 1),
|
||
catchup=True,
|
||
default_args={
|
||
'owner': 'analytics_team',
|
||
'retries': 2,
|
||
}
|
||
)
|
||
```
|
||
|
||
При `catchup=True` система автоматически выполнит все пропущенные запуски от указанной даты начала до текущего момента. Это особенно полезно при первом запуске DAG для обработки накопившихся исторических данных.
|
||
|
||
По умолчанию для DAG с расписанием параметр `catchup` включен (`True`), поэтому при первом деплое с исторической `start_date` можно неожиданно получить большое количество запусков. Если ваш бизнес-сценарий не требует пересчета истории или вы хотите начать обработку только с текущего периода, установите `catchup=False`. В этом случае Airflow будет планировать только ближайшие запуски согласно расписанию.
|
||
|
||
## Ручная перезаливка данных (backfill)
|
||
|
||
Иногда возникает необходимость пересчитать данные за конкретный период времени. Для этого Airflow предоставляет команду `backfill`:
|
||
|
||
```bash
|
||
airflow dags backfill \
|
||
--start-date 2022-01-01 \
|
||
--end-date 2022-03-01 \
|
||
the_main_dag
|
||
```
|
||
|
||
Эта команда запустит DAG `the_main_dag` для каждого интервала между указанными датами, позволяя гибко управлять перерасчетом исторических данных.
|
||
|
||
# Временные зоны и локализация
|
||
|
||
Важный момент: **все вычисления в Airflow по умолчанию выполняются в UTC** (на 3 часа меньше московского времени). Это стандартная практика для распределенных систем, но требует особого внимания при работе с локальными временными метками.
|
||
|
||
Вы можете:
|
||
- Настроить глобальную временную зону в конфигурационном файле Airflow
|
||
- Указать временную зону для DAG через параметр `timezone` или передать в `start_date` объект с явной таймзоной (например, созданный через `pendulum.datetime(..., tz="UTC")`)
|
||
|
||
Однако рекомендуется придерживаться UTC во всех расчетах и преобразовывать временные метки только при выводе результатов для конечных пользователей. Это минимизирует ошибки и упрощает отладку.
|
||
|
||
# Практические рекомендации
|
||
|
||
1. **Всегда тестируйте расписание** на небольшом временном интервале перед запуском в продакшен
|
||
2. **Используйте `catchup=False`** для DAG, которые не требуют исторических пересчетов
|
||
3. **Планируйте запуски с учетом UTC**, особенно если ваша команда работает в разных часовых поясах
|
||
4. **Документируйте временные зависимости** в коде DAG для других разработчиков
|
||
|
||
Понимание временных механизмов Airflow — ключ к созданию надежных и предсказуемых пайплайнов. Правильная настройка расписаний и управление историческими данными позволяют автоматизировать сложные бизнес-процессы без ручного вмешательства.
|