Créer un lakehouse Iceberg gouverné avec BigLake et Dataplex

1. Introduction

Dans un cloud de données d'entreprise moderne, où les données sont stockées dans différents systèmes de stockage physique, la sécurité fragmentée représente un défi architectural majeur.

Comment vous assurez-vous que les données sensibles (comme les montants des transactions financières) sont protégées de manière cohérente lorsque les données sont stockées physiquement dans des formats Open Source tels que Parquet sur Google Cloud Storage et interrogées par plusieurs moteurs différents, tels que BigQuery SQL ou Apache Spark ?

Dans cet atelier de programmation, vous allez créer une architecture de lakehouse de données gouvernées qui résout ces problèmes à l'aide des tables Apache Iceberg, de BigQuery et du catalogue universel Dataplex. Vous utiliserez l'Infrastructure as Code (IaC) pour définir des stratégies de sécurité Zero Trust et la manière dont elles sont appliquées de manière dynamique sur différents moteurs de calcul.

Prérequis

Un projet Google Cloud avec facturation activée.
Connaissances de base des concepts SQL, IAM et Cloud Storage.

Points abordés

Découvrez comment créer des tables BigLake pour Apache Iceberg dans BigQuery, où Cloud Storage stocke les données de manière native.
Découvrez comment appliquer des règles de données centralisées à l'aide de tags avec stratégie pour la sécurité au niveau des colonnes et le masquage des données.
Découvrez comment dissocier l'accès au stockage physique de l'accès logique aux données à l'aide d'une connexion de ressources Cloud.
Découvrez comment appliquer la délégation de calcul Zero Trust à l'aide de Google Cloud Serverless pour Apache Spark afin de vous assurer que les moteurs Open Source ne peuvent pas contourner la gouvernance.
Visualiser la traçabilité des données automatisée

Présentation de l'architecture : gouvernance universelle sur Iceberg

Pour obtenir un contrôle des accès précis (comme la sécurité au niveau des colonnes et le masquage des données) sur les formats de données Open Source, vous devez établir une architecture de sécurité stricte et unifiée.

Comme l'illustre le schéma, ce modèle de lakehouse contrôlé repose sur deux piliers principaux pour résoudre le problème de la sécurité fragmentée :

🛡️ Couches architecturales sécurisées (à gauche)

Au lieu d'autoriser les utilisateurs ou les moteurs externes à accéder directement à Cloud Storage (qui n'est compatible qu'avec une sécurité générale au niveau du bucket), vous créez une base sécurisée.

Format ouvert, métadonnées gérées : les données restent physiquement dans Cloud Storage au format Apache Iceberg (Parquet) ouvert, tandis que BigLake gère de manière transparente les métadonnées associées.
Limite de sécurité logique : vous dissociez l'accès au stockage physique de l'accès logique aux données à l'aide d'une connexion sécurisée aux ressources Cloud. Les utilisateurs finaux ne bénéficient jamais d'un accès IAM physique direct aux fichiers GCS bruts.
Délégation de calcul Zero Trust : pour s'assurer qu'aucun moteur d'exécution ne peut contourner les règles de gouvernance, toutes les demandes de lecture de données sont strictement acheminées via l'API BigQuery Storage. Cela s'applique que la requête provienne de BigQuery SQL natif ou d'Apache Spark Open Source.

🎯 Application centralisée des règles (à droite)

Une fois cette base sécurisée en place, Dataplex agit comme un cerveau unifié pour la gouvernance :

Définissez les tags de règles une seule fois et appliquez-les partout : vous définissez vos tags de règles dans Dataplex une seule fois, et l'architecture applique des règles de masquage cohérentes de manière universelle à tous les runtimes d'exécution compatibles.
Masquage dynamique des données : lorsque des données sont interrogées, le système évalue l'identité de l'utilisateur à la volée. Alors que les utilisateurs autorisés verront les valeurs brutes non masquées (par exemple, 100,0) dans SQL et Spark, les utilisateurs restreints recevront automatiquement des valeurs NULL masquées pour les colonnes restreintes dans les deux moteurs.
Traçabilité automatisée des données : à mesure que les données circulent et se transforment, Dataplex capture automatiquement les métadonnées de transformation, ce qui permet une auditabilité et une traçabilité de bout en bout intégrées sans nécessiter de code de journalisation personnalisé.

