جودة البيانات المبرمَجة باستخدام "كتالوج المعرفة" والذكاء الاصطناعي التوليدي

1. مقدمة

يقدّم هذا الدرس التطبيقي حول الترميز مخططًا فنيًا للمتخصصين في مجال البيانات. يحدّد هذا المستند نهج "التركيز على الترميز" في إدارة البيانات، ويوضّح كيفية تضمين إدارة عالية الجودة للبيانات الوصفية مباشرةً في مراحل التطوير. في جوهرها، تعمل Knowledge Catalog كنسيج بيانات ذكي، ما يتيح للمؤسسات إدارة البيانات ومراقبتها والتحكّم فيها بشكل مركزي في جميع أنظمتها، بدءًا من بحيرات البيانات وصولاً إلى المستودعات.

يوضّح الدرس التطبيقي حول الترميز كيفية الاستفادة من "كتالوج المعرفة" وBigQuery وAntigravity CLI لتسوية البيانات المعقّدة، وتحديد خصائصها آليًا، وإنشاء اقتراحات ذكية لقواعد جودة البيانات، ونشر عمليات فحص الجودة المبرمَجة. الهدف الأساسي هو تجاوز العمليات اليدوية المستندة إلى واجهة المستخدم، والتي تكون عرضة للأخطاء ويصعب توسيع نطاقها، وإنشاء إطار عمل قوي يمكن التحكّم في إصداراته باسم "السياسة كرمز".

أهداف الدورة التعليمية

  • كيفية تسوية بيانات BigQuery المتداخلة باستخدام طرق العرض المادية لتفعيل إنشاء ملفات تعريف شاملة
  • كيفية تشغيل عمليات فحص ملفات Knowledge Catalog وإدارتها آليًا باستخدام Knowledge Catalog Python Client Library
  • كيفية تصدير بيانات الملف الشخصي وتنظيمها كمدخل لنموذج الذكاء الاصطناعي التوليدي
  • كيفية تصميم طلب لواجهة سطر الأوامر Antigravity لتحليل بيانات الملف الشخصي وإنشاء ملف قواعد YAML متوافق مع "كتالوج المعرفة"
  • أهمية عملية تفاعلية تتضمّن مشاركة بشرية (HITL) للتحقّق من صحة الإعدادات التي ينشئها الذكاء الاصطناعي
  • كيفية نشر القواعد التي تم إنشاؤها كعملية فحص مبرمَجة لجودة البيانات

المتطلبات

  • حساب على Google Cloud ومشروع على Google Cloud
  • متصفّح ويب، مثل Chrome

المفاهيم الأساسية: أركان جودة بيانات "كتالوج المعرفة"

يُعدّ فهم المكوّنات الأساسية في "كتالوج المعرفة" أمرًا ضروريًا لوضع استراتيجية فعّالة لجودة البيانات.

  • فحص ملف البيانات: مهمة في "كتالوج المعرفة" تحلّل البيانات وتنشئ بيانات وصفية إحصائية، بما في ذلك النسب المئوية للقيم الفارغة وعدد القيم المميزة وتوزيع القيم. وهذه هي مرحلة "الاكتشاف" الآلية.
  • قواعد جودة البيانات: عبارات توضيحية تحدّد الشروط التي يجب أن تستوفيها بياناتك (مثل NonNullExpectation وSetExpectation وRangeExpectation).
  • الذكاء الاصطناعي التوليدي لاقتراح القواعد: استخدام نموذج لغوي كبير (مثل Gemini) لتحليل ملف بيانات واقتراح قواعد ذات صلة بجودة البيانات. يؤدي ذلك إلى تسريع عملية تحديد إطار عمل أساسي للجودة.
  • فحص جودة البيانات: مهمة في "كتالوج المعرفة" تتحقّق من صحة البيانات استنادًا إلى مجموعة من القواعد المحدّدة مسبقًا أو المخصّصة.
  • إدارة الحوكمة آليًا: هي الموضوع الرئيسي لإدارة عناصر التحكّم في الحوكمة (مثل قواعد الجودة) كرمز (على سبيل المثال، في ملفات YAML ونصوص Python البرمجية). يتيح ذلك إمكانية التشغيل الآلي وإدارة الإصدارات والدمج في مسارات الدمج المتواصل/النشر المتواصل.
  • المشاركة البشرية (HITL): نقطة التحكّم المهمة لدمج الخبرة والإشراف البشري في سير عمل آلي. بالنسبة إلى عمليات الإعداد من إنشاء الذكاء الاصطناعي، يُعدّ التفاعل بين الإنسان والآلة ضروريًا للتحقّق من صحة الاقتراحات ومدى صلتها بالنشاط التجاري وسلامتها قبل نشرها.

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)
gcloud config set project $PROJECT_ID
export LOCATION="us-central1"
export BQ_LOCATION="us"
export DATASET_ID="kc_dq_codelab"
export TABLE_ID="ga4_transactions"

gcloud services enable dataplex.googleapis.com \
                       bigquery.googleapis.com \
                       serviceusage.googleapis.com \
                       aiplatform.googleapis.com

في المثال، نستخدم us (متعدد المناطق) كموقع جغرافي لأنّ بيانات العيّنة العامة التي سنستخدمها تقع أيضًا في us (متعدد المناطق). يشترط BigQuery أن تكون البيانات المصدر وجدول الوجهة لأي طلب بحث في الموقع الجغرافي نفسه.

إنشاء مجموعة بيانات مخصّصة في BigQuery

أنشئ مجموعة بيانات جديدة في BigQuery لتضمين البيانات النموذجية والنتائج.

bq --location=us mk --dataset $PROJECT_ID:$DATASET_ID

إعداد نموذج البيانات

