החל מ-10 באפריל 2026, Dataplex Universal Catalog נקרא עכשיו Knowledge Catalog. השמות של ה-API, ספריית הלקוח, ה-CLI ו-IAM לא משתנים. מידע נוסף זמין במאמר הכרות עם קטלוג הידע של Google Cloud.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שימוש במשימות שקשורות לאיכות הנתונים

משימות איכות הנתונים של Knowledge Catalog מאפשרות לתזמן ולהריץ בדיקות אימות בטבלאות ב-BigQuery מובנות וחיצוניות, כדי לוודא שהרשומות עומדות בציפיות שלכם. אתם יכולים להגדיר כללי SQL מוגדרים מראש או בהתאמה אישית במפרט CloudDQ YAML, לאחסן תוצאות סיכום ב-BigQuery ולפתור בעיות בשורות שנכשלו. מידע נוסף זמין במאמר סקירה כללית של משימות איכות הנתונים.

לפני שמתחילים

ההנחה במאמר הזה היא שכבר יש לכם מאגר נתונים ב-Knowledge Catalog, שבו אתם יוצרים את משימת איכות הנתונים.

הפעלת ממשקי API ושירותים של Google

מפעילים את Dataproc API.

הפעלה של ה-API
מפעילים את הגישה הפרטית ל-Google ברשת ובתת-הרשת. מפעילים את "גישה פרטית ל-Google" ברשת שבה רוצים להשתמש במשימות של Knowledge Catalog לבדיקת איכות הנתונים. אם לא מציינים רשת או רשת משנה כשיוצרים את משימת איכות הנתונים ב-Knowledge Catalog, המערכת משתמשת ברשת המשנה שמוגדרת כברירת מחדל. במקרה כזה, צריך להפעיל את גישה פרטית ל-Google ברשת המשנה שמוגדרת כברירת מחדל.

יצירת קובץ מפרט

ב-Knowledge Catalog משתמשים ב-CloudDQ בקוד פתוח כתוכנית הדרייבר. הדרישות לבדיקת איכות הנתונים של Knowledge Catalog מוגדרות בקובצי המפרט של CloudDQ YAML.

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

כדי להכין קובץ מפרט:

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

שומרים את קובץ המפרט של YAML בפורמט .yml או .yaml. אם יוצרים כמה קובצי מפרט בפורמט YAML, צריך לשמור את כל הקבצים בארכיון ZIP אחד.
יצירת קטגוריה של Cloud Storage
מעלים את קובץ המפרט לקטגוריה של Cloud Storage.

מידע על קובץ המפרט

קובץ המפרט של CloudDQ ב-YAML צריך לכלול את הקטעים הבאים:

כללים (מוגדרים בצומת rules YAML ברמה העליונה): רשימה של כללים להפעלה. אתם יכולים ליצור את הכללים האלה מסוגי כללים מוגדרים מראש, כמו NOT_NULL ו-REGEX, או להרחיב אותם באמצעות הצהרות SQL בהתאמה אישית, כמו CUSTOM_SQL_EXPR ו-CUSTOM_SQL_STATEMENT. ההצהרה CUSTOM_SQL_EXPR מסמנת כל שורה שבה custom_sql_expr הוערך כ-False ככישלון. ההצהרה CUSTOM_SQL_STATEMENT מסמנת כל ערך שמוחזר על ידי ההצהרה כולה ככשל.
מסנני שורות (מוגדרים בצומת ה-YAML ברמה העליונה row_filters): ביטויי SQL שמחזירים ערך בוליאני שמגדיר מסננים לאחזור קבוצת משנה של נתונים מהישות הבסיסית לאימות.
קישורי כללים (מוגדרים בצומת ה-YAML ברמה העליונה rule_bindings): מגדירים את rules ואת rule filters שיחולו על הטבלאות.
מאפייני הכלל (מוגדרים בצומת ה-YAML של rule_dimensions): מגדירים את רשימת המאפיינים המותרים של כללי איכות הנתונים, שכלל יכול להגדיר בשדה dimension המתאים.

לדוגמה:
```
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
```
השדה dimension הוא אופציונלי לכלל. הקטע של מאפייני הכלל הוא חובה אם dimension מופיע בכלל כלשהו.

מידע נוסף זמין במדריך העזר של CloudDQ ובקובצי המפרט לדוגמה.

הערה: בגלל מגבלה של CloudDQ, אי אפשר להגדיר יותר מצומת עליון אחד לכל קטע (כמו rules או rule_bindings) בקובץ YAML אחד, כי CloudDQ מנתח רק את הצומת האחרון מכל סוג בקובץ.

יצירת מערך נתונים לאחסון התוצאות

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

