Fermeture intelligente pour les pipelines CDC intégrés
Les pipelines CDC intégrés s'exécutent en mode Trigger. Chaque mise à jour extrait les modifications de la base de données source, les applique aux tables de destination, puis s'arrête. La clôture intelligente est la politique qui détermine quand une mise à jour a accompli suffisamment de travail pour s'arrêter. Au lieu d'exécuter chaque mise à jour pendant une durée fixe, la clôture intelligente permet à la durée de chaque mise à jour de s'adapter à la quantité de données de modification que la source possède.
La fermeture intelligente s'applique aux pipelines CDC intégrés (également appelés CDC directs), qui exécutent l'extracteur de changements et l'applicateur ensemble dans un seul pipeline Trigger plutôt que comme des composants séparés. Cela ne s'applique pas à l'architecture standard basée sur une passerelle, où la passerelle d'ingestion fonctionne en continu. Consultez Créer un pipeline CDC intégré pour SQL Server.
Lorsqu'une mise à jour s'arrête
Une mise à jour s'arrête lorsque l'une des conditions suivantes est remplie :
État | Motif de l'achèvement | Ce que cela signifie |
|---|---|---|
À jour avec la source |
| La mise à jour a appliqué le backlog des modifications en attente et est proche d'être à jour avec la source. C'est le cas courant pour les mises à jour incrémentielles qui ont peu de choses à traiter. |
Limite d'exécution atteinte |
| La source avait un backlog important (par exemple, parce que le pipeline n'a pas été exécuté pendant une longue durée), l'actualisation s'est donc arrêtée après une durée d'exécution limitée. La prochaine mise à jour planifiée reprend là où celle-ci s'est arrêtée. |
Comment la fermeture intelligente aide
- Coût inférieur et mises à jour plus rapides en cas de changements minimes : une mise à jour se termine dès qu'elle est à jour au lieu de s'exécuter pendant une durée fixe, de sorte que les mises à jour incrémentielles utilisent moins de compute.
- Runtime limité et prévisible : Un important arriéré ne peut pas faire en sorte qu’une seule mise à jour s’exécute indéfiniment. Chaque mise à jour est plafonnée, et les charges de travail importantes sont réparties sur les mises à jour planifiées suivantes.
- Visibilité de l'achèvement : Chaque mise à jour enregistre la raison de sa fin, vous pouvez ainsi savoir si elle a rattrapé la source ou s'est arrêtée à la limite d'exécution.
Constater l'achèvement de la mise à jour
La raison de l'achèvement apparaît dans le message de l'événement COMPLETED du log des événements du pipeline. Une mise à jour qui a rattrapé la source se termine avec la raison lag-converged, et une mise à jour qui s'est arrêtée à la limite du Runtime se termine avec la raison max-runtime-cap-hit.
Pour trouver la raison de la fin, query le log d'événements du pipeline pour l'événement COMPLETED de l'extracteur. Remplacez <pipeline-id> par l'ID de votre pipeline :
SELECT timestamp, message
FROM event_log('<pipeline-id>')
WHERE message LIKE '%Direct Cdc Extraction has COMPLETED%'
ORDER BY timestamp DESC
Le message d'événement intègre la raison, par exemple : Direct Cdc Extraction has COMPLETED (reason=lag-converged).
Planifier les mises à jour récurrentes
Étant donné que la durée de la mise à jour varie en fonction de la quantité de données modifiées que la source contient, un important arriéré pourrait ne pas être traité en une seule mise à jour. Pour ingérer des données selon un calendrier récurrent, créez une tâche Lakeflow Jobs qui exécute le pipeline. Planifiez-le assez fréquemment pour que les mises à jour suivantes soient effectuées. Un point de départ de 60 minutes convient bien à la plupart des charges de travail. Si un trigger se déclenche alors qu'une mise à jour précédente est toujours en cours d'exécution, le pipeline met la nouvelle mise à jour en file d'attente.