Como criar um lakehouse do Iceberg gerenciado com o BigLake e o Dataplex

1. Introdução

Em um Data Cloud empresarial moderno, em que os dados residem em vários sistemas de armazenamento físico, há um enorme desafio arquitetônico de segurança fragmentada.

Como garantir que dados sensíveis (como valores de transações financeiras) sejam protegidos de maneira consistente quando os dados são armazenados fisicamente em formatos de código aberto, como o Parquet no armazenamento do Google Cloud, e consultados por vários mecanismos diferentes, como o SQL do BigQuery ou o Apache Spark?

Neste codelab, você vai criar uma arquitetura de data lakehouse governado que resolve esses problemas usando tabelas do Apache Iceberg, BigQuery e o Dataplex Universal Catalog. Você vai usar a infraestrutura como código (IaC) para definir políticas de segurança de confiança zero e como elas são aplicadas dinamicamente em diferentes mecanismos de computação.

Pré-requisitos

Ter um projeto do Google Cloud com o faturamento ativado.
Entendimento básico dos conceitos de SQL, IAM e Cloud Storage.

O que você vai aprender

Como criar tabelas do BigLake para o Apache Iceberg no BigQuery, em que o Cloud Storage armazena os dados de forma nativa.
Como aplicar políticas de dados centralizadas usando tags de política para segurança no nível da coluna e mascaramento de dados.
Como separar o acesso ao armazenamento físico do acesso lógico aos dados usando a conexão a recursos do Cloud.
Como aplicar a delegação de computação de confiança zero usando Google Cloud Serverless para Apache Spark para garantir que os mecanismos de código aberto não possam ignorar a governança.
Como visualizar a linhagem de dados automatizada .

Visão geral da arquitetura: governança universal no Iceberg

Para alcançar o controle de acesso refinado (como segurança no nível da coluna e mascaramento de dados) em formatos de dados de código aberto, é necessário estabelecer uma arquitetura de segurança rigorosa e unificada.

Conforme ilustrado no diagrama, esse padrão de data lakehouse governado depende de dois pilares principais para resolver o desafio de segurança fragmentada:

🛡️ As camadas arquitetônicas seguras (à esquerda)

Em vez de permitir que usuários ou mecanismos externos acessem o Cloud Storage diretamente, que só oferece suporte à segurança ampla no nível do bucket, você cria uma base segura.

Formato aberto, metadados gerenciados:os dados permanecem fisicamente no Cloud Storage usando o formato aberto do Apache Iceberg (Parquet), enquanto o BigLake gerencia os metadados de governança de maneira integrada.
Limite de segurança lógica:você separa o acesso ao armazenamento físico do acesso aos dados usando uma conexão a recursos do Cloud segura. Os usuários finais nunca recebem acesso físico direto do IAM aos arquivos brutos do GCS.
Delegação de computação de confiança zero:para garantir que nenhum mecanismo de execução possa ignorar as regras de governança, todas as solicitações de leitura de dados são encaminhadas estritamente pela API BigQuery Storage. Isso se aplica se a consulta for originada do SQL nativo do BigQuery ou do Apache Spark de código aberto.

🎯 Aplicação de políticas centralizada (à direita)

Com a base segura, o Dataplex atua como o cérebro unificado da governança:

Defina uma vez, aplique em todos os lugares:você define as tags de política no Dataplex apenas uma vez, e a arquitetura aplica regras de mascaramento consistentes universalmente em todos os ambientes de execução com suporte.
Mascaramento de dados dinâmico:quando os dados são consultados, o sistema avalia a identidade do usuário em tempo real. Embora os usuários autorizados vejam os valores brutos não mascarados (por exemplo, 100,0) no SQL e no Spark, os usuários restritos recebem automaticamente valores NULL mascarados para colunas restritas em ambos os mecanismos.
Linhagem de dados automatizada:à medida que os dados fluem e se transformam, o Dataplex captura automaticamente os metadados de transformação, fornecendo capacidade de auditoria e rastreabilidade de ponta a ponta integradas sem exigir código de registro personalizado.

2. Configuração e requisitos

Iniciar Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

