Pipelines de dados idempotentes: sobrescrita de partição, reexecuções seguras e backfills sem contagem dupla

Objetivo

Tornar cada tarefa agendada segura para rodar duas vezes, de modo que novas tentativas, reexecuções manuais e backfills históricos nunca dupliquem nem percam linhas, e que "reprocessar o mês passado" seja um comando, e não um projeto.

Pré-requisitos

Um agendador que associe um intervalo de dados a cada execução. A documentação do Airflow (citada) define o intervalo como o período de tempo sobre o qual uma execução opera, agenda a execução depois que o intervalo termina, para que todos os dados do período possam ser coletados, e chama de backfill a execução de um Dag para um período histórico especificado. A página de boas práticas afirma que, como as tarefas podem ser repetidas, elas devem produzir o mesmo resultado a cada reexecução; desaconselha o INSERT simples em reexecuções (linhas duplicadas), recomenda UPSERT e orienta ler e gravar em uma partição específica, em vez de usar "os dados mais recentes disponíveis".

Passos

1. Parametrize cada tarefa pelo intervalo (data_interval_start, data_interval_end), nunca por "agora". A seleção da entrada filtra pelo intervalo, de modo que uma reexecução vê a mesma entrada, a menos que a própria fonte tenha mudado.
2. Grave a saída como substituição da fatia do intervalo: delete seguido de insert dentro de uma única transação em um destino relacional, ou sobrescrita de partição em um destino baseado em arquivos. O INSERT OVERWRITE do Spark com partitionOverwriteMode=dynamic sobrescreve apenas as partições que recebem dados na execução (citado); no modo estático, ele antes apaga todas as partições que correspondem à especificação de partição.
3. Onde a substituição for impossível (tabelas de eventos compartilhadas com outros escritores), faça upsert por uma chave determinística derivada do registro, por exemplo o identificador de origem mais o intervalo, para que a reexecução atualize em vez de acrescentar.
4. Faça os agregados a jusante serem recalculados a partir da fatia substituída, em vez de somar deltas; um agregado que soma incrementos contará duas vezes uma partição reprocessada no backfill.
5. Em um backfill, execute os intervalos em ordem, com concorrência limitada, e após cada intervalo compare a contagem de linhas e um checksum das colunas-chave com a versão anterior daquela partição; registre a diferença em log.
6. Reexecute as tarefas dependentes para os mesmos intervalos; fazer o backfill de uma tabela sem seus consumidores deixa o data warehouse internamente inconsistente.

Resultado esperado

Reexecutar qualquer intervalo deixa a saída idêntica à de uma única execução limpa. Fazer o backfill de uma faixa de intervalos produz as mesmas tabelas que teriam resultado se o código corrigido tivesse rodado no agendamento original.

Limites e base de verificação

Fontes que sobrescrevem o histórico (tabelas operacionais mutáveis) quebram o determinismo do intervalo; tire um snapshot por intervalo ou use change data capture. Um backfill que atravessa uma mudança de esquema exige o novo esquema para todos os intervalos. O método é um protocolo derivado da documentação citada; não se afirma nenhuma medição do seu efeito.