2. Préparation

Démarrer Cloud Shell

Bien que Google Cloud puisse être utilisé à distance depuis votre ordinateur portable, nous allons nous servir de Google Cloud Shell pour cet atelier de programmation, un environnement de ligne de commande exécuté dans le cloud.

Dans la console Google Cloud, cliquez sur l'icône Cloud Shell dans la barre d'outils supérieure :

Activer Cloud Shell

Le provisionnement et la connexion à l'environnement prennent quelques instants seulement. Une fois l'opération terminée, le résultat devrait ressembler à ceci :

Capture d'écran du terminal Google Cloud Shell montrant que l'environnement est connecté

Cette machine virtuelle contient tous les outils de développement nécessaires. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud, ce qui améliore nettement les performances du réseau et l'authentification. Vous pouvez effectuer toutes les tâches de cet atelier de programmation dans un navigateur. Vous n'avez rien à installer.

Initialiser l'environnement

Ouvrez Cloud Shell et définissez les variables de votre projet pour vous assurer que toutes les commandes ciblent la bonne infrastructure.

export PROJECT_ID=$(gcloud config get-value project)
export REGION="us-central1"
export ICEBERG_BUCKET="iceberg-retail-demo-${PROJECT_ID}"
export DATASET_ID="lakehouse_retail_demo"
export CONN_NAME="iceberg-bq-conn-demo"

Définissons ensuite nos deux personas.

export USER_ANALYST="retail-analyst-demo"
export EMAIL_ANALYST="${USER_ANALYST}@${PROJECT_ID}.iam.gserviceaccount.com"

export USER_MANAGER="retail-manager-demo"
export EMAIL_MANAGER="${USER_MANAGER}@${PROJECT_ID}.iam.gserviceaccount.com"
export CURRENT_USER=$(gcloud config get-value account)

Activer les API

Activez les services Google Cloud nécessaires.

gcloud services enable \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com \
  datacatalog.googleapis.com \
  bigquerydatapolicy.googleapis.com \
  datalineage.googleapis.com \
  dataplex.googleapis.com \
  dataproc.googleapis.com \
  storage-component.googleapis.com

Télécharger le code source de l'atelier de programmation

Pour éviter d'encombrer votre Cloud Shell, vous allez effectuer un checkout sparse afin de télécharger uniquement les scripts Python nécessaires à cet atelier de programmation à partir du dépôt Google Cloud DevRel.

# Shallow clone without full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos

# Download only the specific folder
git sparse-checkout set data-analytics/governed-lakehouse
cd data-analytics/governed-lakehouse

Créer un espace de stockage

Créez le bucket pour stocker les données Iceberg régies et hautement sécurisées.

gcloud storage buckets create gs://${ICEBERG_BUCKET} --location=${REGION}

Préparer les identités et la sécurité

Configurer la connexion à la ressource cloud Il s'agit de la seule entité qui détient les clés IAM physiques permanentes permettant de lire les fichiers Iceberg bruts.

# Create the BigQuery connection
bq mk --connection \
    --connection_type=CLOUD_RESOURCE \
    --location=${REGION} \
    ${CONN_NAME}

# Retrieve the connection's automatically generated Service Account
export BQ_CONN_SVC_ACCT=$(bq show --format=json --connection ${REGION}.${CONN_NAME} \
    | jq -r '.cloudResource.serviceAccountId')

# Grant Storage Object Admin to the connection for the Iceberg bucket
gcloud storage buckets add-iam-policy-binding gs://${ICEBERG_BUCKET} \
    --member="serviceAccount:${BQ_CONN_SVC_ACCT}" \
    --role="roles/storage.objectAdmin" \
    --quiet

Ensuite, configurez les personas utilisateur. Les utilisateurs bénéficient d'un accès logique, et non physique, au stockage. Pour éviter les erreurs causées par les délais de propagation IAM, vous allez d'abord créer les comptes, attendre quelques secondes, puis attribuer leurs rôles.

