La règle des bases de données vieille de 40 ans que les agents viennent de briser : comment LTAP unifie les charges de travail OLTP et OLAP

Jonathan Katz a passé sa carrière des deux côtés d'une frontière avec laquelle la majeure partie de l'industrie des données a simplement appris à composer. En tant que contributeur de longue date à Postgres et aujourd'hui Senior Staff Product Manager chez Databricks, il a vu les systèmes opérationnels et analytiques fonctionner comme deux mondes distincts, reliés uniquement par des pipelines, des copies et des compromis.

Dans cette conversation, Jonathan explique pourquoi cette séparation existait à l'origine, pourquoi les agents AI sont enfin en train de la briser, et comment LTAP comble le fossé en repensant le point de rencontre de ces deux mondes : non pas dans un moteur unique, mais dans une couche de stockage unifiée.

L'hypothèse que les agents AI ont brisée

L'industrie vit avec une séparation stricte entre les systèmes de bases de données opérationnels et analytiques depuis des décennies. Pourquoi l'essor des agents AI autonomes est-il en train de briser cette frontière ?

Jonathan Katz : Il existe deux mondes de données. Les données opérationnelles sont celles que vous manipulez lorsque vous traitez une transaction par carte de crédit ou recherchez une fraude : des requêtes très courtes et rapides, qui analysent les données ligne par ligne. Les données analytiques sont celles que vous accumulez depuis des semaines, des mois ou des années, et lorsque vous les interrogez, vous examinez l'ensemble du jeu de données. Les deux approches cherchent à renvoyer une réponse le plus rapidement possible, mais elles s'y prennent de manières totalement différentes.

Cette différence n'est pas arbitraire. C'est une question de physique. Si vous stockez vos données en lignes, c'est ainsi que vous renvoyez une réponse unique le plus rapidement possible. Si vous les stockez en colonnes, c'est ainsi que vous parcourez et agrégez l'ensemble des données le plus rapidement possible. De plus, par conception, une requête analytique peut consommer l'intégralité des ressources d'un système massivement parallélisé pour obtenir une réponse sur un très grand jeu de données, tandis qu'une requête opérationnelle est conçue pour consommer le moins de ressources possible tout en renvoyant rapidement une réponse. Cela conduit à deux manières très différentes de concevoir et de gérer votre système de données, et nécessite différents types d'optimisations.

Postgres, l'une des bases de données les plus déployées de la planète, est construite autour des lignes car elle est optimisée pour les charges de travail opérationnelles. Les moteurs analytiques sont construits autour des colonnes pour la raison inverse. En raison de cette différence physique fondamentale, les deux systèmes ont toujours dû rester séparés, et chaque fois que vous vouliez analyser des données opérationnelles, vous deviez les envoyer ailleurs.

L'essor des agents AI a modifié nos besoins en matière de bases de données. C'est en partie pour cela que l'architecture de Lakebase existe : des bases de données conçues pour suivre le rythme de fonctionnement réel des agents. Par exemple, les agents ont pour mission de rechercher des fraudes ou des anomalies, et ces événements se produisent en quelques centaines de millisecondes. Mais ce système gère également un volume énorme d'écritures et de lectures courtes en même temps. Un seul agent peut être assez intelligent pour savoir quelle requête il doit exécuter. Mais une multitude d'agents peut facilement saturer un système opérationnel s'il n'y a pas de garde-fous en place.

Ce qu'est réellement le LTAP

Qu'est-ce que le LTAP et comment fonctionne-t-il réellement sous le capot ?

Jonathan Katz : Le LTAP, ou Lake Transactional/Analytical Processing, vous permet d'exécuter des requêtes analytiques directement sur des données opérationnelles en temps réel, sans déplacer ces données et sans surcharger le système qui gère vos transactions. Il y parvient en unifiant les données transactionnelles et analytiques dans une seule couche de stockage logique, au lieu de les contraindre à passer par des systèmes distincts reliés par un pipeline.

