Habilita el acceso al lakehouse que cumple con las políticas con Knowledge Catalog

Cuando almacenas tus datos en diferentes sistemas de almacenamiento, administrar la seguridad fragmentada puede convertirse en un desafío importante. Debes asegurarte de que la información sensible, como los registros financieros, permanezca protegida, incluso si la almacenas en formatos abiertos como Apache Iceberg en el Google Cloud almacenamiento.

Es fundamental que tus medidas de seguridad funcionen sin problemas en varios motores de consultas, como BigQuery SQL y Apache Spark. En esta arquitectura, Knowledge Catalog resuelve este problema funcionando como un motor de contexto universal. Contiene los metadatos necesarios para garantizar que tu contexto de seguridad se aplique de manera coherente, sin importar qué motor consulte los datos.

En este instructivo, crearás un data lakehouse seguro para resolver estos desafíos. Con las secuencias de comandos, definirás las políticas de seguridad y verás cómo Knowledge Catalog (antes Dataplex Universal Catalog) y Lakehouse sin bordes trabajan juntos para aplicar las políticas en diferentes motores de consultas.

Descripción general de la arquitectura

Para configurar el control de acceso detallado en un formato de tabla abierto como Apache Iceberg, debes crear una arquitectura de seguridad unificada y estricta.

Con este diseño, Knowledge Catalog actúa como el plano de control central. Knowledge Catalog aplica de forma dinámica tu contexto de seguridad en todos los motores compatibles.

Arquitectura de un lakehouse que cumple con las políticas y que usa capas arquitectónicas seguras y aplicación de políticas centralizada.
Arquitectura de un lakehouse que cumple con las políticas

En este instructivo, se usan dos conceptos principales para crear esta arquitectura unificada:

  • Capas arquitectónicas seguras: En lugar de permitir que los usuarios o los motores de consultas accedan directamente a tus buckets de Cloud Storage, compilas una base segura y en capas basada en los siguientes atributos:
    • Formato abierto con metadatos administrados: Tus datos permanecen en su formato abierto de Apache Iceberg (Parquet) dentro de Cloud Storage, mientras que Lakehouse administra los metadatos de la tabla.
    • Límite de seguridad lógica: Desvinculas los permisos de almacenamiento de las consultas de datos mediante una conexión a recursos de Cloud segura. Nunca otorgas a los usuarios finales acceso directo a los archivos.
    • Delegación de procesamiento: Para evitar que los motores de consultas omitan tus reglas, enrutas todas las solicitudes de datos a través de la API de BigQuery Storage. El enrutamiento de solicitudes a través de la API de BigQuery Storage garantiza que Knowledge Catalog pueda interceptar y aplicar políticas incluso para motores de procesamiento externos.
  • Aplicación de políticas centralizada: Con una base segura, usas Knowledge Catalog para aplicar tus reglas de forma universal:
    • Definir una vez, aplicar en todas partes: Defines las etiquetas de política en Knowledge Catalog solo una vez, y la plataforma aplica reglas de enmascaramiento coherentes en todos tus motores de consultas compatibles.
    • Enmascaramiento de datos dinámico: El sistema evalúa la identidad del usuario durante las consultas. Los usuarios autorizados ven los valores sin procesar, mientras que los usuarios restringidos reciben resultados NULL en todos los motores de consultas.
    • Linaje de datos automatizado: Knowledge Catalog realiza un seguimiento automático de las transformaciones de datos, lo que crea un registro de auditoría sin código de registro personalizado.

Objetivos

Antes de comenzar

Antes de comenzar, haz lo siguiente:

Prepara el entorno

En este instructivo, se usa Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

  1. En la Google Cloud consola, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha.

  2. Establece las variables del proyecto:

    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. Define variables para dos personajes de usuario, un analista de comercio minorista y un gerente de comercio minorista:

    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. Habilita las Google Cloud APIs necesarias.

    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

Descarga el código fuente del instructivo

Descarga las secuencias de comandos de Python para este instructivo del repositorio de 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

Crear un bucket de almacenamiento

