Activer l'accès au lakehouse conforme aux règles avec Knowledge Catalog

Lorsque vous stockez vos données dans différents systèmes de stockage, la gestion d'une sécurité fragmentée peut devenir un défi majeur. Vous devez vous assurer que les informations sensibles, telles que les enregistrements financiers, restent protégées, même si vous les stockez dans des formats ouverts comme Apache Iceberg sur Google Cloud stockage.

Vos mesures de sécurité doivent impérativement fonctionner de manière transparente sur différents moteurs de requête, tels que BigQuery SQL et Apache Spark. Dans cette architecture, Knowledge Catalog résout ce problème en fonctionnant comme un moteur contextuel universel. Il contient les métadonnées nécessaires pour garantir que votre contexte de sécurité est appliqué de manière cohérente, quel que soit le moteur qui interroge les données.

Dans ce tutoriel, vous allez créer un data lakehouse sécurisé pour résoudre ces problèmes. À l'aide de scripts, vous définissez des règles de sécurité et voyez comment Knowledge Catalog (anciennement Dataplex Universal Catalog) et Lakehouse sans bordure fonctionnent ensemble pour appliquer les règles sur différents moteurs de requête.

Présentation de l'architecture

Pour configurer un contrôle précis des accès sur un format de table ouvert comme Apache Iceberg, vous devez créer une architecture de sécurité stricte et unifiée.

Avec cette conception, Knowledge Catalog fait office de plan de contrôle central. Knowledge Catalog applique dynamiquement votre contexte de sécurité sur tous les moteurs compatibles.

Architecture d'un lakehouse conforme aux règles, qui utilise des couches architecturales sécurisées et une application centralisée des règles.
Architecture d'un lakehouse conforme aux règles

Ce tutoriel repose sur deux concepts principaux pour créer cette architecture unifiée :

  • Couches architecturales sécurisées : au lieu de laisser les utilisateurs ou les moteurs de requête accéder directement à vos buckets Cloud Storage, vous créez une base sécurisée et multicouche basée sur les attributs suivants :
    • Format ouvert avec métadonnées gérées : vos données restent au format Apache Iceberg (Parquet) ouvert dans Cloud Storage, tandis que Lakehouse gère les métadonnées de la table.
    • Limite de sécurité logique : vous dissociez les autorisations de stockage des requêtes de données à l'aide d'une connexion aux ressources Cloud sécurisée. Vous n'accordez jamais aux utilisateurs finaux un accès direct aux fichiers.
    • Délégation de calcul : pour empêcher les moteurs de requête de contourner vos règles, vous acheminez toutes les requêtes de données via l'API BigQuery Storage. L'acheminement des requêtes via l'API BigQuery Storage garantit que Knowledge Catalog peut intercepter et appliquer des règles, même pour les moteurs de traitement externes.
  • Application centralisée des règles : avec une base sécurisée en place, vous utilisez Knowledge Catalog pour appliquer vos règles de manière universelle :
    • Définir une fois, appliquer partout : vous définissez les tags avec stratégie dans Knowledge Catalog une seule fois, et la plate-forme applique des règles de masquage cohérentes sur tous vos moteurs de requête compatibles.
    • Masquage dynamique des données : le système évalue l'identité de l'utilisateur lors des requêtes. Les utilisateurs autorisés voient les valeurs brutes, tandis que les utilisateurs restreints reçoivent des sorties NULL sur tous les moteurs de requête.
    • Traçabilité des données automatisée : Knowledge Catalog suit automatiquement les transformations de données, créant ainsi une piste d'audit sans code de journalisation personnalisé.

Objectifs

Avant de commencer

Avant de commencer, procédez comme suit :

Préparer votre environnement

Ce tutoriel utilise Cloud Shell, un environnement de ligne de commande qui s'exécute dans le cloud.

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

  2. Définissez les variables de votre projet :

    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"

  3. Définissez des variables pour deux profils d'utilisateur : un analyste de vente au détail et un responsable de vente au détail :

    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)

  4. Activez les Google Cloud API requises.

    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 du tutoriel

