Virtualisation de données : Denodo en quête de simplification

Favoriser l’adoption des métiers

L’éditeur poursuit sur cette lancée avec Denodo 9 et met l’accent sur une plus grande simplicité d’utilisation. De fait, la plateforme de virtualisation de données est habituellement manipulée par des ingénieurs de données ou des habitués des outils ELT/ETL. Mais avec l’adoption multiforme de la philosophie Data Mesh, les entités métiers et les rôles qui les composent sont voués à gagner en autonomie.

Aussi, il faut bien que les métiers puissent manipuler les produits de données constituées avec la couche de data virtualization. En ce sens, Denodo propose un wizard de préparation dans son catalogue de données. L’assistant WYZIWYG doit simplifier la création de filtres et de transformations sur des produits de données sans avoir nécessairement besoin de manipuler le DSL VizQL. Par ailleurs, depuis le Data Catalog accessible avec l’offre Enterprise, Denodo fournit des recommandations de transformations et de filtres issues de l’historique d’utilisation de l’utilisateur. Il est également possible de consulter les vues associées à une base de données et leur association. En parallèle, les administrateurs obtiennent davantage de logs sur l’activité des utilisateurs concernant la modification des vues, des tags, des catégories sans avoir à déployer un module supplémentaire, comme par le passé.

En outre, une nouvelle page d’accueil intégrée au Design Studio doit simplifier « l’accès aux ressources et actions les plus communes afin d’accélérer l’enrôlement des nouveaux utilisateurs ». Design Studio intègre par défaut les templates pour requêter des sources de données SaaS (Dynamics 365, Marketo, Google Analytics, etc.).

Assisted Query : Denodo intègre (lui aussi) l’IA générative

Pour les entreprises ayant souscrit à l’offre Enterprise Plus, la fonction Assisted Query, propulsée à l’IA générative attenante à l’UI Data Catalog entre en disponibilité générale. L’éditeur s’inscrit là dans une tendance suivie par l’ensemble des acteurs du traitement de données, de Snowflake à Oracle.

Celle-ci permet d’interagir en langage naturel pour obtenir une requête VizQL pouvant être exécutée afin d’obtenir une vue, ainsi que son explication. Cette exécution peut être manuelle ou automatique, même si ce deuxième mode est bien plus lent, d’après les recommandations de l’éditeur.

Afin de propulser cette fonction, Denodo s’est d’abord intégré avec les API d’OpenAI et d’Azure OpenAI avant de proposer une intégration avec Claude 3 Sonnet depuis Amazon Bedrock. D’autres LLM seront pris en charge plus tard sur la plateforme d’AWS.

Il est également possible de configurer une API personnalisée tant qu’elle respecte le design de celle fournie par OpenAI.

Attention toutefois, car l’utilisation du service réclame l’envoi des métadonnées vers les LLM distants. Une option « data usage » peut être activée pour « améliorer » la requête suggérée. Celle-ci nécessite l’envoi des métadonnées sur les noms des vues, de leurs descriptions, des noms des champs, des types de données et de leurs relations dans la limite du nombre de tokens pris en charge par le modèle d’IA générative et du service de cache de Denodo (500 lignes).

Le message de l’utilisateur peut être de 1 000 caractères maximum (environ 250 tokens), mais le preprompt envoyé au LLM par Denodo est long de 3 000 tokens. L’éditeur recommande d’exploiter un grand modèle de langage capable de prendre en entrée au moins 10 000 tokens. Cela semble écarter bon nombre de LLM « open weight », dont Llama 3 et ses variantes. En revanche, Mixtral 8x7B semble compatible (il est doté d’une fenêtre de contexte de 32 000 tokens).