Crea un bucket nuevo para contener los archivos de la tabla de Iceberg:

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

Prepara las identidades y la seguridad

En este paso, configurarás la delegación de procesamiento mediante la creación de una conexión a recursos de Cloud. Esta conexión actúa como una identidad segura y delegada que BigQuery usa para administrar y leer tus archivos de Iceberg. Esto ayuda a garantizar que los usuarios individuales nunca tengan acceso directo a tu bucket de Cloud Storage.

Ejecuta los siguientes comandos para crear la conexión, recuperar su cuenta de servicio generada automáticamente y otorgar a esa cuenta los permisos necesarios para administrar tus datos de 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 cuentas de servicio para dos personajes: Analyst y Manager. Los siguientes comandos configuran estas cuentas de servicio, permiten que tu usuario actual las suplante para realizar pruebas y les otorgan roles específicos para ejecutar consultas y ver datos.

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 tablas de Apache Iceberg

Usa el motor de BigQuery SQL para crear tablas de Apache Iceberg. Aunque ejecutas los comandos de creación con BigQuery, Lakehouse actúa como la capa de administración que almacena los metadatos de la tabla y protege los archivos Parquet subyacentes en Cloud Storage.

Después de crear las tablas, ejecutas una transformación rápida para ver cómo Knowledge Catalog controla la seguridad y realiza un seguimiento automático del recorrido de tus datos.

Crea un conjunto de datos de BigQuery

Primero, crea un conjunto de datos de BigQuery para agrupar tus tablas:

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

Crea las tablas de Iceberg

Ejecuta los siguientes comandos para crear tablas de inventario y transacciones:

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

Inserta datos de muestra

Inserta datos de muestra en las tablas:

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

Ahora tienes dos tablas de Iceberg con datos de muestra sin procesar. Lakehouse administra los metadatos, pero los archivos Parquet reales están en tu bucket de Cloud Storage.

Transforma datos para el linaje automatizado

Agrega tus transacciones sin procesar en un resumen de ventas diarias. Esta transformación crea una tabla nueva y genera los metadatos que Knowledge Catalog usa para asignar automáticamente el recorrido de tus datos.

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

Define políticas de administración de acceso

En un entorno de producción, escribir tus reglas de seguridad como código (infraestructura como código) hace que tus políticas sean repetibles, controladas por versiones y más fáciles de mantener. En esta sección, usarás el Google Cloud SDK de Python para definir y aplicar tus reglas automáticamente.

Prepara el entorno virtual de Python

Configura un entorno virtual de Python aislado para administrar tus dependencias y garantizar que las secuencias de comandos se ejecuten de manera confiable:

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

Define taxonomías y etiquetas de seguridad

Comienza por crear la base para tus reglas de seguridad. En este paso, crearás una taxonomía para que actúe como un contenedor y una etiqueta de política para que sirva como una etiqueta de seguridad específica para datos sensibles.

Ejecuta el comando para crear los recursos:

python 1_create_taxonomy.py

Revisa 1_create_taxonomy.py para ver la lógica principal:

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

Si estableces de forma explícita el tipo de política FINE_GRAINED_ACCESS_CONTROL, transformas una etiqueta de metadatos estándar en un límite de seguridad estricto de denegación predeterminada. Cualquier columna con esta etiqueta deniega el acceso a todos los usuarios de forma predeterminada.

Crea una política de enmascaramiento de datos dinámico

Ahora, define qué sucede cuando alguien sin privilegios consulta una columna etiquetada. Crea una política de enmascaramiento de datos que reemplace automáticamente los valores sensibles por NULL para el personaje Analyst.

Ejecuta la secuencia de comandos para configurar la regla de enmascaramiento:

python 2_create_masking.py

Dentro de 2_create_masking.py, la secuencia de comandos busca el ID de la etiqueta de política que creaste y aplica la política de datos a la cuenta de servicio 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}"]
)

Otorga acceso privilegiado a tus datos

