O que Depuração de Pipelines de Dados faz?
Quando usar
- Um job de pipeline falhou ou os dados de saída estão incorretos/ausentes/duplicados.
- Um painel está desatualizado ou uma métrica não reconcilia com a origem.
- Uma parte interessada relata uma discrepância e você deve encontrar a causa.
- NÃO use para erros de execução específicos de ferramenta já cobertos por
debugging-dbt-runs/debugging-airflow-pipelines(comece por lá, depois use esta skill para incidentes de correção de dados).
Fluxo de trabalho
- [ ] Defina o sintoma precisamente (qual tabela, coluna, linhas, janela de tempo)
- [ ] Rastreie a linhagem upstream para encontrar o primeiro estágio onde os dados estão incorretos
- [ ] Isole: é um bug de código, entrada ruim, dados atrasados ou uma falha de execução?
- [ ] Reconcilie o estágio suspeito contra sua origem (contagens/somas)
- [ ] Corrija a causa raiz, depois planeje um backfill idempotente das janelas afetadas
- [ ] Adicione uma verificação para que não possa ocorrer silenciosamente novamente
- Identifique o sintoma. "A receita para 2026-01-15 está ~30% baixa em
fct_orders" é depurável; "os números parecem estranhos" não é. Obtenha a tabela, coluna, linhas e a janela. - Rastreie a linhagem upstream. Caminhe da saída incorreta de volta pelos modelos/tarefas para encontrar o primeiro estágio onde os dados já estão errados. Faça uma busca binária no DAG em vez de ler cada estágio.
- Classifique a causa: alteração de código, dados de origem ruins/atrasados, uma execução com falha/parcial ou uma duplicata não idempotente.
- Reconcilie o estágio suspeito vs sua entrada (contagens de linhas, contagens de chaves, somas) para confirmar onde o delta aparece.
- Corrija + faça backfill das janelas afetadas idempotentemente (veja
designing-backfills-and-replays). - Evite recorrência com uma verificação de qualidade de dados direcionada.
Padrões
Busca binária de linhagem — verifique um estágio na metade do caminho para cima do DAG: se seus dados estiverem corretos, o bug está downstream; se estiverem errados, suba mais. Repita.
Reconcilie origem vs destino para a janela afetada:
-- As contagens/somas correspondem entre o estágio e sua entrada para a janela incorreta?
SELECT 'origem' AS camada, COUNT(*) n, SUM(amount) total
FROM staging.orders WHERE order_date = DATE '2026-01-15'
UNION ALL
SELECT 'destino', COUNT(*), SUM(amount)
FROM marts.fct_orders WHERE order_date = DATE '2026-01-15';
Uma lacuna na contagem → linhas descartadas/filtradas ou uma carga parcial com falha. Uma lacuna na soma com contagens iguais → um bug de transformação/lógica. Contagem de destino maior → duplicação (carga não idempotente).
Verificação de linha do tempo — correlacione a janela do incidente com deploys, alterações de esquema de origem e histórico de execuções; a maioria dos incidentes começa com uma alteração.
Armadilhas comuns
- Corrigir sintomas downstream — corrigir o mart quando o bug está no staging faz com que ele se repita; corrija o primeiro estágio incorreto.
- Correções manuais pontuais em dados de produção — não auditáveis e não repetíveis; corrija o código e execute novamente de forma idempotente.
- Ler o DAG inteiro linearmente — em vez disso, faça busca binária de linhagem.
- Pular a reconciliação — adivinhar onde os dados divergiram perde tempo; meça contagens/somas por estágio.
- Nenhuma verificação preventiva após a correção — a mesma classe de bug retorna despercebida.