Catalogue de données cloud automatisé pour Snowflake et Databricks

Le débat « Databricks vs Snowflake » masque une réalité de terrain : la plupart des organisations data ne choisissent pas, elles utilisent les deux. L’une pour l’entrepôt analytique, l’autre pour la plateforme lakehouse et l’apprentissage automatique (machine learning). Les métadonnées se dispersent alors dans deux univers étanches, chacun doté de son catalogue natif. Un catalogue de données (data catalog) cloud automatisé et agnostique se place au-dessus de ces deux plateformes. Il unifie leurs métadonnées, reconstruit un lignage de bout en bout et ajoute une couche de sens métier. Il ne remplace pas les catalogues natifs : il les fédère.

• Deux plateformes, deux catalogues natifs. Databricks a Unity Catalog, Snowflake a Horizon et Polaris. Chacun gouverne bien son périmètre, et s’arrête à sa frontière.
• Les silos naissent de cette étanchéité. Une même donnée circule d’une data platform à l’autre sans qu’aucun catalogue natif ne voie le trajet complet.
• Un catalogue cross-plateforme réunifie l’ensemble. Il auto-découvre les sources, classe et documente les objets, puis relie les deux mondes.
• Le lignage cross-plateforme est le gain décisif. Suivre une donnée de Snowflake à Databricks et retour, colonne par colonne, sans reconstitution manuelle.
• Les formats de tables ouverts rendent l’interopérabilité possible. Apache Iceberg, Delta Lake et l’Iceberg REST catalog effacent une partie des frontières techniques.
• Fédérer, pas remplacer. Le catalogue tiers se connecte aux catalogues natifs et ajoute glossaire, gouvernance et contexte métier.

Catalogage automatisé sur Snowflake et Databricks : le problème des silos

Un environnement data moderne rassemble rarement toutes ses données au même endroit. Les équipes analytiques travaillent sur Snowflake, un data warehouse (entrepôt de données) cloud pensé pour le SQL, le reporting et la business intelligence (BI). Les équipes data science et data engineering (ingénierie des données) s’appuient sur Databricks, une architecture lakehouse qui unifie stockage de fichiers et traitements distribués. Les deux plateformes tournent sur les grands clouds, de Databricks sur AWS ou Google Cloud à Azure Databricks, et partagent souvent le même stockage cloud objet en arrière-plan. Cette coexistence est la norme.

Deux plateformes, deux catalogues natifs

Chaque plateforme embarque désormais son catalogue. Côté Databricks, Unity Catalog centralise la gouvernance des tables, vues, modèles et volumes. Côté Snowflake, Horizon Catalog assure découverte, sécurité et conformité ; Polaris Catalog gère l’interopérabilité autour des tables Iceberg. Ces outils sont bien intégrés. Le souci n’est pas leur qualité, mais leur portée : chacun connaît parfaitement son périmètre, et lui seul.

Pourquoi les métadonnées se fragmentent

La fragmentation est mécanique. Un pipeline lit une table brute dans Databricks, la transforme, puis pousse le résultat vers un schéma Snowflake qui alimente un tableau de bord. Unity Catalog voit l’amont. Horizon voit l’aval. Aucun ne voit la jointure. Les métadonnées (metadata) d’une même donnée existent alors en double, désynchronisées, sans référentiel commun. Un analyste qui cherche l’origine réelle d’un indicateur se heurte à un mur invisible au milieu de la chaîne.

Les catalogues natifs couvrent chacun leur propre plateforme, mais aucun ne voit nativement le parcours complet d’une donnée lorsqu’elle passe de Databricks à Snowflake.

À cette rupture technique s’ajoute un déficit de sens. Les catalogues natifs décrivent des objets physiques : noms de colonnes, types, tailles. Ils ne disent pas ce qu’une table signifie pour le métier, qui en est responsable, ni si elle contient des données personnelles. Ce contexte manquant bloque le libre-service (self-service) et ralentit la mise en conformité.

Les catalogues natifs : Unity Catalog, Snowflake Horizon et Polaris

Comprendre ce que font, et ne font pas, les catalogues natifs est la base d’une stratégie multi-plateforme lucide. Voici l’essentiel, sans procédure de configuration.

Unity Catalog (Databricks)

Unity Catalog est la couche de gouvernance unifiée de Databricks. Elle gère les permissions, le catalogage et le lignage à l’échelle d’un workspace ou d’un compte. Elle gouverne aussi les emplacements externes (external locations), ces pointeurs vers le stockage cloud objet où résident les fichiers. En juin 2024, Databricks l’a rendue open source sous licence Apache 2.0, hébergée par la LF AI & Data Foundation. Cette version ouverte supporte l’API Apache Iceberg REST Catalog et l’API Apache Hive metastore, ce qui la rend agnostique au moteur de calcul. Elle intègre un journal d’audit et un data lineage jusqu’au niveau colonne, et lit Delta Lake, Apache Iceberg et Apache Hudi. Sur son propre terrain, c’est un catalogue complet.

