Databricks étend sa gouvernance au-delà des données et de l’IA

Lors de son événement annuel, Databricks a surtout mis en avant le fait qu’il rend open source les fondations de sa couche de gouvernance, mais sa variante propriétaire s’étoffe pour gérer et tracer davantage d’actifs, ainsi que d’en superviser la qualité et les coûts.

Unity Catalog c’est la couche de gouvernance de Databricks, celle pour laquelle certains clients choisissent d’adopter sa plateforme plutôt que les solutions concurrentes. Plus de 10 000 sur 12 000 de ses clients l’utiliseraient. Mais qu’est-ce que l’inventeur de Delta Lake et MLFlow fait mieux que les autres ? Quelles sont les fonctionnalités clés de cette couche de gouvernance ?

Première chose à retenir, Databricks n’est pas forcément au-dessus de ses rivaux, il est sans doute un peu plus rapide.

En effet, Databricks a présenté cette couche de gouvernance centralisée en 2021. Depuis, il déploie petit à petit les fonctionnalités qui, selon ses dires, facilitent la gestion des permissions et l’audit de l’ensemble des actifs présents dans le lakehouse. Il tente désormais d’en superviser les coûts.

Une hiérarchie des actifs à suivre à la lettre

Pour cela, cette strate est composée d’au moins un métastore rassemblant les métadonnées et les objets dûment enregistrés et d’un système de gestion des utilisateurs. Unity Catalog peut être intégré avec un IDP de type Entra ID (Azure AD) ou Okta afin de gérer des groupes d’usagers. Unity Catalog peut orchestrer les aspects de gouvernance de données pour les espaces de travail (workspaces) Databricks associés.

Ce métastore hiérarchise les objets en trois niveaux. Il est « représenté comme un espace de noms à trois niveaux (catalog.schema.table-etc) », indique le fournisseur.

Le premier niveau est réservé aux catalogues. Ces catalogues de données renferment des schémas qui eux même peuvent comporter des tables, des vues, des volumes, des modèles IA/ML et des fonctions. Databricks recommande fortement de concevoir les catalogues comme des reflets de la structure de l’entreprise.

« En tant que niveau le plus élevé du modèle de gouvernance des données de votre organisation, chaque catalogue doit représenter une unité logique d’isolation des données et une catégorie logique d’accès aux données, permettant une hiérarchie efficace des accès vers les schémas et les objets qu’ils contiennent », peut-on lire dans la documentation de l’éditeur.

Cette organisation peut être effectuée par entité dans l’entreprise, comme les ressources humaines, le marketing, la finance, etc. Aussi, il est possible de créer un catalogue afin de gérer les données exploitées dans le cadre du développement des produits de celles usées en production, ou de faire de même pour les données des clients et celle d’une application ou de l’entreprise elle-même.

Les métadonnées « administratives » utilisées pour garantir l’audit et la gestion des performances sont, par défaut, référencées dans un catalogue intitulé « system ». En disponibilité générale depuis peu, les tables associées peuvent être interrogées afin d’assurer la gestion des coûts.

Il est également possible d’enregistrer des catalogues « étrangers », par exemple ceux issus de warehouses Snowflake, MySQL, PostgreSQL, RedShift, Azure SQL, BigQuery, Azure Synapse, mais aussi des workspaces Databricks d’un partenaire ou d’un client. Après une étape de connexion nécessaire, cela active la possibilité d’exécuter des requêtes fédérées sur une autre plateforme de gestion de données.

« Nous avons aujourd’hui plus de 5 000 clients par mois qui exploitent notre fonctionnalité nommée “Lakehouse Federation” », a assuré Matei Zaharia, cofondateur et CTO de Databricks, lors de la conférence annuelle Data + AI Summit en juin 2024. Plus tard cette année, Databricks prévoit d’ajouter des connexions vers les catalogues externes Apache Hive et AWS Glue.

À ce premier niveau du métastore sont également enregistrés des objets comme les identifiants vers les espaces de stockage objet, les accès externes, les connexions, les collections d’objets Delta Sharing partageables, les récipients (les entités pouvant accéder aux objets partagés par des fournisseurs de données via Delta Sharing) et les fournisseurs eux-mêmes. La gouvernance des modèles et des tables externes stockées sur Clouflare R2 est en préversion.

Au niveau deux de la hiérarchie évoquée plus haut, l’on trouve les schémas (ou bases de données) qui représentent des cas d’usage, des projets ou encore des sandboxes. Ici, Databricks applique par défaut l’architecture en médaillon. Le système génère au moins un schéma bronze (pour les données brutes), silver (les données filtrées, augmentées) et gold (les données agrégées pour les métiers) par catalogue.

Dans les schémas, l’on trouve donc les volumes permettant d’accéder aux données non structurées (typiquement dans un bucket S3), des tables, des vues, des fonctions UDF et des modèles d’IA enregistrés à l’aide de MLFlow. Cela représente le niveau 3.

