1. מבוא
ה-Codelab הזה מספק תוכנית טכנית לאנשי מקצוע בתחום הנתונים. הוא מתאר גישה של 'קוד קודם' למשילות מידע (data governance), ומראה איך להטמיע ניהול חזק של איכות ומטא-נתונים ישירות במחזור החיים של הפיתוח. בבסיסו, Knowledge Catalog פועל כמארג נתונים חכם, שמאפשר לארגונים לנהל, לנטר ולשלוט בנתונים באופן מרכזי בכל הנכסים שלהם, מאגמי נתונים ועד מחסני נתונים.
ב-Codelab הזה נסביר איך להשתמש ב-Knowledge Catalog, ב-BigQuery וב-Antigravity CLI כדי לשטח נתונים מורכבים, ליצור פרופיל נתונים באופן פרוגרמטי, ליצור הצעות חכמות לכללי איכות נתונים ולפרוס סריקות אוטומטיות של איכות הנתונים. המטרה העיקרית היא לעבור מתהליכים ידניים שמבוססים על ממשק משתמש, שנוטים לשגיאות וקשה להרחיב אותם, ולבסס במקומם מסגרת אמינה של 'מדיניות כקוד' שאפשר לשלוט בגרסאות שלה.
מה תלמדו
- איך לשטח נתונים מקוננים ב-BigQuery באמצעות תצוגות חומריות כדי לאפשר פרופיל מקיף.
- איך מפעילים ומנהלים סריקות של פרופילים ב-Knowledge Catalog באופן פרוגרמטי באמצעות ספריית הלקוח של Knowledge Catalog ב-Python.
- איך לייצא נתוני פרופיל ולבנות אותם כקלט למודל AI גנרטיבי.
- איך ליצור הנחיה ל-Antigravity CLI כדי לנתח נתוני פרופיל וליצור קובץ כללים בפורמט YAML שתואם לקטלוג הידע.
- החשיבות של תהליך אינטראקטיבי עם מעורבות אנושית (HITL) לאימות הגדרות שנוצרו על ידי AI.
- איך פורסים את הכללים שנוצרו כסריקה אוטומטית של איכות הנתונים.
הדרישות
- חשבון Google Cloud ופרויקט Google Cloud
- דפדפן אינטרנט כמו Chrome
מושגי מפתח: עמודי התווך של איכות הנתונים ב-Knowledge Catalog
כדי לבנות אסטרטגיה יעילה לאיכות הנתונים, חשוב להבין את הרכיבים המרכזיים של Knowledge Catalog.
- סריקת פרופיל נתונים: משימה ב-Knowledge Catalog שמנתחת נתונים ומפיקה מטא-נתונים סטטיסטיים, כולל אחוזים של ערכי null, ספירות של ערכים ייחודיים והתפלגויות של ערכים. זהו שלב ה'גילוי' הפרוגרמטי שלנו.
- כללים לאיכות הנתונים: הצהרות שבהן מוגדרים התנאים שהנתונים צריכים לעמוד בהם (לדוגמה,
NonNullExpectation,SetExpectation,RangeExpectation). - AI גנרטיבי להצעת כללים: שימוש במודל שפה גדול (כמו Gemini) כדי לנתח פרופיל נתונים ולהציע כללים רלוונטיים לאיכות הנתונים. כך אפשר לזרז את התהליך של הגדרת מסגרת איכות בסיסית.
- סריקת איכות נתונים: משימה של Knowledge Catalog שמאמתת נתונים מול קבוצה של כללים מוגדרים מראש או מותאמים אישית.
- משילות פרוגרמטית: הנושא המרכזי של ניהול אמצעי בקרה של משילות (כמו כללי איכות) כקוד (למשל, בקובצי 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="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
הכנת נתונים לדוגמה
ב-Codelab הזה תשתמשו בקבוצת נתונים ציבורית שמכילה נתוני מסחר אלקטרוני מעורפלים מ-Google Merchandise Store. מערכי נתונים ציבוריים הם לקריאה בלבד, ולכן צריך ליצור עותק שניתן לשינוי במערך הנתונים שלכם. הפקודה הבאה של 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 שמכיל את מבנה התיקיות וקבצי התמיכה שנדרשים ל-codelab הזה.
# 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. גילוי נתונים אוטומטי באמצעות פרופילים של Knowledge Catalog
פרופיל נתונים ב-Knowledge Catalog הוא כלי רב עוצמה לגילוי אוטומטי של מידע סטטיסטי על הנתונים, כמו אחוזים של ערכי null, ייחודיות והתפלגות ערכים. התהליך הזה חיוני להבנת המבנה והאיכות של הנתונים. עם זאת, מגבלה ידועה של יצירת פרופילים ב-Knowledge Catalog היא חוסר היכולת לבדוק באופן מלא שדות מקוננים או שחוזרים על עצמם (למשל, סוגים RECORD או ARRAY) בתוך טבלה. הוא יכול לזהות שעמודה היא מסוג מורכב, אבל הוא לא יכול ליצור פרופיל של השדות הנפרדים בתוך המבנה המקונן הזה.
כדי לפתור את הבעיה הזו, נשטח את הנתונים לתצוגות חומריות שנוצרו במיוחד למטרה הזו. בשיטה הזו, כל שדה הופך לעמודה ברמה העליונה, וכך Knowledge Catalog יכול ליצור פרופיל לכל אחד מהם בנפרד.
הסבר על סכימה מקוננת
קודם כול, נבדוק את הסכימה של טבלת המקור שלנו. מערך הנתונים של Google Analytics 4 (GA4) מכיל כמה עמודות מקוננות וחוזרות. כדי לאחזר את הסכימה המלאה באופן פרוגרמטי, כולל כל המבנים המקוננים, אפשר להשתמש בפקודה bq show ולשמור את הפלט כקובץ JSON.
bq show --schema --format=json $PROJECT_ID:$DATASET_ID.$TABLE_ID > bq_schema.json
בדיקה של הקובץ bq_schema.json מגלה מבנים מורכבים כמו device, geo, ecommerce ופריטי רשומה שחוזרים על עצמם. אלה המבנים שצריך לשטח כדי ליצור פרופיל יעיל.
השטחת נתונים באמצעות תצוגות מהותיות
הפתרון הכי יעיל ופרקטי לבעיה של נתונים מקוננים הוא ליצור תצוגות חומריות (MVs). התצוגות המומלצות מראש מציעות יתרונות משמעותיים בביצועי השאילתות ובעלות, וגם מספקות למנתחים ולכלי פרופילים מבנה פשוט יותר שדומה למבנה יחסי.
המחשבה הראשונה שעולה בראש היא לשטח את הכול לתצוגה אחת ענקית. עם זאת, הגישה האינטואיטיבית הזו מסתירה מלכודת מסוכנת שעלולה להוביל לפגיעה חמורה בנתונים. נבדוק למה מדובר בטעות קריטית.
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`;
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;
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
עכשיו, אחרי שיש לנו תצוגות שטוחות שאפשר ליצור מהן פרופילים, אנחנו יכולים ליצור ולהפעיל באופן אוטומטי סריקות של פרופילי נתונים ב-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, לוחצים על Open Editor (פתיחת העורך). יוצרים קובץ חדש בשם 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
הסקריפט ינהל עכשיו את יצירת הפרופילים של שלושת התצוגות החומריות, ויספק עדכוני סטטוס בזמן אמת. אחרי שתסיימו, תקבלו פרופיל סטטיסטי עשיר שניתן לקריאה על ידי מכונה לכל תצוגה, שמוכן לשלב הבא בתהליך העבודה שלנו: יצירת כללים לאיכות נתונים מבוססי-AI.
אפשר לראות את הסריקות שהושלמו של הפרופילים במסוף Google Cloud.
- בתפריט הניווט, עוברים אל Knowledge Catalog וData profiling & quality בקטע Govern.
- שלושת סריקות הפרופיל אמורות להופיע ברשימה, לצד סטטוס המשרה האחרון שלהן. כדי לראות את התוצאות המפורטות, לוחצים על סריקה.
מפרופיל BigQuery לקלט מוכן ל-AI
הסריקות של הפרופילים ב-Knowledge Catalog הסתיימו בהצלחה. התוצאות זמינות ב-Knowledge Catalog 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 ומדביקים בו את הקוד הבא. בדומה לשלב הקודם, אפשר לדלג על יצירת קובץ אם שיבטתם את המאגר.
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) כדי לקרוא את תוצאות הסריקה של הפרופיל המקומי. כתיבה ידנית של מפרטים לאיכות הנתונים עבור מערכי נתונים מורכבים היא תהליך שגוזל זמן ומועד לשגיאות. שימוש בסוכן AI גנרטיבי בטרמינל מזרז את תהליך העבודה הזה, כי הוא יוצר טיוטה של הגדרה הצהרתית תוך שניות. כך צוותי נתונים יכולים לעבור מניסוח תחביר ידני לפיקוח ברמה גבוהה של Human-in-the-Loop (HITL) שמותאם לעסק.
כדי להפעיל את Antigravity CLI, מריצים את הפקודה הבאה בטרמינל:
agy
עכשיו אפשר ליצור כללי איכות. מכיוון ש-CLI יכול לקרוא קבצים בספרייה הנוכחית, הוא יכול להשתמש ישירות בנתוני הסריקה של הפרופיל החדש.
הנחיה של הסוכן ליצור תוכנית
קודם כל, נבקש מסוכן 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 כי בטבלה יש מספר קבוע של שורות בנתוני המדגם. כמומחים אנושיים, אתם יודעים שהגודל של הטבלה הזו צפוי לגדול מדי יום, ולכן כלל ספירת שורות מחמיר לא יהיה מעשי וסביר להניח שהוא יוביל להתראות שווא. זו דוגמה מצוינת להוספת הקשר עסקי שחסר ל-AI.
עכשיו תשלחו משוב לסוכן ותתנו לו את הפקודה הסופית ליצירת הקוד. צריך להתאים את ההנחיה הבאה לתוכנית שקיבלתם בפועל ולתיקונים שאתם רוצים לבצע.
ההנחיה שבהמשך היא תבנית. בשורה הראשונה תציינו את התיקונים הספציפיים. אם התוכנית שהנציג נתן לכם מושלמת ולא צריך לשנות בה כלום, אתם יכולים פשוט למחוק את השורה הזו.
באותו סשן של 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 CLI, מקלידים /quit או לוחצים על Ctrl+C פעמיים.
הפקודה הבאה ב-gcloud יוצרת משאב חדש של סריקת נתונים ב-Knowledge Catalog. הסריקה עדיין לא מופעלת, אלא רק ההגדרה והתצורה שלה (קובץ ה-YAML) נרשמות ב-Knowledge Catalog.
מריצים את הפקודה הבאה במסוף:
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
הפקודה הזו תחזיר מזהה של משימה. אפשר לעקוב אחרי הסטטוס של העבודה הזו בקטע Knowledge Catalog במסוף Google Cloud. בסיום, התוצאות ייכתבו לטבלה ב-BigQuery לצורך ניתוח.
5. התפקיד הקריטי של האדם שבתהליך (HITL)
השימוש בסוכן Antigravity כדי להאיץ את יצירת הכללים הוא יעיל מאוד, אבל חשוב להתייחס ל-AI כאל טייס משנה מיומן מאוד, ולא כאל טייס אוטומטי לגמרי. תהליך Human-in-the-Loop (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). קשה לזהות את השגיאות האלה, אבל הן יגרמו לפריסה להיכשל. - התפקיד הקריטי של האדם: התפקיד שלך הוא לפעול ככלי האולטימטיבי לבדיקת קוד (linter) וככלי לאימות סכימות. צריך לבדוק בקפידה את קובץ ה-YAML שנוצר מול המפרט הרשמי של Knowledge Catalog
DataQualityRule. אתם לא רק בודקים אם זה "נראה נכון", אלא גם מוודאים שהתחביר והסמנטיקה נכונים, כדי לוודא שהקוד תואם ב-100% ל-API של היעד. לכן, ה-Codelab מבקש מהסוכן להתייחס לקובצי הסכימה כדי להקטין את הסיכוי לשגיאה, אבל האימות הסופי תלוי בכם.
3. בטיחות וצמצום סיכונים: מניעת השלכות בהמשך
- החולשה של מודל ה-LLM: כלל פגום לאיכות נתונים שמוטמע בסביבת הייצור עלול להוביל להשלכות חמורות. אם ה-AI מציע
rangeExpectationלסכום של עסקה פיננסית שהוא רחב מדי, יכול להיות שהוא לא יזהה פעילות שמקורה בתרמית. לעומת זאת, אם המערכת מציעה כלל מחמיר מדי על סמך מדגם נתונים קטן, היא עלולה להציף את הצוות התורן באלפי התראות חיוביות שגויות, מה שיוביל לתשישות מהתראות ולפספוס של בעיות אמיתיות. - התפקיד הקריטי של האדם: אתה מהנדס הבטיחות. חשוב להעריך את ההשפעה הפוטנציאלית של כל כלל שה-AI מציע. תשאלו את עצמכם: "מה קורה אם הכלל הזה נכשל? האם אפשר לבצע פעולה בעקבות ההתראה? מה הסיכון אם הכלל הזה יעבור באופן שגוי?" הערכת הסיכון הזו היא יכולת ייחודית של בני אדם, שבה נשקלת עלות הכישלון מול התועלת של הבדיקה.
4. ניהול כהליך מתמשך: שילוב ידע צופה פני עתיד
- החולשה של ה-LLM: הידע של ה-AI מבוסס על תמונת מצב סטטית של הנתונים – התוצאות של הפרופיל הן מנקודת זמן ספציפית. אין לו מידע על אירועים עתידיים.
- התפקיד הקריטי של האדם: אסטרטגיית השליטה שלכם צריכה להיות ממוקדת בעתיד. אתם יודעים שמקור נתונים מתוזמן להעברה בחודש הבא, ושהפעולה הזו תשנה את stream_id. אתם יודעים שמדינה חדשה נוספת לרשימה
geo_country. בתהליך HITL, אתם משלבים את הידע הזה לגבי המצב העתידי, מעדכנים כללים או משביתים אותם באופן זמני כדי למנוע שיבושים במהלך התפתחויות עסקיות או טכניות מתוכננות. איכות הנתונים היא לא הגדרה חד-פעמית, אלא תהליך מתמשך שצריך להתפתח, ורק בן אדם יכול להנחות את ההתפתחות הזו.
לסיכום, HITL הוא מנגנון חיוני להבטחת איכות ובטיחות, שהופך את הרעיון החדשני אך המסוכן של ניהול מבוסס-AI לשיטה אחראית, ניתנת להרחבה ומתאימה לארגונים. התהליך הזה מבטיח שהמדיניות הסופית שתופעל לא רק תואץ על ידי AI, אלא גם תאומת על ידי בני אדם, כך שמהירות המכונות תשתלב עם החוכמה וההקשר של מומחים אנושיים.
עם זאת, הדגש הזה על פיקוח אנושי לא מפחית מהערך של ה-AI. להפך, ל-AI הגנרטיבי יש תפקיד חשוב בהאצת תהליך ה-HITL עצמו.
בלי ה-AI, מהנדס נתונים צריך:
- לכתוב ידנית שאילתות SQL מורכבות כדי ליצור פרופיל של הנתונים (לדוגמה,
COUNT DISTINCT, AVG, MIN, MAXלכל עמודה). - לנתח את התוצאות בגיליון האלקטרוני בקפדנות.
- לכתוב כל שורה בקובץ הכללים של YAML מאפס, משימה מייגעת שעלולה להוביל לשגיאות.
ה-AI מבצע את השלבים המייגעים והגוזלים זמן האלה באופן אוטומטי. הוא פועל כנתח נתונים חרוץ שמבצע עיבוד מיידי של הפרופיל הסטטיסטי ומספק טיוטה ראשונה של המדיניות, שהיא מובנית היטב וכוללת 80% מהמידע.
השינוי הזה משנה באופן מהותי את אופי העבודה של בני האדם. במקום להשקיע שעות בניתוח נתונים ידני ובכתיבת קוד סטנדרטי, המומחה האנושי יכול להתמקד מיד במשימות בעלות הערך הגבוה ביותר:
- החלת הקשר עסקי קריטי.
- אימות הנכונות של הלוגיקה של ה-AI.
- לקבל החלטות אסטרטגיות לגבי הכללים שחשובים באמת.
במסגרת השותפות הזו, ה-AI מטפל בשאלה 'מה' (מהם הדפוסים הסטטיסטיים?), וכך מאפשר לאדם להתמקד בשאלה 'למה' (למה הדפוס הזה חשוב לעסק שלנו?) ובשאלה 'אז מה' (אז מה צריכה להיות המדיניות שלנו?). לכן, ה-AI לא מחליף את הלולאה, אלא מייעל את כל מחזור הלולאה, משפר את האיכות שלו ומשפיע יותר.
6. ניקוי הסביבה
כדי להימנע מחיובים עתידיים בחשבון Google Cloud על המשאבים שבהם השתמשתם ב-codelab הזה, אתם צריכים למחוק את הפרויקט שמכיל את המשאבים. עם זאת, אם רוצים לשמור את הפרויקט, אפשר למחוק את המשאבים הבודדים שיצרתם.
מחיקת הסריקות של Knowledge Catalog
קודם צריך למחוק את הפרופיל ואת סריקות האיכות שיצרתם. כדי למנוע מחיקה מקרית של משאבים חשובים, הפקודות האלה משתמשות בשמות הספציפיים של הסריקות שנוצרו ב-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:kc_dq_codelab
7. מעולה!
סיימתם בהצלחה את ה-Codelab!
יצרתם תהליך עבודה מקצה לקצה, פרוגרמטי, של משילות מידע. התחלתם בשימוש בתצוגות חומריות כדי לשטח נתונים מורכבים ב-BigQuery, וכך להפוך אותם למתאימים לניתוח. לאחר מכן הפעלתם סריקות של פרופילים ב-Knowledge Catalog באופן פרוגרמטי כדי ליצור מטא-נתונים סטטיסטיים. והכי חשוב, השתמשתם ב-Antigravity CLI כדי לנתח את הפלט של הפרופיל וליצור באופן חכם ארטיפקט של 'מדיניות כקוד' (dq_rules.yaml). לאחר מכן השתמשתם ב-CLI כדי לפרוס את ההגדרה הזו כסריקה אוטומטית של איכות הנתונים, וכך השלמתם את הלולאה של אסטרטגיית ניהול מודרנית וניתנת להרחבה.
עכשיו יש לכם את התבנית הבסיסית לבניית מערכות אמינות, מבוססות-AI ומאומתות על ידי בני אדם לאיכות נתונים ב-Google Cloud.
מה השלב הבא?
- שילוב עם CI/CD: לוקחים את הקובץ
dq_rules.yamlומבצעים לו קומיט למאגר Git. יוצרים צינור עיבוד נתונים לפיתוח רציף (CI) או פריסה רציפה (CD) (למשל באמצעות Cloud Build או GitHub Actions) שמבצע פריסה אוטומטית של סריקת Knowledge Catalog בכל פעם שקובץ הכללים מתעדכן. - היכרות עם כללי SQL בהתאמה אישית: אפשר להשתמש בכללים שאינם סטנדרטיים. Knowledge Catalog תומך בכללי SQL מותאמים אישית כדי לאכוף לוגיקה מורכבת יותר שספציפית לעסק, שלא ניתן לבטא באמצעות בדיקות מוגדרות מראש. זוהי תכונה שמאפשרת להתאים את האימות לדרישות הייחודיות שלכם.
- אופטימיזציה של הסריקות ליעילות ולחיסכון בעלויות: בטבלאות גדולות מאוד, אפשר לשפר את הביצועים ולהפחית את העלויות על ידי כך שלא תמיד סורקים את מערך הנתונים כולו. אפשר להשתמש במסננים כדי לצמצם את הסריקה לפרקי זמן ספציפיים או לפלחי נתונים, או להגדיר סריקות מדגמיות כדי לבדוק אחוז מייצג של הנתונים.
- הדמיה של התוצאות: הפלט של כל סריקה של איכות הנתונים ב-Knowledge Catalog נכתב בטבלה ב-BigQuery. אפשר לחבר את הטבלה הזו ל-Looker Studio כדי ליצור מרכזי בקרה למעקב אחרי ציוני איכות הנתונים לאורך זמן, בצורה מצטברת לפי המאפיינים שהגדרתם (למשל, שלמות, תוקף). כך אפשר לעקוב אחרי התהליך באופן יזום וכל בעלי העניין יכולים לראות אותו.
- שיתוף שיטות מומלצות: מומלץ לעודד שיתוף ידע בארגון כדי למנף את הניסיון המשותף ולשפר את האסטרטגיה שלכם לאיכות הנתונים. כדי להפיק את המקסימום ממאמצי הניהול, חשוב לטפח תרבות של אמון בנתונים.
- קוראים את התיעוד: