Abilitare l'accesso al lakehouse conforme alle norme con Knowledge Catalog

Quando memorizzi i dati in diversi sistemi di archiviazione, la gestione della sicurezza frammentata può diventare una sfida importante. Vuoi assicurarti che le informazioni sensibili, come i documenti finanziari, rimangano protette, anche se le memorizzi in formati aperti come Apache Iceberg su Google Cloud storage.

Fondamentalmente, le misure di sicurezza devono funzionare perfettamente su vari motori di query, come BigQuery SQL e Apache Spark. In questa architettura, Knowledge Catalog risolve il problema fungendo da motore di contesto universale. Contiene i metadati necessari per garantire che il contesto di sicurezza venga applicato in modo coerente, indipendentemente dal motore che esegue query sui dati.

In questo tutorial, creerai un data lakehouse sicuro per risolvere queste sfide. Utilizzando gli script, definisci le norme di sicurezza e vedi Knowledge Catalog (in precedenza Dataplex Universal Catalog) e Lakehouse for Apache Iceberg collaborare per applicare le norme su diversi motori di query.

Panoramica dell'architettura

Per configurare controllo dell'accesso granulare su un formato di tabella aperto come Apache Iceberg, devi creare un'architettura di sicurezza rigorosa e unificata.

Con questa progettazione, Knowledge Catalog funge da control plane centrale. Knowledge Catalog applica dinamicamente il contesto di sicurezza in tutti i motori supportati.

Architettura di un lakehouse conforme alle policy che utilizza livelli architetturali sicuri e l'applicazione centralizzata delle policy.
Architettura di un lakehouse conforme alle norme

Questo tutorial si basa su due concetti principali per creare questa architettura unificata:

  • Livelli architetturali sicuri: anziché consentire agli utenti o ai motori di query di accedere direttamente ai bucket Cloud Storage, crei una base sicura e a più livelli in base ai seguenti attributi:
    • Formato aperto con metadati gestiti:i tuoi dati rimangono nel formato Apache Iceberg (Parquet) aperto all'interno di Cloud Storage, mentre Lakehouse for Apache Iceberg gestisce i metadati della tabella.
    • Confine di sicurezza logico:separi le autorizzazioni di archiviazione dalle query sui dati utilizzando una connessione alle risorse Cloud sicura. Non concedi mai agli utenti finali l'accesso diretto ai file.
    • Delega di calcolo:per impedire ai motori di query di ignorare le regole, indirizza tutte le richieste di dati tramite l'API BigQuery Storage. Il routing delle richieste tramite l'API BigQuery Storage garantisce che Knowledge Catalog possa intercettare e applicare le policy anche per i motori di elaborazione esterni.
  • Applicazione centralizzata delle norme:con una base sicura, utilizzi Knowledge Catalog per applicare universalmente le regole:
    • Definisci una volta, applica ovunque: definisci i tag di policy in Knowledge Catalog una sola volta e la piattaforma applica regole di mascheramento coerenti a tutti i motori di query supportati.
    • Mascheramento dinamico dei dati:il sistema valuta l'identità dell'utente durante le query. Gli utenti autorizzati vedono i valori non elaborati, mentre gli utenti con accesso limitato ricevono output NULL in tutti i motori di query.
    • Tracciabilità dei dati automatizzata:Knowledge Catalog monitora automaticamente le trasformazioni dei dati, creando un audit trail senza codice di logging personalizzato.

Obiettivi

Prima di iniziare

Prima di iniziare, segui questi passaggi:

prepara l'ambiente

Questo tutorial utilizza Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

  1. Nella Google Cloud console, fai clic sull'icona Cloud Shell nella barra degli strumenti in alto a destra.

  2. Imposta le variabili del progetto:

    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. Definisci le variabili per due buyer persona, un analista della vendita al dettaglio e un responsabile della vendita al dettaglio:

    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. Abilita le API Google Cloud richieste.

    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

Scaricare il codice sorgente del tutorial

Scarica gli script Python per questo tutorial dal repository 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

