En sus de son lakehouse open source, la startup Dremio développe Arctic, une surcouche pour reproduire les fonctions des dépôts Git à partir des projets open source Nessie, Apache Iceberg et Delta Lake.
Ce n’est pas Snowflake ou Databricks. Certes. Et pourtant, Dremio est sans doute l’un des acteurs les plus influents dans le petit monde du Big Data.
Déjà, la startup bénéficie d’un fort soutien de la part des investisseurs : Dremio a levé près de 410 millions de dollars, dont 160 millions de dollars en série E en janvier 2022. Elle commence à convaincre des grands comptes, dont La Poste, Michelin, BNP, Airbus, ou encore Allianz.
Pourquoi ? Parce que son offre technologique permet une grande versatilité. Dremio s’inscrit dans la mouvance Lakehouse, mais n’oblige pas ses clients à opter pour un format de tables et de fichiers propriétaires ou soutenus par un petit nombre d’acteurs. Il s’agit d’un « Open Data Lakehouse ».
Dremio n’est pas le seul à prôner cette approche. Elle émane d’abord de l’adoption de formats de fichier open source de type Apache Parquet, mais surtout de l’adoption massive du stockage objet. Un lakehouse n’est autre qu’un lac de données sur lequel on appose une couche ACID. Or, les éditeurs tels Snowflake, Teradata ou encore Microsoft ont d’abord verrouillé les formats de tables.
L’avènement du Lakehouse ouvert
« L’ère du lakehouse ouvert a réellement été permise par les formats de table comme Apache Iceberg ou Delta Lake qui évite de rester captif par rapport à un éditeur spécifique », affirme Tomer Shiran, cofondateur et Chief Product Officer chez Dremio, lors d’un meetup organisé par l’écosystème « Modern Data Stack ».
Adopter un format de tables ouvert permet de changer de moteur de traitements pour réaliser plusieurs sortes de projets à partir des mêmes données ou d’assurer la réversibilité entre solutions de datawarehousing.
« Même les fournisseurs d’entrepôts de données comme Snowflake et Google avec BigLake s’y mettent, mais c’est un peu maladroit, car ce sont des formats additionnels pour eux », ajoute-t-il. « Ils ont tous bâti leurs optimisations sur leur format propriétaire et maintenant ils réalisent que le marché se dirige vers des formats de données ouverts. Et donc ils s’empressent d’ajouter ce genre de capacités ».
Dremio est un Lakehouse ouvert, oui, mais surtout un Lakehouse « logique ».
Tout comme Databricks, Dremio veut éviter la copie à outrance des données et la gestion complexe de flux ETL. Au lieu de regrouper physiquement les données en un seul endroit, la startup mise aussi sur la virtualisation de données et la fédération de requêtes.
Ses technologies ne remplacent pas les entrepôts de données, les bases de données et les data lakes installés, elles s’y connectent pour manipuler des tables virtuelles et des tables physiques. Elles permettent de les joindre et de réaliser diverses opérations de transformation, en vue de les pousser vers des outils analytiques, de BI ou des notebooks de type Jupyter ou encore Apache Zeppelin.
Pour cela Dremio mise sur Sonar, une couche d’accès « unifiée » aux données, à savoir un moteur de requêtes qui comprend une couche sémantique servant à constituer un data catalog et une fonctionnalité de data lineage. Ce moteur d’exécution distribué orienté colonnes s’appuie sur Apache Arrow, un projet cocréé par Dremio. Apache Arrow est une boîte à outils qui permet de spécifier un format colonnaire en mémoire agnostique des langages de programmation afin de manipuler des données « plates et hiérarchiques ». Chez Dremio, Arrow est couplé au projet Gandiva, une librairie LLVM pour optimiser les traitements vectorisés au niveau CPU.
Une des utilisations les plus simples consiste à utiliser des connecteurs JDBC/ODBC pour se servir de Dremio comme une couche de fédération de requêtes ad hoc sur des tables physiques résidant dans des bases de données (Oracle, DB2, PostgreSQL, MySQL, etc.).
Or les entreprises ont des environnements complexes qui requièrent de croiser des données situées dans des tables et des vues. Il s’agit de le faire rapidement, car ces requêtes sont souvent effectuées à travers un outil BI pour réaliser des rapports sur de gros volumes de données. De plus, l’utilisateur métier souhaite obtenir des résultats rapidement.
Pour ce faire, Dremio pousse le concept de « réflexion ». Les réflexions sont des sortes de vues matérialisées de tables ou de vues (alors considérées comme des ancres de ces réflexions) utilisées par l’optimiseur de requêtes de Dremio afin d’accélérer les requêtes. En clair, quand un utilisateur final (par exemple un business analyst) interroge un tableau de bord, Sonar choisit la meilleure structure de données sur laquelle effectuer la requête. Il y a donc une phase de préparation et de gestion nécessaire de ces réflexions pour les data engineers. Il faut voir ce concept comme l’automatisation partielle d’un Datamart.
Quand la requête est trop complexe ou quand le moteur de Dremio ne prend pas en charge certains types de données ou de transformation, une partie de l’opération peut être externalisée dans une base de données source, ou à l’aide d’un autre moteur de traitement de données. Les transformations effectuées à l’aide des outils de Data Science, comme des notebooks Jupyter ou via Python passent par Arrow Flight. Sonar est souvent utilisé en conjonction de couche de cache cloud pour charger les réflexions, des fichiers Parquet et les métadonnées des différents éléments manipulés.
Outre une version open source, l’offre de Dremio est disponible sur site, mais aussi en version cloud. La startup prépare également une version managée de son Lakehouse nommée Dremio Cloud, disponible en 2023.
Malgré la complexité sous-jacente, Dremio propose une interface simple d’utilisation. Les usagers peuvent connecter leurs outils de BI préférés (Tableau, Power BI, etc.) et y accéder depuis la console en un seul clic.
Dremio prône l’adoption du « Data as Code »
Mais la startup pousse un autre concept : le « Data as Code ». « Nous croyons qu’il est possible de réimaginer la manière dont nous faisons de la gestion de données », affirme Tomer Shiran. « Pour développer des applications et gérer du code, nous avons des systèmes comme Git qui permettent de gérer les sources, les versions et les dépendances du code. Ce serait très bénéfique d’obtenir la même chose pour les données ».
« Pour développer des applications et gérer du code, nous avons des systèmes comme Git [...]. Ce serait très bénéfique d’obtenir la même chose pour les données. »
Tomer ShiranCofondateur et Chief Product Officer, Dremio
« Traiter les données comme du code » permettrait d’effectuer de la gestion de versions de données, de tracer les opérations antérieures, de restaurer des données ou des schémas. Pour cela, Dremio s’appuie sur le projet Nessie, dont il est le principal contributeur. Nessie permet de versionner et de gérer les attributs de tables au format Apache Iceberg ou Delta Lake. Nessie propulse Dremio Arctic, un métastore disponible en préversion qui doit automatiser une partie des tâches de gestion de données comme le partitionnement, l’indexation ou la compression des données.
Le Data as Code permettrait d’isoler des tables afin d’effectuer des transformations ou des optimisations avant de les proposer en validation et de les fusionner avec une « branche principale ». Les contrôles de versions faciliteraient la consultation de tableaux de bord ou la revue d’un modèle de machine learning bâti avec des données historiques. Enfin et surtout, cette approche permettrait une meilleure gouvernance des produits de données, notamment concernant l’administration des accès.
« Parfois, chez Dremio, un de nos clients a un problème, très rare et sporadique, que nous ne pouvons pas reproduire. Que faisons-nous ? Nous cherchons à savoir qui a modifié cette partie du code au cours du mois dernier et qui pourrait en être à l’origine », illustre Tomer Shiran. « Nessie et Arctic doivent faire la même chose pour les données. Si quelque chose semble bizarre, le montant moyen des ventes ne correspond pas à vos évaluations, vous vous demandez : qui a modifié cette table ? Quelles sont les commandes SQL ou les jobs spark qui ont été exécutés sur cette table ? »
En novembre dernier, Dremio avait déjà présenté la possibilité d’effectuer des requêtes Time Travel, à savoir le fait de manipuler des snapshots Iceberg créés à un instant T. En réalité, ce retour en arrière et le versionning de tables sont des capacités d’Apache Iceberg et Delta Lake, tout comme le partitionnement caché ou le retour à une version antérieure. En clair, Nessie est la technologie qui exploite les métadonnées issues de ces formats de tables, tandis qu’Arctic est une surcouche pour que les équipes data puissent manipuler ces fonctionnalités.
La disponibilité de Dremio Arctic est prévue cette année. La startup précisera sa feuille de route lors de son événement SubSurface au début du mois de mars.
