إنشاء مستودع بيانات Iceberg مُدار باستخدام BigLake وDataplex

1. مقدمة

في "سحابة بيانات" حديثة للمؤسسات، حيث تتوفّر البيانات على مستوى أنظمة تخزين فعلية مختلفة، يواجه المستخدمون تحديًا كبيرًا في تصميم بنية الأمان المجزّأة.

كيف تضمن حماية البيانات الحسّاسة (مثل مبالغ المعاملات المالية) بشكل متّسق عند تخزين البيانات فعليًا بتنسيقات مفتوحة المصدر، مثل Parquet على مساحة تخزين Google Cloud، والاستعلام عنها من خلال محركات مختلفة متعددة، مثل BigQuery SQL أو Apache Spark؟

في هذا الدرس التطبيقي حول الترميز، ستنشئ بنية بحيرة بيانات منظَّمة تحلّ هذه المشاكل باستخدام جداول Apache Iceberg وBigQuery وكتالوج Dataplex الشامل. ستستخدم البنية الأساسية كرمز (IaC) لتحديد سياسات الأمان التي لا تثق بأي جهاز، وكيفية فرضها بشكل ديناميكي على محركات الحوسبة المختلفة.

المتطلبات الأساسية

مشروع Google Cloud تم تفعيل الفوترة فيه
فهم أساسي لمفاهيم SQL و"إدارة الهوية وإمكانية الوصول" وCloud Storage

ما ستتعلمه

كيفية إنشاء جداول BigLake بتنسيق Apache Iceberg في BigQuery حيث يتم تخزين البيانات في Cloud Storage بشكلٍ أصلي
كيفية فرض سياسات بيانات مركزية باستخدام علامات السياسة للأمان على مستوى الأعمدة وإخفاء البيانات
كيفية فصل الوصول إلى مساحة التخزين الفعلية عن الوصول إلى البيانات المنطقية باستخدام ربط موارد السحابة الإلكترونية
كيفية فرض تفويض الحوسبة بنهج الثقة المعدومة باستخدام الحوسبة بدون خادم من Google Cloud لـ Apache Spark لضمان عدم إمكانية تجاوز الإدارة من خلال المحركات مفتوحة المصدر
كيفية عرض مصدر البيانات المبرمَج

نظرة عامة على البنية: الإدارة الشاملة على Iceberg

لتحقيق تحكّم دقيق في الوصول (مثل الأمان على مستوى الأعمدة وإخفاء البيانات) في تنسيقات البيانات المفتوحة المصدر، يجب إنشاء بنية أمان موحّدة وصارمة.

كما هو موضّح في الرسم البياني، يعتمد نمط مستودع البيانات الخاضع للإدارة هذا على ركيزتَين أساسيتَين لحلّ مشكلة الأمان المجزّأ:

🛡️ طبقات البنية الآمنة (على اليمين)

بدلاً من السماح للمستخدمين أو المحرّكات الخارجية بالوصول إلى Cloud Storage مباشرةً، الذي يتيح فقط أمانًا واسع النطاق على مستوى الحزمة، يمكنك إنشاء أساس آمن.

تنسيق مفتوح، بيانات وصفية مُدارة: تبقى البيانات فعليًا في Cloud Storage باستخدام تنسيق Apache Iceberg (Parquet) المفتوح، بينما تدير BigLake البيانات الوصفية الحاكمة بسلاسة.
حدود الأمان المنطقي: يمكنك فصل الوصول إلى التخزين الفعلي عن الوصول إلى البيانات المنطقية باستخدام اتصال آمن بمورد على السحابة الإلكترونية. لا يتم منح المستخدمين النهائيين إذن وصول مادي مباشر إلى ملفات GCS الأولية.
تفويض الحساب بدون ثقة: لضمان عدم تمكّن أي محرك تنفيذ من تجاوز قواعد الحوكمة، يتم توجيه جميع طلبات قراءة البيانات بدقة من خلال BigQuery Storage API. وينطبق ذلك سواء كان مصدر طلب البحث هو لغة SQL الأصلية في BigQuery أو Apache Spark مفتوح المصدر.

🎯 تنفيذ السياسات بشكل مركزي (صحيح)

بعد توفير الأساس الآمن، يعمل Dataplex كمركز موحّد للإدارة:

التعريف مرة واحدة والفرض في كل مكان: يمكنك تحديد "علامات السياسة" في Dataplex مرة واحدة، وتطبّق البنية قواعد إخفاء متسقة على مستوى جميع أوقات تشغيل التنفيذ المتوافقة.
إخفاء البيانات الديناميكي: عند طلب البيانات، يقيّم النظام هوية المستخدم في الوقت الفعلي. بينما يرى المستخدمون المصرّح لهم القيم الأولية غير المخفية (مثل 100.0) في كلّ من SQL وSpark، سيتلقّى المستخدمون الذين لديهم أذونات محدودة تلقائيًا قيم NULL مخفية للأعمدة المحظورة في كلّ من المحرّكين.
تتبُّع مصدر البيانات المبرمَج: أثناء تدفّق البيانات وتحويلها، يسجّل Dataplex تلقائيًا البيانات الوصفية للتحويل، ما يوفّر إمكانية تدقيق وتتبُّع مدمجة من البداية إلى النهاية بدون الحاجة إلى رمز تسجيل مخصّص.

2. الإعداد والمتطلبات

بدء Cloud Shell

على الرغم من إمكانية تشغيل Google Cloud عن بُعد من الكمبيوتر المحمول، ستستخدم في هذا الدرس التطبيقي حول الترميز Google Cloud Shell، وهي بيئة سطر أوامر تعمل في السحابة الإلكترونية.

من Google Cloud Console، انقر على رمز Cloud Shell في شريط الأدوات أعلى يسار الصفحة:

تفعيل Cloud Shell

لن يستغرق توفير البيئة والاتصال بها سوى بضع لحظات. عند الانتهاء، من المفترض أن يظهر لك ما يلي:

لقطة شاشة لواجهة سطر الأوامر في Google Cloud Shell توضّح أنّه تم ربط البيئة

يتم تحميل هذه الآلة الافتراضية مزوّدة بكل أدوات التطوير التي ستحتاج إليها. توفّر هذه الخدمة دليلًا منزليًا ثابتًا بسعة 5 غيغابايت، وتعمل على Google Cloud، ما يؤدي إلى تحسين أداء الشبكة والمصادقة بشكل كبير. يمكن إكمال جميع المهام في هذا الدرس العملي ضمن المتصفّح. لست بحاجة إلى تثبيت أي تطبيق.

إعداد البيئة

افتح Cloud Shell واضبط متغيرات مشروعك لضمان استهداف جميع الأوامر للبنية الأساسية الصحيحة.

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"

بعد ذلك، حدِّد شخصيتَي المستخدمين.

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)

تفعيل واجهات برمجة التطبيقات

فعِّل خدمات 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

تنزيل رمز المصدر للدرس التطبيقي حول الترميز

لتجنُّب إرباك Cloud Shell، ستنفّذ استخراجًا جزئيًا لتنزيل نصوص Python البرمجية اللازمة لهذا الدرس التطبيقي حول الترميز فقط من مستودع 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

إنشاء مساحة تخزين

أنشئ الحزمة لتخزين بيانات Iceberg المحكومة الآمنة للغاية.

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

إعداد الهويات والأمان

ضبط اتصال مورد السحابة الإلكترونية وهي الجهة الوحيدة التي تحتفظ بمفاتيح إدارة الهوية وإمكانية الوصول المادية الدائمة لقراءة ملفات 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

بعد ذلك، عليك إعداد شخصيات المستخدمين. يتم منح المستخدمين إذن الوصول المنطقي، وليس إذن الوصول إلى مساحة التخزين الفعلية. لتجنُّب الأخطاء الناتجة عن تأخُّر نشر إدارة الهوية وإمكانية الوصول (IAM)، عليك إنشاء الحسابات أولاً، والانتظار لبضع ثوانٍ، ثم تعيين أدوارها.

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- إنشاء جداول Iceberg أصلية من خلال BigLake

ستستخدم إمكانات BigLake الأصلية لإنشاء جداول Iceberg المُدارة.

إنشاء مجموعة بيانات BigQuery

أولاً، أنشئ مجموعة بيانات BigQuery لتجميع جداول Iceberg منطقيًا.

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

إنشاء جداول Iceberg

بعد ذلك، نفِّذ الأوامر التالية لإنشاء الجداول. لاحظوا الحقل OPTIONS حيث نحدّد table_format = 'ICEBERG' ونربطه مباشرةً بحزمة Cloud Storage وعملية الربط.

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

