Creazione di un lakehouse Iceberg controllato con BigLake e Dataplex

1. Introduzione

In un moderno Data Cloud aziendale, in cui i dati risiedono in vari sistemi di archiviazione fisica, esiste un'enorme sfida architettonica di sicurezza frammentata.

Come fai a garantire che i dati sensibili (come gli importi delle transazioni finanziarie) siano protetti in modo coerente quando vengono archiviati fisicamente in formati open source come Parquet nell'archiviazione Google Cloud e sottoposti a query da più motori diversi, come BigQuery SQL o Apache Spark?

In questo codelab creerai un'architettura Governed Data Lakehouse che risolve questi problemi utilizzando tabelle Apache Iceberg, BigQuery e Dataplex Universal Catalog. Utilizzerai Infrastructure as Code (IaC) per definire le norme di sicurezza zero-trust e il modo in cui vengono applicate dinamicamente in diversi motori di calcolo.

Prerequisiti

Un progetto Google Cloud con la fatturazione abilitata.
Comprensione di base dei concetti di SQL, IAM e Cloud Storage.

Cosa imparerai a fare

Come creare tabelle BigLake per Apache Iceberg in BigQuery in cui Cloud Storage contiene i dati in modo nativo.
Come applicare policy di dati centralizzate utilizzando i tag di policy per la sicurezza a livello di colonna e il mascheramento dei dati.
Come separare l'accesso all'archiviazione fisica dall'accesso ai dati logici utilizzando la connessione alle risorse cloud.
Come applicare la delega di calcolo Zero-Trust utilizzando Google Cloud Serverless per Apache Spark per garantire che i motori open source non possano aggirare la governance.
Come visualizzare la provenienza dei dati automatica.

Panoramica dell'architettura: governance universale su Iceberg

Per ottenere un controllo dell'accesso granulare (come la sicurezza a livello di colonna e il mascheramento dei dati) nei formati di dati open source, devi stabilire un'architettura di sicurezza rigorosa e unificata.

Come illustrato nel diagramma, questo pattern di lakehouse controllato si basa su due pilastri principali per risolvere la verifica di sicurezza frammentata:

🛡️ Livelli architetturali sicuri (a sinistra)

Anziché consentire agli utenti o ai motori esterni di accedere direttamente a Cloud Storage, che supporta solo la sicurezza generica a livello di bucket, crei una base sicura.

Formato aperto, metadati gestiti:i dati rimangono fisicamente in Cloud Storage utilizzando il formato Apache Iceberg (Parquet) aperto, mentre BigLake gestisce senza problemi i metadati di governance.
Confine di sicurezza logica:separi l'accesso allo spazio di archiviazione fisico dall'accesso ai dati utilizzando una connessione alle risorse Cloud sicura. Agli utenti finali non viene mai concesso l'accesso fisico diretto IAM ai file GCS non elaborati.
Delega di calcolo zero-trust:per garantire che nessun motore di esecuzione possa ignorare le regole di governance, tutte le richieste di lettura dei dati vengono indirizzate rigorosamente tramite l'API BigQuery Storage. Ciò vale indipendentemente dal fatto che la query provenga da BigQuery SQL nativo o da Apache Spark open source.

🎯 Applicazione centralizzata delle norme (a destra)

Con la base sicura in atto, Dataplex funge da cervello unificato per la governance:

Definisci una volta, applica ovunque:definisci i tag di policy in Dataplex una sola volta e l'architettura applica regole di mascheramento coerenti in modo universale in tutti i runtime di esecuzione supportati.
Mascheramento dinamico dei dati:quando viene eseguita una query sui dati, il sistema valuta l'identità dell'utente al volo. Mentre gli utenti autorizzati vedranno i valori non elaborati e non mascherati (ad es. 100,0) sia in SQL che in Spark, gli utenti con limitazioni riceveranno automaticamente valori NULL mascherati per le colonne con limitazioni in entrambi i motori.
Derivazione automatica dei dati:man mano che i dati vengono trasferiti e trasformati, Dataplex acquisisce automaticamente i metadati di trasformazione, fornendo auditabilità e tracciabilità end-to-end integrate senza richiedere codice di logging personalizzato.

2. Configurazione e requisiti

Avvia Cloud Shell

Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

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

Attiva Cloud Shell

Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:

Screenshot del terminale Google Cloud Shell che mostra che l'ambiente è connesso

Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro in questo codelab può essere svolto all'interno di un browser. Non devi installare nulla.

