DevOps

Orquestração de pipelines

Sabatina de engenharia de dados quase sempre entra em falha e reprocessamento, porque é lá que o candidato mostra se já operou pipeline em produção. Quem só sabe desenhar o fluxo feliz trava na primeira pergunta sobre retry duplicando lançamento.

Como cai: Seu pipeline diário falhou às 3h e rodou de novo às 6h. O que precisa ser verdade para isso não duplicar dados?

Erros comuns

• ×Colocar o processamento pesado dentro da task do Airflow. O orquestrador vira gargalo e ponto único de falha; o certo é ele disparar o job no Databricks ou no EMR e acompanhar o estado.
• ×Encadear pipelines por horário em vez de por sinal. Se o upstream atrasa 20 minutos, o downstream lê dado incompleto e ninguém percebe até o relatório sair errado.
• ×Escrever task não idempotente. Qualquer retry, backfill ou clique em rerun duplica dado, e retry é justamente o que o orquestrador faz sozinho de madrugada.
• ×Configurar retry infinito ou sem backoff. Se a origem caiu, martelar a cada 30 segundos derruba de vez e ainda esconde o incidente atrás de uma task que fica amarela para sempre.
• ×Tratar SLA como enfeite. Sem prazo declarado, o pipeline que travou às 2h só é descoberto às 9h pelo usuário do relatório, e aí o custo já é reputacional.
• ×Confundir data lógica da execução com a hora do relógio. Se a task usa current_date em vez da data da janela, o backfill de ontem grava tudo com a data de hoje.

Vocabulário

idempotência

— Rodar a mesma task sobre a mesma janela uma ou várias vezes deixa o destino no mesmo estado final.

DataOps e observabilidade

Todo candidato sabe construir um pipeline. A banca quer saber o que acontece quando ele quebra em silêncio, que é o modo de falha mais caro em banco. Este tema separa quem entrega job de quem entrega dado confiável.

Como cai: Como você descobre que um pipeline entregou dado errado antes do usuário descobrir?

Erros comuns

• ×Confundir monitoramento de job com observabilidade de dado. Job verde e dado errado é o cenário mais comum: o pipeline rodou, só entregou lixo.
• ×Testar só na camada final. Quando o erro aparece na gold, a causa já está três camadas atrás e o reprocessamento é caro.
• ×Alertar em tudo. Alerta que dispara toda semana e ninguém investiga é ruído: treina o time a ignorar, incluindo o alerta que importava.
• ×Achar que contrato de dados é documentação. Contrato é acordo com esquema, semântica, prazo e consequência declarada quando alguém quebra.
• ×Reprocessar com append. Rodar o mesmo dia duas vezes e duplicar transação é o defeito mais visível de pipeline não idempotente.
• ×Deixar CI/CD de fora porque 'não dá para testar sem dado de produção'. Dá: esquema, transformação em amostra sintética e contrato são testáveis sem tocar em PII.
• ×Tratar linhagem como diagrama bonito. Linhagem é o que responde, às três da manhã, quais dashboards param se esta tabela estiver errada.

Vocabulário

linhagem

— Registro de origem e destino de cada tabela e coluna ao longo do pipeline.

Ambientes e infraestrutura como código

É a pergunta que separa quem opera de quem só entrega consulta. A banca pergunta como você garante que o ambiente de teste representa a produção, e a resposta boa fala de dado mascarado, de mesma definição de infraestrutura e de plano revisado antes de aplicar, não de 'a gente copia'.

Como cai: Como você garante que o que funcionou em homologação vai funcionar em produção?

Erros comuns

• ×Achar que ambientes se distinguem pelo volume de dados. Distinguem-se por quem consome: produção tem consumidor real, homologação tem validação, desenvolvimento tem quem está construindo.
• ×Copiar produção para desenvolvimento sem mascarar. É o vazamento mais comum em times de dados, e passa despercebido porque parece diligência.
• ×Tratar infraestrutura como código como 'script de criação'. O que a distingue é ser declarativa e ter estado: ela sabe o que já existe e calcula a diferença.
• ×Aplicar sem revisar o plano. O plano mostra o que será criado, alterado e destruído; aplicar sem ler é como aprovar um merge sem ver o diff.
• ×Guardar segredo no repositório. Credencial vai para um cofre e entra por referência; repositório é histórico permanente, e apagar depois não apaga o histórico.
• ×Ter definições diferentes por ambiente. Se produção e homologação são descritas por códigos distintos, homologação deixa de provar qualquer coisa.

Vocabulário

declaratividade

— Descrever o estado desejado, não os passos. Aplicar duas vezes dá o mesmo resultado, porque a ferramenta calcula a diferença em vez de repetir comandos.

estado

— Registro do que a ferramenta já criou. É o que permite calcular a diferença e produzir um plano. Fica remoto, versionado e com bloqueio, para duas execuções não se atropelarem.

deriva de configuração

— Diferença entre o que o código declara e o que existe de fato, criada quando alguém ajusta um recurso pelo console.

CI/CD para dados e dashboards

Na sabatina de Analytics a pergunta chega assim: 'como você garante que uma mudança no modelo não derruba o painel da diretoria?'. Quem responde 'testo antes' perde; quem descreve o que roda no pipeline de verificação, em que ambiente, e o que acontece quando falha, mostra que já quebrou produção antes.

Como cai: Você mudou um modelo que alimenta três dashboards. Como essa mudança chega à produção?

Erros comuns

• ×Achar que CI para dados é só rodar o pipeline. A verificação útil roda em ambiente isolado, com dado de amostra, e falha antes de tocar em produção.
• ×Testar só o código e não o dado. Transformação correta sobre dado que mudou de formato continua quebrando o relatório; teste de dado é parte do pipeline.
• ×Promover mudança direto em produção porque 'é só um SQL'. Modelo que alimenta painel é produção, com consumidor e horário crítico.
• ×Esquecer o dashboard no fluxo. Renomear uma coluna passa no teste do modelo e quebra o painel que referenciava o nome antigo.
• ×Não ter caminho de volta. Sem versionamento do modelo e sem capacidade de reprocessar, o rollback vira restauração de backup no meio do expediente.
• ×Tratar ambiente de desenvolvimento com dado de produção sem mascaramento. Cópia de produção para desenvolver é o vazamento mais comum em times de dados.