Par Andrew Tan
La vérité coûteuse des data stacks modernes
Passez assez de temps auprès des équipes data platform et vous entendrez la même histoire. Une entreprise met en place sa « data stack moderne » — Data Warehouse, couche de traitement, orchestrateur — et tout semble propre sur le schéma d'architecture. Puis la facture du Data Warehouse commence à grimper. Les jobs d'ingestion échouent plus souvent que prévu. Et à chaque incident, il faut une demi-journée pour déterminer si le problème vient du chargement, de la transformation, de l'orchestrateur ou du Data Warehouse lui-même.
À un moment, quelqu'un dans l'équipe finit par dire tout haut ce que tout le monde pense tout bas : « Je crois qu'on a construit un outil d'intégration très cher sans le vouloir. »
Cette personne a généralement raison.
L'erreur de catégorie
Un Data Warehouse est un moteur de requêtes et de stockage. Il est optimisé pour une seule chose : répondre rapidement à des questions analytiques sur de grands jeux de données.
Un Data Pipeline est un runtime de mouvement et de traitement des données. Il est optimisé pour quelque chose de différent : amener les données de là où elles sont à là où elles doivent être, dans le bon format, au bon moment, de manière fiable.
Ce sont deux métiers distincts. Mais au cours de la dernière décennie, nous avons silencieusement demandé au Data Warehouse de faire les deux.
Tout a commencé de manière innocente. Les Data Warehouses se sont améliorés pour charger des données. Puis ils ont eu des procédures stockées. Puis dbt a transformé SQL en couche de traitement. Puis les orchestrateurs ont commencé à déclencher des requêtes de Data Warehouse pour déplacer des données d'une table à une autre. Et avant que quiconque ne nomme cette tendance, le Data Warehouse était devenu la couche d'intégration par défaut.
Le résultat est prévisible. Le Data Warehouse est excellent pour l'analyse. Il est médiocre pour l'intégration. Et quand on l'oblige à faire de l'intégration à grande échelle, on le paie dans trois monnaies : le coût, la fiabilité et la fragilité architecturale.
Ce qui va de travers quand le Data Warehouse devient le pipeline
La facture de calcul devient une surprise
La puissance de calcul d'un Data Warehouse est tarifée pour des requêtes analytiques. Les analystes exécutent quelques grosses requêtes, attendent les résultats, puis vont prendre des décisions. Le calcul est par à coups et rythmé par les humains.
Les workloads d'intégration ne ressemblent pas à ça. Elles tournent en continu ou selon des fréquences serrées. Elles déplacent des millions de lignes. Elles effectuent les mêmes conversions encore et encore. Elles ne s'arrêtent pas pour laisser les humains lire des dashboards.
Quand vous exécutez ce type de workload au sein d'un Data Warehouse, le compteur tourne différemment. Il est courant qu'une « simple » synchronisation horaire consomme plus de crédits que l'ensemble de la workload analytique. Non pas parce que le Data Warehouse est mauvais, mais parce que ce n'est pas le bon moteur pour ce job.
Les échecs deviennent opaques
Un Data Pipeline a un job clair : prendre des données en A, les transformer, les livrer en B. Quand il échoue, vous voulez savoir quelle étape a échoué et pourquoi.
Quand le Data Warehouse est le pipeline, l'échec est réparti sur plusieurs couches. Le chargement était-il lent parce que le Data Warehouse était saturé ? L'orchestrateur a-t-il perdu sa connexion ? La requête de transformation a-t-elle dépassé le temps d'attente ? Les données sont-elles erronées à cause de la source, de la conversion ou d'un changement dans le plan d'exécution du Data Warehouse ?
Le débogage devient de l'archéologie. Vous fouillez dans l'historique des requêtes, les logs de l'orchestrateur et les métriques du Data Warehouse, en essayant de reconstruire ce qui s'est réellement passé. Les outils sont tous là. La clarté, non.
La latence est celle que le Data Warehouse décide
Si votre Data Pipeline est une série de requêtes de Data Warehouse, votre latence est déterminée par l'ordonnancement de ce dernier. Une requête attend dans une file. Elle se compile. Elle s'exécute. Elle peut être préemptée. Elle peut monter en charge. Ou pas.
Pour l'analyse en batch, c'est acceptable. Personne ne se soucie qu'un rapport nocturne se termine à 3h00 ou 3h15.
Pour les cas d'usage opérationnels, ce n'est pas acceptable. La détection de fraude, les mises à jour d'inventaire, les dashboards orientés client — tout cela nécessite des minutes ou des secondes, pas le temps d'attente d'une file de requêtes. Quand le Data Warehouse est votre pipeline, vous héritez de son rythme. Et ce rythme est conçu pour les analystes, pas pour les opérations.
L'enfermement propriétaire s'aggrave
Plus la logique d'intégration vit à l'intérieur du Data Warehouse, plus il devient difficile de s'en passer. Vos réécritures utilisent des dialectes SQL spécifiques au Data Warehouse. Votre orchestration dépend de sessions de Data Warehouse. Vos règles de qualité des données s'exécutent comme des requêtes de Data Warehouse. Même votre visibilité des coûts est façonnée par le Data Warehouse.
Ce n'est pas un complot. C'est simplement ce qui arrive quand un outil assume trop de responsabilités. Le coût de migration augmente jusqu'à ce qu'il semble plus simple de rester malheureux que de partir.
À quoi ressemble une séparation propre
La solution n'est pas de jeter le Data Warehouse. Il est bon dans ce qu'il fait. La solution est de le laisser faire ce pour quoi il est fait et d'arrêter de lui demander de tout faire.
En pratique, cela signifie généralement deux plateformes, et non une seule :
Runtime d'intégration et d'orchestration
C'est ici que les données se déplacent, se transforment, sont validées et acheminées vers les bons consommateurs. C'est également ici que sont planifiés les pipelines, gérés les échecs avec retry, appliquées les dépendances et déclenchés les travaux en aval — à la fois dans la plateforme et dans les systèmes externes. Il s'exécute sur un moteur conçu pour le flux de données continu, pas pour la latence des requêtes.
Data Warehouse
C'est ici que les données sont stockées et interrogées. Il reçoit des données propres et prêtes à être requêtées depuis la couche d'intégration. Il ne se soucie pas de la façon dont les données sont arrivées, du moment où arrivera le prochain chargement ou de ce qu'il faut faire en cas d'échec d'un job. Il se contente de répondre aux questions.
Logiquement, vous pouvez toujours considérer l'intégration et l'orchestration comme des préoccupations distinctes. Opérationnellement, elles appartiennent souvent au même runtime. Un pipeline capable de déplacer des données mais incapable de se planifier lui-même, de se réexécuter en cas d'échec ou de déclencher l'étape suivante n'est qu'à moitié utile. Les meilleures plateformes combinent les deux.
Quand ces préoccupations sont séparées du Data Warehouse, chaque outil devient plus simple. La couche d'intégration est optimisée pour le débit et la fiabilité. L'orchestrateur est optimisé pour la gestion des dépendances et la récupération d'erreurs. Le Data Warehouse est optimisé pour les performances des requêtes.
Plus important encore, les problèmes restent dans leur domaine. Quand l'ingestion échoue, vous regardez le runtime d'intégration. Quand un rapport est erroné, vous regardez le Data Warehouse. Quand un job ne s'exécute pas, vous regardez l'orchestrateur — qui, dans une configuration propre, fait partie du même runtime qui déplace les données.
Quand le Data Warehouse comme pipeline est effectivement acceptable
Je ne veux pas exagérer. Pour certaines équipes, le modèle Data Warehouse comme pipeline fonctionne très bien.
Si vous êtes petit, vos volumes de données sont faibles, vos transformations sont simples et vos exigences de latence se résument à « demain c'est bien », alors garder tout au même endroit est un compromis raisonnable. La simplicité opérationnelle vaut plus que la pureté architecturale.
Les problèmes commencent quand ce modèle continue de croître au-delà de sa limite naturelle. Une équipe qui le dépasse le sait généralement. Les factures deviennent étranges. Les échecs deviennent mystérieux. L'idée d'ajouter un cas d'usage en temps réel devient un projet de plusieurs mois au lieu d'un simple changement de configuration.
La question n'est pas de savoir si ce modèle est mauvais. La question est de savoir s'il est encore le bon modèle pour l'étape où vous en êtes aujourd'hui.
Le chemin de migration que personne ne prend
La plupart des équipes imaginent cette séparation comme un projet de type rip-and-replace. Ce n'est pas nécessaire.
L'approche la meilleure consiste d'abord à extraire la couche de mouvement. Choisissez une source de données. Au lieu de la charger directement dans le Data Warehouse puis de la transformer là-bas, faites-la d'abord transiter par un runtime d'intégration dédié. Nettoyez-la. Validez-la. Puis écrivez les données propres dans le Data Warehouse.
Le Data Warehouse ne change pas beaucoup. Les analystes continuent d'interroger les mêmes tables. Mais maintenant, ces tables sont alimentées par un Data Pipeline conçu pour alimenter des tables.
Une fois qu'une source est déplacée, le modèle se répète. Source par source. Pipeline par pipeline. Avec le temps, le Data Warehouse cesse d'être le hub d'intégration et redevient ce qu'il était censé être : le hub analytique.
Les équipes qui réussissent cette migration ne commencent pas par le pipeline le plus difficile. Elles commencent par un pipeline ennuyeux. Les pipelines ennuyeux vous apprennent le modèle sans risque. Les pipelines difficiles deviennent plus simples une fois le modèle en place.
Où s'inscrit layline.io
Je vais être direct : c'est le pari architectural qui sous-tend layline.io.
Nous avons construit une plateforme de traitement de données qui prend en charge la couche d'intégration et d'orchestration — à la fois batch et streaming — sans obliger le Data Warehouse à faire le gros du travail. Les Data Pipelines déplacent les données, les transforment, les valident et les livrent. Ils se planifient également eux-mêmes, réexécutent en cas d'échec, appliquent les dépendances et déclenchent des workflows en aval, à l'intérieur de layline ou dans des systèmes externes.
Le Data Warehouse stocke les données et les interroge. Chaque outil fait son propre job.
Parce que layline gère à la fois le batch et le streaming dans le même runtime, vous ne vous retrouvez pas avec un outil pour vos chargements horaires et un autre pour vos événements en temps réel. Les mêmes Workflows. La même observabilité. La même équipe. Et parce que l'orchestration est intégrée, vous n'avez pas besoin d'un orchestrateur séparé qui coordonne entre layline et tout le reste.
Ce n'est pas un argumentaire pour tout le monde. Si votre configuration Data Warehouse comme pipeline fonctionne et que vos factures sont raisonnables, vous n'avez pas besoin de nous. Mais si vous regardez une facture de Data Warehouse triplée et que vous vous demandez comment une « simple » synchronisation est devenue si coûteuse, la séparation que nous décrivons est probablement ce que vous cherchez réellement.
La question à poser à votre équipe
Prenez vos trois workloads de Data Warehouse les plus coûteux. Pas les plus grosses requêtes analytiques — celles qui tournent toute la journée à déplacer et transformer des données.
Demandez-vous : ces workloads répondent-elles à des questions métier, ou se contentent-elles de mettre les données dans un format permettant de répondre à des questions métier ?
Si la réponse est la deuxième, vous avez du travail d'intégration qui s'exécute dans un moteur analytique. Ce n'est pas une faute morale. C'est une architecture très courante. Mais c'est aussi une architecture très corrigeable.
Le Data Warehouse est un outil puissant. Ce n'est simplement pas le seul outil.
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 par lots et en temps réel à grande échelle.