La création d’un premier workspace entraîne automatiquement le lancement d’un métastore (et d’un catalogue nommé « main ») dans la région cloud associée. Logiquement, un seul métastore est déployé par région cloud. Les workspaces antérieurs à l’intégration de Unity Catalog peuvent être manuellement associés à un métastore en y connectant les catalogues Hive associés.

Avec cette architecture, les administrateurs peuvent gérer les accès et la traçabilité des données à l’aide de commande SQL. Le système enregistre à la fois les accès aux données et leur lineage, c’est-à-dire l’ensemble des étapes nécessaires à l’obtention d’un jeu de données. Une interface simplifie la sélection des rôles pouvant écrire ou lire sur les tables ou les volumes. La traçabilité des modèles d’IA est encore en préversion.

« Ces deux aspects permettent finalement de comprendre la manière dont les données sont consommées et sont traitées », expliquait un porte-parole de Databricks France auprès de clients et de partenaires en avril 2024.

Il existe trois niveaux d’administration correspondant à une hiérarchie de privilège : l’admin du compte databricks peut configurer la couche de gouvernance et déléguer la gestion du métastore à d’autres rôles qui, eux-mêmes, gèrent les accès aux workspaces.

Simplifier la gestion de la gouvernance des données et des modèles

L’éditeur sait très bien que ses clients ne veulent pas forcer à écrire des requêtes SQL pour retrouver les données. « Catalog Explorer » est l’interface avec laquelle les administrateurs et les usagers peuvent parcourir les catalogues, les tables et les autres objets référencés auxquels ils ont accès. Il est possible pour les gestionnaires d’étiqueter les objets afin de simplifier leur recherche.

Databricks a par ailleurs introduit une fonctionnalité pour attribuer l’accès aux données suivant ces étiquettes, la localisation des utilisateurs, leurs identités ou des périodes prédéfinies. Ce mécanisme institue aussi un moyen de masquer les colonnes en fonction des rôles.

En préversion également, un LLM rattaché à la couche d’IA et de recherche cognitive DatabricksIQ permet de créer automatiquement la description d’une table. Au niveau d’une table, l’interface permet de consulter les colonnes, un échantillon de données, les détails techniques (identifiant, location, type de format, etc.), les permissions associées, l’historique ou encore son lineage.

En outre, il est possible d’intégrer Tableau, Looker et Power BI avec Unity Catalog, permettant ainsi un accès aux tables disponibles depuis les différents workspaces. Plus tard, l’éditeur a prévu d’y cataloguer des métriques métiers issues d’outils de transformation et de BI.

Dans cette même veine, depuis 2022, Databricks entend incorporer des « Data clean Rooms » dans cette méthode de gouvernance, c’est-à-dire des sandboxes pouvant être déployées sur le cloud d’attache de la plateforme Databricks et partagées avec des entreprises et fournisseurs tiers. Ces sandboxes peuvent héberger des tables Delta ou des tables externes, mais aussi accueillir et exécuter des notebooks (écrits en Python, R, SQL, etc.) afin de transformer des données importées.

Un écart fonctionnel de plus en plus fin entre Databricks et Snowflake

« Beaucoup de moyens de vérification de la qualité et de suivi des dérives des modèles et données sont intégrés par défaut [dans Lakehouse Monitoring]. »
Matei ZahariaCofondateur et CTO, Databricks

Lors de son événement annuel, il a également présenté Lakehouse Monitoring. « C’est la possibilité de vérifier la qualité des données et des modèles », stipule Matei Zaharia. « Beaucoup de moyens de vérification de la qualité et de suivi des dérives des modèles et données sont intégrés par défaut », assure-t-il.

Quelles différences avec Snowflake Horizon ? Dans les faits, le concurrent de Databricks entend proposer peu ou prou les mêmes fonctionnalités que son concurrent. Là où Snowflake est en avance sur le partage de données et l’exploitation des clean rooms, quelques fonctionnalités sont encore en préversion privée ou publique, notamment l’accès aux interfaces de lineage, aux marketplaces internes, ou bien l’obtention d’indicateurs sur les jeux de données.

Quant aux différences avec Unity Catalog OSS, il faut bien comprendre que cette variante open source est encore naissante. Logiquement, l’éditeur et la communauté se concentrent sur la gouvernance des données tabulaires, quand la version propriétaire permet déjà de gérer les modèles, les fonctions et les volumes.

Pour l’heure, les clients de Databricks et de Snowflake, qui n’ont pas attendu ces deux éditeurs pour établir leur politique de gouvernance de données, complètent la couche de gouvernance avec des plateformes et des outils tiers, dont ceux de Collibra, de Collate, d’Informatica, de Precisely, etc.

Pour approfondir sur MDM - Gouvernance - Qualité

Close