Entendendo os Modos de Sensor do Airflow: Poke vs Reschedule

Um mergulho profundo na escolha do modo de sensor certo para seus pipelines do Apache Airflow.

Índice

  1. O que são Sensores no Airflow?
  2. Os Dois Modos de Sensor
  3. Modo Poke (Padrão)
    1. Quando usar Poke?
  4. Modo Reschedule
    1. Quando usar Reschedule?
  5. Comparação Detalhada
  6. Exemplo Prático: Pipeline de Dados Diário
  7. Regra de Ouro
  8. Referências

O que são Sensores no Airflow?

Sensores são um tipo especial de operador do Airflow que aguardam uma condição específica ser atendida antes de permitir a execução de tarefas posteriores (downstream). Pense neles como porteiros em seu pipeline de dados — eles verificam continuamente se algo está pronto antes de dar o sinal verde.

Casos de uso comuns incluem:

  • Aguardar um arquivo aparecer em um diretório ou bucket S3
  • Verificar se uma tabela de banco de dados tem novos registros
  • Esperar por uma API retornar um status de sucesso
  • Monitorar a conclusão de um job externo

Os Dois Modos de Sensor

Todos os sensores do Airflow têm um parâmetro mode que controla como eles aguardam. Há dois valores possíveis:

Modo Comportamento Uso de Worker Uso de Slot
poke Executa em loop contínuo Ocupa 1 worker continuamente Ocupa 1 slot continuamente
reschedule Libera o worker entre verificações Libera o worker entre checks Libera o slot entre checks

Modo Poke (Padrão)

No modo poke, o sensor ocupa um worker slot durante toda a sua execução. Ele acorda periodicamente (controlado pelo parâmetro poke_interval), verifica a condição, e se não for atendida, dorme mas continua ocupando o slot.

1
2
3
4
5
6
7
8
9
10

from airflow.sensors.filesystem import FileSensor

wait_for_file = FileSensor(
    task_id="wait_for_file",
    filepath="/data/input/daily_report.csv",
    mode="poke",              # padrão — pode ser omitido
    poke_interval=60,         # verifica a cada 60 segundos
    timeout=3600,             # falha após 1 hora
    dag=dag,
)

Quando usar Poke?

Use poke quando a espera for curta (segundos a poucos minutos) e você tem worker slots disponíveis.

Vantagens:

  • Mais simples de raciocinar
  • Menor overhead de estado (sem persistência entre verificações)
  • Reação mais rápida (sem atraso de reagendamento)

Desvantagens:

  • Consome um worker slot durante toda a espera
  • Em ambientes com poucos workers, pode causar starvation — outros tasks ficam bloqueados

Modo Reschedule

No modo reschedule, o sensor libera o worker slot após cada verificação malsucedida. O Airflow agenda o sensor novamente somente quando o poke_interval termina, liberando recursos para outras tarefas enquanto espera.

1
2
3
4
5
6
7
8
9
10
11

from airflow.sensors.s3_key_sensor import S3KeySensor

wait_for_s3_file = S3KeySensor(
    task_id="wait_for_s3_upload",
    bucket_name="meu-bucket-dados",
    bucket_key="data//arquivo.parquet",
    mode="reschedule",        # libera o worker entre verificações
    poke_interval=300,        # verifica a cada 5 minutos
    timeout=86400,            # falha após 24 horas
    dag=dag,
)

Quando usar Reschedule?

Use reschedule quando a espera for longa (horas ou mais) ou quando você tem muitos sensores rodando simultaneamente.

Vantagens:

  • Não bloqueia worker slots durante a espera
  • Permite escalar para centenas de sensores simultâneos
  • Ideal para esperas longas e indeterminadas

Desvantagens:

  • Overhead adicional de persistência de estado
  • Latência ligeiramente maior (mínimo é o poke_interval)
  • Mais complexo internamente

Comparação Detalhada 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

POKE MODE:
─────────────────────────────────────────────────────────
 t=0      t=60s     t=120s    t=180s    t=240s (sucesso)
  │         │         │         │         │
  ▼         ▼         ▼         ▼         ▼
 [CHECK]──sleep──[CHECK]──sleep──[CHECK]──sleep──[CHECK→OK]
  Worker OCUPADO o tempo todo

RESCHEDULE MODE:
─────────────────────────────────────────────────────────
 t=0      t=60s     t=120s    t=180s    t=240s (sucesso)
  │         │         │         │         │
  ▼         ▼         ▼         ▼         ▼
 [CHECK]  [CHECK]  [CHECK]  [CHECK]  [CHECK→OK]
  │  ▲     │  ▲     │  ▲     │  ▲
  ▼  │     ▼  │     ▼  │     ▼  │
 FREE   FREE   FREE   FREE
  Worker LIVRE entre verificações

Exemplo Prático: Pipeline de Dados Diário

Imagine um pipeline que aguarda um arquivo de dados chegar de um sistema externo:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

from datetime import datetime, timedelta
from airflow import DAG
from airflow.sensors.s3_key_sensor import S3KeySensor
from airflow.operators.python import PythonOperator

default_args = {
    "owner": "bpstrat",
    "retries": 1,
    "retry_delay": timedelta(minutes=5),
}

with DAG(
    dag_id="pipeline_dados_diario",
    default_args=default_args,
    schedule_interval="@daily",
    start_date=datetime(2024, 1, 1),
    catchup=False,
) as dag:

    # Use reschedule: pode esperar horas, não queremos bloquear workers
    aguardar_arquivo = S3KeySensor(
        task_id="aguardar_arquivo_s3",
        bucket_name="dados-producao",
        bucket_key="raw//vendas.parquet",
        mode="reschedule",
        poke_interval=600,   # verifica a cada 10 minutos
        timeout=43200,       # timeout de 12 horas
    )

    processar_dados = PythonOperator(
        task_id="processar_dados",
        python_callable=lambda: print("Processando dados..."),
    )

    aguardar_arquivo >> processar_dados

Regra de Ouro

Nunca use poke para esperas longas em produção. Se você tem 10 sensores esperando por horas em modo poke e apenas 8 workers, 4 tarefas ficam bloqueadas para sempre — um deadlock clássico do Airflow.

Cenário Modo Recomendado
Espera < 5 minutos poke
Espera de 5–30 minutos Qualquer um
Espera > 30 minutos reschedule
Muitos sensores simultâneos reschedule
Ambiente com poucos workers reschedule
Monitoramento em tempo real poke com poke_interval baixo

Referências

© BP STRAT. Todos os direitos reservados. readme