Plus tard, l’éditeur prévoit de prendre en charge les architectures RAG (Retrieval Augmented Generation) afin que ses clients puissent envoyer leurs données vers ces systèmes, mais il ne précise pas comment ni avec quels connecteurs. Une première réponse est à trouver du côté d’un partenariat avec Google Cloud. Denodo entend intégrer sa plateforme avec Vertex AI et VertexDB, une des bases de données vectorielles du géant du cloud. Il s’agirait de vectoriser les métadonnées des tables accessibles depuis Denodo afin d’inclure les résultats obtenus grâce aux données résidant sur des systèmes tierces (dont SAP, Salesforce, Confluent Cloud, etc.). Par ailleurs, la prise en charge des modèles Gemini semble prévue.

Cependant, les fonctionnalités les plus importantes de Denodo 9 sont liées à Virtual DataPort. Ainsi, l’éditeur entend permettre une ségrégation fine des tâches administratives. Par exemple, il est possible de configurer des rôles d’administrateurs responsables du déploiement de la plateforme qui peuvent configurer le serveur sous-jacent, mais qui ne peuvent pas voir les données.

De nouveaux outils permettent par ailleurs d’inspecter l’ensemble des politiques appliquées à chaque accès de données.

Pour harmoniser la gestion des opérations, le planificateur (Scheduler) est désormais intégré dans Design Studio (le remplaçant d’Administration Tool) afin de configurer les jobs de mises en cache. Pour les équipes œuvrant dans une approche DevOps, l’éditeur a intégré des moyens de résoudre les conflits avec Git et propose des « méthodes avancées pour générer des révisions de tables Delta Lake ».

En matière d’intégration, Denodo a revu son connecteur vers MongoDB qui est désormais natif et permet d’accélérer les requêtes. Il propose également des wrappers personnalisés pour les protocoles standards OData 2 et OData 4, ainsi qu’un adaptateur JDBC pour la DBaaS Alibaba MaxCompute.

Denodo mise sur PrestoDB

Surtout, depuis l’année dernière, Denodo mise pleinement sur le moteur massivement parallèle open source PrestoDB (à ne pas confondre avec Trino), conçu à l’origine chez Meta. Il a rejoint la Presto Foundation (filiale de la Linux Foundation).

« Lorsque le moteur d’exécution exécute une requête qui utilise une fonction de fenêtre au-dessus d’une sous-requête qui contient une construction SQL que Denodo ne peut pas pousser vers la base de données sous-jacente, le moteur d’exécution déplace les données vers le MPP (c’est-à-dire un serveur Presto) pour “résoudre la requête” », explique la documentation. À noter que l’éditeur orchestre ce moteur depuis des conteneurs Docker eux-mêmes gérés à l’aide de Kubernetes.

Ainsi, l’éditeur profite des évolutions de Presto pour prendre en charge les tables au format Apache Iceberg afin de mettre en cache les données d’une vue, pour les chargements de données en masse (bulk) et pour les stocker dans une table distante. Avec Delta Lake, Denodo détaille davantage les informations d’exécution des requêtes depuis son MPP. Enfin, les commandes DDL exécutées par le MPP, pour créer des tables mises en cache ou des vues virtuelles, peuvent être personnalisées depuis une UI.

Ces formats de table étant très populaires et comme la plupart des fournisseurs de gestion de données les prennent – au moins partiellement – en charge, l’éditeur a les moyens de convaincre un plus large panel d’entreprises.

C’était l’objectif de l’investissement mené par le fonds d’investissement TPG en 2023, un tour de table permettant à Denodo de récolter 336 millions de dollars en série B.

En tout cas, il semble vouloir résoudre point par point les défauts signalés par les clients ayant posté un commentaire sur G2 et Gartner Peer Insights ces quatre dernières années.

Denodo indique sur son site Web que BNP Paribas, Engie ou encore Sanofi sont clients. L’on peut également citer Suez.

Reste que des acteurs comme Dremio, Starburst, Snowflake, Google Cloud ou encore Databricks entendent répondre à certains cas d’usage similaires en s’appuyant sur la fédération de requêtes.