Ativar o acesso ao lakehouse em conformidade com a política usando o Knowledge Catalog

Ao armazenar dados em diferentes sistemas de armazenamento, o gerenciamento de segurança fragmentada pode se tornar um grande desafio. É importante garantir que informações sensíveis, como registros financeiros, permaneçam protegidas, mesmo que você as armazene em formatos abertos, como o Apache Iceberg em Google Cloud armazenamento.

É fundamental que as medidas de segurança funcionem perfeitamente em vários mecanismos de consulta, como o SQL do BigQuery e o Apache Spark. Nessa arquitetura, o Knowledge Catalog resolve esse problema funcionando como um mecanismo de contexto universal. Ele contém os metadados necessários para garantir que o contexto de segurança seja aplicado de maneira consistente, não importa qual mecanismo consulte os dados.

Neste tutorial, você vai criar um data lakehouse seguro para resolver esses desafios. Usando scripts, você vai definir políticas de segurança e conferir como o Knowledge Catalog (antigo Dataplex Universal Catalog) e o Lakehouse sem fronteiras funcionam juntos para aplicar as políticas em diferentes mecanismos de consulta.

Informações gerais da arquitetura

Para configurar o controle de acesso refinado em um formato de tabela aberto, como o Apache Iceberg, é necessário criar uma arquitetura de segurança unificada e rigorosa.

Com esse design, o Knowledge Catalog atua como o plano de controle central. O Knowledge Catalog aplica dinamicamente o contexto de segurança em todos os mecanismos compatíveis.

Arquitetura de um data lakehouse compatível com políticas que usa camadas arquitetônicas seguras e aplicação de políticas centralizada.
Arquitetura de um lakehouse em conformidade com a política

Este tutorial se baseia em dois conceitos principais para criar essa arquitetura unificada:

  • Camadas arquitetônicas seguras:em vez de permitir que usuários ou mecanismos de consulta acessem diretamente os buckets do Cloud Storage, você cria uma base segura e em camadas com base nos seguintes atributos:
    • Formato aberto com metadados gerenciados:os dados permanecem no formato aberto do Apache Iceberg (Parquet) no Cloud Storage, enquanto o Lakehouse gerencia os metadados da tabela.
    • Limite de segurança lógico:você desvincula as permissões de armazenamento das consultas de dados usando uma conexão a recursos do Cloud segura. Você nunca concede acesso direto aos arquivos para usuários finais.
    • Delegação de computação:para impedir que os mecanismos de consulta ignorem suas regras, encaminhe todas as solicitações de dados pela API BigQuery Storage. O encaminhamento de solicitações pela API BigQuery Storage garante que o Knowledge Catalog possa interceptar e aplicar políticas, mesmo para mecanismos de processamento externos.
  • Aplicação de política centralizada:com uma base segura, use o Knowledge Catalog para aplicar suas regras universalmente:
    • Defina uma vez, aplique em todos os lugares:você define tags de política no Knowledge Catalog apenas uma vez, e a plataforma aplica regras de mascaramento consistentes em todos os mecanismos de consulta compatíveis.
    • Mascaramento de dados dinâmico:o sistema avalia a identidade do usuário durante as consultas. Os usuários autorizados veem valores brutos, enquanto os usuários restritos recebem saídas NULL em todos os mecanismos de consulta.
    • Linhagem de dados automatizada:o Knowledge Catalog rastreia as transformações de dados automaticamente, criando uma trilha de auditoria sem código de registro personalizado.

Objetivos

Antes de começar

Antes de começar, faça o seguinte:

Preparar o ambiente

Este tutorial usa o Cloud Shell, um ambiente de linha de comando executado na nuvem.

  1. No Google Cloud console, clique no ícone do Cloud Shell na barra de ferramentas superior à direita.

  2. Defina as variáveis do projeto:

    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. Defina variáveis para duas personas de usuário, um analista de varejo e um gerente de varejo:

    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. Ative asAPIs necessárias Google Cloud .

    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

Fazer o download do código-fonte do tutorial

Faça o download dos scripts Python para este tutorial do Google Cloud repositórioDevRel:

# 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

Criar um bucket de armazenamento

Crie um novo bucket para armazenar arquivos de tabela do Iceberg:

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

Preparar identidades e segurança

Nesta etapa, você vai configurar a delegação de computação criando uma conexão a recursos do Cloud. Essa conexão atua como uma identidade delegada e segura que o BigQuery usa para gerenciar e ler seus arquivos do Iceberg. Isso ajuda a garantir que usuários individuais nunca tenham acesso direto ao bucket do Cloud Storage.

Execute os comandos a seguir para criar a conexão, recuperar a conta de serviço gerada automaticamente e conceder a essa conta as permissões necessárias para gerenciar os dados do 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

Crie contas de serviço para duas personas: Analista e Gerente. Os comandos a seguir configuram essas contas de serviço, permitem que o usuário atual as represente para testes e concedem papéis específicos para executar consultas e visualizar dados.

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

Criar tabelas do Apache Iceberg

Use o mecanismo SQL do BigQuery para criar tabelas do Apache Iceberg. Embora você execute os comandos de criação com o BigQuery, o Lakehouse atua como a camada de gerenciamento que armazena os metadados da tabela e protege os arquivos Parquet subjacentes no Cloud Storage.

Depois de criar as tabelas, execute uma transformação rápida para conferir como o Knowledge Catalog processa a segurança e rastreia automaticamente a jornada dos dados.

Criar um conjunto de dados do BigQuery

Primeiro, crie um conjunto de dados do BigQuery para agrupar as tabelas:

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

Criar as tabelas do Iceberg

Execute os comandos a seguir para criar tabelas de inventário e transação:

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

Inserir dados de amostra

Insira dados de amostra nas tabelas:

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

Agora você tem duas tabelas do Iceberg com dados de amostra brutos. O Lakehouse gerencia os metadados, mas os arquivos Parquet reais estão no bucket do Cloud Storage.

Transformar dados para linhagem automatizada

Agregue suas transações brutas em um resumo de vendas diárias. Essa transformação cria uma nova tabela e gera os metadados que o Knowledge Catalog usa para mapear automaticamente a jornada dos dados.

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

Definir políticas de governança de acesso

Em um ambiente de produção, escrever as regras de segurança como código (infraestrutura como código) torna as políticas repetíveis, controladas por versão e mais fáceis de manter. Nesta seção, você vai usar o Google Cloud SDK do Python para definir e aplicar suas regras automaticamente.

Preparar o ambiente virtual do Python

Configure um ambiente virtual isolado do Python para gerenciar suas dependências e garantir que os scripts sejam executados de maneira confiável:

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

Definir taxonomias e tags de segurança

Comece criando a base para suas regras de segurança. Nesta etapa, você vai criar uma taxonomia para atuar como um contêiner e uma tag de política para servir como um rótulo de segurança específico para dados sensíveis.

Execute o script para criar os recursos:

python 1_create_taxonomy.py

Analise 1_create_taxonomy.py para conferir a 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)

Ao definir explicitamente o tipo de política FINE_GRAINED_ACCESS_CONTROL, você transforma uma tag de metadados padrão em um limite de segurança rigoroso de negação por padrão. Qualquer coluna com essa tag nega o acesso a todos os usuários por padrão.

Criar uma política de mascaramento de dados dinâmicos

Agora, defina o que acontece quando alguém sem privilégios consulta uma coluna marcada. Crie uma política de mascaramento de dados que substitua automaticamente valores sensíveis por NULL para a persona Analista.

Execute o script para configurar a regra de mascaramento:

python 2_create_masking.py

Em 2_create_masking.py, o script procura o ID da tag de política criada e aplica a política de dados à conta de serviço do Analista:

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