في هذا الدرس التطبيقي حول الترميز، ستستخدم مجموعة بيانات عامة تحتوي على بيانات التجارة الإلكترونية التي تم تشويشها من "متجر بيع سلع Google". بما أنّ مجموعات البيانات العامة تكون للقراءة فقط، عليك إنشاء نسخة قابلة للتعديل في مجموعة البيانات الخاصة بك. ينشئ أمر bq التالي جدولاً جديدًا، ga4_transactions، في مجموعة البيانات kc_dq_codelab. يتم نسخ البيانات من يوم واحد (2021-01-31) لضمان إجراء عمليات الفحص بسرعة.

bq query \
--use_legacy_sql=false \
--destination_table=$PROJECT_ID:$DATASET_ID.$TABLE_ID \
--replace=true \
'SELECT * FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_20210131`'

إعداد دليل العرض التوضيحي

للبدء، عليك استنساخ مستودع GitHub يحتوي على بنية المجلد والملفات الداعمة اللازمة لهذا الدرس التطبيقي حول الترميز.

# Perform a shallow clone to get only the latest repository structure without the full history
git clone --depth 1 --filter=blob:none --sparse https://github.com/GoogleCloudPlatform/devrel-demos.git
cd devrel-demos

# Specify and download only the folder we need for this lab
git sparse-checkout set data-analytics/programmatic-dq
cd data-analytics/programmatic-dq

أصبح هذا الدليل الآن مساحة العمل النشطة. سيتم إنشاء جميع الملفات اللاحقة هنا.

3- الرصد التلقائي للبيانات باستخدام ميزة إنشاء الملفات الشخصية في "كتالوج المعارف"

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

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

فهم المخطط المتداخل

أولاً، لنفحص مخطط جدول المصدر. تحتوي مجموعة بيانات "إحصاءات Google‏ 4" على العديد من الأعمدة المتداخلة والمتكرّرة. لاسترداد المخطط الكامل آليًا، بما في ذلك جميع البُنى المتداخلة، يمكنك استخدام الأمر bq show وحفظ الناتج كملف JSON.

bq show --schema --format=json $PROJECT_ID:$DATASET_ID.$TABLE_ID > bq_schema.json

يكشف فحص الملف bq_schema.json عن بنى معقّدة، مثل الجهاز والموقع الجغرافي والتجارة الإلكترونية وعناصر السجلّ المتكرّرة. هذه هي البُنى التي تتطلّب تسطيحًا لإعداد ملفات تعريف فعّالة.

تسوية البيانات باستخدام "طرق العرض المادية"

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

قد يكون أول ما يخطر في بالك هو دمج كل شيء في عرض واحد كبير. ومع ذلك، يخفي هذا النهج البسيط فخًا خطيرًا يمكن أن يؤدي إلى تلف شديد في البيانات. لنتعرّف على سبب اعتبار هذا الخطأ فادحًا.

  1. mv_ga4_user_session_flat.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_user_session_flat`
OPTIONS (
  enable_refresh = true,
  refresh_interval_minutes = 30
) AS
SELECT
  event_date, event_timestamp, event_name, user_pseudo_id, user_id, stream_id, platform,
  device.category AS device_category,
  device.operating_system AS device_os,
  device.operating_system_version AS device_os_version,
  device.language AS device_language,
  device.web_info.browser AS device_browser,
  geo.continent AS geo_continent,
  geo.country AS geo_country,
  geo.region AS geo_region,
  geo.city AS geo_city,
  traffic_source.name AS traffic_source_name,
  traffic_source.medium AS traffic_source_medium,
  traffic_source.source AS traffic_source_source
FROM
  `$PROJECT_ID.$DATASET_ID.ga4_transactions`;
  1. mv_ga4_ecommerce_transactions.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_transactions`
OPTIONS (
  enable_refresh = true,
  refresh_interval_minutes = 30
) AS
SELECT
  event_date, event_timestamp, user_pseudo_id, ecommerce.transaction_id,
  ecommerce.total_item_quantity,
  ecommerce.purchase_revenue_in_usd,
  ecommerce.purchase_revenue,
  ecommerce.refund_value_in_usd,
  ecommerce.refund_value,
  ecommerce.shipping_value_in_usd,
  ecommerce.shipping_value,
  ecommerce.tax_value_in_usd,
  ecommerce.tax_value,
  ecommerce.unique_items
FROM
  `$PROJECT_ID.$DATASET_ID.ga4_transactions`
WHERE
  ecommerce.transaction_id IS NOT NULL;
  1. mv_ga4_ecommerce_items.sql
CREATE OR REPLACE MATERIALIZED VIEW `$PROJECT_ID.$DATASET_ID.mv_ga4_ecommerce_items`
OPTIONS (
  enable_refresh = true,
  refresh_interval_minutes = 30
) AS
SELECT
  event_date, event_timestamp, event_name, user_pseudo_id, ecommerce.transaction_id,
  item.item_id,
  item.item_name,
  item.item_brand,
  item.item_variant,
  item.item_category,
  item.item_category2,
  item.item_category3,
  item.item_category4,
  item.item_category5,
  item.price_in_usd,
  item.price,
  item.quantity,
  item.item_revenue_in_usd,
  item.item_revenue,
  item.coupon,
  item.affiliation,
  item.item_list_name,
  item.promotion_name
FROM
  `$PROJECT_ID.$DATASET_ID.ga4_transactions`,
  UNNEST(items) AS item
WHERE
  ecommerce.transaction_id IS NOT NULL;

الآن، نفِّذ هذه النماذج باستخدام أداة سطر الأوامر bq. سيقرأ الأمر envsubst كل ملف، ويستبدل المتغيرات مثل $PROJECT_ID و$DATASET_ID بقيمها من بيئة shell، وينقل SQL النهائي والصالح إلى أمر طلب البحث bq.

