Governed Iceberg Lakehouse mit BigLake und Dataplex erstellen

1. Einführung

In einer modernen Enterprise Data Cloud, in der Daten auf verschiedenen physischen Speichersystemen gespeichert sind, stellt die fragmentierte Sicherheit eine enorme architektonische Herausforderung dar.

Wie stellen Sie sicher, dass vertrauliche Daten (z. B. Beträge von Finanztransaktionen) einheitlich geschützt werden, wenn Daten physisch in Open-Source-Formaten wie Parquet in Google Cloud Storage gespeichert und von mehreren verschiedenen Engines wie BigQuery SQL oder Apache Spark abgefragt werden?

In diesem Codelab erstellen Sie eine regulierte Data-Lakehouse-Architektur, die diese Probleme mit Apache Iceberg-Tabellen, BigQuery und Dataplex Universal Catalog löst. Sie verwenden Infrastructure as Code (IaC), um Zero-Trust-Sicherheitsrichtlinien zu definieren und festzulegen, wie sie dynamisch in verschiedenen Compute-Engines erzwungen werden.

Voraussetzungen

Google Cloud-Projekt mit aktivierter Abrechnungsfunktion.
Grundlegendes Verständnis von SQL, IAM und Cloud Storage-Konzepten.

Lerninhalte

BigLake-Tabellen für Apache Iceberg in BigQuery erstellen, wobei die Daten nativ in Cloud Storage gespeichert werden.
So erzwingen Sie zentralisierte Datenrichtlinien mithilfe von Richtlinien-Tags für die Sicherheit auf Spaltenebene und Datenmaskierung.
So entkoppeln Sie den physischen Speicherzugriff vom logischen Datenzugriff mithilfe einer Cloud-Ressourcenverbindung.
So erzwingen Sie die Zero-Trust-Berechnungsdelegierung mit Google Cloud Serverless for Apache Spark, um sicherzustellen, dass Open-Source-Engines die Governance nicht umgehen können.
Data Lineage automatisieren und visualisieren

Architekturübersicht: Universelle Governance für Iceberg

Um eine detaillierte Zugriffssteuerung (z. B. Sicherheit auf Spaltenebene und Datenmaskierung) für Open-Source-Datenformate zu erreichen, müssen Sie eine strenge und einheitliche Sicherheitsarchitektur einrichten.

Wie im Diagramm dargestellt, basiert dieses verwaltete Lakehouse-Muster auf zwei Hauptsäulen, um das Problem der fragmentierten Sicherheit zu lösen:

🛡️ Die sicheren Architekturschichten (links)

Anstatt Nutzern oder externen Engines den direkten Zugriff auf Cloud Storage zu erlauben, was nur eine umfassende Sicherheit auf Bucket-Ebene unterstützt, schaffen Sie eine sichere Grundlage.

Offenes Format, verwaltete Metadaten:Die Daten verbleiben physisch in Cloud Storage im offenen Apache Iceberg-Format (Parquet), während BigLake die zugehörigen Metadaten nahtlos verwaltet.
Logische Sicherheitsgrenze:Sie entkoppeln den physischen Speicherzugriff vom logischen Datenzugriff mithilfe einer sicheren Cloud-Ressourcenverbindung. Endnutzer erhalten niemals direkten physischen IAM-Zugriff auf die GCS-Rohdateien.
Delegierung von Berechnungen ohne Vertrauensstellung:Damit keine Ausführungs-Engine die Governance-Regeln umgehen kann, werden alle Datenleseanfragen streng über die BigQuery Storage API weitergeleitet. Dies gilt unabhängig davon, ob die Abfrage aus nativem BigQuery SQL oder Open-Source-Apache Spark stammt.

🎯 Zentrale Durchsetzung von Richtlinien (richtig)

Mit der sicheren Grundlage fungiert Dataplex als einheitliche Governance-Zentrale:

Einmal definieren, überall durchsetzen:Sie definieren Ihre Richtlinien-Tags nur einmal in Dataplex. Die Architektur wendet einheitliche Maskierungsregeln universell auf alle unterstützten Ausführungs-Runtimes an.
Dynamische Datenmaskierung:Wenn Daten abgefragt werden, wird die Identität des Nutzers dynamisch ausgewertet. Autorisierte Nutzer sehen sowohl in SQL als auch in Spark die Rohwerte (z.B. 100,0). Eingeschränkte Nutzer erhalten automatisch maskierte NULL-Werte für eingeschränkte Spalten in beiden Engines.
Automatisierte Datenherkunft:Wenn Daten fließen und transformiert werden, erfasst Dataplex automatisch Transformationsmetadaten. So sind integrierte End-to-End-Prüfbarkeit und ‑Rückverfolgbarkeit ohne benutzerdefinierten Protokollierungscode möglich.