Conceder acesso privilegiado aos dados

Devido à configuração de negação por padrão, ninguém pode ler a coluna marcada. É necessário conceder acesso explicitamente a usuários autorizados. Conceda à persona Gerente e à sua conta o papel Leitor refinado. Isso permite que esses usuários específicos ignorem as regras de mascaramento e leiam os dados não mascarados.

Execute o script para conceder acesso:

python 3_grant_access.py

Em 3_grant_access.py, o script modifica a política do IAM da tag 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))

Anexar tags de segurança ao esquema da tabela

Por fim, é possível conectar as regras lógicas aos dados reais. Atualize o esquema da tabela do Iceberg para anexar a tag de política diretamente à coluna amount. Depois de fazer isso, o Lakehouse aplica instantaneamente suas proteções aos arquivos de tabela do Iceberg no bucket.

Execute o script para anexar a tag de política:

python 4_attach_tag.py

Analise 4_attach_tag.py. O script busca o esquema da tabela do BigQuery, itera pelos campos e anexa a tag especificamente à coluna 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"])

Verificar as políticas de segurança

Execute algumas consultas de teste para garantir que as permissões funcionem conforme o esperado. Para comprovar que o Knowledge Catalog atua como um mecanismo de contexto universal aplicando as mesmas políticas de segurança ao mudar os mecanismos de consulta, execute esses testes usando o BigQuery e o Apache Spark.

Testar com o SQL do BigQuery

Comece verificando suas políticas diretamente no BigQuery. Essa é a maneira mais rápida de confirmar se as regras de mascaramento e as permissões estão ativas.

Verificar como gerente

A persona Gerente tem acesso de leitor privilegiado e refinado. Ela precisa ver todos os detalhes na tabela, incluindo os valores na coluna 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 o gerente tem o papel Leitor refinado, a consulta mostra os valores brutos do valor:

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

Verificar como analista

Mude para a persona Analista e execute a mesma consulta.

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Mesmo que você execute a mesma consulta, o Knowledge Catalog mascara os valores sensíveis na coluna 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 |
+----+----------+--------+------------------+

Retornar à sua conta

Limpe o estado de autenticação do Cloud Shell para retornar ao usuário administrador.

gcloud config unset auth/impersonate_service_account

Testar com o Apache Spark

A segurança geralmente é quebrada quando os usuários acessam diretamente os arquivos de dados no Cloud Storage. Se um cientista de dados usar o Apache Spark para ler os arquivos de tabela do Iceberg diretamente, ele normalmente ignorará suas regras porque o Cloud Storage só entende as permissões no nível do bucket.

Para evitar isso, use a delegação de computação. Ao usar o conector Spark-BigQuery, você cria uma ponte segura que encaminha todas as solicitações do Spark pela API BigQuery Storage. Isso garante que o Knowledge Catalog verifique as permissões e aplique regras de mascaramento antes que qualquer dado chegue ao cluster do Spark.

Faça o upload do script read_transactions.py para o bucket do Cloud Storage para que o Serviço Gerenciado para Apache Spark possa acessá-lo:

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

Analise a lógica principal no script que você fez o upload:

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

O script não aponta o Spark para o caminho gs:// dos arquivos do Iceberg. Ao especificar .format("bigquery"), a API BigQuery Storage intercepta a solicitação de leitura, verifica a identidade do usuário que executa o job do Spark, aplica as regras de mascaramento do Knowledge Catalog e retorna apenas os dados autorizados ao DataFrame do Spark.

Executar o Spark como gerente

Envie um job do Spark como a persona Gerente. Use o Serviço Gerenciado para Apache Spark, um serviço gerenciado que permite executar cargas de trabalho do Spark sem a necessidade de gerenciar seus próprios 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)"

Analise os registros de saída do job no terminal. Como o gerente tem o papel Leitor refinado, o Spark recupera os valores não mascarados:

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