envsubst < mv_ga4_user_session_flat.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_transactions.sql | bq query --use_legacy_sql=false
envsubst < mv_ga4_ecommerce_items.sql | bq query --use_legacy_sql=false

تنفيذ عمليات فحص الملفات الشخصية من خلال برنامج Python

بعد أن أصبح لدينا عروض مسطّحة وقابلة للإنشاء، يمكننا إنشاء عمليات فحص ملفات بيانات Knowledge Catalog وتشغيلها آليًا لكل عرض. يستخدم نص Python البرمجي التالي مكتبة برامج google-cloud-dataplex لأتمتة هذه العملية.

قبل تشغيل النص البرمجي، من أفضل الممارسات المهمة إنشاء بيئة Python معزولة داخل دليل مشروعك. يضمن ذلك إدارة تبعيات المشروع بشكل منفصل، ما يمنع حدوث تعارضات مع حِزم أخرى في بيئة Cloud Shell.

# Create the virtual environment
python3 -m venv dq_venv

# Activate the environment
source dq_venv/bin/activate

الآن، ثبِّت مكتبة برامج Knowledge Catalog داخل البيئة التي تم تفعيلها حديثًا.

# Install the Knowledge Catalog client library
pip install google-cloud-dataplex

بعد إعداد البيئة وتثبيت المكتبة، تكون مستعدًا لإنشاء نص برمجي للتنسيق.

في شريط أدوات Cloud Shell، انقر على "فتح المحرّر". أنشئ ملفًا جديدًا باسم 1_run_scan.py والصِق رمز Python التالي فيه. إذا استنسخت مستودع GitHub، سيكون هذا الملف متوفّرًا في مجلدك.

سينشئ هذا النص البرمجي عملية فحص لكل "عرض مجسّم" (إذا لم يكن متوفّرًا بعد)، ويُجري عملية الفحص، ثم يستقصي إلى أن تكتمل جميع مهام الفحص.

import os
import sys
import time
from google.cloud import dataplex_v1
from google.api_core.exceptions import AlreadyExists


def create_and_run_scan(
    client: dataplex_v1.DataScanServiceClient,
    project_id: str,
    location: str,
    data_scan_id: str,
    target_resource: str,
) -> dataplex_v1.DataScanJob | None:
    """
    Creates and runs a single data profile scan.
    Returns the executed Job object without waiting for completion.
    """
    parent = client.data_scan_path(project_id, location, data_scan_id).rsplit('/', 2)[0]
    scan_path = client.data_scan_path(project_id, location, data_scan_id)

    # 1. Create Data Scan (skips if it already exists)
    try:
        data_scan = dataplex_v1.DataScan()
        data_scan.data.resource = target_resource
        data_scan.data_profile_spec = dataplex_v1.DataProfileSpec()

        print(f"[INFO] Creating data scan '{data_scan_id}'...")
        client.create_data_scan(
            parent=parent,
            data_scan=data_scan,
            data_scan_id=data_scan_id
        ).result()  # Wait for creation to complete
        print(f"[SUCCESS] Data scan '{data_scan_id}' created.")
    except AlreadyExists:
        print(f"[INFO] Data scan '{data_scan_id}' already exists. Skipping creation.")
    except Exception as e:
        print(f"[ERROR] Error creating data scan '{data_scan_id}': {e}")
        return None

    # 2. Run Data Scan
    try:
        print(f"[INFO] Running data scan '{data_scan_id}'...")
        run_response = client.run_data_scan(name=scan_path)
        print(f"[SUCCESS] Job started for '{data_scan_id}'. Job ID: {run_response.job.name.split('/')[-1]}")
        return run_response.job
    except Exception as e:
        print(f"[ERROR] Error running data scan '{data_scan_id}': {e}")
        return None


def main():
    """Main execution function"""
    # --- Load configuration from environment variables ---
    PROJECT_ID = os.environ.get("PROJECT_ID")
    LOCATION = os.environ.get("LOCATION")
    DATASET_ID = os.environ.get("DATASET_ID")

    if not all([PROJECT_ID, LOCATION, DATASET_ID]):
        print("[ERROR] One or more required environment variables are not set.")
        print("Please ensure PROJECT_ID, LOCATION, and DATASET_ID are exported in your shell.")
        sys.exit(1)

    print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}, Dataset: {DATASET_ID}")

    # List of Materialized Views to profile
    TARGET_VIEWS = [
        "mv_ga4_user_session_flat",
        "mv_ga4_ecommerce_transactions",
        "mv_ga4_ecommerce_items"
    ]
    # ----------------------------------------------------

    client = dataplex_v1.DataScanServiceClient()
    running_jobs = []

    # 1. Create and run jobs for all target views
    print("\n--- Starting Data Profiling Job Creation and Execution ---")
    for view_name in TARGET_VIEWS:
        data_scan_id = f"profile-scan-{view_name.replace('_', '-')}"
        target_resource = f"//bigquery.googleapis.com/projects/{PROJECT_ID}/datasets/{DATASET_ID}/tables/{view_name}"

        job = create_and_run_scan(client, PROJECT_ID, LOCATION, data_scan_id, target_resource)
        if job:
            running_jobs.append(job)
    print("-------------------------------------------------------\n")

    if not running_jobs:
        print("[ERROR] No jobs were started. Exiting.")
        return

    # 2. Poll for all jobs to complete
    print("--- Monitoring job completion status (checking every 30 seconds) ---")
    completed_jobs = {}

    while running_jobs:
        jobs_to_poll_next = []

        print(f"\n[STATUS] Checking status for {len(running_jobs)} running jobs...")

        for job in running_jobs:
            job_id_short = job.name.split('/')[-1][:13] 
            try:
                updated_job = client.get_data_scan_job(name=job.name)
                state = updated_job.state

                if state in (dataplex_v1.DataScanJob.State.RUNNING, dataplex_v1.DataScanJob.State.PENDING, dataplex_v1.DataScanJob.State.CANCELING):
                    print(f"  - Job {job_id_short}... Status: {state.name}")
                    jobs_to_poll_next.append(updated_job) 
                else:
                    print(f"  - Job {job_id_short}... Status: {state.name} (Complete)")
                    completed_jobs[job.name] = updated_job

            except Exception as e:
                print(f"[ERROR] Could not check status for job {job_id_short}: {e}")

        running_jobs = jobs_to_poll_next

        if running_jobs:
            time.sleep(30)

    # 3. Print final results
    print("\n--------------------------------------------------")
    print("[SUCCESS] All data profiling jobs have completed.")
    print("\nFinal Job Status Summary:")
    for job_name, job in completed_jobs.items():
        job_id_short = job_name.split('/')[-1][:13]
        print(f"  - Job {job_id_short}: {job.state.name}")
        if job.state == dataplex_v1.DataScanJob.State.FAILED:
            print(f"    - Failure Message: {job.message}")

    print("\nNext step: Analyze the profile results and generate quality rules.")