2. Einrichtung und Anforderungen

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der Google Cloud Console rechts oben in der Symbolleiste auf das Cloud Shell-Symbol:

Cloud Shell aktivieren

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

Screenshot des Google Cloud Shell-Terminals, auf dem zu sehen ist, dass die Umgebung verbunden ist

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Alle Aufgaben in diesem Codelab können in einem Browser ausgeführt werden. Sie müssen nichts installieren.

Umgebung initialisieren

Öffnen Sie Cloud Shell und legen Sie Ihre Projektvariablen fest, damit alle Befehle auf die richtige Infrastruktur ausgerichtet sind.

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"

Als Nächstes definieren wir unsere beiden 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)

APIs aktivieren

Aktivieren Sie die erforderlichen Google Cloud-Dienste.

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

Codelab-Quellcode herunterladen

Damit Ihre Cloud Shell nicht überladen wird, führen Sie einen Sparse Checkout durch, um nur die für dieses Codelab erforderlichen Python-Skripts aus dem Google Cloud DevRel-Repository herunterzuladen.

# 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

Speicher erstellen

Erstellen Sie den Bucket für die hochsicheren, verwalteten Iceberg-Daten.

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

Identitäten und Sicherheit vorbereiten

Cloud-Ressourcenverbindung konfigurieren Dies ist die einzige Einheit, die die permanenten physischen IAM-Schlüssel zum Lesen der rohen Iceberg-Dateien besitzt.

# 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

Als Nächstes richten Sie die Nutzer-Personas ein. Nutzer erhalten logischen Zugriff, nicht physischen Speicherzugriff. Um Fehler aufgrund von IAM-Verzögerungen zu vermeiden, erstellen Sie zuerst die Konten, warten Sie einige Sekunden und weisen Sie dann die Rollen zu.

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. Native Iceberg-Tabellen über BigLake erstellen

Sie verwenden die nativen Funktionen von BigLake, um die verwalteten Iceberg-Tabellen zu erstellen.

BigQuery-Dataset erstellen

Erstellen Sie zuerst ein BigQuery-Dataset, um unsere Iceberg-Tabellen logisch zu gruppieren.

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

Iceberg-Tabellen erstellen

Führen Sie als Nächstes die folgenden Befehle aus, um die Tabellen zu erstellen. Beachten Sie den OPTIONS-Block, in dem wir table_format = 'ICEBERG' angeben und direkt unserem Cloud Storage-Bucket und unserer Verbindung zuordnen.

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

Tabellen mit Daten füllen

Fügen Sie schließlich Beispieldaten in die neu erstellten Iceberg-Tabellen ein.

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

Sie haben jetzt zwei voll funktionsfähige Iceberg-Tabellen. BigLake verwaltet die Metadaten, die physischen Parquet-Dateien befinden sich jedoch sicher in Ihrem GCS-Bucket.

ETL-Pipeline simulieren

In der Praxis werden Rohdaten häufig in Zusammenfassungstabellen für die Geschäftsberichterstattung aggregiert. Wir schlüpfen in die Rolle eines Data Engineers und erstellen aus unseren Rohdaten zu Transaktionen eine tägliche Umsatzübersichtstabelle.

Hinweis: Führen Sie diesen Schritt jetzt aus, damit Google Cloud genügend Zeit hat, die Hintergrundmetadaten zu verarbeiten. Warum das wichtig ist, erfahren Sie später in diesem 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. Zentrale Verwaltung: Richtlinien mit Python definieren

In einer Produktionsumgebung ist die Konfiguration von Governance-Richtlinien über die Benutzeroberfläche schwer zu skalieren und zu verwalten. Stattdessen wird dringend empfohlen, Infrastructure as Code (IaC) zu verwenden.

In diesem Abschnitt verwenden Sie das Google Cloud Python SDK, um Ihre Zero-Trust-Governance-Regeln programmatisch zu erstellen und schrittweise zu erzwingen.

Python-Umgebung einrichten

Zuerst richten wir eine isolierte Python-Umgebung (venv) ein, um Bibliothekskonflikte zu vermeiden, und installieren die erforderlichen Google Cloud SDKs.

