Tworzenie zarządzanej architektury lakehouse Iceberg przy użyciu Google Cloud Lakehouse i Knowledge Catalog

1. Wprowadzenie

W nowoczesnej chmurze danych dla przedsiębiorstw, w której dane znajdują się w różnych fizycznych systemach pamięci masowej, występuje ogromne wyzwanie architektoniczne związane z rozproszonym bezpieczeństwem.

Jak zapewnić spójną ochronę danych wrażliwych (takich jak kwoty transakcji finansowych), gdy dane są fizycznie przechowywane w formatach open source, takich jak Parquet, w Google Cloud Storage i są odpytywane przez wiele różnych silników, takich jak BigQuery SQL czy Apache Spark?

W tym ćwiczeniu zbudujesz zarządzaną architekturę data lakehouse, która rozwiązuje te problemy za pomocą tabel Apache Iceberg, BigQuery i Knowledge Catalog. Użyjesz infrastruktury jako kodu (IaC), aby zdefiniować zasady bezpieczeństwa oparte na zasadzie zerowego zaufania i sposób ich dynamicznego egzekwowania w różnych usługach obliczeniowych.

Wymagania wstępne

  • Projekt Google Cloud z włączonymi płatnościami.
  • Podstawowa znajomość pojęć związanych z SQL, IAM i Cloud Storage.

Czego się nauczysz

Omówienie architektury: uniwersalne zarządzanie w Icebergu

6f05a096ec94f996.png

Aby uzyskać precyzyjną kontrolę dostępu (np. zabezpieczenia na poziomie kolumn i maskowanie danych) w przypadku formatów danych open source, musisz ustanowić ścisłą i ujednoliconą architekturę zabezpieczeń.

Jak widać na diagramie, ten wzorzec zarządzanej architektury lakehouse opiera się na 2 głównych filarach, które pozwalają rozwiązać problem rozproszonych zabezpieczeń:

🛡️ Warstwy bezpiecznej architektury (po lewej)

Zamiast zezwalać użytkownikom lub zewnętrznym silnikom na bezpośredni dostęp do Cloud Storage, który obsługuje tylko szerokie zabezpieczenia na poziomie zasobnika, możesz zbudować bezpieczną podstawę.

  • Otwarty format, zarządzane metadane: dane pozostają fizycznie w Cloud Storage w otwartym formacie Apache Iceberg (Parquet), a Lakehouse bezproblemowo zarządza metadanymi.
  • Logiczna granica bezpieczeństwa: oddzielasz fizyczny dostęp do pamięci masowej od logicznego dostępu do danych za pomocą bezpiecznego połączenia z zasobem Cloud. Użytkownicy nigdy nie uzyskują bezpośredniego fizycznego dostępu IAM do surowych plików GCS.
  • Delegowanie obliczeń oparte na zasadzie zerowego zaufania: aby żaden silnik wykonawczy nie mógł obejść reguł zarządzania, wszystkie żądania odczytu danych są ściśle kierowane przez interfejs BigQuery Storage API. Dotyczy to zapytań pochodzących z natywnego języka SQL BigQuery lub z Apache Spark o otwartym kodzie źródłowym.

🎯 Centralized Policy Enforcement (Right)

Dzięki bezpiecznej infrastrukturze Knowledge Catalog pełni funkcję ujednoliconego centrum zarządzania:

  • Zdefiniuj raz, egzekwuj wszędzie: tagi zasad definiujesz w Knowledge Catalog tylko raz, a architektura stosuje spójne reguły maskowania uniwersalnie we wszystkich obsługiwanych środowiskach wykonawczych.
  • Dynamiczne maskowanie danych: gdy dane są wysyłane w zapytaniu, system na bieżąco ocenia tożsamość użytkownika. Użytkownicy z uprawnieniami będą widzieć w SQL i Sparku nieprzetworzone, niezasłonięte wartości (np. 100,0), a użytkownicy z ograniczonymi uprawnieniami będą automatycznie otrzymywać zasłonięte wartości NULL w przypadku kolumn z ograniczeniami w obu silnikach.
  • Automatyczna historia danych: w miarę przepływu i przekształcania danych Knowledge Catalog automatycznie rejestruje metadane przekształceń, zapewniając wbudowaną pełną kontrolę i śledzenie bez konieczności stosowania niestandardowego kodu rejestrowania.