Sous le capot, le LTAP n'est possible que grâce à l'architecture même de Lakebase : un calcul sans état et éphémère, entièrement découplé du stockage dans le lake. Cette séparation, héritée de Neon, signifie que la couche de stockage durable peut gérer des écritures à haut débit et les transférer périodiquement vers un stockage objet pour assurer leur pérennité, indépendamment du calcul en cours d'exécution à un instant donné. Puisque ces données étaient déjà optimisées pour le stockage cloud, pourquoi ne pas les représenter dans le même format colonnaire que celui déjà utilisé par le Lakehouse, afin que des moteurs comme Apache Spark et SQL puissent les lire directement et obtenir des lectures analytiques haute performance sans copie secondaire ?

La partie la plus difficile a été de s'assurer que rien ne se perde en cours de route. Postgres possède ses propres types de données et encodages, et les formats ouverts comme Iceberg et Delta ont les leurs. Nous devions écrire les données de manière à préserver la représentation physique exacte des données Postgres d'origine, sans modifier un seul bit, et les intégrer dans un fichier Parquet. C'est ce qui nous a permis de fusionner les représentations opérationnelles et analytiques des mêmes données en une seule. En pratique, la couche de stockage fonctionne sur deux niveaux : un niveau chaud qui conserve les données au format ligne pour un accès opérationnel rapide, et un niveau froid qui les stocke au format colonnaire pour les lectures analytiques, afin que chaque partie puisse obtenir efficacement ce dont elle a besoin.

Pourquoi le LTAP réussit là où l'HTAP a stagné

L'HTAP a tenté de résoudre l'analyse en temps réel il y a des années et a stagné. Pourquoi le fait de réaliser cela au niveau de la couche de stockage du lakehouse réussit-il là où l'HTAP traditionnel a échoué ?

Jonathan Katz : Vous pouvez faire fonctionner les systèmes HTAP, mais ils coûtent cher. Ils sont lourds, difficiles à gérer et généralement fermés. Ce qui différencie le modèle LTAP, c'est que vous disposez d'un calcul opérationnel serverless et d'un calcul analytique serverless sous forme de deux éléments distincts. Vous pouvez adapter précisément la quantité de calcul que vous utilisez pour chaque charge de travail de manière indépendante, plutôt que de payer pour un système unique qui tente de faire les deux tâches à la fois. Le stockage est la partie économique de tout système de données. Le calcul en est la partie coûteuse.

C'est tout l'intérêt d'unifier la couche de stockage plutôt que le moteur : vous conservez le moteur spécialisé et efficace pour chaque tâche, et vous ne payez pour le calcul que là où vous en avez réellement besoin, au lieu d'exécuter un système coûteux qui essaie d'être performant dans tous les domaines à la fois.

Ce qui ne va plus lorsque les agents agissent sur des données obsolètes

Expliquez-moi un cas d'usage d'agent spécifique qui échoue ou se dégrade aujourd'hui parce qu'il lit et agit sur des données obsolètes. Que se passe-t-il concrètement ?

Jonathan Katz : La détection des fraudes en est l'exemple le plus clair. Les transactions par carte de crédit sont validées en quelques centaines de millisecondes ou moins. Si l'agent chargé de détecter les fraudes travaille à partir d'une copie par lots des données datant de plusieurs minutes ou heures, il est tout simplement trop lent pour intercepter quoi que ce soit avant que la transaction ne soit déjà finalisée. Vous voulez donc que cet agent travaille directement sur le système opérationnel.

Mais le système opérationnel gère un flux constant d'écritures et de lectures courtes, et il n'a pas été conçu pour absorber également de lourdes requêtes analytiques. Si l'agent exécute une requête qui parcourt tout l'historique d'achat d'un client pour rechercher des anomalies, c'est une requête coûteuse à exécuter sur un système optimisé pour le type de charge de travail inverse. Cela peut dégrader les performances de toutes les autres transactions qui tentent d'être validées en même temps. De plus, une architecture moderne a généralement besoin des données des côtés opérationnel et analytique pour prendre une bonne décision, l'agent doit donc extraire des données des deux côtés. Un seul agent peut gérer cela de manière responsable. Mais une flotte d'agents exécutant des requêtes similaires en même temps peut rapidement saturer le système opérationnel si rien ne régule la charge qu'ils sont autorisés à lui imposer.

Gouvernance, ouverture et cas d'usage en entreprise