Téléchargez les scripts Python pour ce tutoriel à partir du Google Cloud dépôtDevRel :

# 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 bucket de stockage

Créez un bucket pour stocker les fichiers de table Iceberg :

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

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

Au cours de cette étape, vous allez configurer la délégation de calcul en créant une connexion à une ressource Cloud. Cette connexion fait office d'identité déléguée et sécurisée que BigQuery utilise pour gérer et lire vos fichiers Iceberg. Cela permet de s'assurer que les utilisateurs individuels n'ont jamais d'accès direct à votre bucket Cloud Storage.

Exécutez les commandes suivantes pour créer la connexion, récupérer son compte de service généré automatiquement et accorder à ce compte les autorisations nécessaires pour gérer vos données Iceberg :

# Create the Cloud resource 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

Créez des comptes de service pour deux profils : Analyst (Analyste) et Manager (Responsable). Les commandes suivantes configurent ces comptes de service, autorisent votre utilisateur actuel à les emprunter à des fins de test et leur accordent des rôles spécifiques pour exécuter des requêtes et afficher des données.

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 rules to apply..."
sleep 15

echo "Granting 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!"

Créer des tables Apache Iceberg

Utilisez le moteur SQL BigQuery pour créer des tables Apache Iceberg. Bien que vous exécutiez les commandes de création avec BigQuery, Lakehouse fait office de couche de gestion qui stocke les métadonnées de la table et sécurise les fichiers Parquet sous-jacents dans Cloud Storage.

Une fois les tables créées, vous exécutez une transformation rapide pour voir comment Knowledge Catalog gère la sécurité et suit automatiquement le parcours de vos données.

Créer un ensemble de données BigQuery

Commencez par créer un ensemble de données BigQuery pour regrouper vos tables :

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

Créer les tables Iceberg

Exécutez les commandes suivantes pour créer des tables d'inventaire et de transactions :

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/'
);"

Insérer des exemples de données

Insérez des exemples de données dans les tables :

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 contenant des exemples de données brutes. Lakehouse gère les métadonnées, mais les fichiers Parquet réels se trouvent dans votre bucket Cloud Storage.

Transformer les données pour une traçabilité automatisée

Agrégez vos transactions brutes dans un récapitulatif des ventes quotidiennes. Cette transformation crée une table et génère les métadonnées que Knowledge Catalog utilise pour mapper automatiquement le parcours de vos données.

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;"

Définir des règles de gouvernance des accès

Dans un environnement de production, l'écriture de vos règles de sécurité sous forme de code (infrastructure as code) rend vos règles reproductibles, contrôlées par version et plus faciles à gérer. Dans cette section, vous allez utiliser le Google Cloud SDK Python pour définir et appliquer automatiquement vos règles.

Préparer l'environnement virtuel Python

Configurez un environnement virtuel Python isolé pour gérer vos dépendances et vous assurer que les scripts s'exécutent de manière fiable :

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

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

echo "✅ Python environment is ready!"

Définir des taxonomies et des tags de sécurité

Commencez par créer la base de vos règles de sécurité. Au cours de cette étape, vous allez créer une taxonomie qui servira de conteneur et un tag avec stratégie qui servira de libellé de sécurité spécifique pour les données sensibles.

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

python 1_create_taxonomy.py

Examinez 1_create_taxonomy.py pour voir la logique de base :

# 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 une limite de sécurité stricte avec refus par défaut. Par défaut, toute colonne comportant ce tag refuse l'accès à tous les utilisateurs.

Créer une règle de masquage dynamique des données

Définissez maintenant ce qui se passe lorsqu'une personne sans privilèges interroge une colonne taguée. Créez une règle de masquage des données qui remplace automatiquement les valeurs sensibles par NULL pour le profil Analyst.

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

python 2_create_masking.py

Dans 2_create_masking.py, le script recherche l'ID du tag avec stratégie que vous avez créé et applique la règle de données au compte de service Analyst :

