Optimisez la gouvernance et la sécurité dans votre Lakehouse

Jusqu’ici, vous avez aidé GreenFarm à construire un Lakehouse performant, fiable et scalable. Les tables Delta sont optimisées, historisées, maintenues, et les pipelines sont capables de suivre les changements en temps réel.
Mais, Marc vous alerte sur un nouveau sujet, tout aussi critique que la performance : la gouvernance.
Les équipes se multiplient. Les usages se diversifient. Les données deviennent stratégiques.
Une question s’impose alors :

C’est exactement l’objectif de ce chapitre.

Établissez la gouvernance et la sécurité des Lakehouses

Du data warehouse au Lakehouse : un changement de paradigme pour la gouvernance

Dans les architectures traditionnelles — bases OLTP ou data warehouses OLAP — la gouvernance des données reposait sur une hypothèse simple : les données vivent dans un système unique et centralisé.
Les tables sont :

• stockées dans une base unique,

• visibles via un schéma,

• accessibles depuis un point d’entrée clairement identifié.

Dans ce contexte, “cataloguer les données” revenait souvent à lister les tables de la base. Avec l’arrivée des data lakes, puis des Lakehouses, cette logique vole en éclats. Dans un Lakehouse :

• les données sont stockées sous forme de fichiers ;

• réparties dans des dossiers, parfois plusieurs data lakes ;

• exploitées par plusieurs moteurs (Spark, SQL, ML, IA) ;

• organisées physiquement indépendamment de leur usage logique.

Il n’existe donc plus de réponse évidente à la question : Quelles données existent réellement dans la plateforme ? Lister les fichiers d’un data lake ne suffit plus :

• un dossier peut correspondre à une table logique… ou pas ;

• une même table peut évoluer dans le temps (versions, schéma, optimisations) ;

• plusieurs équipes peuvent exploiter les mêmes données différemment.

C’est précisément ce contexte qui rend indispensable un métastore technique.

Au début d’un projet data, la gouvernance est souvent implicite :

• peu d’utilisateurs,

• peu de tables,

• peu de risques.

Mais à mesure que le Lakehouse grandit, cette approche ne tient plus. Chez GreenFarm, les données concernent désormais :

• les équipes agricoles (pilotage des parcelles),

• les équipes data (analyses et modèles),

• les partenaires externes,

• parfois même des contraintes réglementaires (traçabilité, conformité).

Sans gouvernance claire, les risques apparaissent rapidement :

• accès non maîtrisés à des données sensibles ;

• mauvaise interprétation des indicateurs métier ;

• perte de traçabilité sur l’origine des données ;

• duplication de tables “officieuses” ;

• difficulté à prouver la conformité des traitements.

Le rôle des catalogues de données dans un Lakehouse

Pour faire le lien entre :

• des fichiers physiques dans le data lake,

• des tables logiques utilisées par les moteurs,

• des usages métier et analytiques.

Une brique devient centrale : le catalogue de données, appuyé sur un métastore technique.

Un catalogue de donnée permet de répondre à des questions essentielles :

• quelles données existent ?

• où sont-elles stockées physiquement ?

• comment sont-elles structurées ?

• qui les utilise ?

• qui y a accès ?

Dans un Lakehouse moderne, le catalogue devient :

• la porte d’entrée des données,

• le point de rencontre entre ingénierie, métier et gouvernance,

• le socle de la traçabilité et de la transparence.

Découvrez les catalogues de données

Avant d’entrer dans Unity Catalog, il est important de prendre du recul. Il existe plusieurs grandes familles de catalogues de données.

Catalogues orientés gouvernance et métier

Des solutions comme Collibra, Alation, Alan ou DataGalaxy mettent l’accent sur :

• la documentation métier,

• les glossaires,

• la conformité réglementaire,

• la gouvernance organisationnelle.

Ces outils sont très puissants pour structurer la donnée à l’échelle de l’entreprise, mais ils sont souvent moins intégrés aux moteurs de calcul.

Catalogues orientés métadonnées techniques

Dans un Lakehouse, un métastore technique est indispensable pour :

• déclarer les tables logiques ;

• associer ces tables à des emplacements physiques ;

• exposer les métadonnées aux moteurs de calcul.

Des exemples courants sont Hive Metastore, et AWS Glue Data Catalog. Ils jouent un rôle fondamental, mais restent souvent limités sur :

• la gestion fine des accès ;

• la traçabilité des usages ;

• la gouvernance unifiée multi-équipes.

Catalogues Lakehouse modernes

Les architectures Lakehouse ont fait émerger une nouvelle génération de catalogues, plus intégrés :

• proches du moteur de calcul,

• conscients des formats de tables,

• capables de gérer sécurité, métadonnées et usages ensemble.

