Programmatic Data Quality with Dataplex and Generative AI

1. מבוא

ב-codelab הזה מוצג תרשים טכני לאנשי מקצוע בתחום הנתונים. הוא מתאר גישה של 'קוד קודם' למשילות מידע, ומראה איך להטמיע ניהול איכות ומטא-נתונים ישירות במחזור החיים של הפיתוח. בבסיסו, Dataplex Universal Catalog פועל כמארג נתונים חכם, שמאפשר לארגונים לנהל, לנטר ולשלוט בנתונים באופן מרכזי בכל הנכסים שלהם – מאגמי נתונים ועד מחסני נתונים.

ב-codelab מוצג איך להשתמש ב-Dataplex, ב-BigQuery וב-Gemini CLI כדי לשטח נתונים מורכבים, ליצור פרופיל של הנתונים באופן פרוגרמטי, ליצור הצעות חכמות לכללי איכות נתונים ולפרוס סריקות אוטומטיות של איכות הנתונים. המטרה העיקרית היא לעבור מתהליכים ידניים שמבוססים על ממשק משתמש – תהליכים שמועדים לשגיאות וקשה להרחיב אותם – ולבסס במקומם מסגרת חזקה של 'מדיניות כקוד' שאפשר לשלוט בגרסאות שלה.

דרישות מוקדמות

• הבנה בסיסית של מסוף Google Cloud
• מיומנויות בסיסיות בממשק שורת הפקודה וב-Google Cloud Shell

מה תלמדו

• איך משטחים נתונים מקוננים ב-BigQuery באמצעות תצוגות חומריות כדי לאפשר יצירת פרופיל מקיף.
• איך מפעילים ומנהלים סריקות של פרופילים ב-Dataplex באופן פרוגרמטי באמצעות ספריית הלקוח של Dataplex Python.
• איך לייצא נתוני פרופיל ולבנות אותם כקלט למודל AI גנרטיבי.
• איך ליצור הנחיה ל-Gemini CLI כדי לנתח נתוני פרופיל וליצור קובץ כללים בפורמט YAML שתואם ל-Dataplex.
• החשיבות של תהליך אינטראקטיבי של "האדם שבתהליך" (HITL) לאימות הגדרות שנוצרו על ידי AI.
• איך פורסים את הכללים שנוצרו כסריקה אוטומטית של איכות הנתונים.

מה תצטרכו

• חשבון Google Cloud ופרויקט Google Cloud
• דפדפן אינטרנט כמו Chrome

מושגי מפתח: עמודי התווך של איכות הנתונים ב-Dataplex

כדי לבנות אסטרטגיה יעילה לאיכות הנתונים, חשוב להבין את הרכיבים העיקריים של Dataplex.

• סריקת פרופיל נתונים: משימת Dataplex שמנתחת נתונים ומפיקה מטא-נתונים סטטיסטיים, כולל אחוזים של ערכי null, ספירות של ערכים ייחודיים והתפלגויות של ערכים. זהו שלב ה'גילוי' התוכניתי שלנו.
• כללים לאיכות הנתונים: הצהרות שבהן מוגדרים התנאים שהנתונים צריכים לעמוד בהם (לדוגמה, NonNullExpectation, SetExpectation, RangeExpectation).
• AI גנרטיבי להצעת כללים: שימוש במודל שפה גדול (כמו Gemini) כדי לנתח פרופיל נתונים ולהציע כללים רלוונטיים לאיכות הנתונים. כך אפשר לזרז את התהליך של הגדרת מסגרת איכות בסיסית.
• סריקה של איכות הנתונים: משימת Dataplex שמאמתת נתונים בהשוואה לקבוצה של כללים מוגדרים מראש או מותאמים אישית.
• משילות פרוגרמטית: הנושא המרכזי של ניהול אמצעי בקרה של משילות (כמו כללי איכות) כקוד (למשל, בקובצי YAML ובסקריפטים של Python). האפשרות הזו מאפשרת אוטומציה, ניהול גרסאות ושילוב בפייפליין של CI/CD.
• Human-in-the-Loop (HITL): נקודת בקרה קריטית לשילוב של מומחיות ופיקוח אנושיים בתהליך עבודה אוטומטי. במקרה של הגדרות שנוצרו על ידי AI, חשוב מאוד להשתמש ב-HITL כדי לוודא שההצעות נכונות, רלוונטיות לעסק ובטוחות לפני הפריסה.

2. הגדרה ודרישות

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-codelab הזה תשתמשו ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

יחלפו כמה רגעים עד שההקצאה והחיבור לסביבת העבודה יושלמו. בסיום התהליך, אמור להופיע משהו כזה:

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-codelab הזה בדפדפן. לא צריך להתקין שום דבר.

הפעלת ממשקי API נדרשים והגדרת הסביבה

ב-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="dataplex_dq_codelab"
export TABLE_ID="ga4_transactions"

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

בדוגמה אנחנו משתמשים במיקום us (מספר אזורים) כי נתוני הדוגמה הציבוריים שבהם נשתמש ממוקמים גם ב-us (מספר אזורים). ב-BigQuery, נתוני המקור והטבלה של היעד בשאילתה צריכים להיות באותו מיקום.

יצירת מערך נתונים ייעודי ב-BigQuery

יוצרים מערך נתונים חדש ב-BigQuery כדי לאחסן בו את הנתונים לדוגמה ואת התוצאות.

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

הכנת הנתונים לדוגמה

ב-Codelab הזה תשתמשו במערך נתונים ציבורי שמכיל נתונים מעורפלים של מסחר אלקטרוני מ-Google Merchandise Store. מערכי נתונים ציבוריים הם לקריאה בלבד, ולכן צריך ליצור עותק שניתן לשינוי במערך הנתונים שלכם. הפקודה הבאה של bq יוצרת טבלה חדשה, ga4_transactions, במערך הנתונים dataplex_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 שמכיל את מבנה התיקיות וקבצי התמיכה שנדרשים ל-Codelab הזה.

git clone https://github.com/GoogleCloudPlatform/devrel-demos
cd devrel-demos/data-analytics/programmatic-dq

הספרייה הזו היא עכשיו אזור העבודה הפעיל שלכם. כל הקבצים הבאים ייווצרו כאן.

3. גילוי נתונים אוטומטי באמצעות יצירת פרופילים ב-Dataplex

פרופיל נתונים ב-Dataplex הוא כלי רב עוצמה לגילוי אוטומטי של מידע סטטיסטי על הנתונים, כמו אחוזים של ערכי null, ייחודיות והתפלגות ערכים. התהליך הזה חיוני להבנת המבנה והאיכות של הנתונים. עם זאת, מגבלה ידועה של יצירת פרופילים ב-Dataplex היא חוסר היכולת לבדוק באופן מלא שדות מקוננים או שחוזרים על עצמם (למשל, סוגים RECORD או ARRAY) בטבלה. הוא יכול לזהות שעמודה היא מסוג מורכב, אבל הוא לא יכול ליצור פרופיל של השדות הנפרדים במבנה המקונן הזה.

כדי לפתור את הבעיה הזו, נשטח את הנתונים לתצוגות חומריות שנוצרו במיוחד למטרה הזו. בשיטה הזו כל שדה הופך לעמודה ברמה העליונה, וכך Dataplex יכול ליצור פרופיל לכל אחד מהם בנפרד.

הסבר על סכימה מקוננת

קודם כול, נבדוק את הסכימה של טבלת המקור. מערך הנתונים של Google Analytics 4‏ (GA4) מכיל כמה עמודות מקוננות וחוזרות. כדי לאחזר את הסכימה המלאה באופן פרוגרמטי, כולל כל המבנים המקוננים, אפשר להשתמש בפקודה bq show ולשמור את הפלט כקובץ JSON.

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

💡 כדאי לדעת: אפשר גם לעיין בסכימה המקוננת הזו באופן חזותי במסוף Google Cloud. עוברים אל BigQuery, מאתרים את מערך הנתונים dataplex_dq_codelab, בוחרים את הטבלה ga4_transactions ולוחצים על הכרטיסייה 'סכימה'.

בדיקה של הקובץ bq_schema.json מגלה מבנים מורכבים כמו מכשיר, מיקום גיאוגרפי, מסחר אלקטרוני ופריטי רשומה חוזרים. אלה המבנים שצריך לשטח כדי ליצור פרופיל יעיל.

השטחת נתונים באמצעות תצוגות חומריות

הפתרון הכי יעיל ופרקטי לבעיה הזו של נתונים מקוננים הוא ליצור תצוגות חומריות (MVs). התצוגות המומטריאליות מחשבות מראש את התוצאות המפושטות, ולכן הן מציעות יתרונות משמעותיים בביצועי השאילתות ובעלויות, וגם מספקות מבנה פשוט יותר שדומה למבנה יחסי עבור אנליסטים וכלי פרופילים.

המחשבה הראשונה שעולה בראש היא לשטח את הכול לתצוגה אחת ענקית. אבל, הגישה האינטואיטיבית הזו מסתירה מלכודת מסוכנת שעלולה לגרום לפגם חמור בנתונים. נבדוק למה מדובר בטעות קריטית.

💡 המלכודת של המכפלה הקרטזית: למה תצוגה שטוחה אחת לא מספיקה

כשמבטלים את הקינון של כמה מערכים בבת אחת כדי לשטח טבלה, נוצר מכפלה קרטזית (Cross Join). זו שגיאה קריטית שלא רק מאטה את השאילתות, אלא גם פוגעת בנתונים.

לדוגמה, אירוע יחיד עם 3 פריטים ו-5 פרמטרים יתפרס על פני 15 שורות. כתוצאה מכך, כל מדד ברמת האירוע (כמו הכנסה) יוכפל ב-15, וספירת האירועים תהיה חסרת תועלת. המשמעות של כל שורה לא ברורה.

האסטרטגיה הנכונה היא ליצור כמה תצוגות מפורטות שמותאמות למטרה מסוימת, כך שכל תצוגה מפורטת תשמור על רמת פירוט אנליטית ברורה אחת.

אפשר לחשוב על זה כעל 'נרמול מחדש' של טבלת GA4 הלא מנורמלת למטרות ניתוח שונות, בדומה לטבלאות נפרדות של הזמנות ופריטי הזמנה במסד נתונים מסורתי.

לכן, ב-Codelab הזה, נטמיע את האסטרטגיה הזו על ידי יצירת שלושה תצוגות חומריות נפרדות:

• תצוגת סשן: שורה אחת לכל אירוע.
• תצוגת עסקאות: שורה אחת לכל עסקה.
• תצוגת פריט: שורה אחת לכל פריט.

הגישה הזו מבטיחה שהנתונים יהיו מדויקים לצורך יצירת פרופילים וניתוח.

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`;

2. 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;

3. 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;

עכשיו מריצים את התבניות האלה באמצעות כלי שורת הפקודה של BigQuery. הפקודה envsubst תקרא כל קובץ, תחליף את המשתנים כמו $PROJECT_ID ו-$DATASET_ID בערכים שלהם מסביבת המעטפת שלכם, ותעביר את ה-SQL הסופי והתקין לפקודה bq query.

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

עכשיו, כשיש לנו תצוגות שטוחות שאפשר ליצור להן פרופילים, אנחנו יכולים ליצור ולהפעיל סריקות של פרופילי נתונים ב-Dataplex באופן אוטומטי לכל אחת מהן. הסקריפט הבא ב-Python משתמש בספריית הלקוח google-cloud-dataplex כדי לבצע אוטומציה של התהליך הזה.

לפני שמריצים את הסקריפט, מומלץ מאוד ליצור סביבת Python מבודדת בספריית הפרויקט. כך מוודאים שהתלויות של הפרויקט מנוהלות בנפרד, ומונעים התנגשויות עם חבילות אחרות בסביבת Cloud Shell.

# Create the virtual environment
python3 -m venv dq_venv

# Activate the environment
source dq_venv/bin/activate

עכשיו מתקינים את ספריית הלקוח של Dataplex בסביבה שהופעלה.

# Install the Dataplex client library
pip install google-cloud-dataplex

אחרי שמגדירים את הסביבה ומתקינים את הספרייה, אפשר ליצור את סקריפט התיזמור.

בסרגל הכלים של Cloud Shell, לוחצים על Open Editor (פתיחת העורך). יוצרים קובץ חדש בשם 1_run_dataplex_scans.py ומדביקים בו את קוד Python הבא. אם משכפלים את מאגר GitHub, הקובץ הזה כבר נמצא בתיקייה.

הסקריפט הזה ייצור סריקה לכל תצוגה חומרית (אם היא עדיין לא קיימת), יפעיל את הסריקה ואז יבצע בדיקה חוזרת עד שכל עבודות הסריקה יושלמו.

⚠️ בדיקת הסביבה

יכול להיות שסשנים ב-Cloud Shell יסתיימו בגלל חוסר פעילות. לפני שמריצים את הסקריפט, צריך לוודא שמשתני הסביבה מוגדרים בצורה נכונה. לשם כך, מריצים את הפקודה echo $PROJECT_ID. אם הפקודה מחזירה שורה ריקה, צריך להריץ מחדש את פקודות הייצוא מהקטע 'הגדרה ודרישות'.

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_dataplex_scans.py

הסקריפט ינהל עכשיו את יצירת הפרופילים של שלושת התצוגות החומריות, ויספק עדכוני סטטוס בזמן אמת. אחרי שתסיימו, יהיה לכם פרופיל סטטיסטי עשיר שניתן לקריאה על ידי מכונה לכל תצוגה, שמוכן לשלב הבא בתהליך העבודה שלנו: יצירת כללי איכות נתונים מבוססי-AI.

אפשר לראות את הסריקות שהושלמו של הפרופילים במסוף Google Cloud.

1. בתפריט הניווט, עוברים אל Dataplex Universal catalogue (קטלוג אוניברסלי של Dataplex) ואל Profile (פרופיל) בקטע Govern (ניהול).

2. אמורות להופיע שלוש סריקות של הפרופיל שלכם, לצד סטטוס המשרה האחרון שלהן. כדי לראות את התוצאות המפורטות, לוחצים על סריקה.

מפרופיל BigQuery לקלט שמוכן ל-AI

סריקות הפרופילים ב-Dataplex הסתיימו בהצלחה. התוצאות זמינות ב-Dataplex API, אבל כדי להשתמש בהן כקלט למודל AI גנרטיבי, צריך לחלץ אותן לקובץ מקומי מובנה.

הסקריפט הבא של Python, ‏ 2_dq_profile_save.py, מוצא באופן אוטומטי את העבודה האחרונה של סריקת הפרופיל שהסתיימה בהצלחה בתצוגה mv_ga4_user_session_flat שלנו. לאחר מכן, המערכת מאחזרת את התוצאה המלאה והמפורטת של הפרופיל ושומרת אותה כקובץ JSON מקומי בשם dq_profile_results.json. הקובץ הזה ישמש כקלט ישיר לניתוח ה-AI שלנו בשלב הבא.

ב-Cloud Shell Editor, יוצרים קובץ חדש בשם 2_dq_profile_save.py ומדביקים בו את הקוד הבא. בדומה לשלב הקודם, אם שיבטתם את המאגר, אתם יכולים לדלג על יצירת קובץ.

⚠️ בדיקת הסביבה

יכול להיות שסשנים ב-Cloud Shell יסתיימו בגלל חוסר פעילות. לפני שמריצים את הסקריפט, צריך לוודא שמשתני הסביבה מוגדרים בצורה נכונה. לשם כך, מריצים את הפקודה echo $PROJECT_ID. אם הפקודה מחזירה שורה ריקה, צריך להריץ מחדש את פקודות הייצוא מהקטע 'הגדרה ודרישות'.

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 Dataplex 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 'run_dataplex_scans.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. יצירת כללים לאיכות הנתונים באמצעות Gemini CLI

התקנה והגדרה של Gemini CLI

אפשר להפעיל את Gemini API באופן פרוגרמטי, אבל שימוש בכלי כמו Gemini CLI מאפשר לשלב בינה מלאכותית גנרטיבית ישירות בתהליכי העבודה בטרמינל בצורה אינטראקטיבית ויעילה. ‫Gemini CLI הוא לא רק צ'אט בוט, אלא כלי לתהליכי עבודה בשורת הפקודה שיכול לקרוא את הקבצים המקומיים שלכם, להבין את הקוד שלכם ולקיים אינטראקציה עם כלי מערכת אחרים, כמו gcloud, כדי לבצע אוטומציה של משימות מורכבות. לכן הוא אידיאלי לתרחיש לדוגמה שלנו.

דרישות מוקדמות

קודם כול, צריך לוודא שיש לכם את הדרישה המוקדמת הבאה: צריך להתקין בסביבת Cloud Shell את Node.js גרסה 20 ומעלה. כדי לבדוק את הגרסה, מריצים את הפקודה node -v.

התקנה

יש שתי דרכים להשתמש ב-Gemini CLI: התקנה זמנית או התקנה קבועה יותר. נפרט כאן את שתי השיטות.

אפשר להריץ את Gemini CLI ישירות בסשן יחיד בלי לבצע התקנה קבועה. זו הדרך הכי נקייה ומהירה לנסות את התכונה, כי הסביבה שלכם לא משתנה בכלל.

בטרמינל של Cloud Shell, מריצים את הפקודה:

npx https://github.com/google-gemini/gemini-cli

הפקודה הזו מורידה ומריצה באופן זמני את חבילת ה-CLI.

בכל פרויקט אמיתי, מומלץ להתקין את ה-CLI באופן מקומי בספריית הפרויקט. לגישה הזו יש כמה יתרונות מרכזיים:

• בידוד תלות: הוא מבטיח שלפרויקט תהיה גרסה משלו של ה-CLI, וכך מונע התנגשויות גרסאות עם פרויקטים אחרים.
• שחזור: כל מי שמשכפל את הפרויקט יכול להתקין את אותן תלויות בדיוק, כך שההגדרה שלכם אמינה וניידת.
• התאמה לשיטות מומלצות: הוא פועל לפי המודל הסטנדרטי לניהול תלות בפרויקט Node.js, וכך נמנע מטעויות נפוצות בהתקנות גלובליות (‎-g).

כדי להתקין את ה-CLI באופן מקומי, מריצים את הפקודה הבאה מתיקיית הפרויקט (programmatic-dq):

npm install @google/gemini-cli

הפעולה הזו יוצרת תיקייה בשם node_modules בתוך programmatic-dq. כדי להריץ את הגרסה שהתקנתם, משתמשים בפקודה npx.

npx gemini

הגדרה בפעם הראשונה

בכל שיטה שתבחרו, בפעם הראשונה שתפעילו את ה-CLI, תהליך ההגדרה יתבצע באופן חד-פעמי.

תתבקשו לבחור ערכת צבעים ואז לבצע אימות. השיטה הכי פשוטה היא להיכנס באמצעות חשבון Google כשמוצגת בקשה לעשות זאת. התוכנית החינמית מספיקה ל-Codelab הזה.

עכשיו, אחרי שהתקנתם והגדרתם את ה-CLI, אתם יכולים להמשיך ליצירת הכללים. ה-CLI מודע לקבצים בספרייה הנוכחית שלו, וזה חשוב מאוד לשלב הבא.

יצירת כללים לאיכות הנתונים

אפשר לבקש ממודל LLM ליצור קובץ תצורה בפעם אחת, אבל בגלל האופי הלא דטרמיניסטי של מודלים גנרטיביים, יכול להיות שהפלט לא תמיד יעמוד באופן מושלם בסכימה המחמירה שנדרשת על ידי כלים כמו gcloud. שיטה אמינה יותר היא תהליך אינטראקטיבי רב-שלבי, שבו קודם הבינה המלאכותית פועלת כאנליסט כדי להציע תוכנית, אתם (המומחים האנושיים) בודקים ומאשרים את התוכנית הזו, ורק אז הבינה המלאכותית יוצרת את הקוד הסופי על סמך ההוראות שאושרו על ידכם.

הגישה הזו הופכת את התהליך מפקודה פשוטה לסשן שיתופי, ומבטיחה שהפלט הסופי יהיה מדויק, מאומת ומוכן לפריסה.

קודם כל, נבקש מ-Gemini לנתח את הפרופיל הסטטיסטי ולפעול כמו מהנדס מערכות מידע מומחה, ולהציע תוכנית פעולה. אנחנו אומרים לו במפורש לא לכתוב את קובץ ה-YAML עדיין. הוא מתמקד בניתוח ובמתן הצדקה.

בסשן האינטראקטיבי של Gemini CLI, מדביקים את ההנחיה הבאה:

💡 טיפ לכתיבת הנחיות: שימו לב לשימוש ב-./dq_profile_results.json. כשמציינים את הנתיב באמצעות ./, אומרים ל-CLI לחפש את הקובץ בספריית העבודה הנוכחית. כך ההנחיה תהיה חזקה יותר ותעזור למנוע שגיאות אם ה-CLI הופעל בטעות מהמיקום הלא נכון.

You are an expert Google Cloud Dataplex engineer. 
Your first task is to create a plan. I have a file in the current directory named ./dq_profile_results.json. 
Based on the statistical data within that file, propose a step-by-step plan to create a Dataplex data quality rules file. 
Your plan should identify which specific columns are good candidates for rules like nonNullExpectation, setExpectation, or rangeExpectation, and explain why based on the metrics (e.g., "Plan to create a nonNullExpectation for column X because its null percentage is 0%"). 
Do not write the YAML file yet. Just provide the plan.

‫Gemini ינתח את קובץ ה-JSON ויחזיר תוכנית מובנית שדומה לזו:

Plan to create Dataplex data quality rules

1. Create a row count rule:
  - Analysis: The profile shows a total of 26,489 rows.
  - Proposed Rule: I will implement a rowCount rule to ensure the table's row count remains within a healthy range (e.g., 20,000 to 30,000). This is a fundamental check to guard against major data loading failures or unexpected deletions.
2. Implement non-null expectation rules:
  - Analysis: The profiling results show that many columns have no null values. For example, event_date, event_timestamp, event_name, user_pseudo_id, stream_id, and platform all appear to be fully populated.
  - Proposed Rules: I will create nonNullExpectation rules for columns where the nullRatio is 0 or not present, indicating they are always expected to contain a value:
    - event_date
    - event_timestamp
    - event_name
    - user_pseudo_id
    - stream_id
    - platform
    - device_category
    - device_os
3. Implement set expectation rules:
  - Analysis: Several columns contain a small, finite set of values, making them ideal for set validation.
  - Proposed Rules: I will create setExpectation rules for these columns:
    - platform: It only contains the value "WEB".
    - device_category: It contains only "desktop", "mobile", and "tablet".
    - geo_continent: It has a well-defined list of continents.
traffic_source_medium: It has a small list of valid mediums like "organic", "(none)", and "referral".
4. Implement range expectation rules:
  - Analysis: The profile provides minimum and maximum values for numeric and string length fields.
  - Proposed Rules: I will create rangeExpectation rules for the following:
    - event_timestamp: The profile shows a clear min and max. I will use these values to create a range check.
    - event_date (String Length): The profile indicates that the minLength and maxLength are both 8, which is perfect for enforcing a YYYYMMDD format.

זה השלב הכי חשוב בכל תהליך העבודה: הבדיקה של האדם שבתהליך (HITL). התוכנית שנוצרת על ידי Gemini מבוססת אך ורק על דפוסים סטטיסטיים בנתונים. הוא לא מבין את ההקשר העסקי שלכם, את השינויים בנתונים בעתיד או את הכוונה הספציפית מאחורי הנתונים. התפקיד שלכם כמומחים אנושיים הוא לאמת, לתקן ולאשר את התוכנית הזו לפני שתהפכו אותה לקוד.

חשוב לבדוק היטב את התוכנית ש-Gemini סיפק.

• האם זה הגיוני?
• האם התשובה תואמת לידע שלך על העסק?
• האם יש כללים שהם נכונים מבחינה סטטיסטית אבל חסרי תועלת מבחינה מעשית?

הפלט שתקבלו מ-Gemini עשוי להיות שונה. המטרה שלכם היא לשפר אותו.

לדוגמה, נניח שהתוכנית מציעה כלל rowCount כי בטבלה יש מספר קבוע של שורות בנתוני המדגם. כמומחים אנושיים, אתם יכולים לדעת שהגודל של הטבלה הזו צפוי לגדול מדי יום, ולכן כלל ספירת שורות מחמיר לא יהיה מעשי וסביר להניח שהוא יגרום להתראות שווא. זו דוגמה מצוינת להוספת הקשר עסקי שחסר ל-AI.

עכשיו תשלחו משוב ל-Gemini ותתנו לו את הפקודה הסופית ליצירת הקוד. צריך להתאים את ההנחיה הבאה בהתאם לתוכנית שקיבלת בפועל ולתיקונים שרוצים לבצע.

ההנחיה שבהמשך היא תבנית. בשורה הראשונה תציינו את התיקונים הספציפיים. אם התוכנית ש-Gemini יצר מושלמת ולא צריך לשנות אותה, אפשר פשוט למחוק את השורה הזו.

באותו סשן של Gemini, מדביקים את הגרסה המותאמת של ההנחיה הבאה:

[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'."]

Once you have incorporated my feedback, please generate the `dq_rules.yaml` file.

You must adhere to the following strict requirements:

- Schema Compliance: The YAML structure must strictly conform to the DataQualityRule specification. For a definitive source of truth, you must 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.

- Data-Driven Values: All rule parameters, such as thresholds or expected values, must be derived directly from the statistical metrics in dq_profile_results.json.

- Rule Justification: For each rule, add a comment (#) on the line above explaining the justification, as you outlined in your plan.

- Output Purity: The final output must only be the raw YAML code block, perfectly formatted and ready for immediate deployment.

‫Gemini ייצור עכשיו את תוכן ה-YAML על סמך ההוראות המדויקות שלכם, שעברו אימות על ידי בני אדם. בסיום, קובץ חדש בשם dq_rules.yaml יופיע בספרייה הפעילה.

יצירה והפעלה של סריקת איכות הנתונים

עכשיו, אחרי שיש לכם קובץ dq_rules.yaml שנוצר על ידי AI ואומת על ידי אדם, אתם יכולים לפרוס אותו בביטחון.

כדי לצאת מ-Gemini CLI, מקלידים /quit או לוחצים פעמיים על Ctrl+C.

הפקודה הבאה ב-gcloud יוצרת משאב חדש של סריקת נתונים ב-Dataplex. הסריקה עדיין לא מופעלת, אלא רק ההגדרה והתצורה שלה (קובץ ה-YAML) נרשמות ב-Dataplex.

מריצים את הפקודה הבאה במסוף:

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

הפקודה הזו תחזיר מזהה של משימה. אפשר לעקוב אחרי הסטטוס של העבודה הזו בקטע Dataplex במסוף Google Cloud. בסיום, התוצאות ייכתבו לטבלה ב-BigQuery לצורך ניתוח.

5. התפקיד הקריטי של האדם שבתהליך (HITL)

השימוש ב-Gemini כדי להאיץ את יצירת הכללים הוא יעיל מאוד, אבל חשוב להתייחס ל-AI כאל טייס משנה מיומן מאוד, ולא כאל טייס אוטונומי לחלוטין. תהליך האדם שבתהליך (HITL) הוא לא הצעה אופציונלית, אלא שלב בסיסי שאי אפשר לוותר עליו בכל תהליך עבודה מהימן ומוצק של משילות מידע (data governance). פריסת ארטיפקטים שנוצרו על ידי AI בלי פיקוח אנושי קפדני היא מתכון לכישלון.

אפשר לחשוב על dq_rules.yaml שנוצר על ידי AI כעל בקשת משיכה שנשלחה על ידי מפתח AI מהיר מאוד אבל חסר ניסיון. לפני שניתן למזג את ההמלצה עם 'הסתעפות ראשית' של מדיניות השליטה ולפרוס אותה, נדרשת בדיקה יסודית של מומחה אנושי בכיר – אתם. הביקורת הזו חשובה כדי לצמצם את החולשות המובנות של מודלים גדולים של שפה (LLM).

בהמשך מפורטות הסיבות שבגללן הבדיקה האנושית הזו חיונית, וגם מה בדיוק צריך לבדוק:

1. אימות הקשרי: ל-AI אין מודעות עסקית

• החולשה של מודל LLM: מודל LLM מצטיין בזיהוי דפוסים ובסטטיסטיקה, אבל אין לו שום הבנה של ההקשר העסקי שלכם. לדוגמה, אם בעמודה new_campaign_id יש יחס של 98% ערכי null, יכול להיות שמודל LLM יתעלם מהעמודה הזו מסיבה סטטיסטית.
• התפקיד הקריטי של האדם: אתם, המומחים האנושיים, יודעים שהשדה new_campaign_id נוסף רק אתמול לקראת השקת מוצר חשובה בשבוע הבא. אתם יודעים שיחס הערכים הריקים צריך להיות גבוה עכשיו, אבל צפוי לרדת באופן משמעותי. אתם גם יודעים שאחרי שהמאפיין יאוכלס, הוא חייב להיות בפורמט מסוים. ה-AI לא יכול להסיק את הידע הזה על העסק החיצוני. התפקיד שלכם הוא להחיל את ההקשר העסקי הזה על ההצעות הסטטיסטיות של ה-AI, ולשנות אותן או להוסיף להן פרטים לפי הצורך.

2. נכונות ודיוק: הגנה מפני הזיות ושגיאות קלות

• החולשה של מודלים של שפה גדולה: מודלים של שפה גדולה יכולים להיות "בטוחים בעצמם אבל טועים". הם יכולים ליצור הזיות או ליצור קוד שגוי בצורה עדינה. לדוגמה, יכול להיות שהכלי ייצור קובץ YAML עם כלל ששמו נכון אבל עם פרמטר לא תקין, או שהוא יקליד לא נכון סוג כלל (למשל, setExpectations במקום setExpectation). קשה לזהות את השגיאות האלה, אבל הן יגרמו לפריסה להיכשל.
• התפקיד הקריטי של האדם: התפקיד שלך הוא לפעול ככלי האולטימטיבי לבדיקת קוד ולבדיקת סכימה. חשוב לבדוק בקפידה את קובץ ה-YAML שנוצר מול DataQualityRuleהמפרט הרשמי של Dataplex. אתם לא רק בודקים אם זה "נראה נכון", אלא מוודאים שהתחביר והסמנטיקה נכונים, כדי לוודא שהקוד תואם ב-100% ל-API של היעד. לכן, ב-Codelab Gemini מתבקש להתייחס לקובצי הסכימה כדי להקטין את הסיכוי לשגיאה, אבל האימות הסופי תלוי בכם.

3. בטיחות וצמצום סיכונים: מניעת השלכות בהמשך

• החולשה של מודל ה-LLM: אם כלל לאיכות נתונים עם פגמים נפרס בסביבת הייצור, יכולות להיות לכך השלכות חמורות. אם ה-AI מציע rangeExpectation לסכום של עסקה פיננסית שהוא רחב מדי, יכול להיות שהוא לא יזהה פעילות שמקורה בתרמית. לעומת זאת, אם המערכת מציעה כלל מחמיר מדי על סמך מדגם נתונים קטן, היא עלולה להציף את הצוות התורן באלפי התראות חיוביות כוזבות, מה שיוביל לעייפות מהתראות ולפספוס של בעיות אמיתיות.
• התפקיד הקריטי של האדם: אתם מהנדסי הבטיחות. חשוב להעריך את ההשפעה הפוטנציאלית של כל כלל שה-AI מציע. תשאלו את עצמכם: "מה יקרה אם הכלל הזה ייכשל? האם אפשר לבצע פעולה בעקבות ההתראה? מה הסיכון אם הכלל הזה יעבור באופן שגוי?" הערכת הסיכון הזו היא יכולת ייחודית של בני אדם, שבה נשקלת העלות של כישלון לעומת התועלת של הבדיקה.

4. ניהול כהליך מתמשך: שילוב של ידע צופה פני עתיד

• החולשה של ה-LLM: הידע של ה-AI מבוסס על תמונת מצב סטטית של הנתונים – התוצאות של הפרופיל הן מנקודת זמן ספציפית. אין לו מידע על אירועים עתידיים.
• התפקיד הקריטי של בני אדם: אסטרטגיית הממשל שלכם צריכה להיות ממוקדת בעתיד. אתם יודעים שמקור נתונים מתוזמן להעברה בחודש הבא, ושהפעולה הזו תשנה את stream_id. אתם יודעים שמדינה חדשה נוספת לרשימה geo_country. בתהליך HITL, אתם יכולים להוסיף את הידע הזה לגבי המצב העתידי, לעדכן כללים או להשבית אותם באופן זמני כדי למנוע שיבושים במהלך שינויים מתוכננים בפעילות העסקית או בטכנולוגיה. איכות הנתונים היא לא הגדרה חד-פעמית, אלא תהליך מתמשך שצריך להתפתח, ורק בן אדם יכול להנחות את ההתפתחות הזו.

לסיכום, HITL הוא מנגנון חיוני לבקרת איכות ולבטיחות, שהופך את הרעיון החדשני אך המסוכן של ניהול מבוסס-AI לשיטה אחראית, ניתנת להרחבה ומתאימה לארגונים. כך אנחנו מוודאים שהמדיניות הסופית שמוטמעת לא רק מבוססת על AI, אלא גם מאומתת על ידי אנשים. אנחנו משלבים בין המהירות של המכונות לבין החוכמה וההקשר של מומחים אנושיים.

עם זאת, הדגש הזה על פיקוח אנושי לא מפחית מהערך של ה-AI. להפך, ל-AI הגנרטיבי יש תפקיד חשוב בהאצת תהליך ה-HITL עצמו.

בלי ה-AI, מהנדס מערכות מידע יצטרך:

1. לכתוב באופן ידני שאילתות SQL מורכבות כדי ליצור פרופיל של הנתונים (לדוגמה, COUNT DISTINCT, AVG, MIN, MAX לכל עמודה).
2. לנתח בקפידה את התוצאות בגיליון האלקטרוני.
3. לכתוב כל שורה בקובץ הכללים של YAML מאפס, משימה מייגעת שעלולה להוביל לשגיאות.

ה-AI מבצע את השלבים המייגעים האלה באופן אוטומטי. הוא פועל כנתח נתונים חרוץ שמנתח באופן מיידי את הפרופיל הסטטיסטי ומספק טיוטה ראשונה של המדיניות, שהיא מובנית היטב וכוללת 80% מהמידע.

השינוי הזה משנה באופן מהותי את אופי העבודה של בני האדם. במקום להשקיע שעות בניתוח נתונים ידני ובכתיבת קוד סטנדרטי, המומחה האנושי יכול להתמקד מיד במשימות בעלות הערך הגבוה ביותר:

• החלת הקשר עסקי קריטי.
• אימות הנכונות של הלוגיקה של ה-AI.
• לקבל החלטות אסטרטגיות לגבי הכללים שבאמת חשובים.

במסגרת השותפות הזו, ה-AI מטפל בשאלה 'מה' (מהם הדפוסים הסטטיסטיים?), וכך מאפשר לאדם להתמקד בשאלה 'למה' (למה הדפוס הזה חשוב לעסק שלנו?) ובשאלה 'אז מה' (אז מה צריכה להיות המדיניות שלנו?). לכן, ה-AI לא מחליף את הלולאה, אלא מייעל את כל מחזור הלולאה, כך שהוא מהיר יותר, חכם יותר ומשפיע יותר.

6. פינוי מקום בסביבה

כדי להימנע מחיובים עתידיים בחשבון Google Cloud על המשאבים שבהם השתמשתם ב-codelab הזה, אתם צריכים למחוק את הפרויקט שמכיל את המשאבים. עם זאת, אם רוצים לשמור את הפרויקט, אפשר למחוק את המשאבים הבודדים שיצרתם.

מחיקת הסריקות של Dataplex

קודם צריך למחוק את הפרופיל ואת סריקות האיכות שיצרתם. כדי למנוע מחיקה לא מכוונת של משאבים חשובים, הפקודות האלה משתמשות בשמות הספציפיים של הסריקות שנוצרו ב-codelab הזה.

# 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 (force)‎ כדי להסיר את מערך הנתונים ואת כל הטבלאות שלו ללא אישור.

⚠️ אזהרה: כדי למנוע אובדן נתונים לא מכוון, מומלץ להקליד את הפקודה הבאה באופן ידני במקום להעתיק ולהדביק אותה, ולוודא ששם מערך הנתונים נכון.

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

7. מעולה!

סיימתם בהצלחה את ה-Codelab!

יצרתם תהליך עבודה של משילות מידע מקצה לקצה, שמתבצע באופן אוטומטי. התחלתם בשימוש בתצוגות חומריות כדי לשטח נתונים מורכבים ב-BigQuery, וכך להפוך אותם למתאימים לניתוח. לאחר מכן הפעלתם סריקות של פרופילים ב-Dataplex באופן פרוגרמטי כדי ליצור מטא-נתונים סטטיסטיים. והכי חשוב, השתמשתם ב-Gemini CLI כדי לנתח את הפלט של הפרופיל וליצור באופן חכם ארטיפקט של 'מדיניות כקוד' (dq_rules.yaml). לאחר מכן השתמשתם ב-CLI כדי לפרוס את ההגדרה הזו כסריקה אוטומטית של איכות הנתונים, וכך סגרתם את הלולאה של אסטרטגיית ניהול מודרנית וניתנת להרחבה.

עכשיו יש לכם את התבנית הבסיסית לבניית מערכות אמינות לשיפור איכות הנתונים ב-Google Cloud, שמבוססות על AI ומאומתות על ידי בני אדם.

מה השלב הבא?

• שילוב עם CI/CD: לוקחים את הקובץ dq_rules.yaml ומבצעים commit שלו למאגר Git. יוצרים צינור עיבוד נתונים של CI/CD (לדוגמה, באמצעות Cloud Build או GitHub Actions) שמבצע פריסה אוטומטית של סריקת Dataplex בכל פעם שקובץ הכללים מתעדכן.
• היכרות עם כללי SQL בהתאמה אישית: אפשר להשתמש בכללים שאינם סטנדרטיים. ‫Dataplex תומך בכללי SQL מותאמים אישית כדי לאכוף לוגיקה מורכבת יותר שספציפית לעסק, שלא ניתן לבטא באמצעות בדיקות מוגדרות מראש. זוהי תכונה שימושית מאוד להתאמת האימות לדרישות הייחודיות שלכם.
• אופטימיזציה של הסריקות ליעילות ולחיסכון בעלויות: בטבלאות גדולות מאוד, אפשר לשפר את הביצועים ולהפחית את העלויות על ידי כך שלא תמיד תסרקו את מערך הנתונים כולו. כדאי לנסות להשתמש במסננים כדי לצמצם את הסריקה לפרקי זמן ספציפיים או לפלחי נתונים, או להגדיר סריקות מדגמיות כדי לבדוק אחוז מייצג של הנתונים.
• הדמיה של התוצאות: הפלט של כל סריקת איכות נתונים ב-Dataplex נכתב בטבלה ב-BigQuery. אפשר לחבר את הטבלה הזו ל-Looker Studio כדי ליצור מרכזי בקרה למעקב אחרי ציוני איכות הנתונים לאורך זמן, בצורה מצטברת לפי המאפיינים שהגדרתם (למשל, שלמות, תוקף). כך אפשר לעקוב אחרי התהליך באופן יזום וכל בעלי העניין יכולים לראות אותו.
• שיתוף שיטות מומלצות: כדאי לעודד שיתוף ידע בארגון כדי למנף את הניסיון המשותף ולשפר את האסטרטגיה שלכם לאיכות הנתונים. כדי להפיק את המרב ממאמצי הניהול, חשוב לטפח תרבות של אמון בנתונים.
• קוראים את התיעוד:
  • מאמרי העזרה הרשמיים בנושא Dataplex Data Quality
  • ‫Gemini CLI: סוכן AI בקוד פתוח
  • דוגמת קוד ב-GitHub