تعبئة الجداول بالبيانات

أخيرًا، أدخِل بيانات نموذجية في جداول 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');"

أصبح لديك الآن جدولان من جداول Iceberg يعملان بالكامل. تتولّى BigLake إدارة البيانات الوصفية، ولكن يتم تخزين ملفات Parquet الفعلية بأمان في حزمة GCS.

محاكاة مسار ETL

في سيناريو من العالم الواقعي، غالبًا ما يتم تجميع البيانات الأولية في جداول ملخّصة لإعداد تقارير النشاط التجاري. لنفترض أنّنا مهندسو بيانات وننشئ جدولاً موجزًا يوميًا للمبيعات من بيانات المعاملات الأولية.

(ملاحظة: نفِّذ هذه الخطوة الآن لكي يتوفّر لدى Google Cloud الوقت الكافي لمعالجة البيانات الوصفية في الخلفية. ستتعرّف على أهمية ذلك لاحقًا في هذا الدرس العملي.)

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. الإدارة المركزية: تحديد السياسات باستخدام Python

في بيئة الإنتاج، يصعب توسيع نطاق سياسات الحوكمة والحفاظ عليها من خلال واجهة المستخدم. بدلاً من ذلك، يُنصح بشدة باستخدام "البنية الأساسية كرمز" (IaC).

في هذا القسم، ستستخدم حزمة تطوير البرامج (SDK) من Google Cloud Python لإنشاء قواعد إدارة نهج الثقة المعدومة وتنفيذها خطوة بخطوة بشكل آلي.

إعداد بيئة Python

أولاً، لنقم بإعداد بيئة Python معزولة (venv) لتجنُّب تعارض المكتبات وتثبيت حِزم تطوير البرامج (SDK) المطلوبة من Google Cloud.

نفِّذ الأوامر التالية في 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!"

إنشاء التصنيف وعلامة السياسة

التصنيف هو حاوية منطقية، وعلامة السياسة هي التصنيف المحدّد الذي ستضيفه إلى العمود الحسّاس. لفرض الأمان على مستوى الأعمدة، تحتاج أولاً إلى حاوية منطقية (تصنيف) وتصنيف محدّد (تصنيف سياسة).

إذا نظرت إلى داخل 1_create_taxonomy.py، سيظهر لك منطق أساسي على النحو التالي:

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

من خلال ضبط نوع السياسة FINE_GRAINED_ACCESS_CONTROL بشكلٍ صريح، يمكنك تحويل علامة بيانات وصفية عادية إلى حدود أمان صارمة لا تثق بأي شيء. سيؤدي استخدام هذه العلامة في أي عمود إلى حظر وصول جميع المستخدمين إليه تلقائيًا.

نفِّذ النص البرمجي لإنشاء الموارد:

python 1_create_taxonomy.py

ضبط قاعدة الإخفاء (سياسة البيانات)

الآن، عليك تحديد ما يحدث عندما يستعلم مستخدم ليس لديه امتيازات عن العمود الذي تم وضع علامة عليه. ستنشئ سياسة بيانات تفرض عرض القيمة على النحو NULL، وتربط هذه القاعدة بشخصية المحلّل.

داخل 2_create_masking.py، يبحث النص البرمجي ديناميكيًا عن معرّف علامة السياسة الذي أنشأته للتوّ ويطبّق سياسة بيانات:

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

تنشئ هذه التعليمات البرمجية قاعدة آليًا تفرض عرض القيم الأساسية كقيمة NULL. بعد ذلك، يتمّ منح دور maskedReader في "إدارة الهوية وإمكانية الوصول" لشخصية المحلّل تحديدًا، ما يضمن عدم رؤية سوى النسخة المخفية من البيانات.

نفِّذ النص البرمجي لضبط قاعدة الإخفاء:

python 2_create_masking.py

منح إذن وصول دقيق

بسبب إعداداتنا التي لا تثق بأي مستخدم، لا يمكن لأحد قراءة العمود الذي تم وضع علامة عليه في الوقت الحالي. يجب منح إذن الوصول إلى الحساب الإداري وحسابك الشخصي بشكلٍ صريح.

داخل 3_grant_access.py، يمكنك تعديل سياسة "إدارة الهوية وإمكانية الوصول" الخاصة بـ "علامة السياسة" نفسها:

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

