Mission Control : l'architecture du Databricks Unity Catalog dans le réseau de données d'entreprise moderne
- Databricks
- Databricks
- 8 min de lecture
Dr. Andreas Wagner
Dans l'économie hybride des données d'aujourd'hui, les responsables informatiques sont confrontés à un défi majeur : les données affluent depuis des dizaines de systèmes hétérogènes, allant des systèmes de stockage d'objets natifs du cloud aux bases de données transactionnelles, en passant par des systèmes ERP tels que SAP S/4HANA. Chacun de ces systèmes s'accompagne de ses propres modèles de sécurité, bases de données d'utilisateurs et règles d'accès. Il en résulte un patchwork fragmenté de politiques de sécurité qui non seulement représente un risque de conformité considérable, mais paralyse également l'agilité opérationnelle.
Le Databricks Unity Catalog (UC) met fin à ce « cauchemar en matière de gouvernance ». Il fait office de plan de contrôleunique (Single Plane of Control) universel et multiplateforme, servant de « centre de contrôle » centralisé pour l'ensemble de l'environnement de données et d'IA.
Avec l'arrivée sur le marché (GA – General Availability) de nouvelles interfaces de gouvernance révolutionnaires telles que l'ABAC ( Attribute-Based Access Control – contrôle d'accès basé sur les attributs), les balises réglementées (Governed Tags ) et la classification des données par agent (Agentic Data Classification – classification des données assistée par l'IA), la gestion de la sécurité connaît une transformation radicale : on passe d’un « Data Plumbing » manuel et fastidieux au niveau des tables à une couche de protection déclarative et automatisée qui s’adapte dynamiquement au flux de données.
Dans ce guide, nous vous montrons concrètement comment Unity Catalog fait le lien entre vos systèmes afin de sécuriser vos données à chaque étape. Nous vous guidons à travers l'intégration transparente avec SAP BDC (Business Data Cloud) ainsi qu'avec les services d'identité mondiaux – et nous vous fournissons, en tant qu'architecte, le plan d'action adapté pour mettre en place un concept de sécurité complet et pérenne au sein de votre entreprise.
Table des matières
1. Le problème : du chaos des autorisations à la « jungle des catalogues »
Pour comprendre l'intérêt du Unity Catalog, il convient de revenir sur son évolution historique. Aux débuts de Databricks, la gestion des métadonnées s'effectuait via le Hive Metastore local à l'espace de travail. Cette approche présentait trois inconvénients majeurs dans les environnements d'entreprise :
- Silos de travail : chaque environnement de développement et chaque laboratoire de science des données formait un « îlot » isolé. Les autorisations devaient être synchronisées au niveau du stockage (compartiments S3 ou chemins Azure Data Lake) via des rôles IAM (gestion des identités et des accès) complexes fournis par les fournisseurs de cloud. Il était difficile de vérifier la cohérence du niveau de sécurité à l'échelle globale.
- La fragmentation des catalogues : grâce à l'utilisation de plateformes de données spécialisées, les organisations gèrent aujourd'hui souvent quatre catalogues de métadonnées parallèles, voire plus, simultanément. Outre le catalogue Databricks local, il existe le catalogueSAP BDC, Google Dataplex, Snowflake Horizon ou encore Microsoft Purview. Chacune de ces plateformes fait office de « source de vérité » à part entière, dotée d'API (interfaces de programmation d'applications) propriétaires.
- L'effet « Swivel-Chair » : les utilisateurs de données doivent effectuer des recherches successives dans plusieurs systèmes (« effet du fauteuil pivotant ») pour trouver l'enregistrement souhaité. Pour les responsables de la conformité, c’est un véritable cauchemar que de devoir gérer et contrôler de manière uniforme une seule politique globale – telle que le masquage des informations personnelles identifiables (PII) – au-delà de ces frontières technologiques.
L'effondrement sémantique lors de la réplication des données
Chaque fois que des données sont physiquement copiées d'un système à l'autre afin de respecter les exigences de sécurité, il se produit un effondrement sémantique. Les règles métier, les logiques de conversion monétaire et les structures hiérarchiques (par exemple, les hiérarchies des centres de coûts ou des articles) sont irrémédiablement perdues lors d'exportations de fichiers plats. La reproduction manuelle de cette sémantique dans des systèmes tiers mobilise jusqu’à 80 % des ressources dans les projets de données – un temps précieux qui fait défaut pour la création de valeur proprement dite grâce à l’analyse.
2. La console de contrôle : le principe des espaces de noms à trois niveaux du catalogue Unity
Unity Catalog élimine les barrières technologiques en superposant une hiérarchie structurée et logique à toutes les sources de données physiques connectées. Ce système repose sur le principe des espaces de noms à trois niveaux:
Adresse = CATALOG.SCHEMA.TABLE
- Catalogue : le niveau logique le plus élevé, qui correspond généralement à une entité métier (par exemple, finance_catalog), à un domaine de données ou à un environnement système (prod_analytics).
- Schéma (ou base de données) : regroupement logique au sein du catalogue qui correspond à un projet concret ou à un domaine fonctionnel de données (par exemple, revenue_data).
- Table / Vue / Volume : l'objet de données physique ou logique. Les volumes constituent ici une innovation majeure : ils permettent d'appliquer aux données non structurées (telles que les fichiers PDF, les images, les fichiers JSON ou Parquet) la même gouvernance rigoureuse qu'aux tables relationnelles.
La différence architecturale : Hive vs Unity Catalog
Afin d'illustrer cette réorientation fondamentale, le tableau suivant compare l'architecture Hive classique à la norme moderne Unity Catalog :
3. Mise en œuvre technique de la sécurité au niveau des lignes et des colonnes
La sécurisation des tables sensibles nécessite deux niveaux de restriction d'accès, que Unity Catalog évalue de manière dynamique au moment de l'exécution de la requête (Query Runtime) :
- Sécurité au niveau des lignes (RLS – protection des accès au niveau des lignes) : détermine les enregistrements (lignes) qu' un utilisateur est autorisé à consulter, en fonction d'attributs tels que l'appartenance régionale.
- Sécurité au niveau des colonnes (CLS – Column-Level Security) : détermine la manière dont les attributs sensibles (colonnes) sont affichés. Cela se fait soit par une exclusion totale, soit par un masquage dynamique (par exemple, en réduisant une adresse e-mail à a***@domain.com).
Les aspects techniques de la sécurité au niveau des lignes
La mise en œuvre de RLS dans Unity Catalog repose sur des fonctions définies par l'utilisateur (UDF) basées sur SQL, qui renvoient une valeur booléenne (TRUE ou FALSE).
Lorsqu'une telle fonction est appliquée à un tableau en tant que filtre de ligne, Unity Catalog intercepte chaque requête entrante provenant des nœuds de travail Databricks – ces nœuds de calcul distribués qui supportent la charge de calcul proprement dite. Il injecte la condition de filtrage de manière invisible dans la clause WHERE de la requête, au moyen d'une opération logique ET :
— Création d'une fonction de filtrage pour les responsables régionaux
CREATE FUNCTION company.sales.regional_row_filter(region STRING)
Renvoie une valeur booléenne
RETOUR
is_account_group_member(« global_admin_group »)
OR (is_account_group_member(« apac_managers ») ET region = « APAC »)
OR (is_account_group_member('eu_managers') AND region = 'EU') ;
— Lier la fonction à un filtre de ligne actif
ALTER TABLE company.sales.customer_orders
SET ROW FILTER company.sales.regional_row_filter ON (region);
Si un analyste du groupe apac_managers exécute à présent la requête simple SELECT * FROM customer_orders;, le moteur exécute automatiquement en arrière-plan la requête suivante directement sur la mémoire :
SELECT * FROM client_commandes
WHERE (is_account_group_member('global_admin_group') OR (is_account_group_member('apac_managers') AND region = 'APAC'));
Les aspects techniques de la sécurité au niveau des colonnes
Pour le masquage des colonnes, nous utilisons une fonction de masquage dynamique qui remplace la valeur réelle par une chaîne de caractères altérée en cas d'accès non autorisé. Cela s'effectue également lors de l'exécution, sans modifier les données physiques sur le disque dur :
— Création d'une fonction de masquage pour les adresses e-mail sensibles
CREATE FUNCTION company.sales.mask_email(email STRING)
CHAÎNE DE RETOUR
RETURN CASE
SI is_account_group_member(« pii_readers_group ») ALORS email
SI email EST NULL ALORS NULL
ELSE regexp_replace(email, '(^.).+(@.+$)', '$1***$2')
FIN ;
— Attribution de la fonction de masquage à une colonne spécifique
ALTER TABLE company.sales.customer_orders
ALTER COLUMN email SET MASK company.sales.mask_email;
L'association manuelle de filtres et de masques via la commande ALTER TABLE atteint ses limites en termes d'évolutivité lorsqu'il s'agit de traiter des milliers de tables. Cela comporte un risque élevé que de nouvelles tables sensibles restent non protégées, car un ingénieur de données peut oublier d'attribuer manuellement le masque.
Avec la version GA prévue en mai 2026, Databricks a résolu ce problème. L'accent n'est plus mis sur la configuration manuelle des objets, mais sur un pipeline « Organize-Detect-Protect » entièrement automatisé.
[ ÉTAPE 1 : DÉTECTER ] [ ÉTAPE 2 : ORGANISER ] [ ÉTAPE 3 : PROTÉGER ]
Classification agentique ───► Balises réglementées (par ex., données à caractère personnel) ───► Politiques ABAC (masquage automatique)
Les trois piliers de la gouvernance automatisée
- Balises réglementées : il s'agit de mots-clés de métadonnées valables à l'échelle du compte, soumis à une protection administrative stricte. Il est possible de définir précisément quels rôles sont autorisés à attribuer ces balises et quelles valeurs (par exemple, sensitivity = [« public », « confidentiel », « restreint »]) sont autorisées.
- Classification des données par agent (classification assistée par IA) : un agent intelligent fonctionnant en arrière-plan analyse de manière incrémentielle toutes les nouvelles entrées de table dans le Lakehouse. À l'aide de classificateurs réglementaires intégrés (tels que le RGPD, la loi HIPAA ou la norme PCI-DSS), l'IA détecte les modèles sensibles (tels que les numéros de carte de crédit ou les données de sécurité sociale) et attribue automatiquement les balises de gouvernance appropriées aux colonnes.
- Politiques ABAC (politiques de sécurité basées sur les attributs) : au lieu de modifier les tables une par une, les équipes de gouvernance définissent des politiques globales au niveau du catalogue ou du schéma, qui s'appliquent aux balises. Dès qu'une balise est associée à une colonne, la protection s'applique immédiatement :
— Définition de la balise « Governed »
CREATE GOVERNED TAG sensitivity
DESCRIPTION « Niveau de sécurité des colonnes »
VALUES (« public », « confidentiel », « restreint ») ;
— Politique globale de masquage ABAC pour l'ensemble du catalogue
CREATE POLICY mask_restricted_data
SUR LE CATALOGUE prod_analytics
COMMENT « Masquage automatisé pour toutes les colonnes marquées comme « restricted » »
COLUMN MASK prod_analytics.security.mask_email
TO « utilisateurs du compte »
POUR LES TABLEAUX
MATCH COLUMNS hasTagValue(« sensitivity », « restricted ») AS target_col
ON COLUMN target_col;
Grâce à cette approche déclarative, la complexité administrative est réduite au minimum : la directive est définie une seule fois, et la protection s'applique de manière illimitée à toutes les tables futures.
Le guide Databricks d'Andreas & Yvonne
Vous voulez toutes les informations importantes en un coup d'œil ?
Téléchargez dès maintenant le guide gratuit de SAP Databricks !
5. Une vue d'ensemble de tous les systèmes : gouvernance universelle avec SAP BDC, Microsoft Entra ID et Terraform
Une gouvernance universelle sans faille ne doit pas s'arrêter aux limites de la plateforme Databricks. Dans le cadre d'un environnement de données hybride – en particulier lors de la connexion de données SAP via SAP BDC Connect –, les chaînes d'identité doivent s'imbriquer de manière transparente.
Le pipeline d'identité : synchronisation de bout en bout
Afin de garantir une application cohérente des politiques de sécurité, nous mettons en place un pipeline d'identité fermé :
- Microsoft Entra ID : sert de fournisseur d'identité (IdP) central et constitue la source de référence unique pour tous les utilisateurs et groupes de l'entreprise.
- SAP IPS (Identity Provisioning System) : synchronise automatiquement ces données d'identité et ces appartenances à des groupes dans SAP IAS (Identity Authentication Service).
- Autorisation fédérée : lorsqu'un utilisateur lance un notebook dans Databricks et accède à un produit de données SAP via BDC Connect, Unity Catalog authentifie la requête via la session Entra ID existante. Comme le BDC utilise la même base d'identité via l'IAS, l'accès peut être autorisé en temps réel, sans rupture de média et sans avoir recours à des mots de passe de service non sécurisés et codés en dur.
6. Changement de cap depuis l'orbite : Apache Iceberg, Polaris et le tournant Dremio
L'évolution des plateformes de données modernes progresse à un rythme effréné. L'acquisition par SAP, finalisée en mai 2026, du puissant moteur de requêtes Dremio marque le début d'une nouvelle ère pour le réseau de données. Cette étape affaiblit le lien traditionnellement étroit entre SAP BDC et le format Delta Lake (écosystème Databricks) et ouvre la voie aux architectures de stockage ouvertes.
L'essor d'Apache Iceberg
Alors que le format Delta nécessite par défaut un modèle de catalogue hautement intégré et centralisé, tel que Unity Catalog, la norme Apache Iceberg, qui s'impose de plus en plus sur le marché, repose sur un concept radicalement décentralisé. Dans une structure de table Iceberg, toutes les métadonnées (fichiers de manifeste, instantanés et historiques de schémas) sont stockées directement dans le stockage d'objets, aux côtés des données utiles proprement dites.
Avec l'acquisition de Dremio, SAP positionne son BDC comme un « Enterprise Lakehouse » natif d'Iceberg. Cela signifie que les données stockées dans le FOS (File Object Store) ne doivent plus nécessairement être transférées dans des tables delta. Elles sont disponibles dès le premier jour dans un format ouvert et universel, qui peut être interrogé par n'importe quel moteur sans nécessiter de conversion.
Catalogue Polaris : une alternative décentralisée
Pour sécuriser cet environnement décentralisé, le catalogue Polaris entre en jeu. Polaris est un catalogue de métadonnées open source et indépendant des éditeurs, destiné à Apache Iceberg, qui utilise le protocole standardisé REST (Representational State Transfer):
- Le principe de fonctionnement : au lieu de confier la souveraineté des données à une plateforme centrale, Polaris agit comme une instance légère et logique de pointeur et d'autorisation via l'API REST Catalog.
- Résultat : le stockage SAP utilise désormais un protocole ouvert. L'exclusivité de Databricks s'effrite ; d'autres acteurs du marché, tels que Snowflake, Google BigQuery, AWS Athena ou Trino, peuvent désormais accéder directement aux données SAP physiques via Polaris, avec des privilèges identiques.
La synthèse : orchestration multi-catalogues au sein du réseau d'entreprise
Une question cruciale se pose désormais aux architectes d'entreprise : Polaris va-t-il remplacer Unity Catalog ? La réponse architecturale est claire : non. Les deux coexistent.
Alors que Polaris constitue la base décentralisée du SAP Object Store, compatible avec plusieurs moteurs, Unity Catalog reste la couche de gouvernance incontournable et riche en fonctionnalités pour toutes les charges de travail Databricks (notamment les pipelines Spark complexes, LakeFlow et Mosaic AI).
La solution pour les plateformes de données modernes réside dans une couche d'orchestration de catalogues de niveau supérieur (par exemple, gérée par des systèmes partenaires tels qu'Atlan ou Collibra). Cette couche fédère les politiques au-delà des limites des catalogues : elle lit les autorisations dans Polaris et Unity Catalog, les synchronise avec le pipeline d'identité (Entra ID) et garantit que les règles de gouvernance (telles que le masquage des données à caractère personnel) ne doivent être définies qu'une seule fois au niveau global, mais s'appliquent de manière synchronisée dans les deux environnements.
7. Liste de contrôle Mission Control : bonnes pratiques, pièges à éviter et optimisation des performances
Lors de la mise en place d'une structure de gouvernance globale, il existe dans la pratique des écueils techniques susceptibles d'avoir de graves répercussions sur la sécurité et les performances du système.
Les pièges les plus courants
- Le paradoxe de l'héritage (over-permissioning) : Le catalogue Unity transmet les autorisations de manière stricte, de haut en bas. Si un groupe d'utilisateurs se voit accorder le droit SELECT au niveau du catalogue, ce droit ne peut plus être retiré au niveau du schéma ou de la table par une instruction DENY explicite.
- Solution : n'accordez jamais de droits de lecture généraux au niveau du catalogue. Utilisez des autorisations différenciées au niveau du schéma ou de la table.
- Solution : n'accordez jamais de droits de lecture généraux au niveau du catalogue. Utilisez des autorisations différenciées au niveau du schéma ou de la table.
- Le « contournement » via des chemins directs : Si les utilisateurs disposent d'un accès en lecture directe aux emplacements de stockage cloud sous-jacents (par exemple, les compartiments S3), ils peuvent contourner toutes les règles de sécurité du catalogue Unity.
- Solution : mettez en place une stratégie de sécurité cloud rigoureuse. Aucun utilisateur ne doit disposer d'un accès en lecture directe au stockage physique ; l'accès doit être exclusivement géré via les tables gérées du catalogue Unity (Managed Tables).
- Solution : mettez en place une stratégie de sécurité cloud rigoureuse. Aucun utilisateur ne doit disposer d'un accès en lecture directe au stockage physique ; l'accès doit être exclusivement géré via les tables gérées du catalogue Unity (Managed Tables).
Optimisation des performances avec le masquage actif
L'exécution dynamique de fonctions SQL UDF complexes peut augmenter la charge liée aux requêtes et, dans le pire des cas, empêcher le « predicate pushdown » (le filtrage précoce des blocs de données directement au niveau de la mémoire).
Afin de garantir une performance stable, nous vous recommandons :
- Logiques de masquage simples : utilisez des commandes SQL natives performantes (telles que regexp_replace ou CASE-WHEN) au sein des fonctions définies par l'utilisateur (UDF) plutôt que des appels Python externes complexes.
- Activer la mise en cache delta : assurez-vous que la mise en cache locale sur les disques SSD des nœuds de travail est activée sur les clusters Databricks. Une fois cryptés et autorisés, les blocs de données n'ont pas besoin de repasser par l'ensemble du moteur de règles lors de requêtes répétées :
// Aktivierung des performanten Caching-Mechanismus im Databricks-Cluster
spark.conf.set(« spark.databricks.io.cache.enabled », « true »)
8. Conclusion et recommandations
Aucune fusée ne décolle sans le centre de contrôle de mission. Aucun Data Lakehouse ne peut évoluer sans une instance centrale de gouvernance qui supervise l'ensemble des systèmes. Le Databricks Unity Catalog est bien plus qu'un simple répertoire de métadonnées : c'est le pont technologique qui allie l'agilité d'un Data Lakehouse ouvert à la sécurité sans compromis d'une base de données relationnelle d'entreprise.
Grâce à l'intégration transparente avec SAP BDC Connect et Microsoft Entra ID, nous créons un écosystème dans lequel les politiques de sécurité ne sont plus programmées de manière fastidieuse, mais orchestrées de manière déclarative.
La feuille de route de s-peers pour une mission en toute sécurité :
Veuillez établir la chaîne d'identité depuis Entra ID jusqu'au Unity Catalog via l'IPS avant de connecter les premières données en production.
Tirez parti des nouvelles fonctionnalités ABAC (GA 2026). Créez des fonctions UDF de masquage et de filtrage universelles et gérez l'accès de manière élégante à l'aide des balises contrôlées.
Profitez de la transition technologique à venir pour remplacer de manière ciblée les données obsolètes inutilisées et les métastores Hive dépassés.
Prêts pour l'avenir de l'analyse de données conforme à la protection des données ? L'équipe d'experts de s-peers vous accompagne depuis le premier audit de votre système jusqu'à la mise en place d'une architecture de gouvernance entièrement automatisée dans votre environnement cloud de production. Votre centre de contrôle vous attend.
Votre stratégie en matière de données est personnalisée – vos conseils devraient l'être également.
Le choix entre ces méthodes dépend de nombreux facteurs : votre environnement système existant, vos objectifs commerciaux et votre culture en matière de données. Il n'existe pas de réponse standard.
Discutons sans engagement de la solution la mieux adaptée à vos besoins. Veuillez nous contacter pour un entretien individuel.