מערך הנתונים צריך להיות באותו אזור שבו נמצאות הטבלאות שאתם מריצים עליהן את משימת איכות הנתונים.

‫Knowledge Catalog משתמש בקבוצת הנתונים הזו, ויוצר או משתמש מחדש בטבלה לבחירתכם כדי לאחסן את התוצאות.

יצירה של חשבון שירות

יוצרים חשבון שירות עם התפקידים וההרשאות הבאים בניהול זהויות והרשאות גישה (IAM):

גישת קריאה לנתיב ב-Cloud Storage שמכיל את מפרטי ה-YAML. אתם יכולים להשתמש בתפקיד צפייה באובייקטים באחסון (roles/storage.objectViewer) בקטגוריה של Cloud Storage.
גישת קריאה למערכי הנתונים ב-BigQuery עם הנתונים שצריך לאמת. אפשר להשתמש בתפקיד BigQuery Data Viewer (roles/bigquery.dataViewer).
גישת כתיבה למערך הנתונים ב-BigQuery כדי ליצור טבלה (במידת הצורך) ולכתוב את התוצאות בטבלה הזו. אפשר להשתמש בתפקיד עריכה של נתוני BigQuery (roles/bigquery.dataEditor) ברמת מערך הנתונים.
התפקיד BigQuery Job User‏ (roles/bigquery.jobUser) ברמת הפרויקט, כדי ליצור משימות BigQuery בפרויקט.
התפקיד Dataplex Metadata Reader‏ (roles/dataplex.metadataReader) ברמת הפרויקט או ה-lake.
התפקיד Service Usage Consumer (roles/serviceusage.serviceUsageConsumer) ברמת הפרויקט.
התפקיד Dataproc Worker ‏(roles/dataproc.worker).
ההרשאה iam.serviceAccounts.actAs שניתנה למשתמש ששלח את המשימה.
התפקיד משתמש בחשבון שירות (roles/iam.serviceAccountUser) שמוקצה לחשבון השירות של מאגר הנתונים של Knowledge Catalog. אפשר לראות את חשבון השירות של Knowledge Catalog במסוף Google Cloud .

שימוש בהגדרות מתקדמות

השלבים הבאים הם אופציונליים:

כברירת מחדל, BigQuery מריץ בדיקות של איכות הנתונים בפרויקט הנוכחי. אתם יכולים לבחור פרויקט אחר להרצת המשימות ב-BigQuery. משתמשים בארגומנט --gcp_project_id TASK_ARGS למאפיין --execution-args של המשימה.
אם מזהה הפרויקט שצוין להרצת שאילתות BigQuery שונה מהפרויקט שבו נוצר חשבון השירות (שצוין על ידי --execution-service-account), צריך לוודא שמדיניות הארגון שמשביתה את השימוש בחשבון השירות בפרויקטים שונים (iam.disableServiceAccountCreation) מושבתת. בנוסף, צריך לוודא שלחשבון השירות יש גישה לתזמון המשימות של BigQuery בפרויקט שבו מריצים את השאילתות של BigQuery.

מגבלות

כל הטבלאות שצוינו במשימה מסוימת של איכות נתונים חייבות להיות באותו אזור ב- Google Cloud.

תזמון משימה לבדיקת איכות הנתונים

המסוף

נכנסים לדף Process ב-Knowledge Catalog במסוף Google Cloud .
עוברים אל תהליך.
לוחצים על יצירת משימה.
בכרטיס בדיקת איכות הנתונים, לוחצים על יצירת משימה.
בשדה Dataplex lake, בוחרים את מאגר הנתונים.
בשדה מזהה, מזינים מזהה.
בקטע מפרט איכות הנתונים, בצע את הפעולות הבאות:
1. בשדה Select GCS file, לוחצים על Browse.
2. בוחרים את הקטגוריה של Cloud Storage.
3. לוחצים על בחירה.
בקטע Results table:
1. בשדה Select BigQuery dataset, לוחצים על Browse.
2. בוחרים את מערך הנתונים ב-BigQuery שבו רוצים לשמור את תוצאות האימות.
3. לוחצים על בחירה.
4. בשדה BigQuery table, מזינים את שם הטבלה ב-BigQuery שבה רוצים לשמור את התוצאות. אם הטבלה לא קיימת, Knowledge Catalog יוצר אותה בשבילכם. אל תשתמשו בשם dq_summary כי הוא שמור למשימות עיבוד פנימיות.
בקטע Service account, בוחרים חשבון שירות מהתפריט User service account.
לוחצים על Continue.
בקטע Set schedule, מגדירים את לוח הזמנים להרצת המשימה של בקרת האיכות.
לוחצים על יצירה.

‫CLI של gcloud