Mettez en place Unity Catalog dans Databricks

Unity Catalog est conçu pour devenir le point de vérité central du Lakehouse. Son rôle n’est pas de stocker les données, mais de faire le lien entre :

• les fichiers Delta présents dans le data lake,

• les tables logiques utilisées par les équipes,

• et les règles de gouvernance associées.

L’un de ses apports majeurs est de permettre une abstraction complète du stockage. Concrètement, une fois une table enregistrée dans Unity Catalog, vous pouvez l’interroger simplement avec une syntaxe SQL standard :

SELECT *
FROM agriculture.sensors.humidity_measurements;

Peu importe que cette table référence soit:

• un fichier Delta stocké dans un data lake externe (S3, ADLS, GCS),

• ou une table managée par Unity Catalog, dont le stockage est pris en charge directement par la plateforme.

Unity Catalog repose sur une hiérarchie simple et lisible :

• Metastore

• Catalog

• Schema

• Table / View / Function

Cette organisation permet :

• de structurer les données selon la logique métier ;

• d’éviter l’accumulation anarchique de tables ;

• d’aligner gouvernance et usages.

Tables externes et tables managées

Unity Catalog distingue deux grands types de tables. Une table externe référence des fichiers Delta déjà existants dans un data lake. Unity Catalog ne déplace pas les données, mais :

• enregistre leur schéma,

• expose la table aux moteurs,

• applique les règles de gouvernance.

Une table managée, à l’inverse, est entièrement gérée par Unity Catalog :

• le stockage est pris en charge par la plateforme ;

• les chemins physiques sont abstraits ;

• la gouvernance est appliquée nativement.

Créez une table Unity Catalog directement depuis un DataFrame

Du DataFrame à la table gouvernée

Supposons que vous disposiez d’un DataFrame Spark, issu par exemple :

• d’un fichier CSV,

• d’une transformation,

• ou d’une agrégation intermédiaire.

df = spark.read.option("header", "true").csv("/resources/greenfarm_sensors.csv")

Ce DataFrame contient encore des données brutes. Vous appliquez ensuite une transformation simple (par exemple une agrégation journalière) :

from pyspark.sql.functions import avg, col, to_date

df_daily = (
    df
    .withColumn("date", to_date(col("timestamp")))
    .groupBy("date", "parcel_id")
    .agg(
      avg("humidity").alias("avg_humidity"),
      avg("temperature").alias("avg_temperature")
 )
)

À ce stade, aucune table n’existe encore dans le Lakehouse : vous travaillez uniquement en mémoire.

Créez automatiquement une table Unity Catalog

Pour créer une table managée, il suffit maintenant d’écrire ce DataFrame en précisant son nom complet dans Unity Catalog :

df_daily.write \
  .format("delta") \
  .mode("overwrite") \
  .saveAsTable("agriculture.analytics.sensors_daily")

Cette simple instruction déclenche plusieurs actions à la fois :

• une table Delta est créée ;

• elle est enregistrée automatiquement dans Unity Catalog ;

• son stockage est managé par la plateforme ;

• les règles de gouvernance du catalogue s’appliquent immédiatement.

Vous pouvez aussitôt interroger la table :

SELECT *
FROM agriculture.analytics.sensors_daily;

Sans connaître le chemin des fichiers et le data lake sous-jacent. Ce mécanisme illustre parfaitement la promesse du Lakehouse gouverné :

• les data engineers écrivent des DataFrames ;

• les tables apparaissent automatiquement dans le catalogue ;

• les équipes métier consomment les données via SQL ;

• la gouvernance est appliquée dès la création.

Chez GreenFarm, ce mode de fonctionnement est devenu la norme : les pipelines produisent directement des tables gouvernées, prêtes à être utilisées, sans étape manuelle de déclaration ou de catalogage.

Dans ce screencast, vous allez voir :

• comment enregistrer des tables dans Unity Catalog ;

• comment une requête SQL masque complètement la complexité du stockage ;

• comment gérer les permissions et visualiser les usages.

Découvrez les Métastores et catalogues open source 

Unity Catalog illustre une tendance plus large : celle de catalogues ouverts et interopérables, adaptés aux architectures Lakehouse. Plusieurs projets open source explorent ces approches : 

• Unity Catalog Open Source permet de comprendre et d’expérimenter ces concepts hors plateforme managée.

• DuckLake adopte une approche plus légère, très intégrée à DuckDB, adaptée à des Lakehouses analytiques simples ou locaux.

• Polaris se positionne comme un métastore ouvert orienté Iceberg, avec un fort accent sur l’interopérabilité multi-moteurs.

