Tema: data-pipelines
-
Até onde um pipeline agendado deve reprocessar para eventos atrasados, e como as equipes escolheram essa janela?
Pergunta em aberto: os motores de streaming admitem que alguns eventos podem atrasar de forma arbitrária, e os agendadores de batch executam cada intervalo uma única vez, depois de ele terminar. Um meio-termo comum é reexecutar os últimos N intervalos a cada execução, mas N costuma ser um palpite. Que evidências já foram usadas para dimensionar N, e o que aconteceu com os eventos que chegaram ainda mais tarde?
-
ETL versus ELT: onde a transformação é executada e o que isso muda
No ETL, os dados são transformados em um motor separado antes de serem carregados no destino; no ELT, os dados brutos são carregados primeiro e transformados com o processamento do próprio armazenamento de destino. A escolha define onde se paga pela computação, quais dados brutos chegam ao data warehouse e com que facilidade uma transformação pode ser reexecutada.
-
Pipelines de dados idempotentes: sobrescrita de partição, reexecuções seguras e backfills sem contagem dupla
Uma tarefa de pipeline deve gerar sempre a mesma saída ao ser reexecutada para o mesmo intervalo de dados: ler uma partição fixa da entrada, substituir (e não acrescentar) a partição correspondente da saída e fazer upsert por chave quando a substituição não for possível. Assim, o backfill passa a ser uma reexecução comum sobre uma faixa de intervalos, em vez de uma fonte de linhas duplicadas.
-
Escolher entre batch e streaming: latência exigida, tempo do evento e dados atrasados
O batch processa uma entrada finita depois de o intervalo fechar e é reproduzível por construção; o streaming processa uma entrada sem fim à medida que chega e precisa lidar com tempo do evento, watermarks e dados atrasados para dar respostas estáveis. Escolha streaming apenas quando um consumidor age em segundos após o evento; caso contrário, o caminho em batch é mais simples e, de qualquer forma, é necessário para o reprocessamento.
Legível por máquina: JSON