הדוגמה הבאה היא הפעלה של משימה לבדיקת איכות הנתונים, באמצעות הפקודה של ה-CLI של gcloud למשימות של Knowledge Catalog:

export USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH="USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH"

# Google Cloud project where the Knowledge Catalog task is created.
export GOOGLE_CLOUD_PROJECT="GOOGLE_CLOUD_PROJECT"

# Google Cloud region for the Knowledge Catalog lake.
export DATAPLEX_REGION_ID="DATAPLEX_REGION_ID"

# Public Cloud Storage bucket containing the prebuilt data quality executable artifact. There is one bucket for each Google Cloud region.
export DATAPLEX_PUBLIC_GCS_BUCKET_NAME="dataplex-clouddq-artifacts-${DATAPLEX_REGION_ID}"

# The Knowledge Catalog lake where your task is created.
export DATAPLEX_LAKE_ID="DATAPLEX_LAKE_ID"

# The service account used for running the task. Ensure that this service account
has sufficient IAM permissions on your project, including
BigQuery Data Editor, BigQuery Job User,
Dataplex Editor, Dataproc Worker, and Service
Usage Consumer.
export DATAPLEX_TASK_SERVICE_ACCOUNT="DATAPLEX_TASK_SERVICE_ACCOUNT"

# If you want to use a different dataset for storing the intermediate data quality summary results
and the BigQuery views associated with each rule binding, use the following:
export CLOUDDQ_BIGQUERY_DATASET="CLOUDDQ_BIGQUERY_DATASET"

# The BigQuery dataset where the final results of the data quality checks are stored.
This could be the same as CLOUDDQ_BIGQUERY_DATASET.
export TARGET_BQ_DATASET="TARGET_BQ_DATASET"

# The BigQuery table where the final results of the data quality checks are stored.
export TARGET_BQ_TABLE="TARGET_BQ_TABLE"

# The unique identifier for the task.
export TASK_ID="TASK_ID"

gcloud dataplex tasks create \
    --location="${DATAPLEX_REGION_ID}" \
    --lake="${DATAPLEX_LAKE_ID}" \
    --trigger-type=ON_DEMAND \
    --execution-service-account="$DATAPLEX_TASK_SERVICE_ACCOUNT" \
    --spark-python-script-file="gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq_pyspark_driver.py" \
    --spark-file-uris="gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq-executable.zip","gs://${DATAPLEX_PUBLIC_GCS_BUCKET_NAME}/clouddq-executable.zip.hashsum","${USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH}" \
    --execution-args=^::^TASK_ARGS="clouddq-executable.zip, ALL, ${USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH}, --gcp_project_id='GOOGLE_CLOUD_PROJECT', --gcp_region_id='${DATAPLEX_REGION_ID}', --gcp_bq_dataset_id='${TARGET_BQ_DATASET}', --target_bigquery_summary_table='${GOOGLE_CLOUD_PROJECT}.${TARGET_BQ_DATASET}.${TARGET_BQ_TABLE}'," \
    "$TASK_ID"

פרמטר	תיאור
`USER_CLOUDDQ_YAML_CONFIGS_GCS_PATH`	הנתיב ב-Cloud Storage לקלט של הגדרות ה-YAML של איכות הנתונים, למשימה של איכות הנתונים. אפשר להשתמש בקובץ YAML יחיד בפורמט `.yml` או `.yaml`, או בארכיון ZIP שמכיל כמה קובצי YAML.
`GOOGLE_CLOUD_PROJECT`	Google Cloud הפרויקט שבו נוצרו המשימה של Knowledge Catalog והמשימות של BigQuery.
`DATAPLEX_REGION_ID`	האזור של מאגר הנתונים ב-Knowledge Catalog שבו נוצרה משימת איכות הנתונים.
`SERVICE_ACCOUNT`	חשבון השירות שמשמש לביצוע המשימה. חשוב לוודא שלחשבון השירות הזה יש מספיק הרשאות IAM, כמו שמוסבר בקטע לפני שמתחילים.

ב---execution-args, צריך להעביר את הארגומנטים הבאים כארגומנטים תלויי מיקום, ולכן בסדר הזה:

ארגומנט	תיאור
`clouddq-executable.zip`	קובץ הפעלה שעבר הידור מראש והועבר ב-`spark-file-uris` מקטגוריה ציבורית של Cloud Storage.
`ALL`	מריצים את כל קישורי הכללים. לחלופין, אפשר לציין קישורי כללים ספציפיים כרשימה מופרדת בפסיקים. לדוגמה, `RULE_1,RULE_2`.
`gcp-project-id`	מזהה הפרויקט שבו מריצים את השאילתות ב-BigQuery.
`gcp-region-id`	האזור שבו מריצים את המשימות של BigQuery לאימות איכות הנתונים. האזור הזה צריך להיות זהה לאזור של `gcp-bq-dataset-id` ושל `target_bigquery_summary_table`.
`gcp-bq-dataset-id`	מערך הנתונים ב-BigQuery שמשמש לאחסון התצוגות של `rule_binding` ותוצאות הביניים של סיכום איכות הנתונים.
`target-bigquery-summary-table`	הפניה למזהה הטבלה ב-BigQuery שבה מאוחסנות התוצאות הסופיות של בדיקות איכות הנתונים. אל תשתמשו בערך המזהה `dq_summary` כי הוא שמור למשימות עיבוד פנימיות.
`--summary_to_stdout`	(אופציונלי) כשמעבירים את הדגל הזה, כל שורות תוצאות האימות שנוצרו בטבלה `dq_summary` בהרצה האחרונה נרשמות כרשומות JSON ב-Cloud Logging וב-`stdout`.

הערה: כברירת מחדל, המשימה של בדיקת איכות הנתונים ב-Knowledge Catalog פועלת ברשת Default. אפשר לשנות את הרשת באמצעות אחד מהארגומנטים: --vpc-network-name או --vpc-sub-network-name. איך מגדירים את הארגומנטים האלה

API

מחליפים את מה שכתוב בשדות הבאים:

PROJECT_ID = "Your Knowledge Catalog Project ID"
REGION = "Your Knowledge Catalog lake region"
LAKE_ID = "Your Knowledge Catalog lake ID"
SERVICE_ACC = "Your service account used for reading the data"
DATAPLEX_TASK_ID = "Unique task ID for the data quality task"
BUCKET_NAME = "Your Cloud Storage bucket name containing the CloudDQ configs or YAML specification"
GCP_BQ_BILLING_PROJECT_ID = "Your BigQuery billing project"
GCP_BQ_REGION_ID = "Your BigQuery dataset region ID" #Optional
GCP_BQ_DATASET_ID = "Your BigQuery dataset to store the data quality summary results"
TARGET_TABLE_NAME = "Your target table name to store the results in BigQuery dataset"

שולחים בקשת POST HTTP:

POST https://dataplex.googleapis.com/v1/projects/${PROJECT_ID}/locations/${REGION}/lakes/${LAKE_ID}/tasks?task_id=${DATAPLEX_TASK_ID}
{
"spark": {
    "python_script_file": f"gs://dataplex-clouddq-artifacts-us-central1/clouddq_pyspark_driver.py",
    "file_uris": [  f"gs://dataplex-clouddq-artifacts-us-central1/clouddq-executable.zip",
                    f"gs://dataplex-clouddq-artifacts-us-central1/clouddq-executable.zip.hashsum",
                    f"gs://dataplex-clouddq-artifacts-us-central1/your-clouddq-configs.zip"
                ]
},
"execution_spec": {
    "args": {
        "TASK_ARGS":f"clouddq-executable.zip, ALL, gs://BUCKET_NAME/your-clouddq-configs.zip, --gcp_project_id=${GCP_BQ_BILLING_PROJECT_ID}, --gcp_region_id=${GCP_BQ_REGION_ID}, --gcp_bq_dataset_id=${GCP_BQ_DATASET_ID}, --target_bigquery_summary_table=${GCP_BQ_BILLING_PROJECT_ID}.${GCP_BQ_DATASET_ID}.${TARGET_TABLE_NAME}"
    },
    "service_account": "SERVICE_ACC"
},
"trigger_spec": {
"type": "ON_DEMAND"
},
"description": "${DATAPLEX_TASK_DESCRIPTION}"
}

אפשר גם לעיין בדוגמה ל-DAG של Airflow למשימה של איכות הנתונים ב-Knowledge Catalog.

מעקב אחרי משימה מתוזמנת של איכות נתונים

איך עוקבים אחרי המשימה

צפייה בתוצאות

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