Crea un bucket di archiviazione

Crea un nuovo bucket per contenere i file della tabella Iceberg:

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

Preparare identità e sicurezza

In questo passaggio, configurerai la delega di calcolo creando una connessione alle risorse Cloud. Questa connessione funge da identità delegata sicura che BigQuery utilizza per gestire e leggere i file Iceberg. In questo modo, gli utenti singoli non hanno mai accesso diretto al tuo bucket Cloud Storage.

Esegui i seguenti comandi per creare la connessione, recuperare il account di servizio generato automaticamente e concedere a questo account le autorizzazioni necessarie per gestire i dati 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

Crea service account per due profili: Analista e Manager. I seguenti comandi configurano questi service account, consentono all'utente attuale di rappresentarli per i test e concedono loro ruoli specifici per eseguire query e visualizzare i dati.

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

Crea tabelle Apache Iceberg

Utilizza il motore SQL di BigQuery per creare tabelle Apache Iceberg. Sebbene esegui i comandi di creazione con BigQuery, Lakehouse funge da livello di gestione che archivia i metadati della tabella e protegge i file Parquet sottostanti in Cloud Storage.

Dopo aver creato le tabelle, esegui una rapida trasformazione per vedere come Knowledge Catalog gestisce la sicurezza e monitora automaticamente il percorso dei dati.

Crea un set di dati BigQuery

Innanzitutto, crea un set di dati BigQuery per raggruppare le tabelle:

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

Crea le tabelle Iceberg

Esegui i seguenti comandi per creare tabelle di inventario e transazioni:

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

Inserisci dati di esempio

Inserisci dati di esempio nelle tabelle:

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

Ora hai due tabelle Iceberg con dati di esempio non elaborati. Lakehouse gestisce i metadati, ma i file Parquet effettivi si trovano nel bucket Cloud Storage.

Trasformare i dati per la tracciabilità automatizzata

Aggrega le transazioni non elaborate in un riepilogo giornaliero delle vendite. Questa trasformazione crea una nuova tabella e genera i metadati che Knowledge Catalog utilizza per mappare automaticamente il percorso dei dati.

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

Definisci policy di governance dell'accesso

In un ambiente di produzione, scrivere le regole di sicurezza come codice (infrastruttura come codice) rende le tue norme ripetibili, controllate a livello di versione e più facili da gestire. In questa sezione utilizzerai l' Google Cloud SDK Python per definire e applicare automaticamente le regole.

Prepara l'ambiente virtuale Python

Configura un ambiente virtuale Python isolato per gestire le dipendenze e assicurarti che gli script vengano eseguiti in modo affidabile:

# 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!"

Definisci tassonomie e tag di sicurezza

Inizia creando le basi per le tue regole di sicurezza. In questo passaggio, crei una tassonomia che funge da contenitore e un tag di policy che funge da etichetta di sicurezza specifica per i dati sensibili.

Esegui lo script per creare le risorse:

python 1_create_taxonomy.py

Esamina 1_create_taxonomy.py per vedere la logica principale:

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

Se imposti in modo esplicito il tipo di criterio FINE_GRAINED_ACCESS_CONTROL, trasformi un tag di metadati standard in un limite di sicurezza di tipo deny-by-default. Qualsiasi colonna con questo tag nega l'accesso a tutti gli utenti per impostazione predefinita.

Creare una policy di mascheramento dinamico dei dati

Ora definisci cosa succede quando qualcuno senza privilegi esegue una query su una colonna taggata. Crea un criterio di mascheramento dei dati che sostituisce automaticamente i valori sensibili con NULL per la persona Analista.

Esegui lo script per configurare la regola di mascheramento:

python 2_create_masking.py

All'interno di 2_create_masking.py, lo script cerca l'ID del tag di criteri che hai creato e applica la norma sui dati all'account di servizio 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}"]
)

Concedere l'accesso con privilegi ai tuoi dati