تتيح إضافة دور categoryFineGrainedReader لهؤلاء الجهات الرئيسية المحدّدة تجاوز قواعد إخفاء الهوية وقراءة البيانات الأولية غير المخفية.

شغِّل النص البرمجي لمنح إذن الوصول:

python 3_grant_access.py

ربط علامة السياسة بجدول BigQuery

أخيرًا، يجب إرفاق "علامة السياسة" المنطقية هذه بمخطط جدول Iceberg الفعلي.

ألقِ نظرة على 4_attach_tag.py. يجلب النص البرمجي مخطط جدول BigQuery، ويتكرر خلال الحقول، ويربط العلامة بالعمود 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"])

عند تطبيق تعديل المخطط هذا، يربط BigLake على الفور العلامات المنطقية في Dataplex بملفات Parquet الفعلية المخزَّنة في حزمة Cloud Storage.

نفِّذ النص البرمجي لتعديل مخطط الجدول:

python 4_attach_tag.py

5- التحقّق من سياسات Dataplex

حان الوقت لاختبار ما إذا كانت الحوكمة المركزية فعّالة. ستختبر ذلك على محركَين مختلفَين لإثبات أنّ سياسات Dataplex يتم تطبيقها على مستوى العالم.

التحقّق باستخدام لغة SQL الأصلية في BigQuery

أولاً، ستستخدم Cloud Shell لتولّي هوية الشخصيتَين واستعلام الجدول باستخدام محرّك SQL الأصلي في BigQuery.

الاختبار بصفتك "المشرف" (مستخدم لديه امتيازات):

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

بما أنّ المدير لديه دور "قارئ دقيق"، سيتم عرض قيم المبالغ الأولية

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

الاختبار بصفتك محلّلاً (مستخدمًا محدود الوصول):

gcloud config set auth/impersonate_service_account ${EMAIL_ANALYST}

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

بسبب قاعدة إخفاء البيانات في Dataplex، يعرض عمود "المبلغ" القيمة NULL لكل صف.

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

استعادة هويتك

نظِّف حالة مصادقة Cloud Shell للعودة إلى حساب المستخدم الإداري.

# Unset impersonation
gcloud config unset auth/impersonate_service_account

التحقّق باستخدام Apache Spark (تفويض الحساب)

ماذا لو استخدم أحد علماء البيانات Apache Spark لقراءة هذا الجدول؟ إذا قرأ Spark ملفات Parquet الفعلية في GCS مباشرةً، سيتم تجاوز قواعد إخفاء البيانات في Dataplex بالكامل لأنّ Cloud Storage لا يفهم سوى أذونات مستوى الحزمة.

لمنع حدوث ذلك، يمكنك فرض تفويض الحوسبة باستخدام موصّل Spark-BigQuery. يعمل موصّل البيانات هذا كجسر آمن، حيث يوجّه طلبات القراءة في Spark من خلال BigQuery Storage API ليتم تقييم قواعد إدارة Dataplex بشكلٍ ديناميكي قبل إرسال أي بيانات إلى مجموعة Spark.

ألقِ نظرة على المنطق الأساسي داخل النص البرمجي read_transactions.py الذي نزّلته:

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

لاحظ أنّنا لا نشير إلى Spark بمسار gs:// لملفات Iceberg. من خلال تحديد .format("bigquery")، تعترض BigQuery Storage API طلب القراءة، وتتحقّق من هوية المستخدم الذي ينفّذ مهمة Spark، وتطبّق قواعد إخفاء البيانات في Dataplex، ولا تعرض سوى البيانات المصرّح بها في إطار بيانات Spark.

حمِّل نص PySpark البرمجي هذا إلى حزمة Cloud Storage ليتمكّن Dataproc من الوصول إليه:

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

تشغيل Spark كمدير:

ستستخدم الحوسبة بدون خادم من Google Cloud لـ Apache Spark. تتيح لك هذه الخدمة المُدارة تشغيل أحمال عمل Spark مباشرةً بدون الحاجة إلى توفير مجموعات مخصّصة أو ضبطها أو إدارتها.

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

اطّلِع على سجلّات ناتج المهمة في نافذة المحطة الطرفية. بما أنّ المدير لديه دور "قارئ" دقيق، يستردّ Spark المبالغ الأولية غير المخفية بنجاح.

=== 📊 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 بصفتك المحلل:

الآن، أرسِل مهمة Spark نفسها تمامًا، ولكن هذه المرة بصفتك محلّل البيانات.

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

يُرجى التحقّق من السجلّات مرة أخرى. على الرغم من أنّ المحلّل نفّذ رمز Spark نفسه بالضبط، اعترضت واجهة برمجة التطبيقات BigQuery Storage API الطلب وفرضت سياسة Dataplex. يعرض Spark DataFrame الخاص بالمحلّل null للمبالغ.

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

المفاضلات المعمارية: BigQuery SQL مقابل Spark

لقد أثبتّ للتو أنّ النتيجة متطابقة بغض النظر عن المحرك. تم تطبيق سياسة Dataplex بنجاح. ولكن في مرحلة الإنتاج، أيّهما يجب استخدامه؟

BigQuery SQL: مناسبة لسير العمل التي تكون فيها SQL هي المحرّك المطلوب وتنفّذ العمليات الحسابية مباشرةً في مكانها. وهي مثالية لإجراء إحصاءات سريعة وذكاء الأعمال.
Apache Spark: تتيح إمكانية تنفيذ مهام أكثر تعقيدًا من خلال استخدام Python، ما يجعلها مناسبة تمامًا لعمليات تعلُّم الآلة المتقدّمة أو رمز Hadoop القديم.

الخلاصة: بغض النظر عن المحرّك المستخدَم، لا يمكن تجاوز طبقة إدارة الحوكمة المركزية التي تعتمد نهج الثقة المعدومة من خلال فرض تفويض الحوسبة.

6. تتبُّع سير البيانات آليًا

في أي بنية بيانات مؤسسية، من المهم جدًا معرفة مصدر بياناتك بالضبط وكيف تم تغييرها لأغراض الامتثال وتصحيح الأخطاء وإثبات الموثوقية. يُعرف هذا المفهوم باسم سلسلة البيانات. تجيب هذه الأداة عن أسئلة أساسية، مثل: "إذا كان أحد المدراء يطّلع على تقرير مبيعات يومي، ما هي الجداول الأولية التي تم استخدامها لاحتساب هذه الأرقام؟"

في السابق، كان تتبُّع مراحل النشاط هذه يتطلّب من مهندسي البيانات كتابة رمز تسجيل مخصّص يدويًا أو استخدام أدوات معقّدة تابعة لجهات خارجية لتحليل نصوص لغة الاستعلامات البنيوية (SQL) البرمجية. ومع ذلك، في مستودع بيانات Google Cloud Lakehouse المنظَّم، يتم تتبُّع هذه المعلومات تلقائيًا وبشكل كامل.

هل تتذكر جدول transactions_summary الذي أنشأته من جدول المعاملات الأولية في وقت سابق من هذا الدرس العملي؟ عندما نفّذت BigQuery عبارة CREATE TABLE AS SELECT، رصد محرّك الحوسبة تلقائيًا البيانات الوصفية للتحويل وأرسلها إلى Dataplex. لنطّلع على النتيجة.

تصوُّر مصدر البيانات

في Google Cloud Console، انتقِل إلى الفهرس الشامل في Dataplex > بحث.
اكتب lakehouse_retail_demo.transactions في شريط البحث وانقر على الجدول.
انقر على علامة التبويب مصدر البيانات.

سيظهر لك رسم بياني تفاعلي من إنشاء Dataplex Knowledge Engine يثبت أنّ الجدول المستهدَف (transactions_summary) تم استخراجه من جدول Iceberg الأولي المُدار (transactions). لقد حقّقت إمكانية التتبُّع الشامل الضرورية لتدقيق البيانات.

7. تَنظيم

لتجنُّب تحمّل رسوم في حسابك على Google Cloud مقابل الموارد المستخدَمة في هذا الدرس التطبيقي حول الترميز، اتّبِع الخطوات التالية.

إزالة موارد إدارة Dataplex

قبل حذف مجموعة بيانات BigQuery أو حزمة Cloud Storage، يجب إزالة قواعد إدارة البيانات المنطقية. إذا نظرت إلى داخل النص البرمجي cleanup_governance.py من المستودع، سيظهر لك تسلسل التفكيك التالي:

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

الترتيب هنا مهم للغاية. يحذف النص البرمجي أولاً "سياسة البيانات" (قاعدة الإخفاء) لأنّه يعتمد على "علامة السياسة". بعد إزالة السياسة، سيؤدي حذف التصنيف الرئيسي إلى حذف جميع "علامات السياسة" الأساسية تلقائيًا بدون حدوث أخطاء في تبعية الموارد.

