Polaris : Snowflake veut élargir l’accès aux tables Iceberg par des moteurs tiers
L’éditeur entend simplifier la centralisation des tables Apache Iceberg et les rendre accessibles à des moteurs de traitement tiers, ouverts ou propriétaires. Un projet qui engage déjà Microsoft, Salesforce, Google Cloud, Dremio, AWS et Confluent.
Lors de sa conférence annuelle, Snowflake a annoncé la création d’un catalogue adapté au format Apache Iceberg, nommé Polaris, qu’il rendra open source lors des trois prochains mois.
Pour rappel, Apache Iceberg est un format de table de données ouvert de plus en plus populaire. Il combine des formats de fichiers open source, souvent Parquet, mais aussi Avro et Orc avec un système de gestion de métadonnées. Ce dernier suit les partitions, l’évolution des schémas, et surtout permet de réaliser des snapshots afin de gérer plusieurs versions d’une table et effectuer des retours en arrière si nécessaire. Comme ce format est indépendant des moteurs de traitement open source et que les éditeurs qui l’adoptent conservent cette capacité, les clients l’apprécient pour sa portabilité.
La prise en charge d’Apache Iceberg, sur la feuille de route de Snowflake depuis deux ans, est encore en préversion publique au moment d’écrire ces lignes. Lors de la conférence téléphonique consacrée aux résultats financiers du premier trimestre fiscal 2025 en mai dernier, Shridar Ramaswamy, CEO de Snowflake, affirmait que plus de 300 clients sur 9 822 utilisent le format de tables. « Un grand nombre de nos clients les plus importants ont indiqué qu’ils utiliseraient désormais Snowflake pour davantage de charges de travail grâce à cette fonctionnalité », a assuré le dirigeant lors de cet appel.
« [Polaris] se concentre sur la possibilité d’indexer et d’organiser les données en conformité avec le format de tables Iceberg », assure Christian Kleinerman, vice-président directeur du produit chez Snowflake, lors d’une conférence de presse.
Dans le contexte d’Iceberg, les catalogues sont là pour gérer des collections de tables regroupées en namespaces. Un catalogue est responsable du suivi des métadonnées des tables et indique au moteur de traitement quelles données il doit lire et écrire. C’est en quelque sorte une couche de gestion de base de données.
Il existe plusieurs implémentations open source pour ce faire, par exemple, à travers des API Rest, le metastore Apache Hive, ou un connecteur JDBC.
« Les catalogues Iceberg sont flexibles et peuvent être mis en œuvre en utilisant presque n’importe quel système back-end. Ils peuvent être intégrés à n’importe quel moteur d’exécution Iceberg et permettent à n’importe quel moteur de traitement supportant Iceberg de charger les tables Iceberg suivies », indique la documentation du projet Iceberg.
Or la plupart des éditeurs, dont Snowflake et Databricks, ont fait en sorte que les catalogues ne permettent l’écriture et la lecture de données qu’avec leur moteur, alors que dans la plupart des configurations, les tables sont en lecture seule pour l’extérieur.
« Les clients tiers ne peuvent pas ajouter, supprimer ou réinsérer des données dans les tables Iceberg qui utilisent Snowflake comme catalogue », indique la documentation de Snowflake. Le partage de tables Iceberg entre plusieurs régions cloud ou entre plusieurs clouds n’est pas encore pris en charge par l’éditeur.
« Le volume externe du fournisseur, le compte Snowflake et le compte Snowflake du consommateur doivent tous se trouver dans la même région cloud ».
Il est bien possible d’utiliser AWS Glue pour gérer les catalogues, et donc d’écrire des données avec d’autres moteurs dans le Data AI Cloud, mais la chose est plus complexe à intégrer. Et propriétaire.
« Nous avons constaté que les catalogues sont devenus une nouvelle forme d’enfermement. La plupart des catalogues sont propriétaires et nous voulons renforcer notre engagement en faveur de l’open source ».
Christian KleinermanEVP Produit, Snowflake
« Nous avons constaté que les catalogues sont devenus une nouvelle forme d’enfermement. La plupart des catalogues sont propriétaires et nous voulons renforcer notre engagement en faveur de l’open source », affirme Christian Kleinerman.
L’idée est de rendre enfin exploitables les tables Iceberg par plusieurs moteurs de requête, pas seulement de pouvoir porter les données entre les systèmes.
Interopérabilité : de grands noms soutiennent Polaris
Christian Kleinerman assure que Snowflake a l’intention de prendre à bras-le-corps cet enjeu. « Nous mettons également l’accent sur l’interopérabilité [de Polaris] avec d’autres moteurs de requêtes », assure-t-il.
« Nous rassemblons un certain nombre de partenaires industriels pour nous assurer que nous pouvons donner à nos clients mutuels le choix d’assortir plusieurs moteurs de requête, d’être en mesure de coordonner, de lire et d’écrire les données, et le plus important, de le faire d’une manière ouverte, sans enfermement propriétaire », ajoute-t-il.
Polaris sera d’abord disponible en préversion publique comme « une fonctionnalité de première classe » du « Data AI Cloud » de Snowflake. Les clients de l’éditeur pourront contrôler les tables à l’aide de la couche de gouvernance Horizon, comme ils le font déjà pour les autres tables. Ils pourront également déployer eux-mêmes des instances de ce catalogue sur ses infrastructures et sur d’autres, en exploitant Docker ou Kubernetes.
Techniquement, le catalogue Polaris s’appuie sur le protocole REST d’Apache Iceberg, ce qui le rend de facto compatible avec les moteurs open source qui le prennent en charge. Pour l’instant, il est compatible avec Apache Doris, Apache Flink, Apache Spark, PyIceberg, StarRocks et Trino.
« Un nombre croissant de moteurs et de catalogues commerciaux et open source prennent en charge cette spécification REST API en raison de l’interopérabilité qu’elle offre », justifient des porte-parole de Snowflake, dans un billet de blog.
Justement, les partenaires évoqués par Snowflake s’appuient, eux aussi, – en partie tout du moins – sur ces moteurs de traitement pour leurs solutions propriétaires. Au côté de Snowflake, l’on retrouve AWS, Confluent, Microsoft Azure, Salesforce, Dremio et Google Cloud. Ceux-là s’engagent à prendre en charge Polaris Catalog.
Snowflake n’est pas le premier à s’engager sur cette voie. Son coopétiteur Dremio a déjà mis en place le projet Nessie, un catalogue transactionnel qui gère les namespaces et les tables dans une base de données à l’aide d’un système de gestion de version de type Git.
En s’alliant à Snowflake, il ne fait que rappeler ses engagements en la matière. Il est de même pour Goldman Sachs, cité dans un communiqué de presse. En revanche, Snowflake met en avant Microsoft et son lakehouse Fabric et Salesforce qui promeut en ce moment son Data Cloud et, surtout, la possibilité pour les clients d’effectuer des jobs de Reverse ETL afin de ne pas verrouiller leurs données dans la plateforme CRM. C’est aussi un moyen de renforcer les partenariats avec ces acteurs.
Une vision à étayer
La vision proposée par ces éditeurs vise, in fine, à centraliser l’accès aux tables Iceberg par plusieurs moteurs et, idéalement, de donner le choix aux clients où ils veulent déployer cette brique potentiellement indépendante des plateformes de stockage et de traitement. Il s’agit clairement d’aller (enfin) au bout des préceptes de la « Modern Data Stack », à savoir de stocker les données dans un data lakehouse ou dans un espace de stockage objet et de les cibler avec plusieurs moteurs de traitement.
En revanche, Snowflake n’a pas présenté de calendrier précis concernant l’ouverture de Polaris ni de détails sur la manière dont les éditeurs partenaires implémenteront ce projet.
De son côté, Confluent a indiqué que Polaris serait intégré à Tableflow, un moyen de simplifier la gestion de données d’Apache Kafka vers les tables Iceberg. Tableflow a été présenté en mars dernier, lors du Kafka Summit.
« […] Nous voulons faire progresser notre engagement en faveur de l’open source, mais nous n’avons pas encore spécifié exactement quel projet existant ou quelle fondation Polaris pourrait rejoindre », indique Christian Kleinerman.
Et au vice-président directeur d’insister sur les investissements récents dans la prise en charge d’Iceberg, l’entraînement de collection de modèles open weight Arctic (sous licence Apache 2.0) et sa contribution principale dans Streamlit, un framework de développement d’applications de données qu’il a acquis au mois de mars 2022.