Führen Sie die folgenden Befehle in Cloud Shell aus:

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

Taxonomie und Richtlinien-Tag erstellen

Eine Taxonomie ist ein logischer Container und ein Richtlinien-Tag ist das spezifische Label, das Sie an unsere vertrauliche Spalte anhängen. Um Sicherheit auf Spaltenebene zu erzwingen, benötigen Sie zuerst einen logischen Container (eine Taxonomie) und ein bestimmtes Label (ein Richtlinien-Tag).

Wenn Sie sich 1_create_taxonomy.py ansehen, sehen Sie die folgende Kernlogik:

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

Wenn Sie den Richtlinientyp FINE_GRAINED_ACCESS_CONTROL explizit festlegen, wandeln Sie ein Standard-Metadatentag in eine strikte Zero-Trust-Sicherheitsgrenze um. Bei jeder Spalte mit diesem Tag wird der Zugriff für alle Nutzer standardmäßig verweigert.

Führen Sie das Skript aus, um die Ressourcen zu erstellen:

python 1_create_taxonomy.py

Maskierungsregel (Datenrichtlinie) konfigurieren

Sie definieren jetzt, was passiert, wenn jemand ohne Berechtigungen die getaggte Spalte abfragt. Sie erstellen eine Datenschutzrichtlinie, die erzwingt, dass der Wert als NULL zurückgegeben wird, und hängen diese Regel an die Analyst-Persona an.

Im 2_create_masking.py-Abschnitt sucht das Skript dynamisch nach der Richtlinien-Tag-ID, die Sie gerade erstellt haben, und wendet eine Datenrichtlinie an:

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

Mit diesem Code wird programmatisch eine Regel erstellt, die erzwingt, dass die zugrunde liegenden Werte als NULL zurückgegeben werden. Anschließend wird der Analyst-Persona die IAM-Rolle „maskedReader“ zugewiesen, damit nur die maskierte Version der Daten angezeigt wird.

Führen Sie das Skript aus, um die Maskierungsregel zu konfigurieren:

python 2_create_masking.py

Detaillierten Zugriff gewähren

Aufgrund unserer Zero-Trust-Einrichtung kann derzeit niemand die getaggte Spalte lesen. Sie müssen dem Manager und Ihrem persönlichen Konto explizit Zugriff gewähren.

In 3_grant_access.py ändern Sie die IAM-Richtlinie des Richtlinien-Tags selbst:

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

Durch Hinzufügen der Rolle categoryFineGrainedReader können diese bestimmten Hauptkonten die Maskierungsregeln umgehen und die Rohdaten ohne Maskierung lesen.

Führen Sie das Skript aus, um Zugriff zu gewähren:

python 3_grant_access.py

Richtlinien-Tag an die BigQuery-Tabelle anhängen

Schließlich müssen Sie dieses logische Richtlinien-Tag an unser physisches Iceberg-Tabellenschema anhängen.

4_attach_tag.py Das Skript ruft das BigQuery-Tabellenschema ab, durchläuft die Felder und fügt das Tag speziell an die Spalte amount an:

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

Wenn diese Schemaaktualisierung angewendet wird, werden die logischen Dataplex-Tags sofort auf die physischen Parquet-Dateien übertragen, die in Ihrem Cloud Storage-Bucket gespeichert sind.

Führen Sie das Script aus, um das Tabellenschema zu aktualisieren:

python 4_attach_tag.py

5. Dataplex-Richtlinien prüfen

Es ist an der Zeit, zu testen, ob unsere zentralisierte Verwaltung funktioniert. Sie testen dies mit zwei verschiedenen Engines, um nachzuweisen, dass Dataplex-Richtlinien universell durchgesetzt werden.

Mit nativem BigQuery-SQL überprüfen

Zuerst verwenden Sie Cloud Shell, um die Identität der beiden Personen anzunehmen und die Tabelle mit der nativen SQL-Engine von BigQuery abzufragen.

Als Administrator (privilegierter Nutzer) testen:

# 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\`"

Da der Manager die Rolle „Detaillierter Lesezugriff“ hat, werden die Rohbeträge angezeigt.

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

Als Analyst (eingeschränkter Nutzer) testen:

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Aufgrund der Dataplex-Maskierungsregel wird die Spalte „amount“ für jede Zeile als NULL zurückgegeben.

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

Identität wiederherstellen