Ativar o Cloud Shell

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Captura de tela do terminal do Google Cloud Shell mostrando que o ambiente foi conectado

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

Inicializar o ambiente

Abra o Cloud Shell e defina as variáveis do projeto para garantir que todos os comandos sejam direcionados à infraestrutura correta.

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"

Em seguida, defina nossas duas personas.

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)

Ativar APIs

Ative os serviços necessários do 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 codelab

Para evitar a desordem no Cloud Shell, você vai realizar um checkout esparso para fazer o download apenas dos scripts Python necessários para este codelab no repositório do 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

Criar armazenamento

Crie o bucket para armazenar os dados do Iceberg governado altamente seguros.

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

Preparar identidades e segurança

Configure a conexão a recursos do Cloud. Essa é a única entidade que contém as chaves físicas permanentes do IAM para ler os arquivos brutos do Iceberg.

# 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

Em seguida, configure as personas do usuário. Os usuários recebem acesso lógico, não acesso ao armazenamento físico. Para evitar erros causados por atrasos na propagação do IAM, primeiro crie as contas, aguarde alguns segundos e atribua os papéis.

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. Criar tabelas nativas do Iceberg usando o BigLake

Você vai usar os recursos nativos do BigLake para criar as tabelas gerenciadas do Iceberg.

Criar o conjunto de dados do BigQuery

Primeiro, crie um conjunto de dados do BigQuery para agrupar logicamente as tabelas do Iceberg.

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

Criar as tabelas do Iceberg

Em seguida, execute os comandos a seguir para criar as tabelas. Observe o bloco OPTIONS, em que especificamos table_format = 'ICEBERG' e o mapeamos diretamente para o bucket do Cloud Storage e a conexã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/'
);"

Preencher as tabelas com dados

Por fim, insira dados de amostra nas tabelas do Iceberg recém-criadas.

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 totalmente funcionais. O BigLake gerencia os metadados, mas os arquivos Parquet físicos residem com segurança no bucket do GCS.

Simular um pipeline de ETL

Em um cenário real, os dados brutos costumam ser agregados em tabelas de resumo para relatórios comerciais. Vamos atuar como um engenheiro de dados e criar uma tabela de resumo de vendas diárias com base nos dados de transações brutas.

(Observação: execute esta etapa agora para que o Google Cloud tenha tempo suficiente para processar os metadados em segundo plano. Você vai descobrir por que isso é importante mais adiante no 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. Governança centralizada: definir políticas usando Python

Em um ambiente de produção, é difícil escalonar e manter a configuração de políticas de governança pela interface. Em vez disso, é altamente recomendável usar a infraestrutura como código (IaC).

Nesta seção, você vai usar o SDK Python do Google Cloud para criar e aplicar programaticamente as regras de governança de confiança zero, etapa por etapa.

Configurar o ambiente Python

Primeiro, vamos configurar um ambiente Python isolado (venv) para evitar conflitos de biblioteca e instalar os SDKs necessários do Google Cloud.

Execute os comandos a seguir no 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!"

Criar a taxonomia e a tag de política

Uma taxonomia é um contêiner lógico, e uma tag de política é o rótulo específico que você vai anexar à coluna sensível. Para aplicar a segurança no nível da coluna, primeiro você precisa de um contêiner lógico (uma taxonomia) e um rótulo específico (uma tag de política).

Se você olhar dentro de 1_create_taxonomy.py, verá a seguinte 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 confiança zero. Qualquer coluna com essa tag vai negar o acesso a todos os usuários por padrão.

Execute o script para criar os recursos:

python 1_create_taxonomy.py

Configurar a regra de mascaramento (política de dados)

Agora, você define o que acontece quando alguém sem privilégios consulta a coluna marcada. Você vai criar uma política de dados que força o valor a retornar como NULL e anexar essa regra à persona do analista.

Dentro de 2_create_masking.py, o script pesquisa dinamicamente o ID da tag de política que você acabou de criar e aplica uma política de dados:

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

Esse código cria programaticamente uma regra que força os valores subjacentes a retornar como NULL. Em seguida, ele atribui o papel do IAM maskedReader especificamente à persona do analista, garantindo que ele só veja a versão mascarada dos dados.

Execute o script para configurar a regra de mascaramento:

python 2_create_masking.py

Conceder acesso refinado

Devido à configuração de confiança zero, ninguém pode ler a coluna marcada no momento. Você precisa conceder acesso explicitamente ao gerente e à sua conta pessoal.

Dentro de 3_grant_access.py, você modifica a política do IAM da própria 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))