Snowflake Horizon et Polaris Catalog

Snowflake distingue deux briques. Horizon Catalog est le catalogue natif de gouvernance et de découverte du Data Cloud : conformité, sécurité, confidentialité, contrôle d’accès et interopérabilité forment un ensemble unifié. Il étend la gouvernance aux formats de tables ouverts et se synchronise, via des « Catalog-Linked Databases », avec des objets Iceberg gérés par différents Iceberg REST Catalogs, dont Snowflake Open Catalog et AWS Glue.

Polaris Catalog, dévoilé au Snowflake Summit 2024, est un catalogue open source, implémentation ouverte et neutre pour Apache Iceberg, bâtie sur le protocole Iceberg REST. Snowflake s’est engagé à l’open-sourcer, et le projet est passé sous la fondation Apache sous le nom d’Apache Polaris. Il tourne hébergé dans Snowflake ou en auto-hébergé. Son rôle : permettre à plusieurs moteurs de partager les mêmes tables Iceberg sans dépendre d’un seul fournisseur.

Leurs limites en environnement multi-plateforme

Ces catalogues convergent : Unity Catalog en open source, Polaris chez Apache, Horizon qui s’ouvre aux Iceberg REST catalogs. Cette convergence technique est réelle, portée par l’adoption commune des formats ouverts. Mais elle ne résout pas la gouvernance transverse. Un catalogue natif reste ancré dans sa plateforme d’origine et sert d’abord ses propres charges de travail. Il n’a ni vocation ni intérêt à documenter le patrimoine de son concurrent.

Le tableau révèle la vraie zone aveugle : personne ne couvre nativement l’espace entre les deux. C’est là qu’un catalogue tiers prend son sens.

Ce qu’automatise un catalogue de données cloud

Cataloguer à la main deux plateformes en croissance permanente est intenable. L’automatisation n’est pas un confort, c’est une condition de survie du référentiel. Elle repose sur les métadonnées actives (active metadata) : au lieu d’un inventaire figé, le catalogue observe en continu les sources et se met à jour seul.

Auto-découverte et connexion des sources

Premier automatisme : l’auto-découverte. Le catalogue se branche sur Snowflake et Databricks par des connecteurs dédiés, puis balaie leurs systèmes de métadonnées. Il recense schémas, tables, colonnes, vues et volumes, détecte les nouveaux objets et signale ceux qui disparaissent. L’inventaire vit au rythme des plateformes, sans ressaisie. Une donnée créée le matin dans un notebook Databricks apparaît dans le catalogue sans intervention humaine.

Auto-classification et documentation

Deuxième automatisme : l’auto-classification. En analysant les schémas, les noms et parfois un échantillon de valeurs, le catalogue reconnaît des types sensibles, un e-mail, un identifiant national, un montant, et applique des étiquettes de sensibilité. La documentation se pré-remplit de même : descriptions suggérées, propositions de propriétaire, rattachement à un domaine. Les équipes valident et enrichissent au lieu de partir de zéro.

Lignage cross-plateforme automatique

Troisième automatisme, le plus différenciant : le lignage cross-plateforme. En lisant les requêtes, les définitions de vues et les pipelines de transformation, le catalogue reconstruit le parcours réel de la donnée. Il relie une table source Databricks à sa table cible Snowflake, puis au rapport final, en traversant la frontière que les catalogues natifs ne franchissent pas. Ce fil continu, un lignage de bout en bout, transforme l’analyse d’impact et le diagnostic d’incident. Quand un champ change en amont, on voit immédiatement tout ce qui casse en aval, sur les deux plateformes.

Formats de tables ouverts : la clé de l’interopérabilité

Si le catalogage cross-plateforme est devenu réaliste, c’est grâce à une évolution de fond : les données ne sont plus prisonnières d’un moteur. Les formats de tables ouverts (open table formats) ont banalisé le partage.

Apache Iceberg, Delta Lake et Iceberg REST catalog

Apache Iceberg est un format de table ouvert conçu pour de très grands jeux de données analytiques. Il ajoute une couche de table SQL au-dessus de fichiers stockés dans le cloud et laisse plusieurs moteurs, Apache Spark, Trino, Flink et d’autres, lire et écrire les mêmes tables en simultané. Delta Lake vise un but voisin : ce framework de stockage open source enrichit les fichiers Parquet d’un journal de transactions, pour apporter des transactions ACID, une gestion scalable des métadonnées et l’unification batch et streaming sur des data lakes existants.