Executar o Spark como analista

Por fim, execute o mesmo código do Spark como a 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)"

Analise os registros novamente. Mesmo que o analista tenha executado o mesmo código do Spark, a API BigQuery Storage interceptou a solicitação e aplicou a política do Knowledge Catalog. O DataFrame do Spark do analista mostra null para os valores.

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

Você acabou de comprovar que, como plano de controle central, o Knowledge Catalog aplica suas políticas de segurança de maneira consistente, independentemente do mecanismo de consulta usado.

Conferir a jornada dos dados com linhagem automatizada

Um lakehouse em conformidade com a política exige mais do que apenas controles de acesso. Ele também exige uma trilha de auditoria clara. A linhagem de dados ajuda a entender de onde vêm seus dados e como eles são transformados. Responder a perguntas essenciais, como "Quais tabelas brutas foram usadas para produzir este relatório de vendas?", ajuda a manter a conformidade, depurar pipelines de dados rapidamente e criar uma base de dados confiável.

Em vez de escrever um código de registro complexo manualmente, o Knowledge Catalog rastreia automaticamente esse ciclo de vida em toda a arquitetura. Por exemplo, quando você criou uma tabela de resumo anteriormente neste tutorial, o BigQuery capturou os detalhes da transformação instantaneamente e os enviou para o Knowledge Catalog. Isso atualizou dinamicamente o contexto e o histórico dos dados.

Conhecer o gráfico de linhagem interativo

Confira o mapa interativo gerado pelo Knowledge Catalog. Ele mostra como os dados brutos fluem da tabela transactions para a tabela transactions_summary. Como o Knowledge Catalog coleta metadados como um mecanismo de contexto dinâmico, esse gráfico mostra a rastreabilidade confiável e em tempo real necessária para uma auditoria de dados.

  1. No Google Cloud console, acesse Knowledge Catalog > Pesquisa.
  2. Digite lakehouse_retail_demo.transactions_summary na barra de pesquisa e clique na tabela.
  3. Clique na guia Linhagem.
Gráfico de linhagem de dados mostrando o fluxo da tabela "transactions" para a tabela "transactions_summary".
Gráfico de linhagem de dados

O gráfico interativo confirma que a tabela de destino (transactions_summary) é derivada da tabela bruta do Iceberg governada (transactions). Essa visualização demonstra a rastreabilidade de ponta a ponta dos dados.

Limpar

Para evitar cobranças contínuas, remova os recursos criados para este tutorial.

Remover recursos de política e metadados

Antes de excluir o conjunto de dados do BigQuery ou o bucket do Cloud Storage, é necessário excluir as políticas de governança de dados e os recursos de metadados.

Execute o script de limpeza do Python:

python cleanup_governance.py

Analise o script cleanup_governance.py do repositório para encontrar a seguinte lógica de desmontagem. A ordem de exclusão é fundamental. Primeiro, exclua a política de mascaramento de dados. Em seguida, exclua a taxonomia pai, que remove automaticamente todas as tags de política subjacentes e evita erros de dependência 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)

Remover identidades, armazenamento e recursos de computação

Exclua as tabelas do BigQuery, os buckets do Cloud Storage, as contas de serviço e o ambiente virtual local do Python.

Copie e execute o script de limpeza a seguir no 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!"

Limpe os arquivos do projeto:

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

Conclusão

Você criou um data lakehouse seguro. Usando o Lakehouse para gerenciar tabelas do Iceberg, você manteve os arquivos de tabela subjacentes seguros no Cloud Storage. Ao estabelecer o Knowledge Catalog como seu mecanismo de contexto universal, você definiu tags de política em um local central e as aplicou de maneira consistente em diferentes mecanismos de consulta, como o SQL do BigQuery e o Apache Spark. Por fim, você rastreou automaticamente toda a jornada dos dados com a linhagem de dados em tempo real.

A seguir