echo "Creating Service Accounts..."
for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
    gcloud iam service-accounts create ${USER} --display-name="Lakehouse ${USER}"
done

echo "⏳ Waiting 15 seconds for IAM propagation..."
sleep 15

echo "Granting IAM Roles to Service Accounts..."
for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
    EMAIL="${USER}@${PROJECT_ID}.iam.gserviceaccount.com"
    
    # Allow Cloud Shell to impersonate them for testing
    gcloud iam service-accounts add-iam-policy-binding ${EMAIL} \
        --member="user:${CURRENT_USER}" \
        --role="roles/iam.serviceAccountTokenCreator" \
        --quiet

    # Allow logical viewing of the catalog, querying, and running Dataproc jobs
    for ROLE in "roles/datacatalog.viewer" "roles/bigquery.dataViewer" "roles/bigquery.user" "roles/bigquery.connectionUser" "roles/serviceusage.serviceUsageConsumer" "roles/dataproc.worker"; do
        gcloud projects add-iam-policy-binding ${PROJECT_ID} \
            --member="serviceAccount:${EMAIL}" \
            --role="${ROLE}" \
            --quiet
    done
done

# Grant the Manager data creation rights
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${EMAIL_MANAGER}" \
    --role="roles/bigquery.dataEditor" \
    --quiet

echo "✅ Identity and Security setup completed!"

3. Créer des tables Iceberg natives avec BigLake

Vous utiliserez les fonctionnalités natives de BigLake pour créer les tables Iceberg gérées.

Créer l'ensemble de données BigQuery

Commencez par créer un ensemble de données BigQuery pour regrouper logiquement nos tables Iceberg.

echo "Creating BigQuery Dataset..."
bq mk --location=${REGION} --dataset ${PROJECT_ID}:${DATASET_ID}

Créer les tables Iceberg

Ensuite, exécutez les commandes suivantes pour créer les tables. Notez le bloc OPTIONS où nous spécifions table_format = 'ICEBERG' et le mappons directement à notre bucket et à notre connexion Cloud Storage.

echo "Creating Iceberg tables..."