A causa della configurazione di negazione predefinita, nessuno può leggere la colonna taggata. Devi concedere esplicitamente l'accesso agli utenti autorizzati. Concedi il ruolo Lettore granulare alla persona Manager e al tuo account. In questo modo, questi utenti specifici possono ignorare le regole di mascheramento e leggere i dati non mascherati.

Esegui lo script per concedere l'accesso:

python 3_grant_access.py

All'interno di 3_grant_access.py, lo script modifica il criterio IAM del tag di criteri:

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

Collega i tag di sicurezza allo schema della tabella

Infine, puoi collegare le regole logiche ai dati effettivi. Aggiorna lo schema della tabella Iceberg per collegare il tag di criteri direttamente alla colonna amount. Dopo averlo fatto, Lakehouse applica immediatamente le protezioni ai file della tabella Iceberg nel bucket.

Esegui lo script per collegare il tag di criteri:

python 4_attach_tag.py

Rivedi 4_attach_tag.py. Lo script recupera lo schema della tabella BigQuery, scorre i campi e associa il tag in modo specifico alla colonna 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"])

Verificare le policy di sicurezza

Esegui alcune query di test per assicurarti che le autorizzazioni funzionino come previsto. Per dimostrare che Knowledge Catalog funge da motore di contesto universale applicando le stesse norme di sicurezza quando cambi motore di query, esegui questi test utilizzando sia BigQuery che Apache Spark.

Testare con BigQuery SQL

Inizia controllando i criteri direttamente in BigQuery. È il modo più rapido per verificare che le regole di mascheramento e le autorizzazioni siano attive.

Controlla come gestore