שם העמודה	תיאור
`dataplex_lake`	(מחרוזת) המזהה של מאגר הנתונים ב-Knowledge Catalog שמכיל את הטבלה שעוברת אימות.
`dataplex_zone`	(מחרוזת) המזהה של אזור Knowledge Catalog שמכיל את הטבלה שעוברת אימות.
`dataplex_asset_id`	(מחרוזת) המזהה של הנכס ב-Knowledge Catalog שמכיל את הטבלה שעוברת אימות.
`execution_ts`	(חותמת זמן) חותמת הזמן של מועד ההרצה של שאילתת האימות.
`rule_binding_id`	(מחרוזת) המזהה של קישור הכלל שלגביו מדווחות תוצאות האימות.
`rule_id`	(מחרוזת) המזהה של הכלל שמשויך לקישור הכלל שעבורו מדווחות תוצאות האימות.
`dimension`	(מחרוזת) מאפיין איכות הנתונים של `rule_id`. הערך הזה יכול להיות רק אחד מהערכים שצוינו בצומת ה-YAML של `rule_dimensions`.
`table_id`	(מחרוזת) המזהה של הישות שעבורה מדווחות תוצאות האימות. המזהה הזה מצוין בפרמטר `entity` של קישור הכלל הרלוונטי.
`column_id`	(מחרוזת) המזהה של העמודה שתוצאות האימות מדווחות לגביה. המזהה הזה מצוין בפרמטר `column` של קישור הכלל הרלוונטי.
`last_modified`	(חותמת זמן) חותמת הזמן של השינוי האחרון של `table_id` שמאומת.
`metadata_json_string`	(מחרוזת) צמדי מפתח/ערך של תוכן הפרמטר של המטא-נתונים שצוין בקישור הכלל או במהלך הרצת בדיקת איכות הנתונים.
`configs_hashsum`	(מחרוזת) סכום ה-hash של מסמך ה-JSON שמכיל את קישור הכלל ואת כל הכללים, קישורי הכללים, מסנני השורות והגדרות הישויות שמשויכים אליו. ‫`configs_hashsum` מאפשר לעקוב אחרי שינויים בתוכן של מזהה `rule_binding` או באחת מההגדרות שמפנות אליו.
`dq_run_id`	(מחרוזת) המזהה הייחודי של הרשומה.
`invocation_id`	(מחרוזת) המזהה של הרצת בדיקת איכות הנתונים. כל רשומות הסיכום של איכות הנתונים שנוצרו באותו מופע של הרצת איכות הנתונים חולקות את אותו `invocation_id`.
`progress_watermark`	(ערך בוליאני) קובע אם הרשומה הספציפית הזו נכללת בבדיקת איכות הנתונים כדי לקבוע את הסימן הגבוה ביותר לאימות מצטבר. אם `FALSE`, המערכת מתעלמת מהרשומה המתאימה כשהיא קובעת את הערך של סימן המים הגבוה. המידע הזה שימושי כשמבצעים אימותים של איכות נתוני הבדיקה, שלא אמורים לקדם את סימן המים הגבוה. כברירת מחדל, Knowledge Catalog מאכלס את השדה הזה בערך `TRUE`, אבל אפשר לשנות את הערך אם הארגומנט `--progress_watermark` מכיל את הערך `FALSE`.
`rows_validated`	(מספר שלם) המספר הכולל של הרשומות שאומתו אחרי החלת `row_filters` וכל מסנני הסימן הגבוה בעמודה `incremental_time_filter_column_id`, אם צוינו.
`complex_rule_validation_errors_count`	(float) מספר השורות שהוחזרו על ידי כלל `CUSTOM_SQL_STATEMENT`.
`complex_rule_validation_success_flag`	(בוליאני) סטטוס ההצלחה של `CUSTOM_SQL_STATEMENT` כללים.
`success_count`	(מספר שלם) המספר הכולל של הרשומות שעברו את האימות. השדה הזה מוגדר ל-`NULL` לכללי `CUSTOM_SQL_STATEMENT`.
`success_percentage`	‫(float) אחוז הרשומות שעברו את האימות מתוך המספר הכולל של הרשומות שאומתו. השדה הזה מוגדר לערך `NULL` בכללים של `CUSTOM_SQL_STATEMENT`.
`failed_count`	(מספר שלם) המספר הכולל של הרשומות שהאימות שלהן נכשל. השדה הזה מוגדר ל-`NULL` לכללי `CUSTOM_SQL_STATEMENT`.
`failed_percentage`	‫(float) אחוז הרשומות שהאימות שלהן נכשל מתוך המספר הכולל של הרשומות שאומתו. השדה הזה מוגדר לערך `NULL` בכללים של `CUSTOM_SQL_STATEMENT`.
`null_count`	(מספר שלם) המספר הכולל של הרשומות שהחזירו ערך null במהלך האימות. השדה הזה מוגדר לערך `NULL` לכללים `NOT_NULL` ו-`CUSTOM_SQL_STATEMENT`.
`null_percentage`	‫(float) אחוז הרשומות שהחזירו ערך null במהלך האימות מתוך המספר הכולל של הרשומות שאומתו. השדה הזה מוגדר כ-`NULL` לכללים של `NOT_NULL` ו-`CUSTOM_SQL_STATEMENT`.
`failed_records_query`	בכל כלל שנכשל, בעמודה הזו מאוחסנת שאילתה שבה אפשר להשתמש כדי לקבל רשומות שנכשלו. פתרון בעיות בכללים שנכשלו באמצעות `failed_records_query`