2. Konfiguracja i wymagania

Uruchom Cloud Shell

Z Google Cloud można korzystać zdalnie na laptopie, ale w tym ćwiczeniu użyjesz Google Cloud Shell, czyli środowiska wiersza poleceń działającego w chmurze.

W konsoli Google Cloud kliknij ikonę Cloud Shell na pasku narzędzi w prawym górnym rogu:

Aktywowanie Cloud Shell

Uzyskanie dostępu do środowiska i połączenie się z nim powinno zająć tylko kilka chwil. Po zakończeniu powinno wyświetlić się coś takiego:

Zrzut ekranu terminala Google Cloud Shell pokazujący, że środowisko zostało połączone

Ta maszyna wirtualna zawiera wszystkie potrzebne narzędzia dla programistów. Zawiera również stały katalog domowy o pojemności 5 GB i działa w Google Cloud, co znacznie zwiększa wydajność sieci i usprawnia proces uwierzytelniania. Wszystkie zadania w tym laboratorium możesz wykonać w przeglądarce. Nie musisz niczego instalować.

Inicjowanie środowiska

Otwórz Cloud Shell i ustaw zmienne projektu, aby mieć pewność, że wszystkie polecenia są kierowane do prawidłowej infrastruktury.

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"

Następnie zdefiniujmy 2 profile.

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)

włączyć interfejsy API,

Włącz niezbędne usługi 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

Pobieranie kodu źródłowego ćwiczeń z programowania

Aby uniknąć zaśmiecania Cloud Shell, wykonasz rzadkie wyewidencjonowanie, aby pobrać z repozytorium Google Cloud DevRel tylko skrypty Pythona potrzebne do tego ćwiczenia.

# 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

Tworzenie miejsca na dane

Utwórz zasobnik do przechowywania wysoce bezpiecznych, zarządzanych danych Iceberg.

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

Przygotowywanie tożsamości i bezpieczeństwa

Skonfiguruj połączenie z zasobem Cloud. To jedyny podmiot, który ma stałe fizyczne klucze IAM do odczytywania surowych plików 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

Następnie skonfiguruj profile użytkowników. Użytkownicy mają dostęp logiczny, a nie fizyczny do miejsca na dane. Aby uniknąć błędów spowodowanych opóźnieniami w propagowaniu uprawnień IAM, najpierw utworzysz konta, odczekasz kilka sekund, a potem przypiszesz im role.

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. Tworzenie natywnych tabel Iceberg za pomocą Lakehouse

Do utworzenia zarządzanych tabel Iceberg użyjesz natywnych funkcji Lakehouse.

Utwórz zbiór danych BigQuery

Najpierw utwórz zbiór danych BigQuery, aby logicznie pogrupować tabele Iceberg.

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

Tworzenie tabel Iceberg

Następnie uruchom te polecenia, aby utworzyć tabele. Zwróć uwagę na blok OPTIONS, w którym określamy table_format = 'ICEBERG' i mapujemy go bezpośrednio na nasz zasobnik Cloud Storage i połączenie.

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

Wypełnianie tabel danymi

Na koniec wstaw przykładowe dane do nowo utworzonych tabel Iceberg.

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

Masz teraz 2 w pełni funkcjonalne tabele Iceberg. Lakehouse zarządza metadanymi, ale fizyczne pliki Parquet są bezpiecznie przechowywane w Twoim zasobniku GCS.

Symulowanie potoku ETL

W rzeczywistości surowe dane są często agregowane w tabelach podsumowujących na potrzeby raportowania biznesowego. Wcielmy się w rolę inżyniera danych i utwórzmy tabelę z dziennym podsumowaniem sprzedaży na podstawie nieprzetworzonych danych o transakcjach.

(Uwaga: wykonaj ten krok teraz, aby Google Cloud miał wystarczająco dużo czasu na przetworzenie metadanych w tle. W dalszej części tego przewodnika dowiesz się, dlaczego to jest ważne).

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. Scentralizowane zarządzanie: definiowanie zasad za pomocą języka Python

W środowisku produkcyjnym konfigurowanie zasad zarządzania za pomocą interfejsu użytkownika jest trudne do skalowania i utrzymania. Zamiast tego zdecydowanie zalecamy używanie infrastruktury jako kodu (IaC).