A adição do papel categoryFineGrainedReader permite que esses principais específicos ignorem as regras de mascaramento e leiam os dados brutos não mascarados.

Execute o script para conceder acesso:

python 3_grant_access.py

Anexar a tag de política à tabela do BigQuery

Por fim, você precisa anexar essa tag de política lógica ao esquema da tabela física do Iceberg.

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

Quando essa atualização de esquema é aplicada, o BigLake conecta instantaneamente as tags lógicas do Dataplex aos arquivos Parquet físicos armazenados no bucket do Cloud Storage.

Execute o script para atualizar o esquema da tabela:

python 4_attach_tag.py

5. Verificar as políticas do Dataplex

É hora de testar se nossa governança centralizada funciona. Você vai testar isso em dois mecanismos diferentes para comprovar que as políticas do Dataplex são aplicadas universalmente.

Verificar usando o SQL nativo do BigQuery

Primeiro, você vai usar o Cloud Shell para assumir a identidade das duas personas e consultar a tabela usando o mecanismo SQL nativo do BigQuery.

Teste como gerente (usuário privilegiado):

# 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, ele vai mostrar 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 |
+----+----------+--------+------------------+

Teste como analista (usuário restrito):

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Devido à regra de mascaramento do Dataplex, a coluna de valor retorna como NULL para cada linha.

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

Restaurar sua identidade

Libere memória do estado de autenticação do Cloud Shell para retornar ao usuário administrador.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Verificar usando o Apache Spark (delegação de computação)

E se um cientista de dados usar o Apache Spark para ler essa tabela? Se o Spark ler os arquivos Parquet do GCS físicos diretamente, as regras de mascaramento do Dataplex serão totalmente ignoradas porque o Cloud Storage só entende as permissões no nível do bucket.

Para evitar isso, aplique a delegação de computação usando o conector Spark-BigQuery. Esse conector atua como uma ponte segura, encaminhando as solicitações de leitura do Spark pela API BigQuery Storage para que as regras de governança do Dataplex sejam avaliadas dinamicamente antes que qualquer dado seja enviado ao cluster do Spark.

Confira a lógica principal no script read_transactions.py que você fez o download:

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

Observe que não estamos apontando 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 está executando o job do Spark, aplica as regras de mascaramento do Dataplex e só retorna os dados autorizados para o DataFrame do Spark.

Faça upload desse script do PySpark para o bucket do Cloud Storage para que o Dataproc possa acessá-lo:

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

Executar o Spark como gerente:

Você vai usar o Google Cloud Serverless para Apache Spark. Esse serviço gerenciado permite executar cargas de trabalho do Spark diretamente, sem a necessidade de provisionar, configurar ou gerenciar clusters dedicados.

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

Confira os registros de saída do job no terminal. Como o gerente tem o papel Leitor refinado, o Spark recupera os valores brutos 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:

Agora, envie o mesmo job do Spark, mas desta vez represente a persona do 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)"

Verifique 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 Dataplex. 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         |
+---+--------+------+-------------------+

Compensações arquitetônicas: SQL do BigQuery x Spark

Você acabou de comprovar que o resultado é idêntico, independentemente do mecanismo. A política do Dataplex foi aplicada. Mas, na produção, qual você deve usar?

SQL do BigQuery:ótimo para fluxos de trabalho em que o SQL é o mecanismo desejado e executa cálculos diretamente. É ideal para análises rápidas e Business Intelligence.
Apache Spark:permite cargas de trabalho mais complexas usando o Python, o que o torna adequado para pipelines avançados de machine learning ou código Hadoop legado.

A principal conclusão:não importa qual mecanismo seja usado, ao aplicar a delegação de computação, a camada de governança centralizada de confiança zero nunca pode ser ignorada.

