La modern data stack vs. l'open data Infrastructure

La modern data stack a résolu un vrai problème il y a 10 ans : rassembler les data en un seul endroit, les modéliser, permettre aux analystes de les interroger. C'était le but, et les warehouses y sont parvenus.

Le travail a changé. La plupart des équipes avec lesquelles je discute n’ont pas encore pleinement pris la mesure de l’ampleur du changement. Si vous déployez l'IA en production sur une pile centrée sur les warehouses, vous en payez le prix : en factures de capacités de calcul démesurées, en latence que vous ne pouvez pas expliquer à l'équipe produit, et en dérive progressive des copies de data dont personne n'est vraiment responsable. L'architecture n'est pas défaillante ; elle effectue simplement une tâche pour laquelle elle n'a pas été conçue.

Voici les arguments en faveur du passage à l’open data infrastructure, rédigés autour des questions que les sceptiques posent réellement, et non des questions faciles.

[CTA_MODULE]

« Snowflake et Databricks intègrent des fonctionnalités d'IA directement dans leurs plateformes. Pourquoi devrais-je partir ? »

Vous n'êtes pas obligé de le faire, et c'est justement là où réside tout l'intérêt. Ces plateformes restent les meilleures de leur catégorie en matière de calcul, d'analyse et d'IA. Cortex, Mosaic, AI Functions : elles existent bel et bien, et pour de nombreuses charges de travail, elles correspondent exactement à ce dont vous avez besoin. Le changement ne consiste pas à les remplacer. Il s'agit de changer l'emplacement de vos data afin de pouvoir les utiliser plus efficacement.

La limite ne réside pas dans les outils, mais dans l'architecture. Lorsque les data sont étroitement liées à une seule plateforme, chaque nouveau cas d'utilisation de l'IA qui s'en écarte crée des frictions. Dès que vous devez utiliser un autre modèle, un autre outil ou un autre système, vous devez à nouveau copier des data, créer des pipelines et gérer les incohérences entre les environnements. C'est ainsi que les coûts augmentent, que la latence s'installe et que le contexte se perd.

L'open data infrastructure résout ce problème en séparant le stockage du calcul. Au lieu d'ingérer les data dans chaque plateforme, vous les stockez une seule fois dans un data lake ouvert et géré, et vous laissez Snowflake, Databricks et d'autres moteurs lire à partir de la même source de vérité. Cela élimine les pipelines en double, réduit les coûts d'ingestion et de calcul et garantit la cohérence des data entre les équipes et les outils.

On le constate clairement dans les entreprises réelles. Il est courant que différentes équipes utilisent des outils de calcul différents : la finance sur Snowflake, la data science sur Databricks, voire une nouvelle équipe d’IA expérimentant quelque chose de complètement différent. Ou bien, après une acquisition, vous héritez d’une pile technologique totalement différente. Sans socle commun, vous finissez par faire fonctionner des pipelines parallèles dans chaque système, payer plusieurs fois pour l'ingestion et essayer de réconcilier des versions légèrement différentes des mêmes data. Avec un data lake centralisé, cette complexité disparaît. Vous disposez d’une source unique de vérité, que vous gérez une seule fois, et tous les outils fonctionnent dans le même contexte, toujours à jour.

La question n’est donc pas de savoir s’il faut partir, mais si vous souhaitez que vos data soient liées à un seul système ou accessibles à tous. Conserver ces plateformes comme couches de calcul tout en passant à un socle de data ouvert vous offre de la flexibilité aujourd’hui et des options pour demain, sans vous obliger à tout recréer lorsque vos besoins évolueront inévitablement.

« Nous avons essayé un data lake en 2018. C'était un marécage. En quoi est-ce différent ? »

C'est logique, et beaucoup d'équipes sont confrontées à ce problème. Le data lake de 2018 a échoué pour des raisons spécifiques qui ont depuis été résolues.

Les anciens data lakes n'étaient que des dépôts de fichiers sans aucune garantie transactionnelle. La dérive des schémas était constante, la gouvernance était un élément secondaire, et les moteurs de requête qui lisaient ces fichiers étaient lents et fragiles par rapport à un data warehouse. Les équipes les ont donc abandonnés et sont revenues à Snowflake ou Databricks, ce qui était la bonne décision à l'époque.

Ce qui a réellement changé aujourd'hui : les formats de tables ouverts (Iceberg, Delta) offrent des transactions ACID, l'évolution des schémas et la fonction « time travel » en plus du stockage objet. Les standards de catalogues ont gagné en maturité. Les moteurs de requête qui lisent ces formats sont compétitifs, parfois plus rapides, que les performances natives des warehouses pour de nombreuses charges de travail.

