Membangun Lakehouse Iceberg yang Terkelola dengan BigLake dan Dataplex

1. Pengantar

Di Cloud Data perusahaan modern, tempat data berada di berbagai sistem penyimpanan fisik, terdapat tantangan arsitektur besar terkait keamanan yang terfragmentasi.

Bagaimana cara memastikan bahwa data sensitif (seperti jumlah transaksi keuangan) dilindungi secara konsisten saat data disimpan secara fisik dalam format open source seperti Parquet di penyimpanan Google Cloud dan dikueri oleh beberapa mesin yang berbeda, seperti BigQuery SQL atau Apache Spark?

Dalam codelab ini, Anda akan membangun arsitektur Governed Data Lakehouse yang memecahkan masalah ini menggunakan tabel Apache Iceberg, BigQuery, dan Dataplex Universal Catalog. Anda akan menggunakan Infrastructure as Code (IaC) untuk menentukan kebijakan keamanan zero trust dan cara penerapannya secara dinamis di berbagai mesin komputasi.

Prasyarat

Project Google Cloud yang mengaktifkan penagihan.
Pemahaman dasar tentang konsep SQL, IAM, dan Cloud Storage.

Yang akan Anda pelajari

Cara membuat tabel BigLake untuk Apache Iceberg di BigQuery tempat Cloud Storage secara native menyimpan data.
Cara menerapkan kebijakan data terpusat menggunakan Tag Kebijakan untuk keamanan tingkat kolom dan data masking.
Cara memisahkan akses penyimpanan fisik dari akses data logis menggunakan Koneksi resource Cloud.
Cara menerapkan delegasi komputasi Zero-Trust menggunakan Google Cloud Serverless untuk Apache Spark guna memastikan mesin open source tidak dapat melewati tata kelola.
Cara memvisualisasikan Silsilah Data otomatis.

Ringkasan arsitektur: Tata kelola universal di Iceberg

Untuk mencapai kontrol akses terperinci (seperti keamanan tingkat kolom dan penyamaran data) pada format data open source, Anda harus membuat arsitektur keamanan yang ketat dan terpadu.

Seperti yang diilustrasikan dalam diagram, pola lakehouse yang diatur ini mengandalkan dua pilar utama untuk mengatasi tantangan keamanan yang terfragmentasi:

🛡️ Lapisan Arsitektur yang Aman (Kiri)

Daripada mengizinkan pengguna atau mesin eksternal mengakses Cloud Storage secara langsung—yang hanya mendukung keamanan level bucket yang luas: Anda membangun fondasi yang aman.

Format terbuka, metadata terkelola: Data secara fisik tetap berada di Cloud Storage menggunakan format Apache Iceberg (Parquet) terbuka, sementara BigLake mengelola metadata yang mengatur secara lancar.
Batas keamanan logis: Anda memisahkan akses penyimpanan fisik dari akses data logis menggunakan koneksi resource Cloud yang aman. Pengguna akhir tidak pernah diberi akses IAM fisik langsung ke file GCS mentah.
Delegasi komputasi zero-trust: Untuk memastikan tidak ada mesin eksekusi yang dapat melewati aturan tata kelola, semua permintaan pembacaan data dirutekan secara ketat melalui BigQuery Storage API. Hal ini berlaku baik kueri berasal dari SQL BigQuery native maupun Apache Spark open source.

🎯 Penegakan Kebijakan Terpusat (Kanan)

Dengan fondasi yang aman, Dataplex berfungsi sebagai otak terpadu untuk tata kelola:

Tentukan sekali, terapkan di mana saja: Anda hanya perlu menentukan Tag Kebijakan di Dataplex satu kali, dan arsitektur akan menerapkan aturan penyamaran yang konsisten secara universal di semua runtime eksekusi yang didukung.
Penyamaran data dinamis: Saat data dikueri, sistem akan mengevaluasi identitas pengguna secara langsung. Meskipun pengguna yang diberi otorisasi akan melihat nilai mentah yang tidak disamarkan (misalnya, 100.0) di SQL dan Spark, pengguna yang dibatasi akan otomatis menerima nilai NULL yang disamarkan untuk kolom yang dibatasi di kedua mesin.
Silsilah data otomatis: Saat data mengalir dan bertransformasi, Dataplex secara otomatis merekam metadata transformasi, sehingga memberikan auditabilitas dan ketertelusuran end-to-end bawaan tanpa memerlukan kode logging kustom.