if __name__ == "__main__":
    main()

الآن، نفِّذ النص البرمجي من وحدة Cloud Shell الطرفية.

python 1_run_scan.py

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

يمكنك الاطّلاع على عمليات فحص الملفات الشخصية المكتملة في Google Cloud Console.

  1. في قائمة التنقّل، انتقِل إلى كتالوج المعرفة وتحديد خصائص البيانات وجودتها في قسم الإدارة.
  2. من المفترض أن تظهر لك عمليات فحص الملف الشخصي الثلاث مُدرَجة، بالإضافة إلى أحدث حالة للوظيفة. يمكنك النقر على عملية فحص للاطّلاع على النتائج التفصيلية.

من ملف BigQuery الشخصي إلى الإدخال الجاهز للذكاء الاصطناعي

تم إجراء عمليات فحص ملفات Knowledge Catalog الشخصية بنجاح. على الرغم من أنّ النتائج متاحة ضمن Knowledge Catalog API، لاستخدامها كمدخل لنموذج ذكاء اصطناعي توليدي، علينا استخراجها إلى ملف منظَّم ومحلي.

يعثر نص Python البرمجي التالي، 2_dq_profile_save.py، آليًا على أحدث مهمة ناجحة لفحص الملف الشخصي للعرض mv_ga4_user_session_flat. بعد ذلك، يستردّ نتيجة الملف الشخصي الكاملة والمفصّلة ويحفظها كملف JSON محلي باسم dq_profile_results.json. سيكون هذا الملف هو الإدخال المباشر لتحليل الذكاء الاصطناعي في الخطوة التالية.

في محرِّر Cloud Shell، أنشئ ملفًا جديدًا باسم 2_dq_profile_save.py وألصِق الرمز التالي فيه. كما هو الحال في الخطوة السابقة، يمكنك تخطّي إنشاء ملف إذا نسخت المستودع.

import os
import sys
import json
from google.cloud import dataplex_v1
from google.api_core.exceptions import NotFound
from google.protobuf.json_format import MessageToDict

# --- Configuration ---
# The Materialized View to analyze is fixed for this step.
TARGET_VIEW = "mv_ga4_user_session_flat"
OUTPUT_FILENAME = "dq_profile_results.json"


def save_to_json_file(content: dict, filename: str):
    """Saves the given dictionary content to a JSON file."""
    try:
        with open(filename, "w", encoding="utf-8") as f:
            # Use indent=2 for a readable, "pretty-printed" JSON file.
            json.dump(content, f, indent=2, ensure_ascii=False)
        print(f"\n[SUCCESS] Profile results were saved to '{filename}'.")
    except (IOError, TypeError) as e:
        print(f"[ERROR] An error occurred while saving the file: {e}")


def get_latest_successful_job(
    client: dataplex_v1.DataScanServiceClient,
    project_id: str,
    location: str,
    data_scan_id: str
) -> dataplex_v1.DataScanJob | None:
    """Finds and returns the most recently succeeded job for a given data scan."""
    scan_path = client.data_scan_path(project_id, location, data_scan_id)
    print(f"\n[INFO] Looking for the latest successful job for scan '{data_scan_id}'...")

    try:
        # List all jobs for the specified scan, which are ordered most-recent first.
        jobs_pager = client.list_data_scan_jobs(parent=scan_path)

        # Iterate through jobs to find the first one that succeeded.
        for job in jobs_pager:
            if job.state == dataplex_v1.DataScanJob.State.SUCCEEDED:
                return job

        # If no successful job is found after checking all pages.
        return None
    except NotFound:
        print(f"[WARN] No scan history found for '{data_scan_id}'.")
        return None


def main():
    """Main execution function."""
    # --- Load configuration from environment variables ---
    PROJECT_ID = os.environ.get("PROJECT_ID")
    LOCATION = os.environ.get("LOCATION")

    if not all([PROJECT_ID, LOCATION]):
        print("[ERROR] Required environment variables PROJECT_ID or LOCATION are not set.")
        sys.exit(1)

    print(f"[INFO] Using Project: {PROJECT_ID}, Location: {LOCATION}")
    print(f"--- Starting Profile Retrieval for: {TARGET_VIEW} ---")

    # Construct the data_scan_id based on the target view name.
    data_scan_id = f"profile-scan-{TARGET_VIEW.replace('_', '-')}"

    # 1. Initialize client and get the latest successful job.
    client = dataplex_v1.DataScanServiceClient()
    latest_job = get_latest_successful_job(client, PROJECT_ID, LOCATION, data_scan_id)

    if not latest_job:
        print(f"\n[ERROR] No successful job record was found for '{data_scan_id}'.")
        print("Please ensure the '1_run_scan.py' script has completed successfully.")
        return

    job_id_short = latest_job.name.split('/')[-1]
    print(f"[SUCCESS] Found the latest successful job: '{job_id_short}'.")

    # 2. Fetch the full, detailed profile result for the job.
    print(f"[INFO] Retrieving detailed profile results for job '{job_id_short}'...")
    try:
        request = dataplex_v1.GetDataScanJobRequest(
            name=latest_job.name,
            view=dataplex_v1.GetDataScanJobRequest.DataScanJobView.FULL,
        )
        job_with_full_results = client.get_data_scan_job(request=request)
    except Exception as e:
        print(f"[ERROR] Failed to retrieve detailed job results: {e}")
        return

    # 3. Convert the profile result to a dictionary and save it to a JSON file.
    if job_with_full_results.data_profile_result:
        profile_dict = MessageToDict(job_with_full_results.data_profile_result._pb)
        save_to_json_file(profile_dict, OUTPUT_FILENAME)
    else:
        print("[WARN] The job completed, but no data profile result was found within it.")

    print("\n[INFO] Script finished successfully.")