شغِّل نص Python البرمجي الخاص بعملية التنظيف:

python cleanup_governance.py

إزالة الهويات ومواد عرض التخزين والحوسبة

بعد فصل طبقة الحوكمة، يمكنك حذف جداول BigQuery وحِزم Cloud Storage وحسابات الخدمة وبيئة Python المحلية بأمان.

انسخ كتلة التنظيف الشامل التالية وشغِّلها في Cloud Shell:

echo "Deleting Service Accounts and Impersonation Bindings..."
export CURRENT_USER=$(gcloud config get-value account)

for USER in "${USER_ANALYST}" "${USER_MANAGER}"; do
    EMAIL="${USER}@${PROJECT_ID}.iam.gserviceaccount.com"
    
    # Remove impersonation binding
    gcloud iam service-accounts remove-iam-policy-binding ${EMAIL} \
        --member="user:${CURRENT_USER}" \
        --role="roles/iam.serviceAccountTokenCreator" \
        --quiet > /dev/null 2>&1
        
    # Delete the Service Account
    gcloud iam service-accounts delete ${EMAIL} --quiet
done

echo "Removing BigQuery Dataset and Tables..."
bq rm -f ${DATASET_ID}.transactions_summary
bq rm -f ${DATASET_ID}.transactions
bq rm -f ${DATASET_ID}.inventory
bq rm -f -d ${DATASET_ID}

echo "Removing BigQuery Cloud Resource Connection..."
bq rm --connection --location=${REGION} ${CONN_NAME}

echo "Removing Iceberg Cloud Storage Bucket..."
gcloud storage rm --recursive gs://${ICEBERG_BUCKET} --quiet

echo "Removing Auto-generated Dataproc Staging & Temp Buckets..."
for BUCKET in $(gcloud storage ls | grep -E "gs://dataproc-(staging|temp)-${REGION}"); do
    gcloud storage rm --recursive $BUCKET --quiet
done

echo "Deactivating and removing the local Python environment..."
deactivate
cd ../..
rm -rf devrel-demos

echo "✅ Clean up completed successfully!"

من خلال إكمال هذه الخطوات، تكون قد تأكّدت من عدم بقاء أي موارد غير مرتبطة أو سياسات مخفية في مشروعك.

8. تهانينا!

لقد نفّذت بنجاح Data Lakehouse خاضعًا للحوكمة بالكامل وقابلاً للاستكشاف.

لقد تعلّمتَ ما يلي:

التكامل الأصلي مع Iceberg: يمكن لـ BigLake إدارة جداول Iceberg مفتوحة المصدر بشكل أصلي مع تخزين الملفات المادية بشكل آمن في Cloud Storage.
تفويض الحساب لأغراض الأمان: من خلال توجيه طلبات البحث عبر BigQuery Storage API، فرضت إخفاءً ديناميكيًا دقيقًا على الملفات المادية التي لا يمكنها بشكلٍ أصلي حظر الوصول الجزئي.
الإدارة المستقلة عن المحرّك: تتيح لك "علامات السياسة" تحديد القواعد مرة واحدة وفرضها على مستوى جميع عمليات البحث سواء تم إجراؤها من خلال SQL الأصلي أو أوقات تشغيل Apache Spark.
إمكانية اكتشاف البيانات: تتبّع "محرك المعرفة" في Dataplex تلقائيًا مصدر البيانات، ما يوفّر إمكانية التدقيق الأساسية للمؤسسات.

ما هي الخطوات التالية؟

استكشاف ميزات التحكّم المتقدّمة في الوصول: لتنفيذ سيناريوهات أمان أكثر تعقيدًا، راجِع المستندات الرسمية حول تخصيص BigLake باستخدام ميزات إضافية.
إدارة البيانات غير المنظَّمة للذكاء الاصطناعي التوليدي: استكشِف جداول عناصر BigLake. يمكنك توسيع نطاق نمط "الجسر الآمن" هذا ليشمل الملفات غير المنظَّمة (ملفات PDF والصور) في Cloud Storage، ما يؤدي إلى إنشاء أساس آمن ومحكوم للبيانات من أجل Vertex AI ومسارات التوليد المعزّز بالاسترجاع.