Debido a la configuración de denegación predeterminada, nadie puede leer la columna etiquetada. Debes otorgar acceso de forma explícita a los usuarios autorizados. Otorga al personaje Manager y a tu propia cuenta el rol de lector detallado. Esto permite que estos usuarios específicos omitan las reglas de enmascaramiento y lean los datos sin enmascarar.

Ejecuta la secuencia de comandos para otorgar acceso:

python 3_grant_access.py

Dentro de 3_grant_access.py, la secuencia de comandos modifica la política de IAM de la etiqueta de política:

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

Adjunta etiquetas de seguridad al esquema de la tabla

Por último, puedes conectar tus reglas lógicas a los datos reales. Actualiza el esquema de la tabla de Iceberg para adjuntar tu etiqueta de política directamente a la columna amount. Después de hacerlo, Lakehouse aplica instantáneamente tus protecciones en los archivos de la tabla de Iceberg de tu bucket.

Ejecuta la secuencia de comandos para adjuntar la etiqueta de política:

python 4_attach_tag.py

Revisa 4_attach_tag.py. La secuencia de comandos recupera el esquema de la tabla de BigQuery, itera por los campos y adjunta la etiqueta específicamente a la columna 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"])

Verifica tus políticas de seguridad

Ejecuta algunas consultas de prueba para asegurarte de que tus permisos funcionen como se espera. Para demostrar que Knowledge Catalog actúa como un motor de contexto universal aplicando las mismas políticas de seguridad cuando cambias de motor de consultas, ejecutas estas pruebas con BigQuery y Apache Spark.

Prueba con BigQuery SQL

Comienza por verificar tus políticas directamente en BigQuery. Esta es la forma más rápida de confirmar que tus reglas de enmascaramiento y permisos estén activos.

Verifica como el gerente

