Fermeture intelligente pour les pipelines CDC intégrés
Les pipelines CDC intégrés s'exécutent en mode déclenché. Chaque mise à jour extrait les modifications de la base de données source, les applique aux tables de destination, puis s'arrête. La fermeture intelligente est la règle qui détermine la durée d'exécution d'une mise à jour. Elle donne à chaque mise à jour le temps de traiter les modifications, arrête la mise à jour une fois qu'elle a rattrapé la source et limite la durée d'exécution d'une mise à jour.
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
Databricks configure et ajuste le runtime minimal, le runtime maximal et le threshold de décalage en fonction de l'expérience opérationnelle.
État | Ce que cela signifie |
|---|---|
Runtime minimal | Chaque mise à jour s'exécute pendant une durée minimale avant de pouvoir s'arrêter parce qu'elle a rattrapé la source. |
À jour avec la source | Après le runtime minimal, la mise à jour s'arrête lorsqu'elle a appliqué le backlog de modifications en attente et qu'elle est presque à jour par rapport à la source. Le journal des événements du pipeline enregistre le motif de fin |
Limite d'exécution atteinte | Si la mise à jour ne rattrape pas son retard, elle s'arrête au runtime maximal. La mise à jour suivante reprend là où celle-ci s'est arrêtée. Le journal des événements du pipeline enregistre le motif de fin |
Modification du schéma source | Une modification du schéma source arrête la mise à jour actuelle du pipeline. Le pipeline lance ensuite une nouvelle mise à jour qui utilise le nouveau schéma. |
Comment la fermeture intelligente aide
- Coût inférieur en cas de modifications minimes : après le runtime minimal, une mise à jour se termine lorsqu'elle a rattrapé son retard. Ce comportement permet aux modifications de s'accumuler entre les mises à jour et réduit le coût d'un compute exécuté en continu.
- 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 du volume de données de modification de la source, un grand backlog peut ne pas se terminer 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-la assez fréquemment pour que les mises à jour ultérieures puissent rattraper le retard. Un point de départ de 60 minutes convient à la plupart des charges de travail. Une fois qu’une mise à jour s’arrête, la mise à jour suivante start selon la planification configurée ou après un trigger manuel, selon ce qui se produit en premier. Si un trigger planifié se déclenche alors qu'une mise à jour précédente est toujours en cours d'exécution, Databricks ignore cette mise à jour et utilise l'exécution planifiée suivante.