בישויות של BigQuery, נוצרת תצוגה לכל rule_binding שמכילה את לוגיקת האימות של SQL מההרצה האחרונה. התצוגות האלה נמצאות במערך הנתונים ב-BigQuery שצוין בארגומנט --gcp-bq-dataset-id.

אופטימיזציה של עלויות

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

אימותים מצטברים

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

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

כדי לציין אימות מצטבר, מציינים ערך ל-incremental_time_filter_column_id=TIMESTAMP/DATETIME type column כחלק מקישור כלל.

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

קובצי מפרט לדוגמה

כדי להשתמש בדוגמאות האלה, צרו מערך נתונים ב-BigQuery בשם sales. אחר כך יוצרים טבלת עובדות בשם sales_orders ומוסיפים נתונים לדוגמה על ידי הרצת שאילתה עם הצהרות GoogleSQL הבאות:

CREATE OR REPLACE TABLE sales.sales_orders
(
 id STRING NOT NULL,
 last_modified_timestamp TIMESTAMP,
 customer_id STRING,
 item_id STRING,
 amount NUMERIC,
 transaction_currency STRING
);

INSERT INTO sales.sales_orders
(id, last_modified_timestamp, customer_id, item_id, amount, transaction_currency)
VALUES
("order1",CURRENT_TIMESTAMP(),"customer1","ASDWQ123456789012345",100,"USD"),
("order1",CURRENT_TIMESTAMP(),"customer2","bad_item_id",-10,"XXX"),
("order2",CURRENT_TIMESTAMP(),"customer3","INTNL987654321098765",50,"GBP"),
("order3",CURRENT_TIMESTAMP(),"customer4","INTNL932716428593847",50,"GBP")

דוגמה 1

דוגמת הקוד הבאה יוצרת בדיקות של איכות הנתונים כדי לאמת את הערכים האלה:

‫amount: הערכים הם אפס או מספרים חיוביים.
‫item_id: מחרוזת אלפאנומרית של 5 תווים אלפביתיים, ואחריהם 15 ספרות.
‫transaction_currency: סוג מטבע מותר, כפי שמוגדר ברשימה סטטית. הרשימה הסטטית בדוגמה הזו מאפשרת להשתמש בליש"ט (GBP) ובין יפני (JPY) כמטבעות. האימות הזה חל רק על שורות שמסומנות כבינלאומיות.

# The following `NONE` row filter is required.
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 # This filters for rows marked as international (INTNL).
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# Rule dimensions are optional but let you aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can apply to multiple tables or columns.
rules:
 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

# Rule bindings associate rules to columns within tables.
rule_bindings:
  TRANSACTION_AMOUNT_VALID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

  TRANSACTION_VALID_ITEM_ID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

  TRANSACTION_CURRENCY_VALID:
   entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

מחליפים את מה שכתוב בשדות הבאים:

PROJECT_ID: מזהה הפרויקט.
‫DATASET_ID: מזהה מערך הנתונים.

דוגמה 2

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

כדי להשתמש בדוגמה הזו, צריך ליצור אגם של Knowledge Catalog עם מזהה האגם operations ומזהה האזור procurement. לאחר מכן, מוסיפים את הטבלה sales_orders כנכס לאזור.

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}
rule_bindings:
 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

מחליפים את מה שכתוב בשדות הבאים:

PROJECT_ID: מזהה הפרויקט.
‫REGION_ID: מזהה האזור של מאגר הנתונים ב-Knowledge Catalog שבו נמצאת הטבלה, למשל us-central1.

דוגמה 3

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

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
# This rule is parameterized with column_names as parameter
 NO_DUPLICATES_IN_COLUMN_GROUPS:
   rule_type: CUSTOM_SQL_STATEMENT
   dimension: duplication
   params:
     custom_sql_arguments:
       - column_names
     custom_sql_statement: |-
       select a.*
       from data a
       inner join (
         select
           $column_names
         from data
         group by $column_names
         having count(*) > 1
       ) duplicates
       using ($column_names)

 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}

rule_bindings:
 TRANSACTIONS_UNIQUE:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: id
   row_filter_id: NONE
   rule_ids:
     - NO_DUPLICATES_IN_COLUMN_GROUPS:
         column_names: "id"

 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: amount
   row_filter_id: NONE
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: item_id
   row_filter_id: NONE
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   rule_ids:
     - VALID_CURRENCY_ID

דוגמה 4

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

# This is a convenience section that allows you to shorten the entity_uri
metadata_registry_defaults:
 dataplex:
   projects: PROJECT_ID
   locations: REGION_ID
   lakes: operations
   zones: procurement