if __name__ == "__main__":
    main()

الآن، شغِّل النص البرمجي من الوحدة الطرفية:

python 2_dq_profile_save.py

بعد اكتمال العملية بنجاح، سيظهر ملف جديد باسم dq_profile_results.json في الدليل. يحتوي هذا الملف على بيانات التعريف الإحصائية الغنية والمفصّلة التي سنستخدمها لإنشاء قواعد جودة البيانات. إذا أردت التحقّق من محتوى dq_profile_results.json، نفِّذ الأمر التالي:

cat dq_profile_results.json

4. إنشاء قواعد جودة البيانات باستخدام Antigravity CLI

يمكنك الآن استخدام Antigravity CLI (agy) لقراءة نتائج فحص الملف الشخصي المحلي. إنّ كتابة مواصفات جودة البيانات يدويًا لمجموعات البيانات المعقّدة تستغرق وقتًا طويلاً وعُرضة للأخطاء. يؤدي استخدام وكيل الذكاء الاصطناعي التوليدي في الجهاز إلى تسريع سير العمل هذا من خلال إعداد مسودة أولية لإعدادات تعريفية في ثوانٍ. يتيح ذلك لفِرق البيانات الانتقال من صياغة البنية يدويًا إلى الإشراف على مستوى عالٍ ومتوافق مع النشاط التجاري من خلال نهج "المشاركة البشرية" (HITL).

لبدء واجهة سطر الأوامر Antigravity، نفِّذ الأمر التالي في الوحدة الطرفية:

agy

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

اطلب من الوكيل إنشاء خطة

أولاً، سنطلب من وكيل Antigravity تحليل الملف الإحصائي واقتراح خطة عمل. نطلب منه بشكل صريح عدم كتابة ملف YAML بعد. ويركّز هذا النوع على التحليل والتبرير.

في جلسة Antigravity CLI التفاعلية، أدخِل الطلب المنظَّم التالي:

# Context
You are preparing a data quality rule configuration plan for Google Cloud Knowledge Catalog based on data profile statistics.

# Input
- File Path: `./dq_profile_results.json` (contains metrics like null percentage, distinct counts, and distributions)

# Task
Analyze the input statistics and propose a step-by-step plan for establishing automated data quality rules. 
*Do not write any YAML code in this step.* Focus only on analytical planning.

# Rule Mapping Strategy
For candidate columns, match the statistical metrics to the most appropriate expectations:
- `nonNullExpectation`: Propose for columns with 0% null values in the profile.
- `setExpectation`: Propose for columns with a highly limited, stable set of categorical values.
- `rangeExpectation`: Propose for numeric columns with consistent and predictable value boundaries.

# Guidelines
- Provide a metric-based justification for each proposed rule (e.g., "Recommend `nonNullExpectation` for column 'user_pseudo_id' because its null percentage is 0%").
- Flag volatile metrics such as hardcoded row counts that could cause false-positive alerts in production.

# Output Format
Provide your analysis and proposed rules as a structured, step-by-step markdown plan with clear headings.

سيحلّل الوكيل ملف JSON ويجب أن يعرض خطة منظَّمة مشابهة لما يلي:

Automated Data Quality Rule Configuration Plan                                                                                                          
                                                                                                                                                           
  Google Cloud Knowledge Catalog (Dataplex Data Quality)                                                                                                   
  ──────                                                                                                                                                   
  ## Executive Summary                                                                                                                                     
  This analytical planning document outlines a step-by-step strategy for configuring automated data quality (DQ) rules in Google Cloud Knowledge Catalog (formerly Dataplex Data Quality) based on profiling statistics.
  The dataset contains 26,489 rows representing GA4 event logs. Based on statistical metrics (null ratios, distinct value distributions, and data types), candidate columns are mapped to appropriate expectation rules.
  ──────                                                                                                                                                   
  ## 1. Data Profile Overview & Statistical Highlights                                                                                                     
                                                                                                                                                           
   Column Name     │ Data Type │ Null Ratio     │ Distinct Count │ Key Value Range / Categories
  ─────────────────┼───────────┼────────────────┼────────────────┼──────────────────────────────────────────────────
   event_date      │ STRING    │ 0.0% (0)       │ 1 (3.78e-05)   │ "20210131" (100%)
   event_timestamp │ INTEGER   │ 0.0% (0)       │ ~16,539 (0.62) │ Min: 1612051200657906, Max: 1612137595412363
   event_name      │ STRING    │ 0.0% (0)       │ 16 (0.0006)    │ page_view (35.8%), user_engagement (18.9%), etc.
   user_pseudo_id  │ STRING    │ 0.0% (0)       │ ~2,545 (0.09)  │ 18–21 characters string identifiers
   user_id         │ STRING    │ 100.0% (1.0)   │ 0 (0.0)        │ Entirely NULL
   device_category │ STRING    │ 0.0% (0)       │ 3 (0.0001)     │ desktop (57.5%), mobile (40.1%), tablet (2.4%)
   ...             │ ...       │ ...            │ ...            │ ...
  ──────                                                                                                                                                   
  ## 2. Rule Mapping Strategy & Analytical Justifications                                                                                                  
                                                                                                                                                           
  ### Step 1: Nullability Rules (nonNullExpectation)                                                                                                       
  Propose nonNullExpectation for mandatory columns where the data profile demonstrates 0% null values.                                                     
  • user_pseudo_id, event_timestamp, event_name, event_date, stream_id, platform, device_category (Metric Justification: nullRatio is 0.0%)
                                                                                                                                                           
  │ [!NOTE] Exclusions:                                                                                                                    
  │ • user_id: Has a nullRatio of 100.0% (unauthenticated traffic).
  │ • device_language: Has a nullRatio of 37.53%.                                                                                                          
  ──────                                                                                                                                                   
  ### Step 2: Categorical Value Set Validation (setExpectation)                                                                                            
  Propose setExpectation for columns with a highly limited, stable set of categorical domain values.                                                       
  • device_category: Distinct count is exactly 3. Allowed set: ['desktop', 'mobile', 'tablet']
  • platform: Distinct count is 1. Allowed set expanded to: ['WEB', 'ANDROID', 'IOS'] to avoid over-fitting.
  • geo_continent: Distinct count is 6. Allowed set: ['Americas', 'Asia', 'Europe', 'Africa', 'Oceania', 'Antarctica', '(not set)']
                                                                                                                                                           
  ──────                                                                                                                                                   
  ### Step 3: Numeric & Timestamp Boundary Validation (rangeExpectation)                                                                                   
  Propose rangeExpectation for numeric columns with consistent and predictable value boundaries.                                                           
  • event_timestamp: rangeExpectation requiring event_timestamp > 0 (avoid dynamic microsecond range hardcoding)
  • stream_id: rangeExpectation requiring positive integer stream IDs (stream_id > 0)
                                                                                                                                                           
  ──────                                                                                                                                                   
  ## 3. Risk Warning: Volatile Metrics & Production False Positives                                                                                        
  │ [!WARNING] Volatile Metrics Flagged for Risk Mitigation:                                                                                                      
  1. Hardcoded Total Row Count (rowCount = 26,489) -> Daily event volume fluctuates. Use dynamic volume thresholds.
  2. Hardcoded Partition Date (event_date = '20210131') -> Breaks on future runs. Validate against YYYYMMDD regex patterns.
  3. Exact Timestamp Range Bounds -> Enforcing these microsecond limits on incoming live pipelines will reject all future data.
  4. Single-Value Domain Restrictions -> Single profile sample might lack active streams. Set sets according to enterprise schema.
  
  ──────
  ## Summary Table of Proposed Rules
  
   Target Column   │ Rule Type          │ Metric-Based Justification │ Operational Considerations
  ─────────────────┼────────────────────┼────────────────────────────┼──────────────────────────────────────────────────
   user_pseudo_id  │ nonNullExpectation │ Null Ratio: 0.0%           │ Core identifier, strictly required
   event_timestamp │ nonNullExpectation │ Null Ratio: 0.0%           │ Temporal key, strictly required
   event_timestamp │ rangeExpectation   │ Min: > 0 (Microseconds)    │ Avoid hardcoding epoch min/max
   event_name      │ nonNullExpectation │ Null Ratio: 0.0%           │ Required event taxonomy key
   event_name      │ setExpectation     │ Categorical distribution   │ Map to standard GA4 event taxonomy
   device_category │ nonNullExpectation │ Null Ratio: 0.0%           │ Required form-factor dimension
   device_category │ setExpectation     │ Distinct Count: 3 values   │ ['desktop', 'mobile', 'tablet']
   ...             │ ...                │ ...                        │ ...

إنشاء قواعد جودة البيانات

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

راجِع بعناية الخطة التي قدّمها لك الوكيل.

  • هل هذا منطقي؟
  • هل تتوافق مع معرفتك بنشاطك التجاري؟
  • هل هناك أي قواعد سليمة إحصائيًا ولكنها غير مفيدة عمليًا؟

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

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

الطلب أدناه هو نموذج. السطر الأول هو المكان الذي ستُدخل فيه التصحيحات المحدّدة. إذا كانت الخطة التي قدّمها لك الموظف مثالية ولا تحتاج إلى أي تغييرات، يمكنك ببساطة حذف هذا السطر.

في جلسة Antigravity نفسها، أدخِل نسختك المعدَّلة من الطلب التالي:

# Feedback & Approvals
[YOUR CORRECTIONS AND APPROVAL GO HERE. Examples:
- "The plan looks good. Please proceed."
- "The rowCount rule is not necessary, as the table size changes daily. The rest of the plan is approved. Please proceed."
- "For the setExpectation on the geo_continent column, please also include 'Antarctica'."]

# Objective
Based on the approved analysis plan and the provided feedback, generate the final `dq_rules.yaml` file conforming to the standard `DataQualityRule` schema.

# Instructions
1. **Rule Justifications**: For every generated rule, add a YAML comment (`#`) on the line directly above it, briefly explaining the justification established in the plan.
2. **Schema Alignment**: Ensure the structure strictly adheres to the required Knowledge Catalog data quality scan specification. Refer to the `sample_rule.yaml` file in the current directory and the `DataQualityRule` class definition in the local virtual environment path (`./dq_venv/.../google/cloud/dataplex_v1/types/data_quality.py`) as the schema authority.
3. **Data-Driven Values**: Derive all rule parameters, such as thresholds or expected values, directly from the statistical metrics in `dq_profile_results.json`.

