Apache Iceberg : Snowflake libère Polaris et s’allie à Dremio

Unity Catalog vs Polaris Catalog : des mécanismes de base très similaires

Outre la mise à disposition du code sous licence Apache 2.0, Snowflake propose une implémentation managée de Polaris en préversion publique sur sa plateforme. Elle est également accessible en test pour des prospects qui voudraient essayer le « Data Cloud ». Cela réclame de créer un compte dédié au catalogue Polaris.

Depuis le dépôt GitHub, Snowflake fournit les instructions pour déployer cette couche qui tient sur des conteneurs Docker en dehors de sa plateforme sur un serveur ou à partir de deux pods Kubernetes.

Dans Snowflake, l’implémentation de la spécification REST d’Iceberg est voisine de celle proposée par Databricks.

Avec Polaris, l’on retrouve le même principe de Namespaces imbriqués ou de hiérarchisation des tables qu’avec Unity Catalog (la convention de nommage est elle-même très proche). Ici, cela sert à regrouper logiquement des tables Iceberg sous des espaces de noms, eux-mêmes potentiellement régis par des namespaces, le tout sous l’égide d’un catalogue.

Le catalogue a deux fonctions principales. D’abord, il stocke les pointeurs de métadonnées. « Un pointeur de métadonnées associe le nom d’une table à l’emplacement du fichier de métadonnées actuel de cette table », précise la documentation de Snowflake.

Puis, il hérite des capacités d’iceberg. Il permet « d’effectuer des opérations atomiques afin de mettre à jour le pointeur de métadonnées actuel d’une table avec le pointeur de métadonnées d’une nouvelle version de la table ».

En revanche, Snowflake distingue des catalogues internes, pilotés par Polaris, de catalogues externes. Un catalogue interne renferme des tables Iceberg pouvant être lus et écrites par plusieurs moteurs de requêtes, tandis que son équivalent externe peut être géré par Snowflake, AWS Glue ou Dremio Arctic. Ici, les tables sont synchronisées dans Polaris, mais ne sont qu’en « read-only ».  Cette deuxième option est la seule actuellement disponible dans la plateforme de l’éditeur. Aussi le catalogue pointe vers un volume de stockage objet spécifique, soit Amazon S3, soit Azure Storage, soit GCS.

En clair, la promesse d’interopérabilité avec d’autres moteurs de requêtes n’est pour l’instant pas respectée. Avec Unity Catalog, quelques moteurs peuvent lire et écrire des tables au format Iceberg, Delta et UniForm.

L’autre engagement derrière Polaris, c’est d’offrir une gestion des accès et des rôles unifiée pour les moteurs, les espaces de stockage, les catalogues ainsi que l’ensemble des données et métadonnées. Dans le cas présent, Snowflake a mis en place l’ensemble des mécanismes, en utilisant les paradigmes de Polaris (dont un modèle RBAC) et le IAM des fournisseurs de stockage.

« Alors que d’autres catalogues hébergés par des éditeurs s’écartent de la spécification [REST d’Iceberg], ce qui conduit à un verrouillage, le service de Snowflake pour Polaris Catalog respecte à la lettre l’implémentation open source avec Polaris Catalog, maintenant et demain », assure Snowflake.

La fusion programmée de Polaris Catalog et de Project Nessie

Toutefois, contrairement à Unity Catalog, Polaris ne semble pas prendre en charge des objets tels que des fonctions d’IA et des volumes de données.

Mais le projet pourrait profiter de divers avantages. Dans le billet de blog qui accompagne la disponibilité de Polaris, Dremio, annonce que son Project Nessie, un autre catalogue open source reprenant une sémantique proche de Git, va fusionner avec la solution ouverte proposée par Snowflake.

« La contribution des capacités du projet Nessie au catalogue Polaris formera une communauté inclusive dédiée au développement du catalogue open source le plus robuste pour les architectures open lakehouse », écrit Tomer Shiran, cofondateur et Chief Product Officer chez Dremio.

Outre la réduction des efforts de conception et de support, Dremio compte apporter les fonctionnalités de Nessie telles que « le versionnage de données au niveau du catalogue, la prise en charge de plusieurs moteurs de requêtes, les transactions multibase et un modèle de gestion basé sur Git ».

Pour rappel, Dremio est davantage un concurrent de Starburst que de Snowflake avec ses fonctions de fédération de requêtes. Dremio est cofondateur du projet Apache Arrow, créateur de Nessie et un contributeur régulier à Apache Iceberg.

Le projet fusionné sera géré par et pour la communauté, assurent Dremio et Snowflake.

Snowflake et Dremio se tournent vers l’Apache Software Foundation

À l’annonce de Polaris, Snowflake n’avait pas encore décidé à quelle fondation le projet serait confié. Aujourd’hui, Jean-Baptiste Onofré, ingénieur logiciel principal chez Dremio et membre au comité des directeurs de l’Apache Software Foundation, a formulé la proposition d’incubation de Polaris au sein de l’ASF.

« Bien que la plupart des membres de l’équipe de développement proviennent de deux sociétés, ces sociétés, Snowflake et Dremio, sont engagées dans l’open source, avec de l’expérience sur plusieurs projets ASF », écrit Jean-Baptiste Onofré.

Si la demande est acceptée, la marque déposée Polaris Catalog sera donnée à la fondation par Snowflake.