# You have to define a NONE row filter
row_filters:
 NONE:
   filter_sql_expr: |-
      True
 INTERNATIONAL_ITEMS:
   filter_sql_expr: |-
      REGEXP_CONTAINS(item_id, 'INTNL')

# rule dimensions are optional but allow you to aggregate reporting.
rule_dimensions:
  - consistency
  - correctness
  - duplication
  - completeness
  - conformance
  - integrity

# Rules can be shared across tables or columns.
rules:
# This rule is parameterized with column_names as parameter
 NO_DUPLICATES_IN_COLUMN_GROUPS:
   rule_type: CUSTOM_SQL_STATEMENT
   dimension: duplication
   params:
     custom_sql_arguments:
       - column_names
     custom_sql_statement: |-
       select a.*
       from data a
       inner join (
         select
           $column_names
         from data
         group by $column_names
         having count(*) > 1
       ) duplicates
       using ($column_names)

 VALUE_ZERO_OR_POSITIVE:
   rule_type: CUSTOM_SQL_EXPR
   dimension: correctness
   params:
     custom_sql_expr: |-
       $column >= 0

 VALID_ITEM_ID:
   rule_type: REGEX
   dimension: conformance
   params:
     pattern: |-
       [A-Z]{5}[0-9]{15}

 VALID_CURRENCY_ID:
   rule_type: CUSTOM_SQL_EXPR
   dimension: integrity
   params:
     custom_sql_expr: |-
      $column in ('GBP', 'JPY')

#rule bindings associate rules to {table, column}

rule_bindings:
 TRANSACTIONS_UNIQUE:
   entity_uri: dataplex://projects/PROJECT_ID/locations/REGION_ID/lakes/operations/zones/procurement/entities/sales_orders
   column_id: id
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - NO_DUPLICATES_IN_COLUMN_GROUPS:
         column_names: "id"

 TRANSACTION_AMOUNT_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders # omitting projects/locations/lakes from uri path to use the default values specified in metadata_registry_defaults
   column_id: amount
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALUE_ZERO_OR_POSITIVE

 TRANSACTION_VALID_ITEM_ID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: item_id
   row_filter_id: NONE
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALID_ITEM_ID

 TRANSACTION_CURRENCY_VALID:
   entity_uri: dataplex://zones/procurement/entities/sales_orders
   column_id: transaction_currency
   row_filter_id: INTERNATIONAL_ITEMS
   incremental_time_filter_column_id: last_modified_timestamp
   rule_ids:
     - VALID_CURRENCY_ID

פתרון בעיות בכללים שנכשלו באמצעות `failed_records_query`

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

כדי לנפות באגים, אתם יכולים גם להשתמש ב-reference columns בקובץ ה-YAML, וכך לצרף את הפלט של failed_records_query לנתונים המקוריים כדי לקבל את הרשומה המלאה. לדוגמה, אפשר לציין עמודת primary_key או עמודת primary_key מורכבת כעמודת הפניה.

הערה: שאילתות של רשומות שנכשלו לא משתמשות ב-reference_columns לכללי CUSTOM_SQL_STATEMENT. הפלט של השאילתה של הרשומות שנכשלו תלוי בשאילתה עצמה ב-CUSTOM_SQL_STATEMENT. לדוגמה, אם אתם צריכים עמודת עזר בשאילתת הרשומות שנכשלו בשביל כלל CUSTOM_SQL_STATEMENT, אתם צריכים לכלול את העמודה גם בהצהרת ה-SQL. מידע נוסף זמין במאמר שימוש בשאילתות של רשומות שנכשלו לכללי CUSTOM_SQL_STATEMENT.

ציון עמודות עזר

כדי ליצור עמודות של קובצי עזר, אפשר להוסיף את הפרטים הבאים למפרט ה-YAML:

הקטע reference_columns. בקטע הזה אפשר ליצור קבוצה אחת או יותר של עמודות עזר, כשכל קבוצה מציינת עמודה אחת או יותר.
הקטע rule_bindings. בקטע הזה אפשר להוסיף שורה לקישור של כלל, שמציינת מזהה של עמודת עזר (reference_columns_id) שבה ישתמשו הכללים בקישור הזה. הוא צריך להיות אחד מהקבוצות של עמודות העזר שצוינו בקטע reference_columns.

לדוגמה, קובץ ה-YAML הבא מציין קטע של reference_columns ומגדיר שלוש עמודות: id,‏ last_modified_timestamp ו-item_id כחלק מהקבוצה ORDER_DETAILS_REFERENCE_COLUMNS. בדוגמה הבאה משתמשים בטבלה לדוגמה sales_orders.

reference_columns:
  ORDER_DETAILS_REFERENCE_COLUMNS:
    include_reference_columns:
      - id
      - last_modified_timestamp
      - item_id