Bereinigen Sie den Cloud Shell-Authentifizierungsstatus, um zu Ihrem Administratornutzer zurückzukehren.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Mit Apache Spark überprüfen (Berechnungsdelegierung)

Was passiert, wenn ein Data Scientist Apache Spark verwendet, um diese Tabelle zu lesen? Wenn Spark die physischen GCS-Parquet-Dateien direkt liest, werden die Dataplex-Maskierungsregeln vollständig umgangen, da Cloud Storage nur Berechtigungen auf Bucket-Ebene versteht.

Um dies zu verhindern, erzwingen Sie die Berechnungsdelegierung mit dem Spark-BigQuery-Connector. Dieser Connector fungiert als sichere Brücke und leitet die Spark-Leseanfragen über die BigQuery Storage API weiter, sodass Dataplex-Governance-Regeln dynamisch ausgewertet werden, bevor Daten an den Spark-Cluster gesendet werden.

Sehen Sie sich die Kernlogik im heruntergeladenen read_transactions.py-Skript an:

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

Wir verweisen Spark nicht auf den gs://-Pfad der Iceberg-Dateien. Wenn Sie .format("bigquery") angeben, fängt die BigQuery Storage API die Leseanfrage ab, prüft die Identität des Nutzers, der den Spark-Job ausführt, wendet die Dataplex-Maskierungsregeln an und gibt nur die autorisierten Daten an den Spark-DataFrame zurück.

Laden Sie dieses PySpark-Skript in Ihren Cloud Storage-Bucket hoch, damit Dataproc darauf zugreifen kann:

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

Spark als Manager ausführen:

Sie verwenden Google Cloud Serverless for Apache Spark. Mit diesem verwalteten Dienst können Sie Spark-Arbeitslasten direkt ausführen, ohne dedizierte Cluster bereitstellen, konfigurieren oder verwalten zu müssen.

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

Sehen Sie sich die Jobausgabelogs im Terminal an. Da der Administrator die Rolle „Detaillierter Lesezugriff“ hat, ruft Spark die Rohbeträge ohne Maskierung ab.

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

Spark als Analyst ausführen:

Senden Sie nun denselben Spark-Job noch einmal, aber dieses Mal mit der Identität des Analysten.

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

Prüfen Sie die Logs noch einmal. Obwohl der Analyst genau denselben Spark-Code ausgeführt hat, hat die BigQuery Storage API die Anfrage abgefangen und die Dataplex-Richtlinie erzwungen. Im Spark-DataFrame des Analysten wird null für die Beträge angezeigt.

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

Architektonische Kompromisse: BigQuery SQL im Vergleich zu Spark

Sie haben gerade bewiesen, dass das Ergebnis unabhängig von der Engine identisch ist. Die Dataplex-Richtlinie wurde erfolgreich erzwungen. Welche sollten Sie in der Produktion verwenden?

BigQuery SQL:Ideal für Workflows, in denen SQL die gewünschte Engine ist und Berechnungen direkt vor Ort ausgeführt werden. Sie ist ideal für schnelle Analysen und Business Intelligence.
Apache Spark:Ermöglicht komplexere Arbeitslasten durch die Verwendung von Python und eignet sich daher gut für anspruchsvolle Pipelines für maschinelles Lernen oder Legacy-Hadoop-Code.

Wichtig: Unabhängig davon, welche Engine verwendet wird, kann die zentrale Zero-Trust-Governance-Ebene durch die Erzwingung der Compute-Delegierung niemals umgangen werden.

6. Automatisierte Data Lineage

In jeder Unternehmensdatenarchitektur ist es für Compliance, Fehlerbehebung und Vertrauensbildung entscheidend, genau zu wissen, woher Ihre Daten stammen und wie sie geändert wurden. Dieses Konzept wird als Data Lineage (Datenherkunft) bezeichnet. Damit werden grundlegende Fragen beantwortet, z. B.: „Wenn ein Manager einen täglichen Verkaufsbericht aufruft, welche Rohdatentabellen wurden zur Berechnung dieser Zahlen verwendet?“

Bisher mussten Data Engineers benutzerdefinierten Protokollierungscode manuell schreiben oder komplexe Drittanbietertools zum Parsen von SQL-Skripts verwenden, um diesen Lebenszyklus zu verfolgen. In einem verwalteten Google Cloud Lakehouse ist dieses Tracking jedoch integriert und erfolgt vollständig automatisch.

