Introduction

Cet article a pour but de présenter la gestion des accès et des partages de vos données dans le cadre d’une stratégie de data governance. On s’appuiera sur l’outil Unity Catalog, une solution de gouvernance des données pour le Lakehouse, sur Databricks. Un tour d’horizon sera donc fait sur cet outil pour présenter quelques-uns de ses avantages comme la traçabilité de la donnée et la gestion des identités.

Prérequis

Dans cet article nous ne montrera que certains aspects de la mise en place de Unity Catalog. Des pré-requis sont donc nécessaires pour reproduire la suite de l’article :

• Un compte Databricks de niveau Premium doit être souscrit
• Vous devez posséder un compte Admin sur la ressource Databricks (pas uniquement sur le Workspace)
• Un metastore configuré, ce dernier nécessitant un compte de stockage afin de pouvoir stocker les métadonnées (https://blog.atawiz.fr/article/partage-donnees-azure-databricks)
• Un Workspace configuré, et un cluster supportant Unity Catalog (https://docs.databricks.com/data-governance/unity-catalog/compute.html)

Ce lien documente la mise en place de la plupart de ces pré-requis : https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/get-started

Catalog, schema et tables

Présentation des objets

Unity Catalog (UC) permet de gérer des objets du Lakehouse à 3 niveaux de profondeur. Le metastore contient l’ensemble des permissions attachées aux différents objets : les catalogues, les schémas et les tables. Ainsi il est impératif d’avoir un metastore connecté au workspace pour pouvoir utiliser UC. Ce metastore contiendra également toutes les métadonnées des objets managés. Dans l’éventualité où aucun metastore n’est configuré (et donc que UC n’est pas utilisé), c’est le metastore par défaut de Databricks qui est utilisé (hive_metstore).

Le premier niveau de l’arborescence des objets managable par UC est le niveau des catalogues. Les catalogues sont faits pour organiser les données en regroupant plusieurs schémas. Le second niveau est celui des schémas. C’est l’équivalent des bases de données, un schéma permet d’organiser des tables et des vues. Le dernier niveau est celui des tables (et des vues). C’est à ce niveau que les données sont stockées.

Création des objets

Pour illustrer les possibilités de UC, on crée un catalogue, un schéma et plusieurs tables. Ici on utilise les données mises à disposition par l’API open data vélib’ (https://velib-metropole-opendata.smoove.pro/opendata/Velib_Metropole). On se base sur l’ingestion de ces données sur la base de l’article suivant : https://blog.atawiz.fr/article/data-ingestion-adf . On met à jour le notebook d’ingestion pour prendre en compte le catalogue et on obtient les instructions suivantes :

On crée le catalogue et le schéma. Il faut penser à utiliser un cluster permettant d’utiliser UC pour exécuter toutes les instructions.

On crée les tables bronze avec les dataframes (voir l’article https://blog.atawiz.fr/article/orchestration-notebooks-adf pour reproduire le dataframe), en précisant le catalogue et le schéma.

On fait de même avec des tables silver, en appliquant de légères transformations.

Enfin on crée une table gold en faisant une jointure sur les tables silver.

On peut consulter les objets nouvellement créés dans l’onglet DataExplorer :

Data Lineage

En cliquant sur les tables, on peut consulter un large panel d’informations comme :

• Les colonnes et les types de la table (onglet Columns) où sont physiquement stockées les données (onglet Details)
• Les permissions configurées sur la table (onglet Permissions)
• Les dernière transactions sur la table (onglet History) ou encore son Lineage Ce dernier onglet permet de consulter d’où vient la donnée et où elle est utilisée par la suite. Ce premier écran permet de connaitre de quelles tables proviennent les données de notre table silver (une table bronze), mais aussi de savoir quelles tables utilisent notre table silver en aval (onglet ‘Downstream). On a également accès à des onglets permettant de savoir quels notebooks, workflows, Dashboard et queries utilisent cette table.

En complément, on a accès à une représentation graphique de l’ascendance et de la descendance de la table. Dépliant les entrées et sorties des tables, on peut reconstruire partiellement ou totalement le chemin de la donnée, de l’ingestion jusqu’aux tables métiers. De plus, on peut affiner cette vue au niveau d’une colonne pour voir de quelles autres colonnes elle provient et quelles autres colonnes dépendent d’elle.

Cette traçabilité est donc multifonction. Elle est une documentation automatique pour en savoir plus sur l’origine et l’utilisation des tables et de ses colonnes, mais permet aussi d’identifier les tables qui ne sont exploitées par aucune ressource (notebook, workflow, etc.), ce qui pourrait signifier qu’elles sont obsolètes.  

Permissions et accès aux données

Users, groups et privilèges

UC permet de gérer les permissions d’accès aux données. Plus précisément, on peut donner des privilèges aux objets suivants :

Comme on le voit sur le schéma ci-dessus, il existe une hiérarchie dans les objets. Donner des droits à un objet comme un schéma donne automatiquement des droits aux tables associées (au schéma par exemple). Les principaux type de droits que l’on peut donner sont : USE, CREATE, SELECT et MODIFIY. On peut aussi accorder le privilège ALL PRIVILEGES pour accorder l’ensemble des privilèges en une fois. Il existe d’autres types de privilèges pour des cas particuliers comme EXECUTE dans le cas d’une fonction par exemple. La syntaxe est la suivante : « GRANT privilege_type ON securable_object TO principal ». On peut également révoquer des droits avec la commande REVOKE et interdire des accès avec la commande DENY (pour autoriser l’accès à un schéma à l’exception de certaines tables par exemple).

On peut retrouver l’ensemble de ces droits listés ici avec des détails sur chaque commande : https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/manage-privileges/privileges

Ces permissions peuvent être accordées à un utilisateur, à un groupe ou à un service principal. Ces identités sont managées dans la gestion de la ressource Databricks, au même niveau que le metastore ou les Workspaces. Dans l’onglet User management, on peut ajouter les utilisateurs et les services principaux, mais aussi gérer des groupes d’utilisateurs, de services principaux ou même des groupes de groupes afin d’organiser les identités en accord avec leurs permissions.

Une fois les identités et groupes créés, on peut les consulter au niveau du worskspace, dans la console Admin. Il peut être nécessaire d’ajouter les ressources créées pour les associer au workspace

Une fois assuré que les identités ou groupes souhaités sont bien présents sur le worskpace, on peut leur accorder les privilèges, soit par requête SQL comme vu précédemment, soit via l’interface graphique.

Row / Column Level Security et Data Masking

Un niveau de contrôle encore plus fin est possible grâce à 2 fonctions disponibles si on utilise UC : current_user et is_member.

Ces fonctions permettent de savoir qui est l’utilisateur qui exécute l’instruction en cours, et si cette utilisateur fait partie du groupe passé en paramètre.

On peut se servir de ces informations pour créer des tables ou des vues avec un accès restreint sur certaines lignes ou certaines colonnes. Ici, on crée une vue dont les coordonnées sont cachées aux personnes ne faisant pas partie du groupe ‘velib_bronze’, ainsi qu’une partie du nom de chaque station. Cela permet de créer une column level security et du data masking facilement.

De même on crée une vue avec une sécurité au niveau des lignes (row level security) en ajoutant un filtre dépendant de is_member :

Industrialisation

Afin de pouvoir utiliser les fonctionnalités vues au-dessus dans un contexte industriel, certaines contraintes doivent être respectées. Databricks propose chaque mois des nouvelles possibilités d’adaptation, mais on peut déjà utiliser UC avec les fonctions suivantes.

Tables externes

Il est parfois exigé que les données soient stockées dans un espace de stockage externe plutôt que directement managées par Databricks. Il est possible d’ajouter des tables externes dans le scope de UC en ajoutant quelques configurations. Il est nécessaire d’avoir le privilèges CREATE EXTERNAL TABLE sur le compte de stockage externe par exemple. Pour plus d’informations, vous pouvez suivre la documentation suivante : https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/manage-external-locations-and-credentials

Permissions sur workflow

Lors de traitement industrialisé, il est souvent essentiel d’avoir des taches automatisées et gérées par un orchestrateur. Pour que des utilisateurs n’ayant pas accès à certaines ressources ne puissent pas y avoir accès en passant par l’exécution de notebooks via les workflows, on peut ajouter des permissions aux niveau des jobs.

Ainsi suivant les permissions choisies, les utilisateurs pourront consulter ou non les outputs des jobs ou seulement les exécuter.

Delta sharing à d’autres équipes

Enfin, une autre option est de pouvoir partager des tables Delta à d’autres équipes, organisations ou même outils tiers comme power BI, ou Excel. Des droits particuliers doivent être ajoutés pour permettre le partage (SHARE et RECIPIENT) et la lecture de données partagées (PROVIDER). Pour plus de détails, cet article décrit comment connecter un fichier Excel à une table delta comme source de données, en passant par PowerBi (https://blog.atawiz.fr/article/partage-donnees-azure-databricks)  

Conclusion

Unity Catalog est un outil essentiel pour avoir une gouvernance de la donnée au sein de Databricks. De plus, il s’intègre parfaitement dans le cadre de la mise en place d’un DataMesh. En effet grâce à UC, nous avons une gouvernance de données fédérée, une possibilité de monitorer efficacement la qualité des données (data product) et un partage simplifié des données à travers toute une organisation, même aux équipes ne travaillant pas avec Databricks avec le Delta Sharing.

Il existe encore certaines limites avec Unity Catalog, mais Databricks a déjà intégré à leur roadmap de l’année l’ajout du support des DLT, et la possibilité de faire remonter la traçabilité aux fichiers externes, en amont des tables Delta pour garantir une vision de bout en bout et pas seulement dans le scope de Databricks.