W tej sekcji dowiesz się, jak krok po kroku tworzyć i egzekwować reguły zarządzania oparte na zasadach zerowego zaufania za pomocą pakietu Google Cloud Python SDK.

Konfigurowanie środowiska Pythona

Najpierw skonfigurujmy izolowane środowisko Pythona (venv), aby uniknąć konfliktów bibliotek, i zainstalujmy wymagane pakiety Google Cloud SDK.

Uruchom w Cloud Shell te polecenia:

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

Tworzenie taksonomii i tagu zasad

Taksonomia to logiczny kontener, a tag zasad to konkretna etykieta, którą dołączysz do kolumny zawierającej dane wrażliwe. Aby wymusić zabezpieczenia na poziomie kolumny, musisz najpierw utworzyć kontener logiczny (taksonomię) i konkretną etykietę (tag zasad).

Jeśli zajrzysz do 1_create_taxonomy.py, zobaczysz tę podstawową logikę:

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

Wyraźne ustawienie FINE_GRAINED_ACCESS_CONTROL typu zasady przekształca standardowy tag metadanych w ścisłą granicę bezpieczeństwa opartą na zasadzie zerowego zaufania. Każda kolumna z tym tagiem domyślnie odmawia dostępu wszystkim użytkownikom.

Uruchom skrypt, aby utworzyć zasoby:

python 1_create_taxonomy.py

Konfigurowanie reguły maskowania (zasad dotyczących danych)

Teraz możesz określić, co się stanie, gdy ktoś bez uprawnień zapyta o oznaczoną kolumnę. Utworzysz zasady dotyczące danych, które wymuszą zwracanie wartości NULL, i dołączysz tę regułę do profilu analityka.

W 2_create_masking.py skrypt dynamicznie wyszukuje utworzony właśnie identyfikator tagu zasad i stosuje zasady dotyczące danych:

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

Ten kod automatycznie tworzy regułę, która wymusza zwracanie wartości podstawowych jako NULL. Następnie przypisuje rolę IAM maskedReader konkretnie do profilu analityka, dzięki czemu widzi on tylko zamaskowaną wersję danych.

Uruchom skrypt, aby skonfigurować regułę maskowania:

python 2_create_masking.py

Przyznawanie szczegółowego dostępu

Ze względu na konfigurację opartą na zasadzie zerowego zaufania nikt nie może obecnie odczytać oznaczonej kolumny. Musisz wyraźnie przyznać dostęp do konta menedżera i konta osobistego.

W sekcji 3_grant_access.py możesz zmodyfikować uprawnienia samego tagu zasad:

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

Dodanie roli categoryFineGrainedReader umożliwia tym konkretnym podmiotom zabezpieczeń pomijanie reguł maskowania i odczytywanie nieprzetworzonych, niezasłoniętych danych.

Uruchom skrypt, aby przyznać dostęp:

python 3_grant_access.py

Dołączanie tagu zasad do tabeli BigQuery

Na koniec musisz dołączyć ten logiczny tag zasad do naszego fizycznego schematu tabeli Iceberg.

Sprawdź 4_attach_tag.py. Skrypt pobiera schemat tabeli BigQuery, iteruje po polach i dołącza tag do kolumny 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"])

Po zastosowaniu tej aktualizacji schematu Lakehouse natychmiast połączy logiczne tagi Knowledge Catalog z fizycznymi plikami Parquet przechowywanymi w zasobniku Cloud Storage.

Uruchom skrypt, aby zaktualizować schemat tabeli:

python 4_attach_tag.py

5. Weryfikowanie zasad Knowledge Catalog

Czas sprawdzić, czy nasze scentralizowane zarządzanie działa. Przeprowadzisz testy w 2 różnych wyszukiwarkach, aby udowodnić, że zasady dotyczące Knowledge Catalog są egzekwowane w każdej z nich.

Weryfikacja za pomocą natywnego SQL BigQuery

Najpierw użyjesz Cloud Shell, aby przyjąć tożsamość dwóch osób i wykonać zapytanie dotyczące tabeli za pomocą natywnego silnika SQL BigQuery.

Testowanie jako menedżer (użytkownik uprzywilejowany):

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

Ponieważ konto menedżera ma rolę szczegółowo zdefiniowanego odczytującego, będą na nim wyświetlane wartości kwot w formie surowej.

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