# Inventory table
bq query --use_legacy_sql=false \
"CREATE OR REPLACE TABLE \`${PROJECT_ID}.${DATASET_ID}.inventory\` (
    product_id INT64, 
    product_name STRING, 
    stock_count INT64
) 
WITH CONNECTION \`${REGION}.${CONN_NAME}\` 
OPTIONS (
    file_format = 'PARQUET',
    table_format = 'ICEBERG',
    storage_uri = 'gs://${ICEBERG_BUCKET}/inventory/'
);"

# Transactions table
bq query --use_legacy_sql=false \
"CREATE OR REPLACE TABLE \`${PROJECT_ID}.${DATASET_ID}.transactions\` (
    id INT64, 
    item STRING, 
    amount FLOAT64, 
    transaction_date DATE
) 
WITH CONNECTION \`${REGION}.${CONN_NAME}\` 
OPTIONS (
    file_format = 'PARQUET',
    table_format = 'ICEBERG',
    storage_uri = 'gs://${ICEBERG_BUCKET}/transactions/'
);"

Remplir les tableaux avec des données

Enfin, insérez des exemples de données dans les tables Iceberg que vous venez de créer.

echo "Inserting data into Iceberg tables..."

# Insert into Inventory table
bq query --use_legacy_sql=false \
"INSERT INTO \`${PROJECT_ID}.${DATASET_ID}.inventory\` (product_id, product_name, stock_count)
VALUES (101, 'Widget A', 500), (102, 'Widget B', 250), (103, 'Widget C', 800);"

# Insert into Transactions table
bq query --use_legacy_sql=false \
"INSERT INTO \`${PROJECT_ID}.${DATASET_ID}.transactions\` (id, item, amount, transaction_date)
VALUES 
    (1, 'Widget A', 100.0, DATE '2024-01-01'), 
    (2, 'Widget B', 150.0, DATE '2024-01-02'), 
    (3, 'Widget C', 50.0, DATE '2024-01-03');"

Vous disposez maintenant de deux tables Iceberg entièrement fonctionnelles. BigLake gère les métadonnées, mais les fichiers Parquet physiques résident de manière sécurisée dans votre bucket GCS.

Simuler un pipeline ETL

Dans un scénario réel, les données brutes sont souvent agrégées dans des tableaux récapitulatifs pour les rapports d'entreprise. Agissons comme des ingénieurs de données et créons un tableau récapitulatif des ventes quotidiennes à partir de nos données brutes sur les transactions.

(Remarque : exécutez cette étape maintenant pour que Google Cloud ait suffisamment de temps pour traiter les métadonnées en arrière-plan. Vous comprendrez pourquoi c'est important plus loin dans cet atelier de programmation.)

echo "Creating transactions summary table..."
bq query --use_legacy_sql=false \
"CREATE TABLE \`${PROJECT_ID}.${DATASET_ID}.transactions_summary\` AS 
 SELECT transaction_date, SUM(amount) as total_sales, COUNT(id) as transaction_count 
 FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\` 
 GROUP BY transaction_date;"

4. Gouvernance centralisée : définir des règles à l'aide de Python

Dans un environnement de production, il est difficile de mettre à l'échelle et de maintenir la configuration des règles de gouvernance via l'UI. Nous vous recommandons vivement d'utiliser l'Infrastructure as Code (IaC).

Dans cette section, vous allez utiliser le SDK Python Google Cloud pour créer et appliquer vos règles de gouvernance Zero Trust de manière programmatique, étape par étape.

Configurer l'environnement Python

Commençons par configurer un environnement Python isolé (venv) pour éviter les conflits de bibliothèque et installer les SDK Google Cloud requis.

Exécutez les commandes suivantes dans Cloud Shell :

# Create and activate a virtual environment
python3 -m venv lakehouse_env
source lakehouse_env/bin/activate

# Install required Dataplex and BigQuery governance libraries
pip install google-cloud-datacatalog google-cloud-bigquery-datapolicies google-cloud-bigquery --quiet

echo "✅ Python environment is ready!"

Créer la taxonomie et le tag avec stratégie

Une taxonomie est un conteneur logique, et un tag avec stratégie est le libellé spécifique que vous allez associer à votre colonne sensible. Pour appliquer la sécurité au niveau des colonnes, vous avez d'abord besoin d'un conteneur logique (une taxonomie) et d'un libellé spécifique (un tag avec stratégie).

Si vous examinez 1_create_taxonomy.py, vous verrez la logique de base suivante :

# Create Taxonomy with Fine-Grained Access Control enabled
taxonomy = datacatalog_v1.Taxonomy(
    display_name="BusinessCritical",
    activated_policy_types=[datacatalog_v1.Taxonomy.PolicyType.FINE_GRAINED_ACCESS_CONTROL]
)
created_taxonomy = client.create_taxonomy(parent=parent, taxonomy=taxonomy)

# Create Policy Tag inside the Taxonomy
policy_tag = datacatalog_v1.PolicyTag(display_name="RestrictedFinancial")
created_policy_tag = client.create_policy_tag(parent=created_taxonomy.name, policy_tag=policy_tag)

En définissant explicitement le type de règle FINE_GRAINED_ACCESS_CONTROL, vous transformez un tag de métadonnées standard en limite de sécurité stricte de type "zéro confiance". Par défaut, l'accès à toute colonne comportant ce tag sera refusé à tous les utilisateurs.

Exécutez le script pour créer les ressources :

python 1_create_taxonomy.py

Configurer la règle de masquage (règle de données)

Vous allez maintenant définir ce qui se passe lorsqu'une personne sans privilèges interroge la colonne taguée. Vous allez créer un Règlement sur les données qui forcera la valeur à renvoyer NULL et associera cette règle au Personnage Analyste.

Dans 2_create_masking.py, le script recherche de manière dynamique l'ID du tag avec stratégie que vous venez de créer et applique une règle de données :

# Define a Masking Policy that always returns NULL
data_policy = bigquery_datapolicies_v1.DataPolicy(
    data_policy_id="mask_financial_null",
    policy_tag=policy_tag_id,
    data_policy_type=bigquery_datapolicies_v1.DataPolicy.DataPolicyType.DATA_MASKING_POLICY,
    data_masking_policy=bigquery_datapolicies_v1.DataMaskingPolicy(
        predefined_expression=bigquery_datapolicies_v1.DataMaskingPolicy.PredefinedExpression.ALWAYS_NULL
    )
)

# ... (Policy creation code) ...

# Bind the Masked Reader role to the Analyst
iam_policy.bindings.add(
    role="roles/bigquerydatapolicy.maskedReader", 
    members=[f"serviceAccount:{analyst_email}"]
)

Ce code crée par programmation une règle qui force les valeurs sous-jacentes à renvoyer la valeur NULL. Il attribue ensuite le rôle IAM maskedReader spécifiquement au persona Analyst, ce qui garantit qu'il ne voit que la version masquée des données.

Exécutez le script pour configurer la règle de masquage :

python 2_create_masking.py

Accorder un accès précis

En raison de notre configuration Zero Trust, personne ne peut lire la colonne taguée pour le moment. Vous devez explicitement accorder l'accès au compte administrateur et à votre compte personnel.

Dans 3_grant_access.py, vous modifiez la stratégie IAM du tag de stratégie lui-même :

# Grant original data read access
iam_policy.bindings.add(
    role="roles/datacatalog.categoryFineGrainedReader",
    members=[f"serviceAccount:{manager_email}", f"user:{current_user}"]
)
client.set_iam_policy(request=iam_policy_pb2.SetIamPolicyRequest(resource=policy_tag_id, policy=iam_policy))

L'ajout du rôle categoryFineGrainedReader permet à ces principaux spécifiques de contourner les règles de masquage et de lire les données brutes non masquées.

Exécutez le script pour accorder l'accès :

python 3_grant_access.py

Associer le tag avec stratégie à la table BigQuery

Enfin, vous devez associer ce tag de règle logique à notre schéma de table Iceberg physique.

Regardez le fichier 4_attach_tag.py. Le script récupère le schéma de la table BigQuery, parcourt les champs et associe le tag spécifiquement à la colonne amount :

new_schema =[]
for field in table.schema:
    if field.name == 'amount':
        # Wrap the Policy Tag ID and attach it to the column
        policy_tags_list = bigquery.PolicyTagList(names=[policy_tag_id])
        new_field = bigquery.SchemaField(
            name=field.name, field_type=field.field_type, mode=field.mode,
            description=field.description, policy_tags=policy_tags_list
        )
        new_schema.append(new_field)
    else:
        new_schema.append(field)

# Update the table schema in BigQuery
table.schema = new_schema
client.update_table(table, ["schema"])

Lorsque cette mise à jour du schéma est appliquée, BigLake relie instantanément nos tags logiques Dataplex aux fichiers Parquet physiques stockés dans votre bucket Cloud Storage.

Exécutez le script pour mettre à jour le schéma de la table :

python 4_attach_tag.py

5. Valider les règles Dataplex

Il est temps de tester si notre gouvernance centralisée fonctionne. Vous allez tester cela sur deux moteurs différents pour prouver que les règles Dataplex sont appliquées de manière universelle.

Valider à l'aide du code SQL natif de BigQuery

Tout d'abord, vous utiliserez Cloud Shell pour assumer l'identité de nos deux personas et interroger la table à l'aide du moteur SQL natif de BigQuery.

Testez en tant qu'administrateur (utilisateur privilégié) :

# Impersonate the manager
gcloud config set auth/impersonate_service_account ${EMAIL_MANAGER}

# Query the transactions table
bq query --use_legacy_sql=false "SELECT * FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\`"

Comme le responsable dispose du rôle "Lecteur détaillé", les valeurs brutes des montants s'affichent.

+----+----------+--------+------------------+
| id |   item   | amount | transaction_date |
+----+----------+--------+------------------+
|  1 | Widget A |  100.0 |       2024-01-01 |
|  3 | Widget C |   50.0 |       2024-01-03 |
|  2 | Widget B |  150.0 |       2024-01-02 |
+----+----------+--------+------------------+

Testez en tant qu'analyste (utilisateur restreint) :

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

bq query --use_legacy_sql=false "SELECT * FROM \`${PROJECT_ID}.${DATASET_ID}.transactions\`"

En raison de la règle de masquage Dataplex, la colonne "Montant" renvoie NULL pour chaque ligne.

+----+----------+--------+------------------+
| id |   item   | amount | transaction_date |
+----+----------+--------+------------------+
|  1 | Widget A |   NULL |       2024-01-01 |
|  3 | Widget C |   NULL |       2024-01-03 |
|  2 | Widget B |   NULL |       2024-01-02 |
+----+----------+--------+------------------+

Restaurer votre identité

Nettoyez l'état d'authentification Cloud Shell pour revenir à votre utilisateur administrateur.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Valider à l'aide d'Apache Spark (délégation de calcul)

Que se passe-t-il si un data scientist utilise Apache Spark pour lire cette table ? Si Spark lit directement les fichiers Parquet GCS physiques, les règles de masquage Dataplex sont entièrement contournées, car Cloud Storage ne comprend que les autorisations au niveau du bucket.

Pour éviter cela, vous appliquez la délégation de calcul à l'aide du connecteur Spark-BigQuery. Ce connecteur sert de pont sécurisé, en acheminant les requêtes de lecture Spark via l'API BigQuery Storage. Les règles de gouvernance Dataplex sont ainsi évaluées de manière dynamique avant que les données ne soient envoyées au cluster Spark.

Examinez la logique de base du script read_transactions.py que vous avez téléchargé :

# Reading data via Compute Delegation (Dataplex policies are applied dynamically here)
df = spark.read \
    .format("bigquery") \
    .option("table", f"{project_id}.{dataset_id}.{table_name}") \
    .load()

print("\n=== 📊 Data Preview ===")
df.show(truncate=False)

Notez que nous ne dirigeons pas Spark vers le chemin d'accès gs:// des fichiers Iceberg. En spécifiant .format("bigquery"), l'API BigQuery Storage intercepte la requête de lecture, vérifie l'identité de l'utilisateur exécutant le job Spark, applique les règles de masquage Dataplex et ne renvoie que les données autorisées au DataFrame Spark.

Importez ce script PySpark dans votre bucket Cloud Storage pour que Dataproc puisse y accéder :

# Upload script to GCS
gsutil cp read_transactions.py gs://${ICEBERG_BUCKET}/scripts/read_transactions.py

Exécutez Spark en tant que gestionnaire :

Vous utiliserez Google Cloud Serverless pour Apache Spark. Ce service géré vous permet d'exécuter directement des charges de travail Spark sans avoir à provisionner, configurer ni gérer de clusters dédiés.

echo "🚀 Submitting Dataproc Serverless Job as [MANAGER]..."
gcloud dataproc batches submit pyspark gs://${ICEBERG_BUCKET}/scripts/read_transactions.py \
    --project=${PROJECT_ID} \
    --region=${REGION} \
    --service-account=${EMAIL_MANAGER} \
    --version=2.3 \
    -- ${PROJECT_ID} ${DATASET_ID} \
    --format="value(name)"

Examinez les journaux de sortie du job dans le terminal. Étant donné que le responsable dispose du rôle Lecteur détaillé, Spark récupère correctement les montants bruts non masqués.

=== 📊 Data Preview ===
+---+--------+------+-------------------+
|id |item    |amount|transaction_date   |
+---+--------+------+-------------------+
|1  |Widget A|100.0 |2024-01-01         |
|2  |Widget B|150.0 |2024-01-02         |
|3  |Widget C|50.0  |2024-01-03         |
+---+--------+------+-------------------+

Exécutez Spark en tant qu'analyste :

Maintenant, envoyez exactement la même tâche Spark, mais cette fois en vous faisant passer pour l'analyste.

echo "🚀 Submitting Dataproc Serverless Job as [ANALYST]..."
gcloud dataproc batches submit pyspark gs://${ICEBERG_BUCKET}/scripts/read_transactions.py \
    --project=${PROJECT_ID} \
    --region=${REGION} \
    --service-account=${EMAIL_ANALYST} \
    --version=2.3 \
    -- ${PROJECT_ID} ${DATASET_ID} \
    --format="value(name)"

Vérifiez à nouveau les journaux. Même si l'analyste a exécuté exactement le même code Spark, l'API BigQuery Storage a intercepté la requête et appliqué le règlement Dataplex. Le DataFrame Spark de l'analyste affiche null pour les montants.

=== 📊 Data Preview ===
+---+--------+------+-------------------+
|id |item    |amount|transaction_date   |
+---+--------+------+-------------------+
|1  |Widget A|null  |2024-01-01         |
|2  |Widget B|null  |2024-01-02         |
|3  |Widget C|null  |2024-01-03         |
+---+--------+------+-------------------+

Compromis architecturaux : BigQuery SQL vs Spark

Vous venez de prouver que le résultat est identique, quel que soit le moteur. La règle Dataplex a bien été appliquée. Mais en production, laquelle devez-vous utiliser ?

BigQuery SQL : idéal pour les workflows où SQL est le moteur souhaité et exécute les calculs directement sur place. Il est idéal pour l'analyse rapide et l'informatique décisionnelle.
Apache Spark : permet des charges de travail plus complexes grâce à l'utilisation de Python, ce qui le rend bien adapté aux pipelines de machine learning avancés ou au code Hadoop hérité.

En résumé : Quel que soit le moteur utilisé, la délégation de calcul permet de s'assurer que la couche de gouvernance centralisée Zero Trust ne peut jamais être contournée.

6. Traçabilité des données automatisée

Dans toute architecture de données d'entreprise, il est essentiel de savoir exactement d'où proviennent vos données et comment elles ont été modifiées pour assurer la conformité, le débogage et la fiabilité. Ce concept est appelé lignée de données. Il répond à des questions fondamentales telles que : "Si un responsable consulte un rapport sur les ventes quotidiennes, quelles tables brutes ont été utilisées pour calculer ces chiffres ?"

Traditionnellement, le suivi de ce cycle de vie nécessite que les ingénieurs de données écrivent manuellement du code de journalisation personnalisé ou utilisent des outils tiers complexes pour analyser les scripts SQL. Toutefois, dans un lakehouse Google Cloud gouverné, ce suivi est intégré et entièrement automatique.

Vous vous souvenez de la table transactions_summary que vous avez créée à partir de la table des transactions brutes plus tôt dans l'atelier de programmation ? Lorsque BigQuery a exécuté cette instruction CREATE TABLE AS SELECT, le moteur de calcul a automatiquement capturé les métadonnées de transformation et les a envoyées à Dataplex. Voyons le résultat.

Visualiser la traçabilité

Dans la console Google Cloud, accédez à Catalogue universel Dataplex > Rechercher.
Saisissez lakehouse_retail_demo.transactions dans la barre de recherche, puis cliquez sur le tableau.
Cliquez sur l'onglet Traçabilité.

Un graphique interactif généré par le moteur de connaissances Dataplex s'affiche, prouvant que la table cible (transactions_summary) a été dérivée de la table Iceberg brute régie (transactions). Vous avez obtenu une traçabilité de bout en bout essentielle pour l'audit des données.

7. Effectuer un nettoyage

Pour éviter que les ressources utilisées dans cet atelier de programmation soient facturées sur votre compte Google Cloud, procédez comme suit :

Supprimer les ressources de gouvernance Dataplex

Avant de supprimer l'ensemble de données BigQuery ou le bucket Cloud Storage, vous devez supprimer les règles de gouvernance logique. Si vous examinez le script cleanup_governance.py du dépôt, vous verrez la séquence de démontage suivante :

# 1. Delete Data Policy
data_policy_name = f"{parent_loc}/dataPolicies/mask_financial_null"
dp_client.delete_data_policy(name=data_policy_name)

# 2. Find and Delete Taxonomy (This auto-deletes child Policy Tags)
taxonomies = catalog_client.list_taxonomies(parent=parent_loc)
taxonomy_id = next((t.name for t in taxonomies if t.display_name == "BusinessCritical"), None)
catalog_client.delete_taxonomy(name=taxonomy_id)

L'ordre est essentiel. Le script supprime d'abord la règle d'omission des données, car il s'appuie sur le tag avec stratégie. Une fois la règle supprimée, la suppression de la taxonomie parente se répercute automatiquement sur tous les tags avec stratégie sous-jacents, qui sont également supprimés sans générer d'erreurs de dépendance des ressources.

Exécutez le script de nettoyage Python :

python cleanup_governance.py

Supprimer les identités, le stockage et les ressources de calcul

Maintenant que le niveau de gouvernance est détaché, vous pouvez supprimer sans risque les tables BigQuery, les buckets Cloud Storage, les comptes de service et l'environnement Python local.

Copiez et exécutez le bloc de nettoyage complet suivant dans Cloud Shell :

echo "Deleting Service Accounts and Impersonation Bindings..."
export CURRENT_USER=$(gcloud config get-value account)

for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
    EMAIL="${USER}@${PROJECT_ID}.iam.gserviceaccount.com"
    
    # Remove impersonation binding
    gcloud iam service-accounts remove-iam-policy-binding ${EMAIL} \
        --member="user:${CURRENT_USER}" \
        --role="roles/iam.serviceAccountTokenCreator" \
        --quiet > /dev/null 2>&1
        
    # Delete the Service Account
    gcloud iam service-accounts delete ${EMAIL} --quiet
done

echo "Removing BigQuery Dataset and Tables..."
bq rm -f ${DATASET_ID}.transactions_summary
bq rm -f ${DATASET_ID}.transactions
bq rm -f ${DATASET_ID}.inventory
bq rm -f -d ${DATASET_ID}

echo "Removing BigQuery Cloud Resource Connection..."
bq rm --connection --location=${REGION} ${CONN_NAME}

echo "Removing Iceberg Cloud Storage Bucket..."
gcloud storage rm --recursive gs://${ICEBERG_BUCKET} --quiet

echo "Removing Auto-generated Dataproc Staging & Temp Buckets..."
for BUCKET in $(gcloud storage ls | grep -E "gs://dataproc-(staging|temp)-${REGION}"); do
    gcloud storage rm --recursive $BUCKET --quiet
done

echo "Deactivating and removing the local Python environment..."
deactivate
cd ../..
rm -rf devrel-demos

echo "✅ Clean up completed successfully!"

En suivant ces étapes, vous vous êtes assuré qu'il ne reste aucune ressource orpheline ni aucune règle cachée dans votre projet.

8. Félicitations !

Vous avez implémenté un Data Lakehouse entièrement gouverné et détectable.

Vous avez appris que :

Intégration native d'Iceberg : BigLake peut gérer de manière native les tables Iceberg Open Source tout en stockant les fichiers physiques de manière sécurisée dans Cloud Storage.
Délégation de calcul pour la sécurité : en acheminant les requêtes via l'API BigQuery Storage, vous avez appliqué un masquage dynamique précis aux fichiers physiques qui ne peuvent pas limiter l'accès partiel de manière native.
Gouvernance indépendante du moteur : les tags de règles vous permettent de définir des règles une seule fois et de les appliquer de manière universelle, qu'elles soient interrogées via des runtimes SQL natifs ou Apache Spark.
Visibilité des données : le moteur de connaissances Dataplex a automatiquement suivi la lignée des données, ce qui a permis d'assurer l'auditabilité essentielle de l'entreprise.

Et ensuite ?

Découvrez le contrôle d'accès avancé : pour implémenter des scénarios de sécurité plus complexes, consultez la documentation officielle sur la personnalisation de BigLake avec des fonctionnalités supplémentaires.
Gouverner les données non structurées pour l'IA générative : découvrez les tables d'objets BigLake. Étendez ce modèle de pont sécurisé exact aux fichiers non structurés (PDF, images) dans Cloud Storage, en établissant une base de données sécurisée et régie pour Vertex AI et les pipelines RAG.