APRENDER. PRATICAR. EVOLUIR.1. Desenhar o caminho de execução
Num cenário fictício, um sistema de posições mantém a origem SQL na rede privada e entrega dados a um lake. O desenho deve identificar o processo que abre cada ligação, as credenciais e o percurso de rede. Um self-hosted integration runtime pode executar a cópia a partir de uma rede com acesso à origem; esse processo também precisa de alcançar o destino. Colocar o ícone Data Factory numa região não demonstra onde todos os dados serão processados. Desenha origem, runtime, destino e transformações como componentes separados. Para o handover, pede evidência das duas ligações com a identidade operacional, responsáveis pelos hosts e uma execução durante manutenção de um nó. Uma ligação bem-sucedida a partir do portátil do arquiteto não valida o percurso usado à noite pelo serviço.
2. Definir o que constitui uma alteração
A equipa quer reduzir a carga diária e copiar apenas alterações. Primeiro, define o contrato: novas linhas, atualizações, eliminações ou todos estes eventos. Um filtro sobre um marcador crescente pode selecionar linhas alteradas, mas uma linha já eliminada não reaparece nessa consulta. Se o destino tem de refletir eliminações, é necessário um mecanismo que as represente, como change tracking suportado ou registos de eliminação definidos pela aplicação. No exercício fictício, o destino conserva uma posição encerrada e apresenta exposição a mais. O problema não se resolve aumentando a frequência da mesma consulta. Pede ao owner da origem evidência de como cada tipo de alteração chega ao consumidor. Inclui alterações tardias e a precisão do marcador na análise, antes de escolher limites de janela.
3. Avançar o checkpoint depois da aceitação
Um marcador persistente diz até onde o consumidor considera o trabalho concluído. Captura um limite superior estável para a execução e documenta os limites inclusivos ou exclusivos. No tutorial oficial, a atualização do marcador sucede à cópia; no nosso caso fictício acrescentamos reconciliação antes de aceitar a janela. Se o processo falha após escrever dados, mas antes de gravar o checkpoint, a mesma janela poderá ser repetida. Por isso, desenha uma chave de negócio, uma estratégia de substituição ou uma operação idempotente no destino. Um identificador novo de execução ajuda a investigar, mas não identifica por si só a mesma transação de negócio. O exercício Python usa versões inteiras e um único escritor; não simula transações distribuídas, concorrência ou todas as formas de captura de alterações.
4. Separar início, conclusão e aceitação de uma janela
Um calendário responde à pergunta de quando iniciar. O contrato de processamento também precisa de mostrar quais os intervalos concluídos, em falta ou por repetir. Tumbling window triggers mantêm estado por janelas; essa capacidade é útil quando o requisito inclui backfill de períodos. Mesmo assim, o owner deve definir o que a pipeline faz e como o destino resiste a repetições. No cenário fictício, a janela das 22h falha e a das 23h termina. O dashboard deve evidenciar o intervalo em falta em vez de mostrar apenas a execução mais recente. Define dependências entre janelas apenas quando os dados as exigem, pois serialização desnecessária pode atrasar a recuperação. Regista limite inicial, final, estado, versão do contrato e referência de reconciliação para permitir uma decisão de fecho informada.
5. Tratar linhas ignoradas como uma decisão de negócio
A tolerância a falhas pode permitir continuar uma cópia ignorando dados incompatíveis. Num fecho fictício, foram lidas 1 200 linhas, escritas 1 196 e ignoradas quatro. A igualdade entre lidas e escritas mais ignoradas explica a contagem; não prova que o conjunto entregue satisfaz o fecho. O contrato deste exercício exige todas as posições válidas, pelo que o responsável suspende a publicação, identifica as quatro linhas e corrige a causa. Noutro produto, um descarte autorizado pode ser aceitável, desde que tenha critérios e rastreabilidade. Define essas regras antes do incidente. Reconcilia também chaves, totais de controlo e versões quando o resultado depende deles. Contagens iguais podem esconder substituição de uma linha por outra ou um valor monetário incorreto.
6. Evoluir o esquema com um contrato explícito
Uma origem acrescenta uma coluna opcional e, noutra entrega, altera o significado de um montante. São mudanças diferentes. Permitir schema drift ajuda a processar colunas que variam, mas a flexibilidade não decide o significado dos dados. No cenário fictício, a equipa preserva novas colunas na zona de entrada e valida um esquema aprovado antes da publicação curada. A mudança de euros para cêntimos exige uma versão e transformação explícitas, mesmo que o tipo numérico continue compatível. Define tratamento para colunas desconhecidas, ausentes e obrigatórias, bem como para conversões falhadas. Guarda amostras sintéticas de cada contrato para ensaiar o consumidor. Ao rever uma proposta que promete absorver qualquer alteração automaticamente, pede exemplos de mudanças semânticas e critérios de rejeição.
7. Escolher análise e permissões em conjunto
Para explorar ficheiros de um lake com consultas ocasionais, avalia serverless SQL e o volume processado pelas consultas. Para um warehouse com dados carregados e necessidades próprias de distribuição e capacidade, avalia um dedicated SQL pool com medições representativas. O nome SQL não torna os dois serviços equivalentes ao sistema transacional que origina as posições. Em paralelo, verifica como a identidade acede ao lake. Uma concessão RBAC de dados pode tornar irrelevante uma restrição que a equipa julgava impor apenas por ACL. No caso fictício, um analista precisa de uma pasta curada, mas recebe leitura no contentor inteiro. A revisão deve corrigir o âmbito da concessão e ensaiar acessos permitidos e recusados, incluindo dados de entrada que ainda não foram aceites.
8. Aceitar resultados com a semântica temporal correta
Um painel pode agrupar eventos pelo momento em que ocorreram ou pelo momento em que chegaram. A escolha muda o significado do resultado quando há atrasos. Em Stream Analytics, as políticas de eventos tardios e fora de ordem podem descartar ou ajustar tempos; uma maior tolerância também pode aumentar o atraso da saída. No exemplo fictício, uma interrupção de rede entrega uma série de eventos antigos depois do fecho preliminar. O owner deve decidir se publica uma correção, mantém um resultado provisório ou aceita a regra previamente acordada. Define esse comportamento com o consumidor, em vez de alterar tolerâncias apenas para silenciar alertas. Fecha a aula com uma ficha que ligue janela, completude, duplicados, eliminações, esquema, acesso e procedimento de correção a evidências observáveis.
# Fictional single-writer model with unique integer event versions.
# No Azure calls, concurrency or distributed-transaction simulation.
def deliver(events, low, high, target, accepted):
if high < low:
raise ValueError("window moved backwards")
window = [e for e in events if low < e["version"] <= high]
for event in sorted(window, key=lambda e: e["version"]):
key = event["key"]
if event["op"] == "delete":
target.pop(key, None)
elif event["op"] == "set":
target[key] = event["value"]
else:
raise ValueError("unknown operation")
# Rejected work may already have been written: replay must be safe.
return high if accepted else low
events = [
{"version": 11, "key": "P7", "op": "set", "value": 75},
{"version": 12, "key": "P7", "op": "set", "value": 82},
{"version": 13, "key": "P9", "op": "delete"},
]
target = {"P9": 30}
assert deliver(events, 10, 12, target, False) == 10
assert target == {"P9": 30, "P7": 82}
assert deliver(events, 10, 12, target, True) == 12
assert target == {"P9": 30, "P7": 82}
assert deliver(events, 12, 13, target, True) == 13
assert target == {"P7": 82}
assert deliver(events, 13, 13, target, True) == 13
assert target == {"P7": 82}
print("eight fictional checkpoint and replay checks passed")
Caso fictício: a carga de posições termina com quatro linhas ignoradas e a janela anterior está por repetir. O responsável retém a publicação e pede reconciliação antes de avançar o checkpoint.
Armadilhas comuns
Avançar o marcador antes de aceitar a entrega; usar o run ID como chave de negócio; ignorar eliminações; aceitar contagens sem reconciliar valores; assumir que ACL restringe uma concessão RBAC existente.
Tópicos relacionados: Idempotência e recuperação · Contratos de dados · Aceitação operacional
A integração está pronta para operar quando a equipa consegue provar o que entregou, detetar o que falta e repetir o trabalho sem alterar indevidamente o resultado.
Referência: Integration runtime in Azure Data Factory and Synapse · AZ-305 objectives 2026-04-17