El personaje Manager tiene acceso de lectura privilegiado y detallado. Debería ver todos los detalles de la tabla, incluidos los valores de la columna 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\`"

Como el gerente tiene el rol de lector detallado, la consulta muestra los valores de cantidad sin procesar:

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

Verifica como el analista

Cambia al personaje Analyst y ejecuta la misma consulta.

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Aunque ejecutas la misma consulta, Knowledge Catalog enmascara los valores sensibles de la columna 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 |
+----+----------+--------+------------------+

Vuelve a tu cuenta

Limpia el estado de autenticación de Cloud Shell para volver a tu usuario administrador.

gcloud config unset auth/impersonate_service_account

Prueba con Apache Spark

La seguridad suele fallar cuando los usuarios van directamente a los archivos de datos en Cloud Storage. Si un científico de datos usa Apache Spark para leer los archivos de la tabla de Iceberg directamente, normalmente omitiría tus reglas porque Cloud Storage solo comprende los permisos a nivel de bucket.

Para evitar esto, usa la delegación de procesamiento. Con el conector de Spark-BigQuery, creas un puente seguro que enruta todas las solicitudes de Spark a través de la API de BigQuery Storage. Esto garantiza que Knowledge Catalog verifique los permisos y aplique reglas de enmascaramiento antes de que los datos lleguen al clúster de Spark.

Sube la secuencia de comandos read_transactions.py a tu bucket de Cloud Storage para que Managed Service para Apache Spark pueda acceder a ella:

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

Revisa la lógica principal en la secuencia de comandos que subiste:

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

La secuencia de comandos no dirige Spark a la ruta de acceso gs:// de los archivos de Iceberg. Cuando se especifica .format("bigquery"), la API de BigQuery Storage intercepta la solicitud de lectura, verifica la identidad del usuario que ejecuta el trabajo de Spark, aplica las reglas de enmascaramiento de Knowledge Catalog y muestra solo los datos autorizados en el DataFrame de Spark.

Ejecuta Spark como el gerente

Envía un trabajo de Spark como el personaje Manager. Usa Managed Service para Apache Spark, un servicio administrado que te permite ejecutar cargas de trabajo de Spark sin la molestia de administrar tus propios clústeres:

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

Revisa los registros de salida del trabajo en la terminal. Como el gerente tiene el rol de lector detallado, Spark recupera correctamente las cantidades sin enmascarar:

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

Ejecuta Spark como el analista

Por último, ejecuta el mismo código de Spark como el personaje 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)"

Vuelve a revisar los registros. Aunque el analista ejecutó el mismo código de Spark, la API de BigQuery Storage interceptó la solicitud y aplicó la política de Knowledge Catalog. El DataFrame de Spark del analista muestra null para las cantidades.

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

Acabas de demostrar que, como tu plano de control central, Knowledge Catalog aplica tus políticas de seguridad de manera coherente, independientemente del motor de consultas que uses.

Consulta el recorrido de tus datos con el linaje automatizado

Un lakehouse que cumple con las políticas requiere más que solo controles de acceso; también requiere un registro de auditoría claro. El linaje de datos te ayuda a comprender de dónde provienen tus datos y cómo se transforman. Responder preguntas esenciales como "¿Qué tablas sin procesar se usaron para producir este informe de ventas?" te ayuda a mantener el cumplimiento, depurar canalizaciones de datos rápidamente y crear una base de datos confiable.

En lugar de escribir código de registro complejo de forma manual, Knowledge Catalog realiza un seguimiento automático de este ciclo de vida en toda tu arquitectura. Por ejemplo, cuando creaste una tabla de resumen antes en este instructivo, BigQuery capturó los detalles de la transformación de inmediato y los envió a Knowledge Catalog. Esto actualizó de forma dinámica el contexto y el historial de tus datos.

Explora el gráfico de linaje interactivo

Consulta el mapa interactivo que generó Knowledge Catalog. Muestra cómo fluyen los datos sin procesar de la tabla transactions a la tabla transactions_summary. Como Knowledge Catalog recopila metadatos como un motor de contexto dinámico, este gráfico muestra la trazabilidad confiable y en tiempo real que necesitas para una auditoría de datos.

  1. En la Google Cloud consola de, ve a Knowledge Catalog > Search.
  2. Escribe lakehouse_retail_demo.transactions_summary en la barra de búsqueda y haz clic en la tabla.
  3. Haz clic en la pestaña Linaje.
Gráfico de linaje de datos que muestra el flujo desde la tabla de transacciones a la tabla de resumen de transacciones.
Gráfico de linaje de datos

El gráfico interactivo confirma que la tabla de destino (transactions_summary) se deriva de la tabla de Iceberg administrada sin procesar (transactions). Esta visualización demuestra la trazabilidad de extremo a extremo de tus datos.

Limpia

Para evitar cargos continuos, quita los recursos que creaste para este instructivo.

Quita los recursos de política y metadatos

Antes de borrar el conjunto de datos de BigQuery o el bucket de Cloud Storage, debes borrar las políticas de administración de datos y los recursos de metadatos.

Ejecuta la secuencia de comandos de limpieza de Python:

python cleanup_governance.py

Revisa la secuencia de comandos cleanup_governance.py del repositorio para encontrar la siguiente lógica de desmantelamiento. El orden de eliminación es fundamental. Primero, borras la política de enmascaramiento de datos. Luego, borras la taxonomía superior, que quita automáticamente todas las etiquetas de política subyacentes y evita errores de dependencia de recursos.

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

Quita identidades, almacenamiento y recursos de procesamiento

Borra las tablas de BigQuery, los buckets de Cloud Storage, las cuentas de servicio y el entorno virtual de Python local.

Copia y ejecuta la siguiente secuencia de comandos de limpieza en 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!"

Limpia los archivos del proyecto:

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

Conclusión

Creaste correctamente un data lakehouse seguro. Con Lakehouse para administrar tablas de Iceberg, mantuviste seguros los archivos de tabla subyacentes en Cloud Storage. Cuando estableciste Knowledge Catalog como tu motor de contexto universal, definiste etiquetas de política en una ubicación central y las aplicaste de manera coherente en diferentes motores de consultas, como BigQuery SQL y Apache Spark. Por último, realizaste un seguimiento automático de todo el recorrido de tus datos con el linaje de datos en tiempo real.

¿Qué sigue?