Des pipelines que l’on peut relancer sans risque
À retenir : Un pipeline est prêt pour un usage récurrent lorsque les relances, les données tardives et les chargements interrompus ont un résultat défini. La première exécution réussie n’est qu’un début.
Préciser ce que représente une ligne
Supposons qu’un pipeline quotidien rapproche des exports de commandes et des paiements pour un tableau de bord opérationnel. Avant de choisir un orchestrateur, définissez la granularité de sortie : une ligne par commande, ligne de commande ou paiement ? Ce choix détermine les jointures et agrégations valides.
Documentez la clé métier, la convention temporelle, la devise, les champs facultatifs et le traitement des annulations. Si deux systèmes donnent des sens différents à « terminé », conservez ces distinctions jusqu’à ce que la règle de rapprochement soit explicite. Une jointure techniquement correcte peut sinon produire un chiffre trompeur.
Prévoir les relances dès la conception
Apache Airflow recommande de traiter les tâches comme des transactions et d’obtenir le même résultat lors d’une relance. Dans ce pipeline de commandes, ajouter directement chaque fichier à la table finale permettrait à une relance de doubler les ventes de la veille. Apache Airflow : bonnes pratiques
Une approche pratique consiste à charger dans une zone intermédiaire, valider le lot, puis effectuer une fusion sur une clé stable ou remplacer la partition visée. Le choix dépend de la source et de la base. Conservez l’identifiant du lot pour retrouver les enregistrements que chaque exécution devait traiter.
Contrôler les données, pas seulement le code de retour
Un export vide peut être normal un jour calme et signaler un incident un jour chargé. Associez des contrôles structurels, comme l’unicité des clés et les colonnes attendues, à des contrôles métier : fraîcheur, volumes plausibles et rapprochement avec les totaux sources. Définissez les tolérances avec les personnes qui connaissent le processus.
Déterminez quelles erreurs doivent bloquer la publication et lesquelles justifient une mise à l’écart des lignes concernées. Conservez si nécessaire le dernier jeu exploitable, en indiquant clairement son ancienneté. Un tableau de bord ne doit pas présenter discrètement des données périmées comme si l’actualisation avait réussi.
Tester la reprise avant l’incident
Sur un petit lot, simulez quatre situations : un fichier reçu deux fois, une modification tardive de commande, une interruption après le chargement intermédiaire et une colonne source renommée. Vérifiez les lignes finales et le journal d’exécution. La reprise doit être observable, pas simplement déduite d’un voyant vert.
La documentation doit désigner un responsable, expliquer comment rejouer une période précise et identifier les rapports en aval potentiellement affectés. Un pipeline modeste avec une procédure de reprise claire peut être plus facile à exploiter qu’un système élaboré dont chaque panne exige l’intervention de son auteur.