Testowanie jako analityk (użytkownik z ograniczonym dostępem):

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Z powodu reguły maskowania w Knowledge Catalog kolumna kwoty zwraca wartość NULL w każdym wierszu.

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

Przywracanie tożsamości

Wyczyść stan uwierzytelniania Cloud Shell, aby powrócić do użytkownika z uprawnieniami administracyjnymi.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Weryfikacja za pomocą Apache Spark (delegowanie obliczeń)

Co się stanie, jeśli badacz danych użyje Apache Spark do odczytania tej tabeli? Jeśli Spark odczytuje fizyczne pliki Parquet GCS bezpośrednio, reguły maskowania Knowledge Catalog są całkowicie pomijane, ponieważ Cloud Storage rozumie tylko uprawnienia na poziomie zasobnika.

Aby temu zapobiec, możesz wymusić delegowanie obliczeń za pomocą oprogramowania sprzęgającego Spark-BigQuery. To oprogramowanie sprzęgające działa jak bezpieczny pomost, który kieruje żądania odczytu Spark przez interfejs BigQuery Storage API, dzięki czemu reguły zarządzania Knowledge Catalog są dynamicznie oceniane, zanim jakiekolwiek dane zostaną wysłane do klastra Spark.

Przyjrzyj się podstawowej logice skryptu read_transactions.py, który został pobrany:

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

Zwróć uwagę, że nie kierujemy Sparka na ścieżkę gs:// plików Iceberg. Po określeniu .format("bigquery") interfejs BigQuery Storage API przechwytuje żądanie odczytu, sprawdza tożsamość użytkownika wykonującego zadanie Spark, stosuje reguły maskowania Knowledge Catalog i zwraca do ramki danych Spark tylko autoryzowane dane.

Prześlij ten skrypt PySpark do zasobnika Cloud Storage, aby Dataproc mógł uzyskać do niego dostęp:

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

Uruchom Sparka jako menedżera:

Będziesz korzystać z Google Cloud Serverless for Apache Spark. Ta usługa zarządzana umożliwia bezpośrednie uruchamianie zbiorów zadań Spark bez konieczności udostępniania, konfigurowania i zarządzania dedykowanymi klastrami.

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

Sprawdź logi danych wyjściowych zadania w terminalu. Menedżer ma rolę szczegółowego odczytującego, więc Spark pobiera nieprzetworzone, niezasłonięte kwoty.

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

Uruchom Sparka jako analityk:

Teraz prześlij dokładnie to samo zadanie Spark, ale tym razem podszyj się pod analityka.

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

Sprawdź ponownie logi. Analityk uruchomił ten sam kod Sparka, ale interfejs BigQuery Storage API przechwycił żądanie i wymusił zastosowanie zasad Knowledge Catalog. W ramce danych Spark analityka wyświetla null w przypadku kwot.

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

Kompromisy architektoniczne: SQL BigQuery a Spark

Właśnie udowodniłeś, że wynik jest identyczny niezależnie od silnika. Zasady usługi Knowledge Catalog zostały zastosowane. Którego z nich należy jednak używać w środowisku produkcyjnym?

  • BigQuery SQL: idealny w przypadku przepływów pracy, w których pożądany jest silnik SQL, a obliczenia są wykonywane bezpośrednio w miejscu. Jest idealna do szybkiej analizy i analityki biznesowej.
  • Apache Spark: umożliwia obsługę bardziej złożonych zadań dzięki użyciu Pythona, co sprawia, że dobrze nadaje się do zaawansowanych potoków uczenia maszynowego lub starszego kodu Hadoop.

Najważniejsze informacje: niezależnie od używanego silnika, dzięki wymuszaniu delegowania obliczeń nie można pominąć scentralizowanej warstwy zarządzania opartej na zasadzie zerowego zaufania.

6. Automatyczna historia danych

W każdej architekturze danych przedsiębiorstwa kluczowe znaczenie dla zgodności z przepisami, debugowania i budowania zaufania ma dokładna wiedza o tym, skąd pochodzą dane i jak zostały zmienione. To pojęcie jest znane jako pochodzenie danych. Odpowiada na podstawowe pytania, np. „Jeśli menedżer przegląda dzienny raport sprzedaży, które tabele danych pierwotnych zostały użyte do obliczenia tych liczb?”.

