Fechamento inteligente para pipelines de CDC integrados
Pipelines CDC integrados são executados no modo Trigger. Cada atualização extrai alterações do banco de dados de origem, aplica-as às tabelas de destino e, em seguida, é interrompida. Smart closure é a política que determina quanto tempo uma execução dura. Isso dá a cada execução tempo para processar alterações, interrompe a execução após ela alcançar a origem e limita o tempo de execução de uma atualização.
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
O Databricks configura e ajusta o runtime mínimo, o runtime máximo e o limite de atraso com base na experiência operacional.
Condição | O que significa |
|---|---|
Runtime mínimo | Each update runs for a minimum amount of time before it can stop because it has caught up with the source. |
Em dia com a origem | Após o runtime mínimo, a atualização é interrompida quando o backlog de alterações pendentes é aplicado e está próximo de se equiparar à fonte. O log de eventos do pipeline registra o motivo da conclusão |
Limite de tempo de execução atingido | Se a atualização não acompanhar, ela para no runtime máximo. A próxima atualização é retomada de onde esta parou. O log de eventos do pipeline registra o motivo da conclusão |
Alteração de esquema de origem | Uma alteração no esquema de origem interrompe a atualização atual do pipeline. O pipeline então começa uma nova atualização que usa o novo esquema. |
Como o smart closure ajuda
- Custo menor quando há pouca alteração: Após o runtime mínimo, uma atualização termina quando atinge o estado mais recente. Esse comportamento permite que as alterações se acumulem entre as atualizações e reduz o custo de execução contínua do 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
Because update duração varies with how much change data the source has, a large backlog might not finish in a single update. Para ingerir dados em uma programação recorrente, crie uma Lakeflow Jobs tarefa que executa o pipeline. Programe-o com frequência suficiente para que as atualizações subsequentes o alcancem. A starting point of 60 minutes works well for most workloads. After an update stops, the next update começa at the configured programar or after a manual Trigger, whichever occurs first. If a scheduled Trigger fires while a previous update is still running, Databricks skips that update and uses the following scheduled execução.