Comment Databricks implémente-t-il spécifiquement le LTAP aujourd'hui, et comment l'expliqueriez-vous à quelqu'un qui comprend déjà pourquoi l'HTAP présente des limites ?

Jonathan Katz : Au-delà des mécanismes de stockage, l'autre élément majeur est le catalogue. L'une des véritables innovations du Lakehouse a été d'offrir aux entreprises une vue centralisée et unifiée de toutes leurs données : qui a accès à quoi, des politiques cohérentes pour l'ensemble, afin que personne ne puisse lire des informations sensibles comme un numéro de sécurité sociale sans faire partie d'un groupe privilégié. Cela ne s'est jamais vraiment appliqué aux systèmes opérationnels, car ceux-ci ont été conçus dès le départ comme des silos de données. Auparavant, la relation entre les données opérationnelles et analytiques se résumait à : vous construisez un pipeline, vous transférez les données, et ensuite, bonne chance. Personne ne gérait ce qu'il advenait d'elles en aval. Le LTAP change la donne. Toutes vos données se trouvent dans un modèle de stockage unifié, sous un catalogue unique. Vous n'avez plus à craindre que des données opérationnelles ne quittent un périmètre de gouvernance simplement parce que quelqu'un a eu besoin de les analyser.

Il y a également de bonnes raisons pour que cela repose sur des bases ouvertes. Postgres est en passe de devenir la troisième base de données la plus appréciée dans les classements de DB-Engines. Ce n'est pas nécessairement une mesure de l'adoption, mais c'est un signal fort de la direction que prennent les choses, et cela montre la valeur de la flexibilité et du choix. L'open source propulse certains des systèmes les plus importants au monde depuis des décennies. Le LTAP étend ce même principe. Même au sein de Postgres, vos données sont portables entre différents systèmes Postgres, mais vous restez lié à Postgres. Avec la couche de stockage unifiée du LTAP, vous ne déplacez plus vos données pour y appliquer le bon moteur. C'est vous qui apportez le moteur aux données.

Le changement fondamental : le stockage unifié

Si vous deviez décrire le changement fondamental que représente le LTAP en une seule phrase, quelle qu'elle soit, comment la formuleriez-vous ?

Jonathan Katz : La version simplifiée à l'extrême est le stockage unifié. Dites cela à quelqu'un du côté analytique et il comprendra presque immédiatement. Dites-le à quelqu'un du côté opérationnel et il vous demandera peut-être ce que vous voulez dire. Mais une fois que vous pouvez réunir les représentations opérationnelles et analytiques des mêmes données sans rien déplacer, sans qu'aucun bit ne change, cela élimine de nombreux problèmes qui semblaient auparavant inévitables. Je n'ai plus besoin d'exécuter des pipelines simplement pour amener les données dans une couche bronze ou silver. Je peux commencer à les analyser dès qu'elles sont écrites. Je présenterais également les choses différemment : il s'agit moins d'inventer quelque chose de nouveau que de réunir deux mondes qui n'auraient jamais dû être séparés. Les données ne sont que des données. Plus nous les traitons ainsi, plus il devient facile pour les personnes, et désormais pour les agents, de travailler avec elles sans que tout le monde ait à négocier d'abord à travers un pipeline.

Réunir à nouveau ces deux mondes

Pendant quarante ans, la frontière entre données opérationnelles et analytiques a persisté parce que la physique du stockage l'exigeait. Les agents sont la première charge de travail qui ne peut tolérer le délai créé par cette frontière. LTAP ne cherche pas à effacer la différence entre une transaction et une requête analytique. Il élimine le coût supplémentaire qui découlait auparavant de l'exécution des deux sur les mêmes données. Pour un Data Architect qui évalue si une charge de travail agentique a réellement besoin de ce modèle, le test décrit par Jonathan est utile : si la prochaine décision d'un agent dépend de données qui sont encore en cours de stabilisation, sur un système conçu pour garder ces données proches et protégées, l'ancien modèle de pipeline et de copie ne sera pas assez rapide. C'est le problème spécifique que LTAP a été conçu pour résoudre.

Pour en savoir plus sur LTAP, lisez Du monolithe au Lakebase puis à LTAP : repenser la base de données à partir du stockage.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original