Tradycyjnie śledzenie tego cyklu życia wymaga od inżynierów danych ręcznego pisania niestandardowego kodu logowania lub używania złożonych narzędzi innych firm do analizowania skryptów SQL. W zarządzanym Google Cloud Lakehouse śledzenie jest jednak wbudowane i całkowicie automatyczne.

Pamiętasz transactions_summary tabelę utworzoną wcześniej w tym laboratorium z tabeli z surowymi transakcjami? Gdy BigQuery wykonało to polecenie CREATE TABLE AS SELECT, silnik obliczeniowy automatycznie przechwycił metadane przekształcenia i wysłał je do Knowledge Catalog. Zobaczmy wynik.

Wyświetlanie historii danych

  1. W konsoli Google Cloud otwórz Knowledge Catalog > Wyszukiwanie.
  2. Wpisz lakehouse_retail_demo.transactions w pasku wyszukiwania i kliknij tabelę.
  3. Kliknij kartę Pochodzenie.

c890a11d6ea1cca4.png

Zobaczysz interaktywny wykres wygenerowany przez silnik wiedzy, który potwierdza, że tabela docelowa (transactions_summary) została utworzona na podstawie nieprzetworzonej, zarządzanej tabeli Iceberg (transactions). Uzyskasz kompleksową ścieżkę pochodzenia danych, która jest niezbędna do audytu danych.

7. Czyszczenie danych

Aby uniknąć obciążenia konta Google Cloud opłatami za zasoby zużyte w tym samouczku, wykonaj te czynności.

Usuwanie zasobów zarządzania Knowledge Catalog

Zanim usuniesz zbiór danych BigQuery lub zasobnik Cloud Storage, musisz usunąć reguły zarządzania logicznego. Jeśli zajrzysz do skryptu cleanup_governance.py w repozytorium, zobaczysz tę sekwencję:

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

Kolejność ma tu kluczowe znaczenie. Skrypt najpierw usuwa zasady dotyczące danych (regułę maskowania), ponieważ zależą one od tagu zasad. Po usunięciu zasad usunięcie taksonomii nadrzędnej spowoduje automatyczne usunięcie wszystkich tagów zasad bez wywoływania błędów zależności zasobów.

Uruchom skrypt czyszczenia w Pythonie:

python cleanup_governance.py

Usuwanie tożsamości, zasobów pamięci i zasobów obliczeniowych

Po odłączeniu warstwy zarządzania możesz bezpiecznie usunąć tabele BigQuery, zasobniki Cloud Storage, konta usługi i lokalne środowisko Pythona.

Skopiuj i uruchom w Cloud Shell ten blok kompleksowego czyszczenia:

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

Wykonanie tych czynności gwarantuje, że w projekcie nie pozostaną żadne osierocone zasoby ani ukryte zasady.

8. Gratulacje!

Udało Ci się wdrożyć w pełni zarządzany i łatwy do odkrycia Data Lakehouse.

Wiesz już, że:

  • Natywna integracja z Icebergiem: Lakehouse może natywnie zarządzać tabelami Iceberg typu open source, bezpiecznie przechowując pliki fizyczne w Cloud Storage.
  • Delegowanie obliczeń na potrzeby zabezpieczeń: kierując zapytania przez BigQuery Storage API, wymuszasz precyzyjne dynamiczne maskowanie plików fizycznych, które natywnie nie mogą ograniczać częściowego dostępu.
  • Niezależne od silnika zarządzanie: tagi zasad umożliwiają jednokrotne zdefiniowanie reguł i ich uniwersalne egzekwowanie niezależnie od tego, czy zapytanie jest wykonywane za pomocą natywnego SQL czy środowisk wykonawczych Apache Spark.
  • Wykrywalność danych: silnik wiedzy automatycznie śledził historię danych, zapewniając niezbędną możliwość audytu w firmie.

Co dalej?

  • Poznaj zaawansowane opcje kontroli dostępu: aby wdrożyć bardziej złożone scenariusze zabezpieczeń, zapoznaj się z oficjalną dokumentacją dotyczącą dostosowywania Lakehouse za pomocą dodatkowych funkcji.
  • Zarządzanie nieustrukturyzowanymi danymi na potrzeby generatywnej AI: poznaj tabele obiektów. Rozszerz ten wzorzec bezpiecznego mostu na nieuporządkowane pliki (PDF, obrazy) w Cloud Storage, aby utworzyć bezpieczną, zarządzaną bazę danych dla Vertex AI i potoków RAG.