# 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}"]
)

Accorder un accès privilégié à vos données

En raison de votre configuration de refus par défaut, personne ne peut lire la colonne taguée. Vous devez accorder explicitement l'accès aux utilisateurs autorisés. Attribuez le rôle Lecteur détaillé au profil Manager et à votre propre compte. Cela permet à ces utilisateurs spécifiques de contourner les règles de masquage et de lire les données non masquées.

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

python 3_grant_access.py

Dans 3_grant_access.py, le script modifie la stratégie IAM du tag avec stratégie :

# 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))

Associer des tags de sécurité au schéma de table

Enfin, vous pouvez connecter vos règles logiques aux données réelles. Mettez à jour le schéma de votre table Iceberg pour associer directement votre tag avec stratégie à la colonne amount. Une fois cette opération effectuée, Lakehouse applique instantanément vos protections aux fichiers de table Iceberg de votre bucket.

Exécutez le script pour associer le tag avec stratégie :

python 4_attach_tag.py

Examinez 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"])

Vérifier vos règles de sécurité

Exécutez quelques requêtes de test pour vous assurer que vos autorisations fonctionnent comme prévu. Pour prouver que Knowledge Catalog fait office de moteur contextuel universel en appliquant les mêmes règles de sécurité lorsque vous changez de moteur de requête, vous exécutez ces tests à l'aide de BigQuery et d'Apache Spark.

Tester avec BigQuery SQL

Commencez par vérifier vos règles directement dans BigQuery. Il s'agit du moyen le plus rapide de confirmer que vos règles de masquage et vos autorisations sont actives.

Vérifier en tant que responsable

Le profil Manager dispose d'un accès privilégié et précis en lecture. Il doit voir tous les détails de la table, y compris les valeurs de la colonne amount.

# 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\`"

Étant donné que le responsable dispose du rôle Lecteur détaillé, la requête affiche les valeurs brutes du montant :

+----+----------+--------+------------------+
| 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 |
+----+----------+--------+------------------+

Vérifier en tant qu'analyste

Passez au profil Analyst et exécutez la même requête.

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Même si vous exécutez la même requête, Knowledge Catalog masque les valeurs sensibles de la colonne amount :

+----+----------+--------+------------------+
| 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 |
+----+----------+--------+------------------+

Retourner à votre compte

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

gcloud config unset auth/impersonate_service_account

Tester avec Apache Spark

La sécurité est souvent compromise lorsque les utilisateurs accèdent directement aux fichiers de données dans Cloud Storage. Si un data scientist utilise Apache Spark pour lire directement les fichiers de table Iceberg, il contourne normalement vos règles, car Cloud Storage ne comprend que les autorisations au niveau du bucket.

Pour éviter cela, utilisez la délégation de calcul. En utilisant le connecteur Spark-BigQuery, vous créez un pont sécurisé qui achemine toutes les requêtes Spark via l'API BigQuery Storage. Cela garantit que Knowledge Catalog vérifie les autorisations et applique les règles de masquage avant que les données n'atteignent le cluster Spark.

Importez le script read_transactions.py dans votre bucket Cloud Storage afin que Managed Service pour Apache Spark puisse y accéder :

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

Examinez la logique de base dans le script que vous avez importé :

# Reading data via Compute Delegation (Knowledge Catalog 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)

Le script ne pointe 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 qui exécute le job Spark, applique les règles de masquage de Knowledge Catalog et ne renvoie que les données autorisées au DataFrame Spark.

Exécuter Spark en tant que responsable

Envoyez un job Spark en tant que profil Manager. Utilisez Managed Service pour Apache Spark, un service géré qui vous permet d'exécuter des charges de travail Spark sans avoir à gérer vos propres clusters :

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 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écuter Spark en tant qu'analyste

Enfin, exécutez le même code Spark en tant que profil Analyst :

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)"