L’Iceberg REST catalog est la pièce d’articulation. C’est un protocole standard par lequel un moteur interroge un catalogue pour savoir où vivent les tables Iceberg et comment les lire. Unity Catalog l’expose, Polaris repose dessus, Horizon s’y synchronise. Les trois catalogues natifs parlent donc une langue commune autour d’Iceberg. Un metastore partagé et ce protocole ouvert permettent à une table écrite d’un côté d’être lue de l’autre sans copie. Le catalogue tiers s’appuie sur cette interopérabilité pour cartographier ce qui circule réellement entre les plateformes, plutôt que de deviner.

Fédérer plutôt que remplacer : le catalogue tiers au-dessus des deux

La bonne stratégie n’oppose pas catalogue natif et catalogue tiers. Elle les articule. Les catalogues natifs restent le point d’ancrage opérationnel de chaque plateforme : permissions, exécution, gouvernance de proximité. Le catalogue agnostique se place au-dessus et tient un rôle qu’aucun natif ne peut assurer : la vue d’ensemble.

Les catalogues natifs couvrent chacun leur propre plateforme, mais aucun ne voit nativement le parcours complet d’une donnée lorsqu’elle passe de Databricks à Snowflake.

Connecteurs et fédération des catalogues natifs

La fédération de catalogue consiste à connecter le catalogue tiers aux catalogues natifs plutôt qu’à recopier leurs contenus. Via ses connecteurs, il interroge Unity Catalog et Horizon, ingère leurs métadonnées et les projette dans un référentiel commun. Les définitions techniques restent maîtresses côté plateforme ; le catalogue fédéré les reflète, les relie et les enrichit. On évite ainsi la double saisie et le référentiel fantôme qui se périme. Le principe est celui de la synchronisation continue, pas de la migration.

Cette approche respecte les investissements déjà faits. Une équipe qui a structuré Unity Catalog ne repart pas de zéro : son travail remonte tel quel dans la vue unifiée. Idem pour Horizon et Polaris. Le catalogue cross-plateforme capitalise sur l’existant au lieu de le concurrencer.

La couche métier et la gouvernance unifiée

Au-dessus des métadonnées techniques fédérées, le catalogue tiers ajoute ce qui manque ailleurs : le sens. Un glossaire relie chaque terme de l’entreprise, chiffre d’affaires, client actif, marge, aux tables et colonnes physiques qui le portent, sur Snowflake comme sur Databricks. Cette couche sémantique, un glossaire métier partagé, aligne enfin le vocabulaire des équipes data et celui des métiers.

La gouvernance des données devient alors transverse. Politiques de confidentialité, responsabilités et règles de conformité s’expriment une fois, à l’échelle du patrimoine entier, et non plateforme par plateforme. Le libre-service en profite directement : un utilisateur cherche un indicateur, trouve sa définition métier, son propriétaire, son niveau de sensibilité et son lignage complet, sans se soucier de l’endroit physique où la donnée réside.

L’enjeu dépasse le seul reporting. Gartner a prédit qu’au moins 30 % des projets d’IA générative seraient abandonnés après la phase de preuve de concept (proof of concept, POC), notamment à cause d’une qualité de données insuffisante et de contrôles des risques inadéquats. Un catalogue unifié, en fiabilisant et en documentant les données qui alimentent les modèles, s’attaque à cette cause racine.

Cas d’usage fréquents d’un catalogue cross-plateforme

Ces bénéfices se concrétisent dans des cas d’usage (use cases) précis. Le tableau les positionne selon leur valeur métier et leur faisabilité une fois le catalogue automatisé en place sur Snowflake et Databricks.

La logique est constante : plus le lignage et le contexte métier sont automatisés, plus ces usages passent d’un effort ponctuel à une capacité permanente.

Choisir un catalogue automatisé pour Snowflake et Databricks

Toutes les solutions ne se valent pas sur ce terrain. Le bon réflexe est d’évaluer un catalogue au regard de la réalité multi-plateforme, pas d’une démo mono-source. Une évaluation structurée évite de se laisser séduire par des fonctions périphériques et garde le cap sur ce qui compte.

Les critères d’évaluation

Le fil conducteur est simple : le catalogue doit rendre le paysage lisible dans son ensemble, sans imposer un nouveau point de captivité. Un outil qui ne saurait fédérer que Snowflake, ou que Databricks, reproduirait le problème qu’il prétend résoudre.

C’est l’orientation de un catalogue de données automatisé agnostique, qui se connecte à Snowflake et à Databricks, fédère leurs catalogues natifs et réunit métadonnées, lignage et glossaire métier dans un seul référentiel gouverné. À mesure que les usages analytiques et les modèles d’IA se nourrissent des mêmes données, cette vue unifiée devient le socle pour gouverner données et IA dans un cadre unifié, au-dessus des plateformes plutôt qu’à l’intérieur de chacune.

À propos de l'auteur: Max Faivre

Product Marketing Manager