Mais ces capacités n'apportent pas de valeur à elles seules. Vous devez toujours convertir les data dans ces formats, les maintenir à jour en permanence, gérer les modifications de schémas et assurer la cohérence des metadata entre les systèmes — c'est là que la plupart des équipes se heurtent à la complexité.

Le Service gestion de data lake de Fivetran s'en charge pour vous. Il fournit des data dans des formats ouverts, assure la synchronisation en continu de votre data lake à partir des systèmes sources, gère automatiquement l'évolution des schémas et publie les metadata dans votre catalogue afin que chaque moteur puisse accéder à une vue cohérente et gérée des data. Au lieu de devoir assembler vous-même ces éléments, il vous offre les avantages d'un data lake ouvert sans la charge opérationnelle qui l'accompagnait traditionnellement.

« Databricks a créé Delta Lake et détient désormais Tabular, qui a développé Iceberg. En quoi est-ce « ouvert » ? »

L'ouverture est un concept qui s'inscrit sur un continuum, et tout dépend de l'axe auquel on se réfère. L'ouverture des formats — la capacité de plusieurs moteurs à lire et à écrire les data — est bien réelle. Iceberg dispose d'implémentations opérationnelles provenant de Snowflake, AWS, Google, Trino, DuckDB et d'autres. Delta bénéficie également d'une large prise en charge. Quel que soit le fournisseur à l'origine de la spécification, vos data résident dans un stockage objet que vous contrôlez, dans un format lisible par plusieurs moteurs. C'est une situation très différente de celle du stockage dans un warehouse propriétaire.

L'ouverture en matière de gouvernance, c'est-à-dire qui contrôle la spécification, est plus complexe. Iceberg relève de la Apache Foundation, mais Databricks détient désormais Tabular. Delta est dirigé par Databricks et bénéficie de la gouvernance de la Linux Foundation. Aucun des deux n'est totalement neutre. Ce qui importe sur le plan opérationnel, c'est que si votre stockage et votre catalogue sont suffisamment ouverts pour vous permettre de changer de moteur de requête sans avoir à réimporter des pétaoctets de data, vous disposez d'un levier significatif. C'est là la barre à franchir. L’ODI la franchit. Ce n'est pas le cas du stockage dans un warehouse propriétaire.

« Est-ce que je ne vais pas simplement passer d’un fournisseur à cinq ? Mon équipe chargée de la plateforme ne peut pas gérer ça. »

C'est là que de nombreux arguments en faveur d’une « pile modulaire » s'effondrent dans la pratique. L’ODI vous offre de la flexibilité, et la flexibilité a un coût opérationnel. Si vous l'assemblez vous-même à partir d'éléments bruts — un catalogue par-ci, un moteur de requêtes par-là, une orchestration intégrée —, vous aurez besoin d'une équipe dédiée à la plateforme capable de tout coordonner. Pour de nombreuses organisations, ce n’est pas réaliste.

Deux éléments rendent cela gérable. Premièrement, les couches les plus importantes, le stockage et le catalogue, sont de plus en plus standardisées ; vous n’avez donc pas à assembler cinq systèmes propriétaires, mais à configurer des couches qui interopèrent réellement. Deuxièmement, des offres gérées existent désormais pour la plupart des éléments, ce qui vous permet d'adopter l'architecture sans avoir à gérer vous-même chaque composant.

La vraie question n'est pas « modulaire ou consolidé ». C'est « Où est-ce que je souhaite disposer de cette flexibilité ? » Si vous consolidez au sein d’un seul fournisseur, vous échangez la simplicité opérationnelle d’aujourd’hui contre des coûts de migration demain. Si vous adoptez l'ODI, vous échangez une certaine complexité opérationnelle aujourd'hui contre la possibilité d'adapter l'acheminement des charges de travail au fur et à mesure de leur évolution. Les deux options sont valables. L’erreur serait de prétendre qu’il n’y a pas de compromis.

« Ma facture associée au warehouse est tout à fait correcte. Montrez-moi en quoi la charge de travail liée à l’IA fait réellement pencher la balance. »

Cela ne pose pas de problème pour les premières expérimentations. Cela pose problème à un stade que la plupart des équipes n'ont pas encore atteint.

