Fechamento inteligente para pipelines de CDC integrados
Pipelines de CDC integrados realizam execução no modo triggered. Cada atualização extrai alterações do banco de dados de origem, aplica-as às tabelas de destino e então para. Fechamento inteligente é a política que decide quando uma atualização fez trabalho suficiente para parar. Em vez de executar cada atualização por um período fixo de tempo, o fechamento inteligente permite que a duração de cada atualização se adapte à quantidade de dados de alteração que a origem possui.
O fechamento inteligente se aplica a pipelines de CDC integrados (também chamado de CDC direto), que executam o extrator de alterações e o aplicador juntos em um único pipeline acionado, em vez de como componentes separados. Não se aplica à arquitetura padrão baseada em gateway, onde o gateway de ingestão está em execução continuamente. Consulte Criar um pipeline de CDC integrado para SQL Server.
Quando uma atualização para
Uma atualização para quando uma das seguintes condições for atendida:
Condição | Motivo de conclusão | O que significa |
|---|---|---|
Em dia com a origem |
| A atualização aplicou o backlog de alterações pendentes e está quase em sincronia com a origem. Este é o caso comum para atualizações incrementais que têm pouco a processar. |
Limite de tempo de execução atingido |
| A origem tinha um grande backlog (por exemplo, porque o pipeline não foi executado por uma longa duração), então a atualização parou após um tempo de execução limitado. A próxima atualização agendada continua de onde esta parou. |
Como o smart closure ajuda
- Custo mais baixo e atualizações mais rápidas quando há pouca alteração: uma atualização termina assim que é concluída, em vez de ser executada por uma duração fixa, então as atualizações incrementais usam menos tempo de compute.
- Tempo de execução limitado e previsível: um grande backlog não pode fazer com que uma única atualização seja executada indefinidamente. Cada atualização é limitada, e grandes cargas de trabalho são distribuídas pelas atualizações agendadas subsequentes.
- Visibilidade da conclusão: cada atualização registra o motivo pelo qual ela terminou, para que você possa saber se ela alcançou a origem ou parou no limite de tempo de execução.
Verificar a conclusão da atualização
O motivo da conclusão aparece na mensagem do evento COMPLETED no log de eventos do pipeline. Uma atualização que se igualou à origem é concluída com a razão lag-converged, e uma atualização que parou no limite de tempo de execução é concluída com a razão max-runtime-cap-hit.
Para encontrar o motivo da conclusão, consulte o log de eventos do pipeline para o evento COMPLETED do extrator. Substitua <pipeline-id> pelo ID do seu pipeline:
SELECT timestamp, message
FROM event_log('<pipeline-id>')
WHERE message LIKE '%Direct Cdc Extraction has COMPLETED%'
ORDER BY timestamp DESC
A mensagem do evento incorpora o motivo, por exemplo, Direct Cdc Extraction has COMPLETED (reason=lag-converged).
Programar atualizações recorrentes
Como a duração da atualização varia de acordo com a quantidade de dados de alteração que a origem possui, um grande backlog pode não ser concluído em uma única atualização. Para ingerir dados em um agendamento recorrente, crie uma tarefa do Lakeflow Jobs que execute o pipeline. Programe-o com frequência suficiente para que as atualizações subsequentes possam acompanhar. Um ponto de partida de 60 minutos funciona bem para a maioria das cargas de trabalho. Se um gatilho for acionado enquanto uma atualização anterior ainda estiver em execução, o pipeline enfileira a nova atualização.