Lakehouse//RT : Databricks se met à l’analytique en quasi-temps réel

Un quatrième moteur analytique propriétaire propulse Lakehouse//RT

Là où Photon est, en réalité, un co-moteur vectorisé pour Spark SQL – comme Apache Velox l’est pour Microsoft Fabric, AccelData, IBM et Google Lightning Engine –, Reyden est un moteur asynchrone vectorisé, « Single Threaded-First » et massivement parallèle.

Ici, Databricks joue la carte de la performance. Lakehouse//RT supporterait jusqu’à 12 000 requêtes par seconde (jusqu’à 16 000 selon les tests menés par les ingénieurs de Databricks) et un temps de réponse sous les 100 ms sur les grands jeux de données. Les benchmarks de TPC-H et TPC-DS contre les compétiteurs à peine masquées, ClickHouse et Snowflake, plaçaient évidemment Databricks en tête. Les ingénieurs ont également évoqué Vertica comme inspiration. Le moteur vieillissant racheté par Rocket Software demeure une référence en matière d’accélération des requêtes BI. Ici, la latence ne suit pas une loi de mise à l’échelle, mais augmente légèrement avec le volume de données en entrée.

LeMagIT a demandé à l’éditeur des précisions techniques concernant les entrailles de Reyden. L’article sera mis à jour en conséquence. En attendant, Databricks ne joue pas à produire des objets techniques uniquement pour le plaisir de ses ingénieurs. Si l’architecture LTAP cible les acteurs comme Oracle ou SingleStore, avec Lakehouse//RT, l’entreprise basée à San Francisco cherche à s’emparer de parts de marché partout où elle le peut.

Pour référence, à la fin du mois de mai 2026, ClickHouse a présenté un revenue run rate de 250 millions de dollars porté par 4000 clients. Le triple de l’année passée. La startup a convaincu certaines entreprises de ne pas recourir à Databricks et à Snowflake pour certaines charges de travail analytiques sensibles à la latence.

Car au-delà du discours ambiant sur l’IA agentique, l’usage premier de Lakehouse//RT demeure la livraison concurrente de tableaux de bord et de rapports BI.

La performance analytique, un problème algorithmique

Toutefois, les ingénieurs de Databricks insistent. Les algorithmes sous le capot de Lakehouse//RT sont entraînés sur toute la richesse des milliers de milliards de requêtes traitées à travers la plateforme de gestion de données.

« Lorsque vous concevez le système, vous êtes très concentré sur une charge de travail particulière que vous essayez d’optimiser », déclare Nong Li, ingénieur logiciel chez Databricks. « Vous manquez en quelque sorte les autres parties de l’espace du problème. Parce que nous avons une telle diversité de données issue de l’historique de l’entreprise, nous sommes capables de les intégrer tous dans le système dès le début ». En clair, l’éditeur cherche à généraliser l’apprentissage des modèles de machine learning sous-jacent afin de convenir à davantage de types de charges de travail analytique.

Selon Nicolas Maillard, vice-président responsable du field engineering dans la région SEMEA chez Databricks, Lakehouse//RT est efficace pour les requêtes faiblement à moyennement complexes. Les clients qui ont pu le tester le confirment. En revanche, les performances avec les requêtes les plus élaborées sont encore dégradées. « Nous n’avons pas encore la couverture totale que nous aurions avec un Spark, avec ou sans Photon. Cela réclame des efforts de développement », note-t-il. En cause, la prédiction du jeu de clés-valeur potentiel avec un grand nombre de tables s’avère compliquée. La bêta privée devrait permettre de mieux cibler les charges de travail correspondantes afin d’optimiser le moteur.

Les temps de latence et le nombre de requêtes par seconde affichés par l’éditeur découlent par ailleurs d’un ensemble d’optimisations. Elles concernent les pipelines d’ingestion avec Zerobus Ingest, la capacité d’optimisation prédictive des structures de données, Liquid Clustering, les fonctions de mise à l’échelle automatique et l’autoscaling incrémental de Lakehouse//RT. En clair, le service sélectionne par lui-même la taille de l’instance et ajoute ou supprime des nœuds de traitement en fonction de la charge. Les ingénieurs recommandent de ne pas toucher à ces paramètres et d’en suivre les coûts.

Plus tard, les ingénieurs prévoient la prise en charge de la recherche plein texte (full text search), des données géospatiales, de Spark et des DataFrames. Comme LakeBase, Lakehouse//RT est intégré au catalogue de données Unity.

Enfin, la question du prix n’a pas été abordée dans le détail. Pour l’instant, Lakehouse//RT est disponible en bêta privée avec une réduction de 30 % sur la facture jusqu’au mois de janvier 2027.