Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Erstellung eines regulierten Iceberg-Lakehouse mit Google Cloud Lakehouse und Knowledge Catalog

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 im Google Cloud-Speicher gespeichert und von mehreren verschiedenen Engines wie BigQuery SQL oder Apache Spark abgefragt werden?

In diesem Codelab erstellen Sie eine Architektur für ein verwaltetes Data Lakehouse, die diese Probleme mit Apache Iceberg-Tabellen, BigQuery und Knowledge 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

Google Cloud Lakehouse-Tabellen für Apache Iceberg in BigQuery erstellen, in denen 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.
Durchsetzung der Zero-Trust-Berechnungsdelegierung mit Managed Service for Apache Spark, um sicherzustellen, dass Open-Source-Engines die Governance nicht umgehen können.
Automatisierte Data Lineage 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 die zugehörigen Metadaten nahtlos von Lakehouse verwaltet werden.
Logische Sicherheitsgrenze:Sie entkoppeln den physischen Speicherzugriff vom logischen Datenzugriff über eine sichere Cloud-Ressourcenverbindung. Endnutzer erhalten niemals direkten physischen IAM-Zugriff auf die GCS-Rohdateien.
Zero-Trust-Berechnungsdelegierung:Damit keine Ausführungs-Engine die Governance-Regeln umgehen kann, werden alle Datenleseanfragen strikt ü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 Knowledge Catalog als einheitliche Governance-Zentrale:

Einmal definieren, überall durchsetzen:Sie definieren Ihre Richtlinien-Tags nur einmal im Knowledge Catalog. 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 in Echtzeit ausgewertet. Während autorisierte Nutzer sowohl in SQL als auch in Spark die unmaskierten Rohwerte (z. B. 100,0) sehen, erhalten eingeschränkte Nutzer automatisch maskierte NULL-Werte für eingeschränkte Spalten in beiden Engines.
Automatisierte Datenherkunft:Wenn Daten fließen und transformiert werden, erfasst Knowledge Catalog automatisch Transformationsmetadaten. So wird eine integrierte End-to-End-Prüfbarkeit und ‑Rückverfolgbarkeit ohne benutzerdefinierten Protokollierungscode ermöglicht.

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 die 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 zum Speichern der hochsicheren, verwalteten Iceberg-Daten.

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

Identitäten und Sicherheit vorbereiten

Konfigurieren Sie die Cloud-Ressourcenverbindung. Dies ist die einzige Entität, die die permanenten physischen IAM-Schlüssel zum Lesen der rohen Iceberg-Dateien enthält.

# 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

Richten Sie als Nächstes die Nutzeridentitäten ein. Nutzern wird logischer Zugriff gewährt, nicht physischer Speicherzugriff. Um Fehler zu vermeiden, die durch IAM-Verzögerungen bei der Weitergabe verursacht werden, 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 Lakehouse erstellen

Sie verwenden die nativen Funktionen von Lakehouse, 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. Das Lakehouse 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 es schwierig, Governance-Richtlinien über die Benutzeroberfläche 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 Knowledge Catalog 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 die Sicherheit auf Spaltenebene zu erzwingen, benötigen Sie zuerst einen logischen Container (eine Taxonomie) und ein spezifisches 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, wird ein Standard-Metadatentag in eine strikte Zero-Trust-Sicherheitsgrenze umgewandelt. Für alle Spalten 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 weisen diese Regel der Analyst-Persona zu.

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 Rolle „Analyst“ 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-Konfiguration kann derzeit niemand die getaggte Spalte lesen. Sie müssen dem Verwaltungskonto 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 unmaskierten Rohdaten 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 Knowledge Catalog-Tags sofort mit den physischen Parquet-Dateien in Ihrem Cloud Storage-Bucket verknüpft.

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

python 4_attach_tag.py

5. Knowledge Catalog-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 die Knowledge Catalog-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 Maskierungsregel für den Knowledge Catalog wird in der Spalte „Betrag“ für jede Zeile 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 Maskierungsregeln des Knowledge Catalog 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 die Governance-Regeln des Knowledge Catalog 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 (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)

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 Maskierungsregeln des Knowledge Catalog 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 Managed Apache Spark 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 verwaltetes 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 Managed Apache Spark 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 genau denselben Spark-Job, aber dieses Mal mit der Identität des Analysten.

echo "🚀 Submitting Managed Apache Spark 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)"

Sehen Sie sich die Logs noch einmal an. Obwohl der Analyst genau denselben Spark-Code ausgeführt hat, hat die BigQuery Storage API die Anfrage abgefangen und die Knowledge Catalog-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 Knowledge Catalog-Richtlinie wurde erfolgreich durchgesetzt. Welche sollten Sie in der Produktion verwenden?

BigQuery SQL:Ideal für Workflows, in denen SQL die gewünschte Engine ist und Berechnungen direkt ausgeführt werden. Es eignet sich hervorragend 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 für die Nachverfolgung dieses Lebenszyklus benutzerdefinierten Protokollierungscode manuell schreiben oder komplexe Drittanbietertools zum Parsen von SQL-Scripts verwenden. In einem regulierten Google Cloud Lakehouse ist diese Nachverfolgung 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 diese CREATE TABLE AS SELECT-Anweisung ausgeführt hat, hat die Compute Engine die Transformationsmetadaten automatisch erfasst und an Knowledge Catalog gesendet. Sehen wir uns das Ergebnis an.

Herkunft visualisieren

Rufen Sie in der Google Cloud Console Knowledge Catalog > Suchen 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 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.

Knowledge Catalog-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. Das Skript löscht zuerst die Datenrichtlinie (Maskierungsregel), da sie auf dem Richtlinien-Tag basiert. Sobald die Richtlinie entfernt wurde, wird beim Löschen der übergeordneten Taxonomie automatisch auch die Löschung aller zugrunde liegenden Richtlinien-Tags ausgelöst, 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:Lakehouse 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 Knowledge Engine hat die Datenherkunft automatisch nachverfolgt und so für die erforderliche Prüfbarkeit von Unternehmen gesorgt.

Nächste Schritte

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