Examinez à nouveau les journaux. Même si l'analyste a exécuté le même code Spark, l'API BigQuery Storage a intercepté la requête et appliqué la règle Knowledge Catalog. 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         |
+---+--------+------+-------------------+

Vous venez de prouver que, en tant que plan de contrôle central, Knowledge Catalog applique vos règles de sécurité de manière cohérente, quel que soit le moteur de requête que vous utilisez.

Suivre le parcours de vos données grâce à la traçabilité automatisée

Un lakehouse conforme aux règles nécessite plus que des contrôles d'accès. Il nécessite également une piste d'audit claire. La traçabilité des données vous aide à comprendre d'où viennent vos données et comment elles sont transformées. Répondre à des questions essentielles telles que "Quelles tables brutes ont été utilisées pour générer ce rapport sur les ventes ?" vous aide à maintenir la conformité, à déboguer rapidement les pipelines de données et à créer une base de données fiable.

Au lieu d'écrire manuellement du code de journalisation complexe, Knowledge Catalog suit automatiquement ce cycle de vie dans votre architecture. Par exemple, lorsque vous avez créé une table récapitulative plus tôt dans ce tutoriel, BigQuery a capturé instantanément les détails de la transformation et les a envoyés à Knowledge Catalog. Cela a mis à jour dynamiquement le contexte et l'historique de vos données.

Explorer le graphique de traçabilité interactif

Consultez la carte interactive générée par Knowledge Catalog. Elle montre comment les données brutes circulent de la table transactions vers la table transactions_summary. Étant donné que Knowledge Catalog collecte les métadonnées en tant que moteur contextuel dynamique, ce graphique affiche la traçabilité fiable et en temps réel dont vous avez besoin pour un audit des données.

  1. Dans la Google Cloud console, accédez à Knowledge Catalog > Rechercher.
  2. Saisissez lakehouse_retail_demo.transactions_summary dans la barre de recherche, puis cliquez sur la table.
  3. Cliquez sur l'onglet Traçabilité.
Graphique de traçabilité des données montrant le flux de la table "transactions" vers la table "transactions_summary".
Graphique de traçabilité des données

Le graphique interactif confirme que la table cible (transactions_summary) est dérivée de la table Iceberg brute gérée (transactions). Cette visualisation illustre la traçabilité de bout en bout de vos données.

Libérer de l'espace

Pour éviter des frais continus, supprimez les ressources que vous avez créées pour ce tutoriel.

Supprimer les éléments de règle et de métadonnées

Avant de pouvoir supprimer l'ensemble de données BigQuery ou le bucket Cloud Storage, vous devez supprimer les règles de gouvernance des données et les éléments de métadonnées.

Exécutez le script de nettoyage Python :

python cleanup_governance.py

Examinez le script cleanup_governance.py du dépôt pour trouver la logique de suppression suivante. L'ordre de suppression est essentiel. Tout d'abord, vous supprimez la règle de masquage des données. Ensuite, vous supprimez la taxonomie parente, ce qui supprime automatiquement tous les tags avec stratégie sous-jacents et évite les erreurs de dépendance des ressources.

# 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)

Supprimer les éléments d'identité, de stockage et de calcul

Supprimez les tables BigQuery, les buckets Cloud Storage, les comptes de service et l'environnement virtuel Python local.

Copiez et exécutez le script de nettoyage suivant dans votre 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 "✅ Clean up completed successfully!"

Nettoyez les fichiers du projet :

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

Conclusion

Vous avez créé un lakehouse de données sécurisé. En utilisant Lakehouse pour gérer les tables Iceberg, vous avez sécurisé les fichiers de table sous-jacents dans Cloud Storage. En établissant Knowledge Catalog comme moteur contextuel universel, vous avez défini des tags avec stratégie dans un emplacement central et les avez appliqués de manière cohérente sur différents moteurs de requête tels que BigQuery SQL et Apache Spark. Enfin, vous avez suivi automatiquement l'ensemble du parcours de vos données grâce à la traçabilité des données en temps réel.

Étape suivante