Inizializza l'ambiente

Apri Cloud Shell e imposta le variabili del progetto per assicurarti che tutti i comandi abbiano come target l'infrastruttura corretta.

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"

Poi definiamo le nostre due buyer persona.

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)

Abilita le API

Attiva i servizi Google Cloud necessari.

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

Scarica il codice sorgente del codelab

Per evitare di sovraccaricare Cloud Shell, esegui un controllo sparso per scaricare solo gli script Python necessari per questo codelab 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 spazio di archiviazione

Crea il bucket per contenere i dati Iceberg governati e altamente sicuri.

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

Preparare identità e sicurezza

Configura la connessione alla risorsa cloud. Questa è l'unica entità che contiene le chiavi IAM fisiche permanenti per leggere i file Iceberg non elaborati.

# 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

Successivamente, configura le buyer persona. Agli utenti viene concesso l'accesso logico, non l'accesso allo spazio di archiviazione fisico. Per evitare errori causati da ritardi di propagazione di IAM, crea prima gli account, attendi qualche secondo e poi assegna i ruoli.

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. Crea tabelle Iceberg native tramite BigLake

Utilizzerai le funzionalità native di BigLake per creare le tabelle Iceberg gestite.

Crea il set di dati BigQuery

Innanzitutto, crea un set di dati BigQuery per raggruppare logicamente le tabelle Iceberg.

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

Crea le tabelle Iceberg

Successivamente, esegui i seguenti comandi per creare le tabelle. Nota il blocco OPTIONS in cui specifichiamo table_format = 'ICEBERG' e lo mappiamo direttamente al nostro bucket Cloud Storage e alla nostra connessione.

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

Compilare le tabelle con i dati

Infine, inserisci i dati di esempio nelle tabelle Iceberg appena create.

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 completamente funzionanti. BigLake gestisce i metadati, ma i file Parquet fisici risiedono in modo sicuro nel tuo bucket GCS.

Simulare una pipeline ETL

In uno scenario reale, i dati non elaborati vengono spesso aggregati in tabelle riepilogative per i report aziendali. Agiamo come data engineer e creiamo una tabella di riepilogo delle vendite giornaliere a partire dai dati delle transazioni non elaborati.

(Nota: esegui questo passaggio ora in modo che Google Cloud abbia abbastanza tempo per elaborare i metadati di sfondo. Scoprirai perché è importante più avanti nel codelab.)

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. Governance centralizzata: definisci i criteri utilizzando Python

In un ambiente di produzione, la configurazione dei criteri di governance tramite la UI è difficile da scalare e gestire. Ti consigliamo vivamente di utilizzare Infrastructure as Code (IaC).

In questa sezione utilizzerai l'SDK Google Cloud Python per creare e applicare in modo programmatico le regole di governance Zero Trust passo dopo passo.

Configura l'ambiente Python

Innanzitutto, configuriamo un ambiente Python isolato (venv) per evitare conflitti tra librerie e installiamo gli SDK Google Cloud richiesti.

Esegui questi comandi in 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!"

Creare il tag tassonomia e policy

Una tassonomia è un contenitore logico, mentre un tag di policy è l'etichetta specifica che verrà associata alla colonna sensibile. Per applicare la sicurezza a livello di colonna, devi prima disporre di un contenitore logico (una tassonomia) e di un'etichetta specifica (un tag criterio).

Se guardi all'interno di 1_create_taxonomy.py, vedrai la seguente logica di 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)

Se imposti in modo esplicito il tipo di criterio FINE_GRAINED_ACCESS_CONTROL, trasformi un tag di metadati standard in un limite di sicurezza Zero Trust rigoroso. Per impostazione predefinita, qualsiasi colonna con questo tag negherà l'accesso a tutti gli utenti.

Esegui lo script per creare le risorse:

python 1_create_taxonomy.py

Configurare la regola di mascheramento (norme sui dati)

Ora definisci cosa succede quando qualcuno senza privilegi esegue una query sulla colonna taggata. Creerai una norma sui dati che impone la restituzione del valore come NULL e collegherai questa regola alla persona dell'analista.

All'interno di 2_create_masking.py, lo script cerca dinamicamente l'ID tag di policy che hai appena creato e applica una norma relativa ai dati:

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

