Par Andrew Tan
La pile d'orchestration typique d'une équipe de données évolue par étapes raisonnables. Vous commencez avec Airflow. Ça va. L'équipe le connaît. Les DAGs s'exécutent selon le calendrier. Cinq ans plus tard, Airflow exécute 300 DAGs et tout le monde a peur de toucher à l'image de base.
Ensuite, vous avez besoin de quelque chose de moderne. Une nouvelle recrue propose Prefect — c'est natif à Python, l'expérience développeur est meilleure, et l'UI est plus propre. Vous commencez donc de nouveaux projets dans Prefect et laissez les anciens dans Airflow.
Puis une équipe de ML arrive. Ils veulent Dagster parce que la pensée centrée sur les Assets et le suivi de la lignée correspondent à leur travail sur le magasin de fonctionnalités. Raisonnable. Vous ajoutez Dagster.
Personne n'a pris une mauvaise décision. Chaque outil était le bon choix dans le contexte. Mais l'équipe paie maintenant pour trois planificateurs, trois ensembles de travailleurs, trois tableaux de bord de surveillance, et trois modèles mentaux. Lorsque les données passent d'Airflow à Dagster avant d'aller à un appel d'API orchestré par Prefect, la lignée se brise. Vous pouvez voir chaque étape isolément. Vous ne pouvez pas voir toute la chaîne.
C'est la taxe d'orchestration. Et elle est presque universelle dans les entreprises qui construisent une infrastructure de données depuis plus de deux ans.
Comment la taxe se manifeste
La facture cachée apparaît dans trois endroits que la plupart des équipes ne mesurent pas.
La couture de coordination. Quand le Pipeline A (Airflow) doit déclencher le Pipeline B (Dagster), comment fait-il ? Habituellement : un dépôt de fichier, un indicateur de base de données, un appel d'API, ou — le plus courant — un message Slack entre les humains qui possèdent chaque système. Cette "intégration" est maintenant porteuse de charge. Lorsqu'elle se casse, elle échoue silencieusement. Vous le découvrez trois heures plus tard lorsque le pipeline Dagster s'est exécuté sur les données d'hier.
Certaines équipes finissent par avoir un ingénieur entier dédié à maintenir ce qu'elles appellent en interne "la couche de colle". C'est un rôle à plein temps écrivant des scripts Python pour faire semblant que trois outils d'orchestration ne font qu'un.
Le labyrinthe de débogage. Un problème de qualité des données apparaît dans l'outil BI. Le chiffre est faux. Où cela a-t-il mal tourné ? Vous commencez par les journaux Airflow. Le DAG a réussi. Vous vérifiez Prefect — le flux d'événements a réussi. Vous vérifiez Dagster — les Assets se sont matérialisés. Quelque part dans le transfert entre les systèmes, quelque chose a mal tourné, et il n'y a pas de vue unifiée de ce qui s'est passé.
Le MTTR (temps moyen de résolution) pour les échecs inter-systèmes est constamment 3 à 5 fois plus élevé que pour les échecs d'un seul système dans les équipes qui suivent cela. Le coût de débogage est le plus grand élément caché.
Le péage du changement de contexte. Le planificateur d'Airflow pense en expressions cron et dépendances de tâches. Dagster pense en Assets et politiques de fraîcheur. Prefect pense en flux et déploiements. Chacun a son propre modèle d'authentification, sa propre gestion des secrets, sa propre façon de gérer les reprises. Les ingénieurs deviennent compétents dans les trois — ce qui signifie qu'ils ne sont experts dans aucun d'eux, et chaque transition d'outil coûte une surcharge cognitive qui n'apparaît dans aucun suivi de sprint.
La situation Kestra
C'est pourquoi le marketing de Kestra résonne. Leur argument — "vous pouvez exécuter Airflow, Spark, dbt, et des scripts personnalisés, le tout à partir d'un seul orchestrateur" — répond directement à la frustration multi-outils.
Mais il y a une différence entre un tableau de bord unique et une source unique de vérité. Kestra peut envelopper vos outils existants. C'est utile. Cela ne réduit pas réellement le problème de coordination distribuée. Vous avez ajouté un autre outil au-dessus de trois outils.
La prolifération de l'orchestration n'est pas un problème d'UI. C'est un problème de propriété du flux de données. Qui possède l'événement qui déclenche la chaîne ? Qui possède le schéma des données passant entre les systèmes ? Qui est responsable lorsque le transfert entre l'étape 2 et l'étape 3 échoue ?
Une nouvelle couche d'orchestration au sommet ne répond pas à ces questions. Elle ajoute simplement un système de plus à examiner lorsque vous déboguez à 2 heures du matin.
Ce qui aide réellement
Soyons directs sur ce qui fonctionne par rapport à ce qui ne fait que déplacer le problème.
Fonctionne : se concentrer sur un modèle unique, de manière agressive. Choisissez l'outil qui gère bien 80 % de votre charge de travail actuelle, migrez tout ce que vous pouvez, et vivez avec la friction de déplacer les tâches héritées. C'est douloureux pendant six mois. Après cela, vous avez un modèle de planification, un ensemble de travailleurs, un endroit où regarder lorsque les choses échouent. Les équipes qui font cela rapportent systématiquement une réduction de 40 à 60 % du temps de réponse aux incidents en un an.
Fonctionne : traiter les transferts inter-systèmes comme des données de première classe. Si vous devez exécuter plusieurs outils pour des raisons légitimes (par exemple, les pipelines ML bénéficient réellement du modèle d'Assets de Dagster), faites de chaque transfert un transfert de données explicite et surveillé. Pas un dépôt de fichier. Pas un indicateur de base de données que quelqu'un a ajouté à une table il y a quatre ans. Un schéma défini, avec observabilité, avec reprises, avec alertes. La colle devient partie de la conception de votre système plutôt qu'un accident de celle-ci.
Ne fonctionne pas : ajouter de l'observabilité au-dessus de la fragmentation. Un autre tableau de bord montrant le statut des trois systèmes ne résout pas le problème de coordination — il rend simplement l'échec distribué visible à plus d'endroits. Vous avez besoin de moins de choses à observer, pas de meilleurs outils pour observer plus de choses.
Ne fonctionne pas : le théâtre de la migration. "Nous migrons vers Dagster au cours des 18 prochains mois" n'est pas un plan. C'est une déclaration que la douleur n'est pas encore assez forte pour faire le travail réel. Tant que vous n'avez pas réellement retiré l'ancien outil, vous ajoutez simplement une surface d'intégration pendant que vous planifiez.
La pièce batch/streaming
Une véritable raison pour laquelle les équipes utilisent plusieurs outils d'orchestration est que le batch et le streaming ont réellement des exigences différentes. Airflow planifie des tâches. Kafka traite des flux. Différents paradigmes, différents outils — et si vous essayez de servir les deux dans la même plateforme de données, vous vous retrouvez avec deux systèmes de gestion de workflow séparés.
Cela vaut la peine de le nommer directement : une plateforme qui gère à la fois le batch et le streaming dans le même modèle de déploiement, la même définition de workflow, et les mêmes outils d'opérations signifie que la même équipe qui exécute l'ETL nocturne peut gérer le traitement d'événements en temps réel. Pas parce que quelqu'un réinvente Airflow ou Kafka, mais parce que la séparation entre "planifié" et "événementiel" ne devrait pas nécessiter deux spécialités d'ingénierie distinctes et deux systèmes de surveillance distincts.
Le but n'est pas de remplacer tout ce que vous avez. C'est d'arrêter de payer la taxe.
La véritable question
La conversation revient généralement à la même question : "Est-ce vraiment un problème qui vaut la peine d'être résolu, ou juste la nature de la construction de systèmes de données ?"
Juste. Chaque entreprise a une dette technique. Toutes les dettes ne valent pas la peine d'être remboursées.
Voici une façon simple d'y penser : si votre rotation d'astreinte inclut "vérifier les trois planificateurs" comme une étape dans chaque manuel d'exploitation, vous payez la taxe d'orchestration chaque semaine. Si un nouvel ingénieur en données a besoin d'un mois pour devenir productif parce qu'il doit apprendre les modèles mentaux de plusieurs outils, vous la payez à chaque embauche. Si votre processus de débogage nécessite de croiser les références de trois systèmes de journaux différents, vous la payez à chaque incident.
Additionnez cela. Puis décidez.
Si vous faites face à une prolifération de l'orchestration et souhaitez comprendre à quoi ressemble un chemin vers la consolidation — surtout lorsque vous gérez à la fois des charges de travail batch et en temps réel — contactez-nous. Nous pouvons examiner votre configuration spécifique et vous donner une image honnête de ce qui vaut la peine d'être changé et de ce qui ne l'est pas.
Andrew Tan est un entrepreneur en série et fondateur de layline.io, construisant une infrastructure de traitement de données d'entreprise qui gère à la fois les charges de travail batch et en temps réel à grande échelle.