Une tâche d'agent unique, par exemple la génération d'une recommandation, ressemble à un seul résultat. En réalité, il s'agit d'une recherche sur le comportement des utilisateurs, d'une recherche de produit, d'une vérification des stocks, d'une inférence de modèle et, souvent, d'un passage de reclassement. Ce n'est pas une seule requête, mais une douzaine, parfois plus. Exécutez-la pour un utilisateur, pas de problème. Exécutez-la sur des milliers d'agents simultanés, et le coût par tâche sur un système de calcul à prix de warehouse commence à paraître ridicule par rapport à ce que coûteraient les mêmes opérations sur une configuration tenant compte du routage.

Il y a également un autre problème : la latence. Les warehouses sont optimisés pour le débit sur les requêtes volumineuses, pas pour les recherches à faible latence sur les petites requêtes. Lorsque les agents effectuent des récupérations en chaîne, chaque centième de milliseconde s'accumule. Certaines charges de travail s'exécuteront sur le warehouse sans que vous ne vous en rendiez compte. D'autres deviendront discrètement inutilisables, et la réponse à laquelle l'équipe aboutira sera « mettez en place un autre système », ce qui vous mènera au problème du patchwork.

Si vous voulez vous en rendre compte par vous-même, instrumentez un workflow d'agent réel de bout en bout et examinez le coût par tâche et la latence p95. Les chiffres ont tendance à être plus convaincants que les arguments.

Nous l'avons constaté en interne. À mesure que l'utilisation pilotée par les agents augmentait, le volume de requêtes et les coûts ont augmenté beaucoup plus rapidement que prévu. La réponse initiale a été d’ajouter des garde-fous, mais cela n’a fait que mettre en évidence le problème sous-jacent : si chaque nouveau workflow d’IA dépend du même chemin coûteux, le déploiement de l’IA devient un problème de coût, et non plus de capacité. C'est ce qui nous a poussés à évoluer vers une architecture de data lake, où les charges de travail à haut volume pouvaient s'exécuter sur des moteurs moins coûteux au lieu d'être automatiquement dirigées vers le warehouse.

« N’est-ce pas simplement un argumentaire commercial déguisé en conseil architectural ? »

Chaque argument en faveur d'une architecture a ses partisans. Les fournisseurs qui développent des composants ODI — formats de tables ouverts, moteurs de requêtes, catalogues et plateformes de déplacement de data — tirent profit de la croissance de ce modèle. Mais surtout, les fournisseurs de warehouse font également partie de cet écosystème. Dans une approche ODI, ils continuent de jouer un rôle essentiel en tant que couches de calcul puissantes — mais ne sont plus le seul endroit où résident vos data.

Ce qu’il est plus difficile d’ignorer, c’est que les changements sous-jacents — les formats de table ouverts qui deviennent le standard de stockage, le calcul qui est découplé du stockage, les agents qui deviennent les principaux consommateurs de data — se produisent quel que soit le fournisseur qui l’emporte. Snowflake prend en charge Iceberg. Databricks a racheté Tabular. AWS, Google et les principaux catalogues convergent tous vers cette couche. La question n'est pas de savoir si l'architecture évolue dans cette direction. C’est le cas. La question est de savoir avec quelle détermination vous vous repositionnez pour y répondre, et quelle part de votre pile actuelle vous êtes prêt à recréer en cours de route.

Une lecture raisonnable : si les fournisseurs qui auraient à perdre dans ce changement s'orientent eux-mêmes vers celui-ci, le changement est probablement réel.

La modern data stack vs. l'open data infrastructure

Par où commencer

Vous n'avez pas besoin de démanteler le warehouse. Vous devez cesser de le considérer comme le centre de l'univers. Commencez par migrer la couche de stockage vers des formats ouverts : Iceberg ou Delta sur un stockage objet que vous contrôlez réellement. Tout le reste repose sur cette base. La plupart des warehouses peuvent désormais lire ces formats, il ne s'agit donc pas d'une migration hors de votre pile existante ; il s'agit de repositionner les data afin que d'autres moteurs puissent également y accéder.

Retirez ensuite une charge de travail du warehouse. Choisissez une tâche que le warehouse gère mal : une récupération à haute fréquence, un pipeline de fonctionnalités pour un cas d'utilisation de ML, un workflow d'agent qui génère des factures surprenantes. Acheminez-la via un autre moteur vers le même stockage. Mesurez la différence. C'est là votre argument de poids en interne.

[CTA_MODULE]

Enfin, n'oubliez pas d'investir dans la couche contextuelle. Les metadata et la sémantique peuvent sembler être un travail de back-office jusqu'à ce que vous voyiez un agent agir sur la base d'une définition obsolète. Elles ne sont pas facultatives pour l'IA ; elles font la différence entre les agents qui fonctionnent et ceux qui ne fonctionnent pas.