Que signifie qu'un pipeline soit idempotent, et comment en construisez-vous un ?

Un pipeline idempotent produit le même résultat que vous le lanciez une fois ou cinq fois sur la même fenêtre d'entrée. Construisez-le en faisant en sorte que chaque exécution possède une tranche de données déterministe, puis en remplaçant cette tranche au lieu d'y ajouter. Utilisez l'écrasement de partition ou un merge sur une clé stable, dérivez la fenêtre de l'intervalle planifié plutôt que de l'horloge, et évitez les effets de bord non rejouables.

Cela veut dire que je peux relancer le job d'hier maintenant et obtenir exactement la même table que s'il s'était exécuté proprement une seule fois. Le motif que j'utilise : chaque exécution possède une partition, et l'écriture remplace cette partition au lieu d'y ajouter. Donc le job du 2026-08-25 supprime et réécrit la partition de cette date, ou merge sur une clé unique, et le lancer quatre fois ne change rien après la première. Le détail qui piège les gens, c'est le temps. Si votre job filtre sur maintenant moins un jour, alors une relance trois jours plus tard traite la mauvaise fenêtre : l'intervalle doit venir de l'intervalle de données de l'orchestrateur, pas de l'horloge à l'intérieur de la tâche. Je surveille aussi les effets de bord, parce que nous avions un pipeline qui envoyait un e-mail de synthèse à la fin, et une reprise a fait que la finance a reçu deux fois le même rapport. Nous avons déplacé la notification dans une tâche séparée, avec sa propre clé de déduplication. Une fois que tout est idempotent, rejouer l'historique revient simplement à exécuter une plage de dates.