Sergey Bogomyako - stock.adobe.c
AIStor Table Sharing : MinIO convertit Databricks au cloud hybride
Alors qu’Ali Ghodsi, cofondateur et CEO de Databricks refusait mordicus l’extension de la plateforme vers les environnements sur site, voilà que ses clients l’ont poussé à faire le contraire. Et c’est le spécialiste du stockage objet MinIO qui dit avoir trouvé le moyen de simplifier cette tuyauterie jusqu’alors complexe.
Un dogme persiste chez Databricks. Si l’éditeur dirigé par Ali Ghodsi intégrait sa plateforme avec les lacs de données et autres entrepôts déployés sur site, c’était pour mieux les ingérer à des fins d’analyse ou de traitement. Ou mieux, pour lui, les migrer définitivement. Aux clients de se débrouiller s’ils souhaitaient stocker les données sur site. À eux de maintenir une version de Delta Lake. Une autre solution existe depuis 2023 : il faut passer par Dell ECS, qui s’occupe de packager Delta Lake. Snowflake a fait de même avec Pure Storage pour requêter des tables externes sur ses baies à travers les API PortWorx (une offre que l’entreprise n’aime pas proposer). Une option supplémentaire, plus versatile, fait son apparition.
« Cloud Only » : Databricks baisse (un peu) les armes
MinIO a obtenu le soutien de Databricks pour intégrer le protocole Delta Sharing au sein de son offre AIStor. « Les clients nous demandent systématiquement de pouvoir gouverner et partager les données stockées dans le cloud et en dehors du cloud », reconnaît Stephan Orban, SVP, écosystème produits et partenariats chez Databricks, dans un communiqué de presse. « Grâce à l'intégration native de Delta Sharing, MinIO permet aux entreprises de connecter en toute sécurité leurs données sur site à Databricks sans réplication complexe, ce qui accélère l'obtention d'informations avec les charges de travail hybrides ».
Cette capacité s’appuie sur les tables AIStor, lancé en disponibilité générale en février 2026. Comme AWS avec ses S3 Tables, MinIO intègre la gestion des tables de données dans sa technologie de stockage objet compatible S3.
En février, l’éditeur avait commencé par annoncer la prise en charge d’Apache Iceberg V3. Dans les faits, MinIO a rendu son client AIStor compatible avec PyIceberg, une API Python permettant d’interagir avec des tables Iceberg. Dans son implémentation, l’éditeur a ajouté la possibilité de créer un entrepôt qui accueille les tables AIStor, à travers une API dédiée. Du fait de la compatibilité avec l’API Iceberg et REST Catalog, ce « warehouse » peut être interrogé par différents moteurs analytiques et de transformation, dont Dremio, Apache Spark, Starburst et Trino.
Delta Sharing s’invite dans le binaire AIStor
L’intégration de Delta Sharing, le protocole d’échange lié à Delta Lake, la technologie open source contribuée par Databricks, et la fondation de sa suite de gestion de données, permet désormais de prendre en charge les tables Iceberg formatées pour Delta Sharing… et les tables Delta en lien avec la plateforme de Databricks. Mieux, cela rend la couche de stockage objet avec toutes les technologies compatibles avec le protocole Delta Sharing, dont PowerBI. Les données peuvent être interrogées par plusieurs moteurs, sans les répliquer. Par exemple, Databricks lit les données et métadonnées directement depuis l’API AIStor. Rappelons que les formats de tables Delta et Iceberg s’appuient tous deux sur le format de données Apache Parquet.
Techniquement, MinIO implémente le format universel Delta (UniForm) au cœur du binaire d’AIStor. « Il n'y a donc pas de conteneurs side-car ni de proxys tiers à déployer. L'authentification est flexible et prend en charge les tokens porteurs pour un accès simple et l'intégration OAuth2/OIDC pour la fédération d'identités de niveau entreprise », affirme MinIO.
Il faut toutefois correctement implémenter les conditions d’accès aux tables, schémas, chemins afin de limiter l’éventuelle surface d’attaques. À noter que ces règles gérées depuis AIStor ne sont pas compatibles nativement avec le partage de tables. « Excluez les partages de tables des règles de cycle de vie afin d'éviter toute corruption accidentelle des données des tables et des métadonnées associées », recommande l’acteur, dans sa documentation.
Pour les charges de travail d’IA et de machine learning en production, MinIO réclame des interfaces réseau de 10 Gb/s minimum et recommande plutôt 100 Gb/s quand la concurrence des requêtes est forte. L’éditeur n’a pas présenté de benchmarks pour donner une idée des performances. Les deux grosses limitations, actuellement, sont l’absence de la prise en charge de la réplication à des fins de reprise d’activité et le chiffrement SSE.
MinIO offre là une capacité taillée pour le cloud hybride. Il faut donc recourir aux fonctions de type PrivateLink pour éviter l’exposition des données à l’Internet public. Et de vanter l’aspect multicloud de sa solution. « En prenant en charge à la fois les tables Delta et Apache Iceberg, MinIO évite d'enfermer ses clients dans une seule voie analytique ou un modèle de partage propriétaire », assure l’entreprise.
Faire du stockage objet le centre de gravité du Lakehouse
Selon Don Gentile, analyste spécialiste du stockage et de la résilience de données chez HyperFrame Research, MinIO pousse une approche singulière dans une tendance de fond. « La frontière entre le lac de données et la couche de stockage devient de moins en moins nette », déclare-t-il, dans un billet de blog. « Les fournisseurs rapprochent les capacités d'accès aux données et de gouvernance du substrat de stockage ».
Alors qu’habituellement, le partage de données est géré par la plateforme analytique ou depuis un serveur distinct – par exemple celui dédié à Delta Sharing dans son implémentation originelle – MinIO l’embarque, ici, dans la couche de stockage objet. « L'avantage potentiel réside dans la simplification architecturale et la réduction de la prolifération opérationnelle », soupèse-t-il.
Le principe de séparation du stockage et du calcul s’invite aussi sur site. Il n’est plus nécessaire d’imposer la copie des données vers le cloud avant de les traiter et de renvoyer les résultats. Un processus coûteux et complexe, rappelle l’analyste. Reste que l’exposition de certaines données au cloud public, même à travers un lien privé n’est pas toujours souhaitée.
« En contrepartie, la plateforme de stockage assume davantage de responsabilités, ce qui peut modifier la façon dont les organisations envisagent l'autorité de gouvernance au sein de l'architecture Lakehouse au sens large », anticipe-t-il.
Cette volonté de faire de la couche de stockage objet le centre de gravité du Lakehouse n’est pas exclusive à MinIO. De fait, des acteurs comme Fivetran, Dremio, Starburst et dans une certaine mesure Qlik, ainsi qu’AWS la partagent. Cette approche plus modulaire du Lakehouse non pas vu comme une solution unifiée ne fait pas forcément consensus, même si elle paraît plus réaliste au vu des paysages de données éclatées au sein des entreprises. Databricks et Snowflake ont convaincu leur monde. Hyperscalers compris.
Et, malgré ce désir de MinIO de jouer la carte de l’OpenShift du stockage objet, Don Gentile rappelle la jeunesse de la fonctionnalité. « Bien que MinIO indique que son développement a été motivé par la demande des clients, la plupart des entreprises en sont encore à l'étape de l'évaluation plutôt qu'à celle de la mise en œuvre à grande échelle », insiste-t-il. « Pour l'instant, cette annonce doit être comprise comme un indicateur architectural de la manière dont les plateformes lakehouse et les systèmes de stockage pourraient continuer à évoluer ensemble ».