La persona Manager dispone di un accesso in lettura privilegiato e granulare. Devono visualizzare ogni dettaglio della tabella, inclusi i valori della colonna 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\`"

Poiché il gestore ha il ruolo Lettore granulare, la query mostra i valori degli importi non elaborati:

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

Controlla come analista

Passa al profilo Analista ed esegui la stessa query.

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Anche se esegui la stessa query, Knowledge Catalog maschera i valori sensibili nella colonna 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 |
+----+----------+--------+------------------+

Tornare al tuo account

Pulisci lo stato di autenticazione di Cloud Shell per tornare all'utente amministratore.

gcloud config unset auth/impersonate_service_account

Testare con Apache Spark

La sicurezza viene spesso compromessa quando gli utenti accedono direttamente ai file di dati in Cloud Storage. Se un data scientist utilizza Apache Spark per leggere direttamente i file della tabella Iceberg, in genere ignora le tue regole perché Cloud Storage comprende solo le autorizzazioni a livello di bucket.

Per evitare questo problema, utilizza la delega di Compute. Utilizzando il connettore Spark-BigQuery, crei un ponte sicuro che indirizza tutte le richieste Spark tramite l'API BigQuery Storage. In questo modo, Knowledge Catalog controlla le autorizzazioni e applica le regole di mascheramento prima che i dati raggiungano il cluster Spark.

Carica lo script read_transactions.py nel bucket Cloud Storage in modo che Managed Service for Apache Spark possa accedervi:

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

Esamina la logica di base nello script che hai caricato:

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

Lo script non punta Spark al percorso gs:// dei file Iceberg. Se specifichi .format("bigquery"), l'API BigQuery Storage intercetta la richiesta di lettura, controlla l'identità dell'utente che esegue il job Spark, applica le regole di mascheramento di Knowledge Catalog e restituisce solo i dati autorizzati a Spark DataFrame.

Esegui Spark come gestore

Invia un job Spark come persona Manager. Utilizza Managed Service for Apache Spark, un servizio gestito che ti consente di eseguire workload Spark senza la seccatura di gestire i tuoi cluster:

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

Esamina i log di output del job nel terminale. Poiché il gestore ha il ruolo Lettore granulare, Spark recupera correttamente gli importi non mascherati:

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

Eseguire Spark come analista

Infine, esegui lo stesso codice Spark della persona Analista:

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

Rivedi i log. Anche se l'analista ha eseguito lo stesso codice Spark, l'API BigQuery Storage ha intercettato la richiesta e applicato il criterio Knowledge Catalog. Il DataFrame Spark dell'analista mostra null per gli importi.

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

Hai appena dimostrato che, in qualità di piano di controllo centrale, Knowledge Catalog applica in modo coerente le tue norme di sicurezza indipendentemente dal motore di query che utilizzi.

Visualizzare il percorso dei dati con la derivazione automatica

Un lakehouse conforme alle norme richiede più di semplici controlli dell'accesso, ma anche un audit trail chiaro. La derivazione dei dati ti aiuta a capire da dove provengono i dati e come vengono trasformati. Rispondere a domande essenziali come "Quali tabelle non elaborate sono state utilizzate per produrre questo report sulle vendite?" ti aiuta a mantenere la conformità, eseguire il debug delle pipeline di dati rapidamente e creare una base di dati affidabile.

Invece di scrivere manualmente un codice di logging complesso, Knowledge Catalog monitora automaticamente questo ciclo di vita nell'architettura. Ad esempio, quando hai creato una tabella riepilogativa in precedenza in questo tutorial, BigQuery ha acquisito immediatamente i dettagli della trasformazione e li ha inviati a Knowledge Catalog. In questo modo, il contesto e la cronologia dei dati vengono aggiornati dinamicamente.

Esplorare il grafico della derivazione interattivo

Dai un'occhiata alla mappa interattiva generata da Knowledge Catalog. Mostra il flusso dei dati non elaborati dalla tabella transactions alla tabella transactions_summary. Poiché Knowledge Catalog raccoglie i metadati come motore di contesto dinamico, questo grafico mostra la tracciabilità affidabile e in tempo reale necessaria per un audit dei dati.

  1. Nella console Google Cloud , vai a Knowledge Catalog > Search.
  2. Digita lakehouse_retail_demo.transactions_summary nella barra di ricerca e fai clic sulla tabella.
  3. Fai clic sulla scheda Lignaggio.
Grafico della derivazione dei dati che mostra il flusso dalla tabella delle transazioni alla tabella transactions_summary.
Grafico della derivazione dei dati

Il grafico interattivo conferma che la tabella di destinazione (transactions_summary) deriva dalla tabella Iceberg non elaborata e controllata (transactions). Questa visualizzazione mostra la tracciabilità end-to-end dei tuoi dati.

Esegui la pulizia

Per evitare addebiti continui, rimuovi le risorse che hai creato per questo tutorial.

Rimuovere gli asset di norme e metadati

Prima di poter eliminare il set di dati BigQuery o il bucket Cloud Storage, devi eliminare le norme di governance dei dati e gli asset di metadati.

Esegui lo script di pulizia Python:

python cleanup_governance.py

Esamina lo script cleanup_governance.py del repository per trovare la seguente logica di smontaggio. L'ordine di eliminazione è fondamentale. Innanzitutto, elimina la policy di mascheramento dei dati. Poi, elimini la tassonomia principale, che rimuove automaticamente tutti i tag criterio sottostanti ed evita errori di dipendenza delle risorse.

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

Rimuovere identità, spazio di archiviazione e asset di calcolo

Elimina le tabelle BigQuery, i bucket Cloud Storage, i service account e l'ambiente virtuale Python locale.

Copia ed esegui il seguente script di pulizia in 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!"

Libera spazio nei file di progetto:

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

Conclusione

Hai creato una data lakehouse sicura. Utilizzando Lakehouse for Apache Iceberg per gestire le tabelle Iceberg, hai mantenuto protetti i file delle tabelle sottostanti in Cloud Storage. Se hai impostato Knowledge Catalog come motore di contesto universale, hai definito i tag di policy in una posizione centrale e li hai applicati in modo coerente a diversi motori di query come BigQuery SQL e Apache Spark. Infine, hai monitorato automaticamente l'intero percorso dei tuoi dati con la tracciabilità dei dati in tempo reale.

Passaggi successivi