Marc et toute l'équipe GreenFarm sont fiers de vos accomplissements ! Ces compétences vous permettent maintenant de concevoir et gérer des plateformes de données à l'échelle de l'entreprise. N'hésitez pas à continuer d'explorer, d'expérimenter et de partager vos connaissances avec la communauté. L'agriculture de précision et la transformation digitale ne font que commencer, et vous êtes maintenant équipé pour relever ces défis passionnants.
Vous avez compris pourquoi les data lakes traditionnels ne suffisent plus, comment les formats open table comme Delta Lake et Iceberg apportent fiabilité et évolutivité, et comment le calcul distribué permet de passer à l’échelle. Vous avez ensuite exploré les mécanismes avancés de performance, d’historisation et de suivi des changements, avant d’aborder un enjeu fondamental : la gouvernance des données.
À travers le cas de GreenFarm, vous avez vu qu’un Lakehouse n’est pas qu’un empilement de technologies, mais un équilibre entre stockage, calcul, performance et gouvernance. Les catalogues et métastores jouent un rôle clé pour transformer des fichiers distribués en données compréhensibles, sécurisées et exploitables par toute une organisation.
Vous disposez désormais des bases conceptuelles et techniques pour :

• concevoir un Lakehouse robuste ;

• faire des choix éclairés entre outils et formats ouverts ;

• structurer une plateforme data capable de soutenir des usages analytiques, décisionnels et avancés.

Le Lakehouse n’est pas une mode : c’est une évolution naturelle des architectures de données. À vous maintenant de l’adapter à vos propres contextes, contraintes et ambitions.

À vous de jouer !

Contexte

Dans cet exercice, vous allez mettre en pratique les concepts de gouvernance et de catalogage en jouant le rôle d’un architecte data chez GreenFarm. Votre objectif est de transformer un simple fichier CSV en une table Delta gouvernée, accessible via un catalogue, avec des règles d’accès claires. 

Consigne  

1. Créez la structure du Lakehouse :

• Créez un catalogue nommé `agriculture`.

• A l’intérieur de ce catalogue, créez deux schémas: `raw`et `analytics`.

2. Sauvegardez le CSV en Delta (zone raw) :

• Chargez le fichier greenfarm_sensors.csv.

• Sauvegardez-le au format Delta Lake dans le data lake, enregistrez le fichier dans Unity sous `agriculture.raw.sensors`.

• Regardez son chemin d’accès et vérifier qu’il s’agisse bien d’une table managée.

• Exécutez la requête suivante pour vérifier l’accès : `  

  SELECT * FROM agriculture.raw.sensors LIMIT 10

3. Créez une table managée pour l’analytics :

• Sélectionnez les colonnes utiles depuis la table source : la date de mesure ; l’identifiant de la parcelle ; les valeurs d’humidité et de température.

• Transformez la date si nécessaire pour ne conserver que le jour (sans l’heure).

• Regroupez les données par jour et parcelle.

• Calculez les agrégats suivants : la moyenne de l’humidité (avg_humidity) et la moyenne de la température (avg_temperature).

• Créez la table managée avec le nom suivant : `agriculture.analytics.sensors_daily`

4. Interrogez les deux tables créées via le catalogue.

5. Gérez les accès aux données : Accordez des droits de lecture (SELECT) à votre utilisateur sur le schéma : agriculture.analytics

En résumé

• L’architecture Lakehouse introduit une nouvelle complexité par rapport aux bases de données classiques : les données sont stockées sous forme de fichiers distribués, potentiellement répartis sur plusieurs data lakes, ce qui rend impossible un simple inventaire basé sur les tables physiques.

• Pour relier les fichiers stockés dans le data lake aux tables logiques exploitées par les moteurs de calcul, un métastore technique devient indispensable ; il constitue la couche de traduction entre stockage physique, schéma logique et usages analytiques.

• Les catalogues de données modernes étendent ce rôle en centralisant les métadonnées, la traçabilité et les règles d’accès, devenant ainsi la colonne vertébrale de la gouvernance d’un Lakehouse.

• Unity Catalog propose une gouvernance unifiée en abstrahant totalement l’emplacement physique des données : une table peut référencer un fichier Delta stocké dans un data lake externe ou être entièrement managée par la plateforme, tout en restant accessible via une syntaxe SQL standard (catalog.schema.table).

• Cette séparation claire entre stockage et gouvernance permet d’appliquer des règles de sécurité cohérentes, quel que soit le moteur ou le type d’usage (ingénierie, analytique, machine learning).

• Les principes de catalogage et de métastore dépassent le cadre de Databricks : des alternatives open source comme Unity Catalog Open Source, DuckLake ou Polaris illustrent l’évolution vers des catalogues interopérables, adaptés aux formats open table et aux architectures distribuées.

Félicitations, vous avez terminé le cours ! Il ne vous reste plus qu’à tester vos connaissances avec le quiz final !