# Constraints
- **Output Purity**: Return ONLY the raw, valid, and properly formatted YAML code block.
- Do not include conversational preambles, introductory sentences, explanations, or markdown blocks around the YAML.

سينشئ الوكيل الآن محتوى YAML استنادًا إلى تعليماتك الدقيقة التي تم التحقّق منها من قِبل الإنسان. عند اكتمال العملية، سيظهر ملف جديد باسم dq_rules.yaml في دليل العمل.

إنشاء عملية فحص جودة البيانات وتنفيذها

بعد الحصول على ملف dq_rules.yaml تم إنشاؤه بواسطة وكيل وتم التحقّق منه من قِبل أحد الموظفين، يمكنك نشره بثقة.

اخرج من واجهة سطر الأوامر Antigravity عن طريق كتابة /quit أو الضغط على Ctrl+C مرّتين.

ينشئ أمر gcloud التالي موردًا جديدًا لفحص بيانات Knowledge Catalog. لا يتم تنفيذ عملية المسح الضوئي بعد، بل يتم ببساطة تسجيل تعريف عملية المسح الضوئي وإعداداتها (ملف YAML) في "كتالوج المعرفة".

نفِّذ الأمر التالي في الوحدة الطرفية:

export DQ_SCAN="dq-scan"
gcloud dataplex datascans create data-quality $DQ_SCAN \
    --project=$PROJECT_ID \
    --location=$LOCATION \
    --data-quality-spec-file=dq_rules.yaml \
    --data-source-resource="//bigquery.googleapis.com/projects/$PROJECT_ID/datasets/$DATASET_ID/tables/mv_ga4_user_session_flat"

بعد تحديد عملية البحث، يمكنك تشغيل مهمة لتنفيذها.

gcloud dataplex datascans run $DQ_SCAN --location=$LOCATION --project=$PROJECT_ID

سيؤدي هذا الأمر إلى عرض معرّف مهمة. يمكنك مراقبة حالة هذه المهمة في قسم "كتالوج المعرفة" في Google Cloud Console. بعد اكتمال العملية، ستتم كتابة النتائج في جدول BigQuery لتحليلها.

5- الدور الحاسم لنهج "المشاركة البشرية" (HITL)

على الرغم من أنّ استخدام وكيل Antigravity لتسريع عملية إنشاء القواعد فعّال للغاية، من المهم التعامل مع الذكاء الاصطناعي كمساعد تقني ماهر للغاية، وليس كطيار آلي مستقل تمامًا. إنّ عملية "المشاركة البشرية" (HITL) ليست اقتراحًا اختياريًا، بل هي خطوة أساسية لا يمكن التغاضي عنها في أي سير عمل لإدارة البيانات. إنّ مجرد نشر نتائج من إنشاء الذكاء الاصطناعي بدون إشراف بشري دقيق هو وصفة للفشل.

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

في ما يلي تفاصيل حول أهمية هذه المراجعة التي يجريها الفريق وما يجب البحث عنه تحديدًا:

1. التحقّق من الصحة في السياق: يفتقر الذكاء الاصطناعي إلى الوعي بالنشاط التجاري

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

2. الصحة والدقة: الحماية من الهلوسة والأخطاء الطفيفة

  • نقطة ضعف النماذج اللغوية الكبيرة: يمكن أن تكون النماذج اللغوية الكبيرة "واثقة من خطئها". يمكن أن "تتوهم" أو تنشئ رمزًا برمجيًا غير صحيح بشكل طفيف. على سبيل المثال، قد ينشئ ملف YAML يتضمّن قاعدة مسمّاة بشكل صحيح ولكن مع مَعلمة غير صالحة، أو قد يخطئ في كتابة نوع قاعدة (مثل setExpectations بدلاً من setExpectation الصحيح). ستؤدي هذه الأخطاء الطفيفة إلى تعذُّر النشر، ولكن قد يكون من الصعب رصدها.
  • الدور المهم للمراجع البشري: وظيفتك هي العمل كأداة تدقيق نهائية وأداة للتحقّق من صحة المخطط. عليك التحقّق بدقة من ملف YAML الذي تم إنشاؤه مقارنةً بمواصفات DataQualityRule الرسمية في "كتالوج المعرفة". لا تتحقّق فقط مما إذا كان "يبدو صحيحًا"، بل تتحقّق من صحته النحوية والدلالية للتأكّد من أنّه متوافق بنسبة% 100 مع واجهة برمجة التطبيقات المستهدَفة. لهذا السبب، يطلب درس تطبيقي حول الترميز من الوكيل الرجوع إلى ملفات المخطط للحدّ من احتمال حدوث خطأ، ولكن تقع مسؤولية التحقّق النهائي على عاتقك.

3- السلامة والحدّ من المخاطر: منع العواقب اللاحقة

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

4. الحوكمة كعملية مستمرة: دمج المعرفة الاستشرافية

  • نقطة ضعف النموذج اللغوي الكبير: تستند معلومات الذكاء الاصطناعي إلى لقطة ثابتة من البيانات، أي أنّ نتائج الملف الشخصي تعود إلى نقطة زمنية محدّدة. ليس لديه معلومات عن الأحداث المستقبلية.
  • الدور المهم للموظفين: يجب أن تكون استراتيجية الحوكمة استشرافية. أنت تعلم أنّه من المقرّر نقل مصدر بيانات في الشهر المقبل، ما سيؤدي إلى تغيير stream_id. أنت تعلم أنّه سيتمّ إضافة بلد جديد إلى قائمة geo_country. عملية HITL هي المكان الذي يتم فيه إدخال هذه المعرفة حول الحالة المستقبلية، وتعديل القواعد أو إيقافها مؤقتًا لمنع حدوث أعطال أثناء التطورات المخطط لها في الأنشطة التجارية أو التطورات الفنية. جودة البيانات ليست عملية إعداد لمرة واحدة، بل هي عملية مستمرة يجب أن تتطوّر، ولا يمكن لأحد سوى الإنسان توجيه هذا التطوّر.

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