6. Linhagem de dados automatizada

Em qualquer arquitetura de dados corporativa, saber exatamente de onde os dados vêm e como eles foram alterados é fundamental para a conformidade, a depuração e o estabelecimento de confiança. Esse conceito é conhecido como linhagem de dados. Ele responde a perguntas fundamentais como: "Se um gerente estiver analisando um relatório de vendas diárias, quais tabelas brutas foram usadas para calcular esses números?"

Tradicionalmente, o rastreamento desse ciclo de vida exige que os engenheiros de dados escrevam manualmente um código de registro personalizado ou usem ferramentas complexas de terceiros para analisar scripts SQL. No entanto, em um data lakehouse governado do Google Cloud, esse rastreamento é integrado e totalmente automático.

Você se lembra da tabela transactions_summary que criou na tabela de transações brutas anteriormente no codelab? Quando o BigQuery executou a instrução CREATE TABLE AS SELECT, o mecanismo de computação capturou automaticamente os metadados de transformação e os enviou ao Dataplex. Vamos conferir o resultado.

Visualizar a linhagem

No console do Google Cloud, acesse Dataplex Universal Catalog > Pesquisar.
Digite lakehouse_retail_demo.transactions na barra de pesquisa e clique na tabela.
Clique na guia Linhagem.

Você vai ver um gráfico interativo gerado pelo Dataplex Knowledge Engine que comprova que a tabela de destino (transactions_summary) foi derivada da tabela bruta do Iceberg governado (transactions). Você alcançou a rastreabilidade de ponta a ponta essencial para a auditoria de dados.

7. Liberar espaço

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados neste codelab, siga estas etapas.

Remover recursos de governança do Dataplex

Antes de excluir o conjunto de dados do BigQuery ou o bucket do Cloud Storage, é necessário remover as regras de governança lógica. Se você olhar dentro do script cleanup_governance.py do repositório, verá a seguinte sequência de encerramento:

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

A ordem aqui é fundamental. O script primeiro exclui a política de dados (regra de mascaramento) porque ela depende da tag de política. Depois que a política é removida, a exclusão da taxonomia pai é automaticamente em cascata e exclui todas as tags de política subjacentes sem acionar erros de dependência de recursos.

Execute o script de limpeza do Python:

python cleanup_governance.py

Remover identidades, armazenamento e recursos de computação

Agora que a camada de governança está desanexada, você pode excluir com segurança as tabelas do BigQuery, os buckets do Cloud Storage, as contas de serviço e o ambiente Python local.

Copie e execute o seguinte bloco de limpeza abrangente 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 "Deactivating and removing the local Python environment..."
deactivate
cd ../..
rm -rf devrel-demos

echo "✅ Clean up completed successfully!"

Ao concluir essas etapas, você garante que nenhum recurso órfão ou política oculta permaneça no seu projeto.

8. Parabéns!

Você implementou um data lakehouse totalmente governado e detectável.

Você aprendeu que:

Integração nativa do Iceberg:o BigLake pode gerenciar tabelas do Iceberg de código aberto de forma nativa, armazenando os arquivos físicos com segurança no Cloud Storage.
Delegação de computação para segurança:ao encaminhar consultas pela API BigQuery Storage, você aplicou o mascaramento dinâmico refinado em arquivos físicos que não podem restringir o acesso parcial de forma nativa.
Governança independente do mecanismo:as tags de política permitem definir regras uma vez e aplicá-las universalmente, seja consultado por SQL nativo ou ambientes de execução do Apache Spark.
Detectabilidade de dados:o Dataplex Knowledge Engine rastreou automaticamente a linhagem de dados, fornecendo capacidade de auditoria empresarial essencial.

Qual é a próxima etapa?

Conheça o controle de acesso avançado: para implementar cenários de segurança mais complexos, consulte a documentação oficial sobre como personalizar o BigLake com recursos adicionais.
Governar dados não estruturados para GenAI: descubra as tabelas de objetos do BigLake. Estenda esse padrão de ponte segura para arquivos não estruturados (PDFs, imagens) no Cloud Storage, estabelecendo uma base de dados segura e governada para pipelines do Vertex AI e RAG.