02. Monitoramento de transformações e Dataflow Gen2

Uma consulta funciona na prévia, mas falha ao atualizar todo o conjunto. A prévia ajuda a desenvolver; o histórico e os logs da atualização mostram o que aconteceu com os dados reais. Monitorar Dataflow Gen2 exige distinguir extração, transformação, staging e escrita no destino.

Prévia e atualização completa

A prévia examina um subconjunto e não garante que todas as linhas sejam compatíveis com conversões e regras. Um valor inválido pode surgir somente em uma partição posterior. Registre a consulta, o passo e o contexto do erro para reproduzir o problema com dados representativos.

Quando o Dataflow é chamado por um pipeline, o erro externo pode ser resumido. Abra o histórico da atualização do próprio Dataflow e relacione os identificadores. O orquestrador informa onde a chamada falhou; os logs do mecanismo ajudam a localizar a operação responsável.

Um campo pode parecer numérico na prévia e conter o texto indisponível em uma linha posterior. O erro de atualização não contradiz o sucesso da prévia; os conjuntos observados são diferentes. Reproduza com o valor real e identifique o passo em que o contrato deixa de ser atendido. Se a solução usa conversão tolerante, acompanhe os nulos ou rejeições resultantes. A mudança deve tornar o tratamento explícito, e não apenas fazer o refresh terminar sem expor o que foi perdido.

Origem do refresh e limites de taxa

Uma publicação pode ser seguida por uma atualização conforme o fluxo da experiência. Correlacione o evento com o histórico antes de atribuir todo refresh a uma agenda. Proteções de taxa também coexistem com limites acumulados: muitas chamadas em segundos podem sofrer throttling mesmo quando o total da janela ainda está abaixo do teto. Distribua solicitações e consulte os limites vigentes. Repetir imediatamente cada rejeição pode concentrar ainda mais a pressão.

Logs e decomposição de fases