ومع ذلك، لا يقلّل هذا التركيز على الإشراف البشري من قيمة الذكاء الاصطناعي. على العكس من ذلك، يؤدي الذكاء الاصطناعي التوليدي دورًا حاسمًا في تسريع عملية HITL نفسها.

بدون الذكاء الاصطناعي، على مهندس البيانات إجراء ما يلي:

  1. كتابة استعلامات SQL معقّدة يدويًا لإنشاء ملف تعريف للبيانات (مثل COUNT DISTINCT وAVG وMIN وMAX لكل عمود)
  2. تحليل نتائج جداول البيانات بدقة
  3. كتابة كل سطر من ملف قاعدة YAML من البداية، وهي مهمة شاقة وعرضة للأخطاء

ويعمل الذكاء الاصطناعي على تنفيذ هذه الخطوات الشاقة التي تستغرق وقتًا طويلاً بشكل آلي. تعمل هذه الميزة كمحلّل لا يكلّ يعالج الملف الإحصائي على الفور ويقدّم "مسودة أولى" للسياسة منظَّمة بشكل جيد ومكتملة بنسبة% 80.

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

  • تطبيق سياق الأعمال المهم.
  • التحقّق من صحة منطق الذكاء الاصطناعي
  • اتّخاذ قرارات استراتيجية بشأن القواعد المهمة حقًا

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

6. تنظيف البيئة

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

حذف عمليات البحث في "كتالوج المعارف"

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

# Delete the Data Quality Scan
gcloud dataplex datascans delete dq-scan \
    --location=us-central1 \
    --project=$PROJECT_ID --quiet

# Delete the Data Profile Scans
gcloud dataplex datascans delete profile-scan-mv-ga4-user-session-flat \
    --location=us-central1 \
    --project=$PROJECT_ID --quiet

gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-transactions \
    --location=us-central1 \
    --project=$PROJECT_ID --quiet

gcloud dataplex datascans delete profile-scan-mv-ga4-ecommerce-items \
    --location=us-central1 \
    --project=$PROJECT_ID --quiet

حذف مجموعة بيانات BigQuery

بعد ذلك، احذف مجموعة بيانات BigQuery. لا يمكن التراجع عن هذا الأمر، ويستخدم العلامة -f (فرض) لإزالة مجموعة البيانات وجميع جداولها بدون تأكيد.

# Manually type this command to confirm you are deleting the correct dataset
bq rm -r -f --dataset $PROJECT_ID:kc_dq_codelab

7. تهانينا!

لقد أكملت الدرس التطبيقي حول الترميز بنجاح.

لقد أنشأت سير عمل متكاملاً آليًا لإدارة البيانات. بدأت باستخدام "طرق العرض المادية" لتسوية بيانات BigQuery المعقّدة، ما جعلها مناسبة للتحليل. بعد ذلك، أجريت عمليات فحص لملفات Knowledge Catalog الشخصية آليًا من أجل إنشاء بيانات وصفية إحصائية. والأهم من ذلك، أنّك استفدت من Antigravity CLI لتحليل ناتج الملف الشخصي وإنشاء عنصر dq_rules.yaml "سياسة كرمز" بذكاء. ثم استخدمت واجهة سطر الأوامر لنشر هذا الإعداد كعملية فحص تلقائية لجودة البيانات، ما يتيح لك إكمال دورة استراتيجية حوكمة حديثة وقابلة للتوسّع.

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

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

  • التكامل مع CI/CD: خذ ملف dq_rules.yaml واحفظه في مستودع Git. أنشئ مسار CI/CD (على سبيل المثال، باستخدام Cloud Build أو GitHub Actions) ينشر عملية فحص "كتالوج المعرفة" تلقائيًا كلما تم تعديل ملف القاعدة.
  • استكشاف قواعد SQL المخصّصة: يمكنك استخدام أنواع قواعد تتجاوز الأنواع العادية. يتيح "كتالوج المعرفة" استخدام قواعد SQL مخصّصة لفرض منطق أكثر تعقيدًا خاصًا بالنشاط التجاري ولا يمكن التعبير عنه باستخدام عمليات التحقّق المحدّدة مسبقًا. هذه ميزة لتخصيص عملية التحقّق وفقًا لمتطلباتك الفريدة.
  • تحسين عمليات البحث من أجل الكفاءة والتكلفة: بالنسبة إلى الجداول الكبيرة جدًا، يمكنك تحسين الأداء وتقليل التكاليف من خلال عدم البحث دائمًا في مجموعة البيانات بأكملها. استكشِف إمكانية استخدام الفلاتر لتضييق نطاق البحث إلى أُطر زمنية أو شرائح بيانات معيّنة، أو إعداد عمليات بحث مستنِدة إلى عيّنات للتحقّق من نسبة تمثيلية من بياناتك.
  • تصوُّر النتائج: تتم كتابة نتائج كل عملية فحص لجودة البيانات في "كتالوج المعرفة" في جدول BigQuery. اربط هذا الجدول بأداة Looker Studio لإنشاء لوحات بيانات تتتبّع نتائج جودة بياناتك بمرور الوقت، ويتم تجميعها حسب السمات التي حدّدتها (مثل الاكتمال والصحة). ويجعل ذلك عملية الرصد استباقية ومرئية لجميع الجهات المعنية.
  • مشاركة أفضل الممارسات: شجِّع على مشاركة المعلومات داخل مؤسستك للاستفادة من الخبرة الجماعية وتحسين استراتيجية جودة البيانات. إنّ تعزيز ثقافة الثقة في البيانات هو المفتاح للاستفادة إلى أقصى حد من جهود الإدارة.
  • قراءة المستندات: