Programmatic Data Quality with Dataplex and Generative AI

1. מבוא

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

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

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

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

מה תלמדו

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

מה צריך

• חשבון 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, חשוב מאוד לבצע אימות של ההצעות לפני הפריסה כדי לוודא שהן נכונות, רלוונטיות לעסק ובטוחות.

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

הפעלת Cloud Shell

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

ב-Google Cloud Console, לוחצים על סמל 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 ולוחצים על הכרטיסייה Schema (סכימה).

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

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

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

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

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

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

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

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

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

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

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

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

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;

עכשיו מריצים את התבניות האלה באמצעות כלי שורת הפקודה של bq. הפקודה 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 מציע דרך אינטראקטיבית ועוצמתית לשלב AI גנרטיבי ישירות בתהליכי העבודה שלכם בטרמינל. ‫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 כשמוצגת בקשה לעשות זאת. התוכנית החינמית מספיקה לתרגיל הזה.

אחרי שהתקנתם והגדרתם את ה-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=$REGION \
    --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=$REGION --project=$PROJECT_ID

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

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

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

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

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

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

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

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

• החולשה של מודלים של שפה גדולה: מודלים של שפה גדולה יכולים להיות "בטוחים בעצמם אבל טועים". הם יכולים ליצור הזיות או ליצור קוד שגוי בצורה עדינה. לדוגמה, יכול להיות שהכלי ייצור קובץ YAML עם כלל ששמו נכון אבל עם פרמטר לא תקין, או שהוא יאיית בצורה שגויה סוג כלל (למשל, ‫setExpectations במקום setExpectation הנכון). השגיאות האלה הן קטנות ויגרמו לפריסה להיכשל, אבל קשה לזהות אותן.
• התפקיד הקריטי של האדם: התפקיד שלך הוא לפעול ככלי האולטימטיבי לבדיקת קוד (linter) וככלי לאימות סכימות. צריך לבדוק בקפידה את קובץ ה-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 data-scans delete profile-scan-mv-ga4-user-session-flat \
    --location=us-central1 \
    --project=$PROJECT_ID --quiet

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

gcloud dataplex data-scans 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 ומבצעים לו קומיט למאגר Git. יוצרים צינור עיבוד נתונים של CI/CD (לדוגמה, באמצעות Cloud Build או GitHub Actions) שמבצע פריסה אוטומטית של סריקת Dataplex בכל פעם שקובץ הכללים מתעדכן.
• בדיקת כללי SQL בהתאמה אישית: אפשר להשתמש בכללים שאינם סטנדרטיים. ‫Dataplex תומך בכללי SQL מותאמים אישית כדי לאכוף לוגיקה מורכבת יותר שספציפית לעסק, ושאי אפשר לבטא אותה באמצעות בדיקות מוגדרות מראש. זוהי תכונה שימושית מאוד להתאמת האימות לדרישות הייחודיות שלכם.
• אופטימיזציה של הסריקות ליעילות ולחיסכון בעלויות: בטבלאות גדולות מאוד, אפשר לשפר את הביצועים ולהפחית את העלויות על ידי כך שלא תמיד תסרקו את מערך הנתונים כולו. אפשר להשתמש במסננים כדי לצמצם את הסריקה לפרקי זמן ספציפיים או לפלחי נתונים, או להגדיר סריקות מדגמיות כדי לבדוק אחוז מייצג של הנתונים.
• הדמיה של התוצאות: הפלט של כל סריקה של איכות הנתונים ב-Dataplex נכתב בטבלה ב-BigQuery. אפשר לקשר את הטבלה הזו ל-Looker Studio כדי ליצור מרכזי בקרה למעקב אחרי ציוני איכות הנתונים לאורך זמן, בצורה מצטברת לפי המאפיינים שהגדרתם (למשל, השלמות, התוקף). כך אפשר לעקוב אחרי התהליך באופן יזום וכל בעלי העניין יכולים לראות אותו.
• שיתוף שיטות מומלצות: כדאי לעודד שיתוף ידע בארגון כדי למנף את הניסיון המשותף ולשפר את האסטרטגיה שלכם לאיכות הנתונים. כדי להפיק את המרב ממאמצי הניהול, חשוב לטפח תרבות של אמון בנתונים.
• קוראים את התיעוד:
  • התיעוד הרשמי של Dataplex Data Quality
  • Gemini CLI: סוכן AI בקוד פתוח
  • דוגמת קוד ב-GitHub