Questo codice crea in modo programmatico una regola che forza la restituzione dei valori sottostanti come NULL. Quindi, assegna il ruolo IAM maskedReader in modo specifico alla persona dell'analista, assicurandosi che veda solo la versione mascherata dei dati.

Esegui lo script per configurare la regola di mascheramento:

python 2_create_masking.py

Concedi l'accesso granulare

A causa della nostra configurazione zero-trust, al momento nessuno può leggere la colonna taggata. Devi concedere esplicitamente l'accesso all'account amministratore e al tuo account personale.

All'interno di 3_grant_access.py, modifichi la policy IAM del tag di policy stesso:

# 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'aggiunta del ruolo categoryFineGrainedReader consente a queste entità specifiche di ignorare le regole di mascheramento e leggere i dati non elaborati e non mascherati.

Esegui lo script per concedere l'accesso:

python 3_grant_access.py

Allegare il tag di policy alla tabella BigQuery

Infine, devi collegare questo tag delle norme logico al nostro schema della tabella Iceberg fisico.

Dai un'occhiata a 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"])

Quando viene applicato questo aggiornamento dello schema, BigLake collega immediatamente i tag logici Dataplex ai file Parquet fisici archiviati nel bucket Cloud Storage.

Esegui lo script per aggiornare lo schema della tabella:

python 4_attach_tag.py

5. Verifica le policy Dataplex

È il momento di verificare se la nostra governance centralizzata funziona. Eseguirai il test su due motori diversi per dimostrare che le policy Dataplex vengono applicate universalmente.

Verifica utilizzando SQL nativo di BigQuery

Innanzitutto, utilizzerai Cloud Shell per assumere l'identità delle nostre due buyer persona ed eseguire query sulla tabella utilizzando il motore SQL nativo di BigQuery.

Test come Manager (utente con privilegi):

# 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, vengono visualizzati 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 |
+----+----------+--------+------------------+

Test come analista (utente con accesso limitato):

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

A causa della regola di mascheramento Dataplex, la colonna dell'importo viene restituita come NULL per ogni riga.

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

Ripristinare la tua identità

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

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Verifica tramite Apache Spark (delega del calcolo)

Cosa succede se un data scientist utilizza Apache Spark per leggere questa tabella? Se Spark legge direttamente i file Parquet GCS fisici, le regole di mascheramento Dataplex vengono completamente ignorate perché Cloud Storage comprende solo le autorizzazioni a livello di bucket.

Per evitare questo problema, applica la delega del calcolo utilizzando il connettore Spark-BigQuery. Questo connettore funge da ponte sicuro, instradando le richieste di lettura Spark tramite l'API BigQuery Storage in modo che le regole di governance di Dataplex vengano valutate dinamicamente prima che i dati vengano inviati al cluster Spark.

Dai un'occhiata alla logica di base all'interno dello script read_transactions.py che hai scaricato:

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

Tieni presente che non stiamo indirizzando 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 Dataplex e restituisce solo i dati autorizzati al DataFrame Spark.

Carica questo script PySpark nel tuo bucket Cloud Storage in modo che Dataproc possa accedervi:

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

Esegui Spark come manager:

Utilizzerai Google Cloud Serverless per Apache Spark. Questo servizio gestito ti consente di eseguire i workload Spark direttamente senza dover eseguire il provisioning, la configurazione o la gestione di cluster dedicati.

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

Esegui Spark come analista:

Ora invia lo stesso job Spark, ma questa volta impersona la persona dell'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)"

Controlla di nuovo i log. Anche se l'analista ha eseguito esattamente lo stesso codice Spark, l'API BigQuery Storage ha intercettato la richiesta e applicato il criterio Dataplex. 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         |
+---+--------+------+-------------------+

Compromessi architetturali: BigQuery SQL e Spark

Hai appena dimostrato che il risultato è identico indipendentemente dal motore. Il criterio Dataplex è stato applicato correttamente. Ma in produzione, quale dovresti utilizzare?

BigQuery SQL: ideale per i workflow in cui SQL è il motore desiderato ed esegue i calcoli direttamente sul posto. È ideale per analisi rapide e business intelligence.
Apache Spark: consente workload più complessi grazie all'utilizzo di Python, il che lo rende ideale per pipeline di machine learning avanzate o codice Hadoop legacy.

Il punto chiave:indipendentemente dal motore utilizzato, applicando la delega di calcolo, il livello di governance zero-trust centralizzato non può mai essere bypassato.

6. Derivazione dei dati automatica

In qualsiasi architettura dei dati aziendali, sapere esattamente da dove provengono i dati e come sono stati modificati è fondamentale per la conformità, il debug e la creazione di fiducia. Questo concetto è noto come data lineage. Risponde a domande fondamentali come: "Se un responsabile sta esaminando un report sulle vendite giornaliere, quali tabelle non elaborate sono state utilizzate per calcolare questi numeri?"

Tradizionalmente, il monitoraggio di questo ciclo di vita richiede agli ingegneri dei dati di scrivere manualmente codice di logging personalizzato o di utilizzare strumenti complessi di terze parti per analizzare gli script SQL. Tuttavia, in un data lakehouse Google Cloud gestito, questo monitoraggio è integrato e completamente automatico.

Ricordi la tabella transactions_summary che hai creato dalla tabella delle transazioni non elaborate in precedenza nel codelab? Quando BigQuery ha eseguito l'istruzione CREATE TABLE AS SELECT, il motore di calcolo ha acquisito automaticamente i metadati di trasformazione e li ha inviati a Dataplex. Vediamo il risultato.

Visualizzare la derivazione

Nella console Google Cloud, vai a Dataplex Universal Catalog > Cerca.
Digita lakehouse_retail_demo.transactions nella barra di ricerca e fai clic sulla tabella.
Fai clic sulla scheda Lignaggio.

Vedrai un grafico interattivo generato da Dataplex Knowledge Engine che dimostra che la tabella di destinazione (transactions_summary) è stata derivata dalla tabella Iceberg non elaborata e controllata (transactions). Hai ottenuto la tracciabilità end-to-end essenziale per l'audit dei dati.

7. Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo codelab, segui questi passaggi.

Rimuovere le risorse di governance di Dataplex

Prima di eliminare il set di dati BigQuery o il bucket Cloud Storage, devi rimuovere le regole di governance logica. Se esamini lo script cleanup_governance.py del repository, vedrai la seguente sequenza di smontaggio:

# 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'ordine è fondamentale. Lo script elimina prima la policy dei dati (regola di mascheramento) perché si basa sul tag di policy. Una volta rimossa la norma, l'eliminazione della tassonomia principale verrà eseguita automaticamente e verranno eliminati tutti i tag criterio sottostanti senza attivare errori di dipendenza delle risorse.

Esegui lo script di pulizia Python:

python cleanup_governance.py

Rimuovere identità, spazio di archiviazione e asset di calcolo

Ora che il livello di governance è separato, puoi eliminare in sicurezza le tabelle BigQuery, i bucket Cloud Storage, i service account e l'ambiente Python locale.

Copia ed esegui il seguente blocco di pulizia completo 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 "Deactivating and removing the local Python environment..."
deactivate
cd ../..
rm -rf devrel-demos

echo "✅ Clean up completed successfully!"

Completando questi passaggi, ti sei assicurato che nel progetto non rimangano risorse orfane o criteri nascosti.

8. Complimenti!

Hai implementato correttamente un data lakehouse completamente governato e rilevabile.

Hai imparato che:

Integrazione nativa di Iceberg:BigLake può gestire in modo nativo le tabelle Iceberg open source memorizzando i file fisici in modo sicuro in Cloud Storage.
Delega del calcolo per la sicurezza:eseguendo il routing delle query tramite l'API BigQuery Storage, hai applicato una maschera dinamica granulare ai file fisici che non possono limitare l'accesso parziale in modo nativo.
Governance indipendente dal motore:i tag delle norme ti consentono di definire le regole una sola volta e di applicarle universalmente, indipendentemente dal fatto che vengano eseguite query tramite runtime SQL nativi o Apache Spark.
Rilevabilità dei dati:il motore di conoscenza di Dataplex ha monitorato automaticamente la derivazione dei dati, fornendo un'auditabilità aziendale essenziale.

Passaggi successivi

Esplora il controllo dell'accesso avanzato:per implementare scenari di sicurezza più complessi, consulta la documentazione ufficiale sulla personalizzazione di BigLake con funzionalità aggiuntive.
Governa i dati non strutturati per l'AI generativa:scopri le tabelle degli oggetti BigLake. Estendi questo modello di bridge sicuro esatto a file non strutturati (PDF, immagini) in Cloud Storage, stabilendo una base di dati sicura e controllata per Vertex AI e le pipeline RAG.