Erinnern Sie sich an die Tabelle transactions_summary, die Sie zuvor im Codelab aus der Tabelle mit Rohdaten zu Transaktionen erstellt haben? Als BigQuery die CREATE TABLE AS SELECT-Anweisung ausgeführt hat, hat die Compute Engine automatisch die Transformationsmetadaten erfasst und an Dataplex gesendet. Sehen wir uns das Ergebnis an.

Herkunft visualisieren

Rufen Sie in der Google Cloud Console Dataplex Universal Catalog > Search auf.
Geben Sie lakehouse_retail_demo.transactions in die Suchleiste ein und klicken Sie auf die Tabelle.
Klicken Sie auf den Tab Lineage.

Sie sehen ein interaktives Diagramm, das von der Dataplex Knowledge Engine generiert wurde und beweist, dass die Zieltabelle (transactions_summary) aus der verwalteten Iceberg-Rohdatentabelle (transactions) abgeleitet wurde. Sie haben eine End-to-End-Rückverfolgbarkeit erreicht, die für die Datenprüfung unerlässlich ist.

7. Bereinigen

Mit den folgenden Schritten vermeiden Sie, dass Ihrem Google Cloud-Konto die in diesem Codelab verwendeten Ressourcen in Rechnung gestellt werden.

Dataplex-Governance-Ressourcen entfernen

Bevor Sie das BigQuery-Dataset oder den Cloud Storage-Bucket löschen, müssen Sie die logischen Governance-Regeln entfernen. Wenn Sie sich das cleanup_governance.py-Skript aus dem Repository ansehen, sehen Sie die folgende Abbaufolge:

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

Die Reihenfolge ist hier entscheidend. Im Script wird zuerst die Datenrichtlinie (Maskierungsregel) gelöscht, da sie auf dem Richtlinien-Tag basiert. Sobald die Richtlinie entfernt wurde, wird beim Löschen der übergeordneten Taxonomie automatisch eine Kaskadierung ausgelöst und alle zugrunde liegenden Richtlinien-Tags werden gelöscht, ohne dass Fehler aufgrund von Ressourcenabhängigkeiten auftreten.

Führen Sie das Python-Bereinigungsskript aus:

python cleanup_governance.py

Identitäten, Speicher- und Compute-Assets entfernen

Nachdem die Governance-Ebene getrennt wurde, können Sie die BigQuery-Tabellen, Cloud Storage-Buckets, Dienstkonten und die lokale Python-Umgebung gefahrlos löschen.

Kopieren Sie den folgenden umfassenden Bereinigungsblock und führen Sie ihn in Cloud Shell aus:

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

Wenn Sie diese Schritte ausführen, stellen Sie sicher, dass keine verwaisten Ressourcen oder verborgenen Richtlinien in Ihrem Projekt verbleiben.

8. Glückwunsch!

Sie haben ein vollständig verwaltetes, auffindbares Data Lakehouse implementiert.

Sie haben Folgendes gelernt:

Native Iceberg-Integration:BigLake kann Open-Source-Iceberg-Tabellen nativ verwalten und die physischen Dateien sicher in Cloud Storage speichern.
Compute-Delegierung für mehr Sicherheit:Durch das Weiterleiten von Abfragen über die BigQuery Storage API haben Sie eine detaillierte dynamische Maskierung für physische Dateien erzwungen, bei denen der partielle Zugriff nativ nicht eingeschränkt werden kann.
Engine-unabhängige Governance:Mit Richtlinien-Tags können Sie Regeln einmal definieren und sie universell erzwingen lassen, unabhängig davon, ob die Abfrage über native SQL- oder Apache Spark-Laufzeiten erfolgt.
Auffindbarkeit von Daten:Die Dataplex Knowledge Engine hat die Datenherkunft automatisch nachverfolgt und so für die erforderliche Auditierbarkeit von Unternehmen gesorgt.

Nächste Schritte

Erweiterte Zugriffssteuerung:Wenn Sie komplexere Sicherheitsszenarien implementieren möchten, lesen Sie die offizielle Dokumentation zum Anpassen von BigLake mit zusätzlichen Funktionen.
Unstrukturierte Daten für generative KI verwalten:BigLake-Objekttabellen Erweitern Sie dieses Secure Bridge-Muster auf unstrukturierte Dateien (PDFs, Bilder) in Cloud Storage, um eine sichere, verwaltete Datengrundlage für Vertex AI- und RAG-Pipelines zu schaffen.