2. Penyiapan dan persyaratan

Mulai Cloud Shell

Meskipun Google Cloud dapat dioperasikan dari jarak jauh menggunakan laptop Anda, dalam codelab ini, Anda akan menggunakan Google Cloud Shell, lingkungan command line yang berjalan di Cloud.

Dari Google Cloud Console, klik ikon Cloud Shell di toolbar kanan atas:

Mengaktifkan Cloud Shell

Hanya perlu waktu beberapa saat untuk penyediaan dan terhubung ke lingkungan. Jika sudah selesai, Anda akan melihat tampilan seperti ini:

Screenshot terminal Google Cloud Shell yang menunjukkan bahwa lingkungan telah terhubung

Mesin virtual ini berisi semua alat pengembangan yang Anda perlukan. Layanan ini menawarkan direktori beranda tetap sebesar 5 GB dan beroperasi di Google Cloud, sehingga sangat meningkatkan performa dan autentikasi jaringan. Semua pekerjaan Anda dalam codelab ini dapat dilakukan di browser. Anda tidak perlu menginstal apa pun.

Lakukan inisialisasi lingkungan

Buka Cloud Shell dan tetapkan variabel project Anda untuk memastikan semua perintah menargetkan infrastruktur yang benar.

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"

Kemudian, tentukan dua persona kita.

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)

Aktifkan API

Aktifkan layanan Google Cloud yang diperlukan.

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

Download kode sumber Codelab

Agar tidak membuat Cloud Shell Anda berantakan, Anda akan melakukan sparse checkout untuk mendownload hanya skrip Python yang diperlukan untuk codelab ini dari repositori 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

Membuat penyimpanan

Buat bucket untuk menyimpan data Iceberg yang diatur dan sangat aman.

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

Menyiapkan identitas & keamanan

Konfigurasi koneksi resource cloud. Entitas ini adalah satu-satunya entitas yang memiliki kunci IAM fisik permanen untuk membaca file Iceberg mentah.

# 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

Selanjutnya, siapkan persona pengguna. Pengguna diberi akses logis, bukan akses penyimpanan fisik. Untuk mencegah error yang disebabkan oleh penundaan propagasi IAM, Anda akan membuat akun terlebih dahulu, menunggu beberapa detik, lalu menetapkan perannya.

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. Membuat tabel Iceberg native melalui BigLake

Anda akan menggunakan kemampuan native BigLake untuk membuat tabel Iceberg terkelola.

Buat Set Data BigQuery

Pertama, buat set data BigQuery untuk mengelompokkan tabel Iceberg secara logis.

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

Buat tabel Iceberg

Selanjutnya, jalankan perintah berikut untuk membuat tabel. Perhatikan blok OPTIONS tempat kita menentukan table_format = 'ICEBERG' dan memetakannya langsung ke bucket dan koneksi Cloud Storage kita.

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

Mengisi tabel dengan data

Terakhir, masukkan data sampel ke dalam tabel Iceberg yang baru dibuat.

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

Sekarang Anda memiliki dua tabel Iceberg yang berfungsi penuh. BigLake mengelola metadata, tetapi file Parquet fisik berada dengan aman di bucket GCS Anda.

Menyimulasikan Pipeline ETL

Dalam skenario dunia nyata, data mentah sering kali digabungkan ke dalam tabel ringkasan untuk pelaporan bisnis. Mari kita bertindak sebagai data engineer dan membuat tabel ringkasan penjualan harian dari data transaksi mentah kita.

(Catatan: jalankan langkah ini sekarang agar Google Cloud memiliki cukup waktu untuk memproses metadata latar belakang. Anda akan mengetahui pentingnya hal ini nanti dalam codelab ini.)

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. Tata kelola terpusat: Menentukan kebijakan menggunakan Python

Di lingkungan produksi, mengonfigurasi kebijakan tata kelola melalui UI sulit diskalakan dan dikelola. Sebagai gantinya, sangat disarankan untuk menggunakan Infrastructure as Code (IaC).

Di bagian ini, Anda akan menggunakan Google Cloud Python SDK untuk membuat dan menerapkan aturan tata kelola Zero Trust secara terprogram langkah demi langkah.

Menyiapkan Lingkungan Python

Pertama, siapkan lingkungan Python yang terisolasi (venv) untuk menghindari konflik library dan instal Google Cloud SDK yang diperlukan.

Jalankan perintah berikut di 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!"

Buat Taksonomi dan Tag Kebijakan

Taksonomi adalah penampung logis, dan Tag Kebijakan adalah label spesifik yang akan Anda lampirkan ke kolom sensitif kami. Untuk menerapkan keamanan tingkat kolom, Anda memerlukan container logis (Taksonomi) dan label tertentu (Tag Kebijakan) terlebih dahulu.

Jika melihat ke dalam 1_create_taxonomy.py, Anda akan melihat logika inti berikut:

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

Dengan menetapkan jenis kebijakan FINE_GRAINED_ACCESS_CONTROL secara eksplisit, Anda mengubah tag metadata standar menjadi batas keamanan zero-trust yang ketat. Kolom apa pun dengan tag ini akan menolak akses ke semua pengguna secara default.

Jalankan skrip untuk membuat resource:

python 1_create_taxonomy.py

Mengonfigurasi Aturan Penyamaran (Kebijakan Data)

Sekarang, Anda menentukan apa yang terjadi saat seseorang tanpa hak istimewa membuat kueri kolom yang diberi tag. Anda akan membuat Kebijakan Data yang memaksa nilai ditampilkan sebagai NULL dan melampirkan aturan ini ke persona Analis.

Di dalam 2_create_masking.py, skrip secara dinamis mencari ID Tag Kebijakan yang baru saja Anda buat dan menerapkan kebijakan data:

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

Kode ini membuat aturan secara terprogram yang memaksa nilai pokok ditampilkan sebagai NULL. Kemudian, IAM menetapkan peran maskedReader secara khusus ke persona Analis, sehingga memastikan bahwa mereka hanya melihat versi data yang disamarkan.

Jalankan skrip untuk mengonfigurasi aturan penyamaran:

python 2_create_masking.py

Memberikan Akses Terperinci

Karena penyiapan zero-trust kami, saat ini tidak ada yang dapat membaca kolom yang diberi tag. Anda harus memberikan akses secara eksplisit ke pengelola dan akun pribadi Anda.

Di dalam 3_grant_access.py, Anda mengubah kebijakan IAM Tag Kebijakan itu sendiri:

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

Menambahkan peran categoryFineGrainedReader memungkinkan akun utama tertentu ini melewati aturan penyamaran dan membaca data mentah yang tidak disamarkan.

Jalankan skrip untuk memberikan akses:

python 3_grant_access.py

Melampirkan Tag Kebijakan ke Tabel BigQuery

Terakhir, Anda harus melampirkan Tag Kebijakan logis ini ke skema tabel Iceberg fisik kami.

Lihat 4_attach_tag.py. Skrip mengambil skema tabel BigQuery, melakukan iterasi melalui kolom, dan melampirkan tag secara khusus ke kolom 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"])

Saat pembaruan skema ini diterapkan, BigLake akan langsung menghubungkan tag logis Dataplex kita ke file Parquet fisik yang disimpan di bucket Cloud Storage Anda.

Jalankan skrip untuk memperbarui skema tabel:

python 4_attach_tag.py

5. Memverifikasi Kebijakan Dataplex

Sekarang saatnya menguji apakah tata kelola terpusat kita berfungsi. Anda akan mengujinya di dua mesin yang berbeda untuk membuktikan bahwa kebijakan Dataplex diberlakukan secara universal.

Memverifikasi menggunakan SQL native BigQuery

Pertama, Anda akan menggunakan Cloud Shell untuk mengasumsikan identitas dua persona kami dan membuat kueri tabel menggunakan mesin SQL native BigQuery.

Uji sebagai Pengelola (Pengguna istimewa):

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

Karena pengelola memiliki peran Fine-Grained Reader, nilai jumlah mentah akan ditampilkan

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

Pengujian sebagai analis (Pengguna terbatas):

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

Karena aturan penyamaran Dataplex, kolom jumlah ditampilkan sebagai NULL untuk setiap baris.

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

Memulihkan identitas Anda

Bersihkan status autentikasi Cloud Shell Anda untuk kembali ke pengguna admin Anda.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

Memverifikasi menggunakan Apache Spark (Delegasi komputasi)

Bagaimana jika Data Scientist menggunakan Apache Spark untuk membaca tabel ini? Jika Spark membaca file Parquet GCS fisik secara langsung, aturan masking Dataplex akan sepenuhnya dilewati karena Cloud Storage hanya memahami izin tingkat bucket.

Untuk mencegah hal ini, Anda menerapkan delegasi komputasi menggunakan Konektor Spark-BigQuery. Konektor ini berfungsi sebagai jembatan yang aman, yang merutekan permintaan baca Spark melalui BigQuery Storage API sehingga aturan tata kelola Dataplex dievaluasi secara dinamis sebelum data apa pun dikirim ke cluster Spark.

Lihat logika inti di dalam skrip read_transactions.py yang Anda 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)

Perhatikan bahwa kita tidak mengarahkan Spark ke jalur gs:// file Iceberg. Dengan menentukan .format("bigquery"), BigQuery Storage API akan mencegat permintaan baca, memeriksa identitas pengguna yang menjalankan tugas Spark, menerapkan aturan penyamaran Dataplex, dan hanya menampilkan data yang diotorisasi kembali ke DataFrame Spark.

Upload skrip PySpark ini ke bucket Cloud Storage Anda agar Dataproc dapat mengaksesnya:

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

Jalankan Spark sebagai pengelola:

Anda akan menggunakan Google Cloud Serverless untuk Apache Spark. Dengan layanan terkelola ini, Anda dapat menjalankan workload Spark secara langsung tanpa perlu menyediakan, mengonfigurasi, atau mengelola cluster khusus.

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

Lihat log output tugas di terminal. Karena pengelola memiliki peran Fine-Grained Reader, Spark berhasil mengambil jumlah mentah yang tidak disamarkan.

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

Jalankan Spark sebagai analis:

Sekarang, kirimkan tugas Spark yang sama persis, tetapi kali ini tirukan persona analis.

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

Periksa log lagi. Meskipun analis menjalankan kode Spark yang sama persis, BigQuery Storage API mencegat permintaan dan menerapkan kebijakan Dataplex. DataFrame Spark analis menampilkan null untuk jumlahnya.

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

Trade-off Arsitektur: BigQuery SQL vs. Spark

Anda baru saja membuktikan bahwa hasilnya identik, terlepas dari mesinnya. Kebijakan Dataplex berhasil diterapkan. Namun, dalam produksi, mana yang harus Anda gunakan?

SQL BigQuery: Sangat cocok untuk alur kerja yang menggunakan SQL sebagai mesin yang diinginkan dan menjalankan komputasi secara langsung di tempat. Ideal untuk analisis cepat dan Business Intelligence.
Apache Spark: Memungkinkan workload yang lebih kompleks karena menggunakan Python, sehingga cocok untuk pipeline Machine Learning tingkat lanjut atau kode Hadoop lama.

Kesimpulan Penting: Terlepas dari mesin yang digunakan, dengan menerapkan delegasi komputasi, lapisan tata kelola zero-trust terpusat tidak akan pernah dapat dilewati.

6. Silsilah data otomatis

Dalam arsitektur data perusahaan apa pun, mengetahui persis dari mana data Anda berasal dan bagaimana data tersebut telah diubah sangat penting untuk kepatuhan, proses debug, dan membangun kepercayaan. Konsep ini dikenal sebagai Silsilah Data. Hal ini menjawab pertanyaan mendasar seperti: "Jika seorang manajer melihat laporan penjualan harian, tabel mentah mana yang digunakan untuk menghitung angka tersebut?"

Biasanya, pelacakan siklus proses ini mengharuskan engineer data menulis kode logging kustom secara manual atau menggunakan alat pihak ketiga yang kompleks untuk mengurai skrip SQL. Namun, di Google Cloud Lakehouse yang terkelola, pelacakan ini bersifat bawaan dan sepenuhnya otomatis.

Ingat tabel transactions_summary yang Anda buat dari tabel transaksi mentah sebelumnya di codelab? Saat BigQuery menjalankan pernyataan CREATE TABLE AS SELECT tersebut, mesin komputasi akan otomatis mengambil metadata transformasi dan mengirimkannya ke Dataplex. Mari kita lihat hasilnya.

Memvisualisasikan silsilah

Di Konsol Google Cloud, buka Dataplex universal catalog > Search.
Ketik lakehouse_retail_demo.transactions di kotak penelusuran, lalu klik tabel.
Klik tab Silsilah.

Anda akan melihat grafik interaktif yang dihasilkan oleh Dataplex Knowledge Engine yang membuktikan bahwa tabel target (transactions_summary) berasal dari tabel Iceberg mentah yang diatur (transactions). Anda telah mencapai ketertelusuran menyeluruh yang penting untuk audit data.

7. Pembersihan

Agar tidak menimbulkan biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam codelab ini, ikuti langkah-langkah berikut.

Menghapus resource tata kelola Dataplex

Sebelum menghapus set data BigQuery atau bucket Cloud Storage, Anda harus menghapus aturan tata kelola logis. Jika melihat di dalam skrip cleanup_governance.py dari repositori, Anda akan melihat urutan penonaktifan berikut:

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

Urutan di sini sangat penting. Skrip pertama-tama menghapus Kebijakan Data (aturan penyamaran) karena bergantung pada Tag Kebijakan. Setelah kebijakan dihapus, penghapusan Taksonomi induk akan otomatis berjenjang dan menghapus semua Tag Kebijakan yang mendasarinya tanpa memicu error dependensi resource.

Jalankan skrip pembersihan Python:

python cleanup_governance.py

Menghapus aset identitas, penyimpanan, dan komputasi

Setelah lapisan tata kelola dilepas, Anda dapat menghapus tabel BigQuery, bucket Cloud Storage, Akun Layanan, dan lingkungan Python lokal dengan aman.

Salin dan jalankan blok pembersihan komprehensif berikut di Cloud Shell Anda:

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

Dengan menyelesaikan langkah-langkah ini, Anda telah memastikan tidak ada resource yang tidak terkait atau kebijakan tersembunyi yang tersisa di project Anda.

8. Selamat!

Anda telah berhasil menerapkan Data Lakehouse yang sepenuhnya diatur dan dapat ditemukan.

Anda telah mempelajari bahwa:

Integrasi Iceberg native: BigLake dapat mengelola tabel Iceberg open source secara native sambil menyimpan file fisik dengan aman di Cloud Storage.
Delegasi komputasi untuk keamanan: Dengan merutekan kueri melalui BigQuery Storage API, Anda menerapkan masking dinamis terperinci pada file fisik yang secara native tidak dapat membatasi akses sebagian.
Tata Kelola Agnostik Mesin: Tag Kebijakan memungkinkan Anda menentukan aturan satu kali dan menerapkannya secara universal, baik saat dikueri melalui runtime SQL native atau Apache Spark.
Kemampuan penemuan data: Mesin Pengetahuan Dataplex secara otomatis melacak silsilah data, sehingga memberikan auditabilitas perusahaan yang penting.

Apa selanjutnya?

Jelajahi kontrol akses lanjutan: Untuk menerapkan skenario keamanan yang lebih kompleks, tinjau dokumentasi resmi tentang menyesuaikan BigLake dengan fitur tambahan.
Mengatur data tidak terstruktur untuk GenAI: Temukan Tabel Objek BigLake. Perluas pola jembatan Secure yang sama persis ini ke file tidak terstruktur (PDF, gambar) di Cloud Storage, dengan membangun fondasi data yang aman dan dikelola untuk pipeline Vertex AI dan RAG.