fr.wedoany.com Rapport : Databricks annonce le lancement d’une technologie baptisée LTAP (lake transactional/analytical processing), avec pour slogan marketing « une seule donnée, zéro compromis, zéro copie », visant à résoudre la difficulté de faire coexister OLTP et OLAP au sein d’un même système. Cette technologie s’appuie sur le moteur d’analyse unifié open source Apache Spark et repose sur deux nouveaux produits : Reyden (un nouveau moteur de calcul) et Lakebase (un PostgreSQL sans serveur basé sur un stockage objet ouvert). Databricks tente d’unifier les transactions, l’analyse, les flux et les données opérationnelles sur une seule copie de stockage dans un data lakehouse (combinaison d’un data lake et d’un data warehouse), afin de relever le défi fondamental où l’OLTP exécute de petites lectures orientées lignes et des écritures fréquentes, tandis que l’OLAP effectue de grandes lectures orientées colonnes et des écritures par lots. Cette problématique devient particulièrement urgente alors que le marché des bases de données cherche à répondre aux charges de travail générées par le déploiement d’agents IA.
Cependant, la revendication « zéro copie » suscite la controverse. Des ingénieurs de données soulignent que, dans LTAP, les données PostgreSQL actuelles existent sous forme de stockage local au format pageserver, avant d’être propagées vers le stockage objet au format Parquet pour une persistance à long terme. PostgreSQL/Lakebase peut récupérer les données depuis le stockage objet et reconvertir les données Parquet en pageserver. Un commentateur issu d’un concurrent de Databricks indique qu’il s’agit en réalité de « deux copies de données, pas une ». Lors d’une conférence PostgreSQL en mai dernier, les diapositives des ingénieurs de Databricks Hristo Stoyanov et Jonathan Katz le confirment également, montrant que le pageserver assure le stockage tandis que les exécuteurs d’analyse Spark extraient des fichiers de couche contenant des images de pages complètes depuis la couche miroir du stockage objet. Dans une communauté de messages privés consultée par The Register, un ingénieur de Databricks a répondu qu’il s’agit techniquement de deux copies, car le pageserver agit comme un cache ou une couche de matérialisation dans l’architecture Neon. Lakebase est basé sur la technologie Neon, acquise par Databricks l’année dernière, et propose des branches copy-on-write ainsi qu’un calcul sans serveur à mise à l’échelle automatique.
Unifier OLTP et OLAP n’est pas une première pour Databricks. En 2014, SingleStore a commencé à travailler sur un stockage en mémoire orienté lignes et un stockage sur disque orienté colonnes, adoptant une technologie de stockage hiérarchique permettant d’effectuer analyses et traitements transactionnels sur un seul système. Un service de base de données cloud lancé par cette société en 2020 prétend gérer automatiquement les données à travers une architecture à trois niveaux : mémoire, cache local et stockage objet. En réponse à l’affirmation de Databricks selon laquelle le traitement hybride transactionnel/analytique (HTAP) aurait échoué, Nadeem Asghar, directeur technique de SingleStore, a répondu qu’unifier OLTP et OLAP est précisément l’objectif du HTAP, et que « le renommer en LTAP ne fait que changer le marketing. Cela ne change pas la réalité physique ». Il souligne que le système de Databricks fait fonctionner trois moteurs, chacun avec son propre cache et sa propre perception de la fraîcheur des données, et que la forme physique des « deux copies de données » nécessite un mécanisme pour les maintenir synchronisées. Par ailleurs, MongoDB propose des index de stockage en colonnes, Oracle HeatWave for MySQL permet d’exécuter des analyses sur des applications transactionnelles, et SAP promeut l’analyse en temps réel depuis 2011 avec sa base de données en mémoire HANA.
Databricks insiste sur la véracité de sa revendication « zéro copie », arguant qu’elle évite d’avoir deux copies faisant autorité des données nécessitant une synchronisation. Dans une déclaration à The Register, un porte-parole de Databricks a indiqué que, dans LTAP, les utilisateurs opèrent sur une seule copie faisant autorité des données, avec une source unique de vérité dans Iceberg, tandis que les autres copies internes intermédiaires relèvent de la « hiérarchie de stockage de la base de données ». Lors d’une récente conférence, Databricks a précisé qu’il n’existe qu’une seule copie « faisant autorité » des données ou qu’une seule copie « dans le stockage », une description similaire à celle de SingleStore pour sa couche de stockage, qualifiée de « transparente pour l’utilisateur ».
Andy Pavlo, professeur associé en bases de données à l’Université Carnegie Mellon, souligne que, indépendamment des débats marketing, Databricks a réalisé un travail d’ingénierie impressionnant en permettant au nouveau moteur Reyden de lire les pages PostgreSQL. Il indique que le moteur Reyden parvient à interpréter le contenu des pages PostgreSQL, ce qui n’est pas une mince affaire, car les pages ne sont pas entièrement autonomes et nécessitent de revenir à Neon/PostgreSQL pour obtenir les métadonnées du catalogue. Cette technologie permet des analyses plus rapides, réalisées de manière transactionnellement sûre, sans attendre que les données soient poussées vers S3. Par ailleurs, Reyden est sans état et peut être mis à l’échelle horizontalement en augmentant les ressources de calcul. Pavlo reconnaît également qu’« elles finissent par copier les données de toute façon ».