rules:
  VALUE_ZERO_OR_POSITIVE:
  rule_type: CUSTOM_SQL_EXPR
  params:
    custom_sql_expr: |-

row_filters:
NONE:
  filter_sql_expr: |-
      True

rule_bindings:
TRANSACTION_AMOUNT_VALID:
  entity_uri: bigquery://projects/PROJECT_ID/datasets/DATASET_ID/tables/sales_orders
  column_id: amount
  row_filter_id: NONE
  reference_columns_id: ORDER_DETAILS_REFERENCE_COLUMNS
  rule_ids:
    - VALUE_ZERO_OR_POSITIVE

שימוש בשאילתה של רשומות שנכשלו

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

הדוגמה הבאה היא פלט של שאילתה על רשומות שנכשלו, בקובץ ה-YAML שמתואר בקטע ציון עמודות עזר. מוצג כשל בעמודה amount וערך הכשל הוא -10. הוא גם מתעד את הערך התואם לעמודת ההפניה.

_dq_validation_invocation_id	_dq_validation_rule_binding_id	_dq_validation_rule_id	_dq_validation_column_id	_dq_validation_column_value	_dq_validation_dimension	_dq_validation_simple_rule_row_is_valid	_dq_validation_complex_rule_validation_errors_count	_dq_validation_complex_rule_validation_success_flag	id	last_modified_timestamp	item_id
10a25be9-8dfa-446c-a42c-75f6bb4a49d9	TRANSACTION_AMOUNT_VALID	VALUE_ZERO_OR_POSITIVE	סכום	-10		לא נכון			order1	2022-01-22T02:30:06.321Z	bad_item_id

שימוש בשאילתות של רשומות שנכשלו לכללי CUSTOM_SQL_STATEMENT

בכללים של CUSTOM_SQL_STATEMENT, שאילתות של רשומות שנכשלו כוללות את העמודה custom_sql_statement_validation_errors. העמודה custom_sql_statement_validation_errors היא עמודה בתצוגת עץ עם שדות שתואמים לפלט של הצהרת ה-SQL. עמודות של קובצי עזר לא נכללות בשאילתות של רשומות שנכשלו ב-CUSTOM_SQL_STATEMENT כללים.

לדוגמה, הכלל של CUSTOM_SQL_STATEMENT יכול להיראות כך:

rules:
  TEST_RULE:
    rule_type: CUSTOM_SQL_STATEMENT
    custom_sql_arguments:
      - existing_id
      - replacement_id
    params:
     CUSTOM_SQL_STATEMENT: |-
       (SELECT product_name, product_key FROM data
       where $existing_id != $replacement_id)

התוצאות בדוגמה הזו יכילו שורה אחת או יותר בעמודה custom_sql_statement_validation_errors, עם שורה לכל מופע שבו existing_id!=replacement_id.

כשמעבדים את התוכן של תא בעמודה הזו ב-JSON, הוא יכול להיראות כך:

{
  "custom_sql_statement_valdation_errors" :{
    "product_name"="abc"
    "product_key"="12345678"
    "_rule_binding_id"="your_rule_binding"
  }
}

אפשר לצרף את התוצאות האלה לטבלה המקורית באמצעות הפניה בתצוגת עץ כמו join on custom_sql_statement_valdation_errors.product_key.

המאמרים הבאים

מפרט YAML של CloudDQ
לדוגמאות של כללים לאיכות הנתונים, ראו כללים פשוטים וכללים מתקדמים.
דוגמה ל-DAG של Airflow למשימה של איכות הנתונים ב-Knowledge Catalog

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

לפני שמתחילים

הפעלת ממשקי API ושירותים של Google

יצירת קובץ מפרט

מידע על קובץ המפרט

יצירת מערך נתונים לאחסון התוצאות

יצירה של חשבון שירות

שימוש בהגדרות מתקדמות

מגבלות

תזמון משימה לבדיקת איכות הנתונים

המסוף

‫CLI של gcloud

API

מעקב אחרי משימה מתוזמנת של איכות נתונים

צפייה בתוצאות

אופטימיזציה של עלויות

אימותים מצטברים

קובצי מפרט לדוגמה

דוגמה 1

דוגמה 2

דוגמה 3

דוגמה 4

פתרון בעיות בכללים שנכשלו באמצעות failed_records_query

ציון עמודות עזר

שימוש בשאילתה של רשומות שנכשלו

שימוש בשאילתות של רשומות שנכשלו לכללי CUSTOM_SQL_STATEMENT

המאמרים הבאים

שימוש במשימות שקשורות לאיכות הנתונים

פתרון בעיות בכללים שנכשלו באמצעות `failed_records_query`