סקירה כללית על איכות הנתונים האוטומטית

‫Knowledge Catalog (לשעבר Dataplex Universal Catalog) מאפשר לכם להגדיר ולמדוד את איכות הנתונים בטבלאות של BigQuery ו-Iceberg REST Catalog. אתם יכולים להגדיר שהסריקה של הנתונים תתבצע אוטומטית, לאמת את הנתונים לפי כללים מוגדרים ולתעד התראות אם הנתונים לא עומדים בדרישות האיכות. התכונה 'איכות נתונים אוטומטית' מאפשרת לכם לנהל כללים לפריסה ולאיכות נתונים כקוד, וכך לשפר את השלמות של צינורות לייצור נתונים.

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

‫Knowledge Catalog מספק מעקב, פתרון בעיות והתראות של Cloud Logging שמשולבים עם איכות נתונים אוטומטית.

מודל קונספטואלי

סריקה של איכות הנתונים היא סוג של סריקת נתונים בקטלוג הידע שבודקת את הנתונים שלכם בהתאם לקבוצה של כללים מובנים. סריקת נתונים היא משימה ב-Knowledge Catalog שדוגמת נתונים מ-BigQuery ומ-Cloud Storage (דרך טבלאות חיצוניות של BigQuery) ומסיקה סוגים שונים של מטא-נתונים. כדי למדוד את איכות הטבלה באמצעות איכות נתונים אוטומטית, יוצרים אובייקט DataScan מסוג data quality. הסריקה מופעלת רק על טבלה אחת ב-BigQuery. הסריקה משתמשת במשאבים בפרויקט דייר ב-Google, כך שלא צריך להגדיר תשתית משלכם.

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

1. הגדרת כללים לאיכות הנתונים
2. הגדרת מתן תוקף לכלל
3. ניתוח התוצאות של סריקת איכות הנתונים
4. הגדרה של מעקב והתראות
5. פתרון בעיות שקשורות לאיכות הנתונים

הגדרת הכלל

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

• שימוש בהמלצות מפרופיל הנתונים של Knowledge Catalog
• שימוש בכללים המובנים או בתבניות של כללי מערכת
• יצירת כללי SQL בהתאמה אישית
• שימוש חוזר בכללים של איכות הנתונים

כללים מובְנים

‫Knowledge Catalog תומך בקטגוריות הבאות של כללים מובנים:

ברמת השורה

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

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

במצטבר

בכללים מצטברים, הציפייה מוחלת על ערך יחיד שמצטבר על פני כל הנתונים. לדוגמה, Avg(someCol) >= 10. כדי שהבדיקה תעבור, הערך שלה צריך להיות בוליאני true. כללים מצטברים לא מספקים ספירה עצמאית של מעבר או כשל לכל שורה.

בשתי קטגוריות הכללים אפשר להגדיר את הפרמטרים הבאים:

• העמודה שהכלל חל עליה
• מאפיין

בטבלה הבאה מפורטים סוגי הכללים הנתמכים ברמת השורה וברמת הצבירה:

סוג הכלל (שם במסוף) Google Cloud	כלל ברמת השורה או כלל מצטבר	תיאור	סוגי עמודות נתמכים	פרמטרים ספציפיים לכלל
RangeExpectation (בדיקת טווח)	ברמת השורה	בודקים אם הערך נמצא בין המינימום למקסימום.	כל העמודות מסוג מספר, תאריך וחותמת זמן.	חובה: אחוז סף המעבר ערכים של min או max: צריך לציין לפחות ערך אחד. אופציונלי: הפעלה של strict min: אם האפשרות הזו מופעלת, בדיקת הכלל משתמשת בסימן ">" במקום בסימן ">=". הפעלת strict max: אם האפשרות הזו מופעלת, בדיקת הכלל משתמשת ב-"<" במקום ב-"<=". הפעלה ignore null: אם ההגדרה מופעלת, המערכת מתעלמת מערכי null בבדיקת הכלל.
‫NonNullExpectation (בדיקת ערך Null)	ברמת השורה	מוודאים שערכי העמודות לא ריקים.	כל סוגי העמודות הנתמכים.	חובה: אחוז הסף למעבר.
SetExpectation (הגדרת המחאה)	ברמת השורה	בודקת אם הערכים בעמודה הם אחד מהערכים שצוינו בקבוצה.	כל סוגי העמודות הנתמכים, מלבד Record ו-Struct.	חובה: קבוצה של ערכי מחרוזת לבדיקה. אחוז הסף למעבר. אופציונלי: ‫Enable ignore null: אם ההגדרה הזו מופעלת, המערכת מתעלמת מערכי null בבדיקת הכלל.
RegexExpectation (בדיקת ביטוי רגולרי)	ברמת השורה	בודקת את הערכים מול ביטוי רגולרי שצוין.	String	חובה: תבנית של ביטוי רגולרי שמשמשת לבדיקה. אחוז הסף למעבר. הערה: GoogleSQL מספקת תמיכה בביטויים רגולריים באמצעות הספרייה re2. אפשר לעיין במאמרי העזרה האלה כדי לראות את תחביר הביטויים הרגולריים. אופציונלי: ‫Enable ignore null: אם ההגדרה הזו מופעלת, המערכת מתעלמת מערכי null בבדיקת הכלל.
Uniqueness (בדיקת ייחודיות)	במצטבר	בודקים אם כל הערכים בעמודה ייחודיים.	כל סוגי העמודות הנתמכים, מלבד Record ו-Struct.	חובה: העמודה והמאפיין מהפרמטרים הנתמכים. אופציונלי: ‫Enable ignore null: אם ההגדרה הזו מופעלת, המערכת מתעלמת מערכי null בבדיקת הכלל.
StatisticRangeExpectation (בדיקת נתונים סטטיסטיים)	במצטבר	בודקת אם המדד הסטטיסטי שצוין תואם לטווח הצפוי.	כל הסוגים הנתמכים של עמודות מספריות.	חובה: הערכים mean,‏ min או max: צריך לציין לפחות ערך אחד. אופציונלי: הפעלה של strict min: אם האפשרות הזו מופעלת, בדיקת הכלל משתמשת בסימן ">" במקום בסימן ">=". הפעלת strict max: אם האפשרות הזו מופעלת, בדיקת הכלל משתמשת ב-"<" במקום ב-"<=".

סוגים נתמכים של כללי SQL בהתאמה אישית

כללי SQL מאפשרים להרחיב את האימות באמצעות לוגיקה מותאמת אישית. הכללים האלה הם מהסוגים הבאים.

סוג הכלל	כלל ברמת השורה או כלל מצטבר	תיאור	סוגי העמודות הנתמכים	פרמטרים ספציפיים לכלל	דוגמה
תנאי השורה	ברמת השורה	מגדירים ציפייה לכל שורה באמצעות הגדרת ביטוי SQL בסעיף WHERE. הערך של ביטוי ה-SQL צריך להיות true (עבר) או false (נכשל) בכל שורה. ב-Knowledge Catalog מחושב אחוז השורות שעומדות בדרישה הזו, והערך הזה מושווה לאחוז הסף של השורות שעומדות בדרישה כדי לקבוע אם הכלל הצליח או נכשל. הביטוי יכול לכלול הפניה לטבלה אחרת, למשל כדי ליצור בדיקות של שלמות הפניה.	כל העמודות	חובה: תנאי SQL לשימוש אחוז סף המעבר מאפיין אופציונלי: העמודה שאליה יש לשייך את הכלל הזה.	grossWeight <= netWeight
תנאי טבלה (ביטוי SQL מצטבר)	במצטבר	הכללים האלה מופעלים פעם אחת לכל טבלה. מזינים ביטוי SQL שהערך המחושב שלו הוא בוליאני true (עבר) או false (נכשל). ביטוי ה-SQL יכול לכלול הפניה לטבלה אחרת באמצעות שאילתות משנה של ביטויים.	כל העמודות	חובה: תנאי SQL לשימוש מאפיין אופציונלי: העמודה שאליה יש לשייך את הכלל הזה	דוגמה פשוטה לחישוב מצטבר: avg(price) > 100 שימוש בשאילתת משנה של ביטוי כדי להשוות ערכים בטבלה אחרת: (SELECT COUNT(*) FROM `example_project.example_dataset.different-table`) < COUNT(*)
טענת נכוֹנוּת (assertion) של SQL	במצטבר	כלל אסרטיביות משתמש בשאילתת איכות נתונים כדי למצוא שורות שלא עומדות בתנאי אחד או יותר שצוינו בשאילתה. צריך לספק הצהרת SQL שמוערכת כדי להחזיר שורות שתואמות למצב לא תקין. אם השאילתה מחזירה שורות כלשהן, הכלל נכשל. משמיטים את הנקודה-פסיק בסוף הצהרת ה-SQL. הצהרת ה-SQL יכולה לכלול הפניה לטבלה אחרת באמצעות שאילתות משנה של ביטויים.	כל העמודות	חובה: הצהרת SQL לבדיקת מצב לא תקין מאפיין אופציונלי: העמודה שאליה יש לשייך את הכלל הזה.	דוגמה פשוטה של צבירה כדי לוודא ש-discount_pct לא גדול מ-100: SELECT * FROM example_project.example_dataset.table WHERE discount_pct > 100 שימוש בשאילתת משנה של ביטוי כדי להשוות ערכים בטבלה אחרת: SELECT * FROM `example_project.example_dataset.different-table` WHERE gross_weight > (SELECT avg(gross_weight) FROM `example_project.example_dataset.different-table`)

דוגמאות לכללים אפשר לראות במאמר כללים לדוגמה לאיכות נתונים אוטומטית.

לרשימת פונקציות SQL נתמכות, ראו הפניה ל-GoogleSQL.

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

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

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

• תבניות של כללים למדידת איכות נתונים: אפשר ליצור תבניות מותאמות אישית של כללים כדי לאחסן הגדרות מורכבות או סטנדרטיות של כללים עסקיים שאפשר לשתף בין כמה כללים למדידת איכות נתונים. יוצרים רשומה data-quality-rule-template ומוסיפים לה היבט data-quality-rule-template כדי להגדיר את הלוגיקה של התבנית.
• כללי נתונים כמטא-נתונים: אפשר להצהיר על כללים לאיכות הנתונים כהיבטים ב-Knowledge Catalog ברשומות כמו טבלאות BigQuery או מונחים במילון המונחים הארגוני. משתמשים בסוג ההיבט data-rules כדי לצרף את הכללים האלה לרשומות.
• תבניות של כללי מערכת: אפשר להשתמש בתבניות של כללי מערכת לכללים שנמצאים בשימוש נפוץ.

מידע נוסף זמין במאמר בנושא שימוש חוזר בכללים לאיכות הנתונים.

מידות

מאפיינים מאפשרים לצבור את התוצאות של כמה כללים לבדיקת איכות הנתונים לצורך מעקב והתראות. צריך לשייך כל כלל לאיכות הנתונים למאפיין. ‫Knowledge Catalog מספק את המאפיינים הבאים:

עדכניות

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

עוצמת הקול

הנפח מציין אם כל הנתונים הצפויים קיימים.

השלמות

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

תוקף

תוקף – הערכה של התאימות של הנתונים לסטנדרטים מובנים של פורמט, טווחים מקובלים או קריטריונים אחרים. לדוגמה, אם תאריך תקין צריך להיות בפורמט YYYY/mm/dd, אז 08-12-2019 הוא נתון לא תקין. דוגמה נוספת: אם מחיר מבצע תקין של פריט הוא בין 10 $ל-20$, אז מחיר מבצע של 100 $הוא נתון לא תקין.

עקביות

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

דיוק

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

ייחודיות

המדד 'ייחודיות' בודק אם הנתונים שונים ואין כפילויות.

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

הטקסט שהוקלד בכללים

כל הפרמטרים מסוג value מועברים ל-API כערכי מחרוזת. כדי להשתמש ב-Knowledge Catalog, צריך להזין נתונים בפורמט שצוין ב-BigQuery.

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

סוג	פורמטים נתמכים	דוגמאות
בינארי	ערך בקידוד Base64	YXBwbGU=
חותמת הזמן	YYYY-[M]M-[D]D[( |T)[H]H:[M]M:[S]S[.F]] [time_zone] OR YYYY-[M]M-[D]D[( |T)[H]H:[M]M:[S]S[.F]][time_zone_offset]	2014-09-27 12:30:00.45-08
תאריך	YYYY-M[M]-D[D]	2014-09-27
שעה	[H]H:[M]M:[S]S[.DDDDDD]	12:30:00.45
DateTime	YYYY-[M]M-[D]D [[H]H:[M]M:[S]S[.DDDDDD]]	‫2014-09-27 12:30:00.45

פרמטר של הפניה לנתונים

כשיוצרים כלל SQL מותאם אישית, אפשר להפנות לטבלה של מקור נתונים ולכל המסננים של התנאים המוקדמים שלה באמצעות פרמטר ההפניה לנתונים ${data()} בכלל, במקום לציין במפורש את טבלת המקור והמסננים שלה. ב-Knowledge Catalog, הפרמטר מפורש כהפניה לטבלת המקור ולמסננים שלה. דוגמאות למסנני תנאי מוקדם כוללות מסנני שורות, אחוזים של דגימה ומסננים מצטברים.

לדוגמה, נניח שיש לכם טבלה של מקור נתונים בשם my_project_id.dim_dataset.dim_currency. רוצים להריץ סריקה מצטברת של איכות הנתונים שתסרוק רק נתונים יומיים חדשים. מסנן שורות שמסנן את הרשומות של היום, transaction_timestamp >= current_date(), מופעל בטבלה.

כלל SQL מותאם אישית למציאת שורות עם discount_pct להיום נראה כך:

discount_pct IN (SELECT discount_pct FROM my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date())

אם משתמשים בפרמטר של הפניה לנתונים, אפשר לפשט את הכלל. מחליפים את האזכור של הטבלה ואת מסנני התנאים המוקדמים שלה בפרמטר ${data()}:

discount_pct IN (SELECT discount_pct FROM ${data()})

Knowledge Catalog מפרש את הפרמטר ${data()} כהפניה לטבלת מקור הנתונים עם הרשומות של היום, my_project_id.dim_dataset.dim_currency WHERE transaction_timestamp >= current_date(). בדוגמה הזו, פרמטר ההפניה לנתונים מתייחס רק לנתונים המצטברים.

הפרמטר ${data()} הוא תלוי אותיות רישיות.

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

מומלץ:

• משתמשים בפרמטר להפניה לנתונים כדי להפנות לטבלת המקור:

  discount_pct IN (
  SELECT discount_pct FROM
  `my_project_id.dim_dataset.dim_currency` AS temp-table
  WHERE
  temp-table.transaction_timestamp = ${data()}.timestamp
  )
  

• השמטת ההפניה לטבלה:

  discount_pct IN (
  SELECT discount_pct FROM
  `another_project.another_dataset.another_table` AS temp-table
  WHERE
  temp-table.transaction_timestamp = timestamp
  

לא מומלץ:

• אל תשתמשו בהפניה ישירה לטבלה כדי להפנות לעמודות בטבלת המקור:

  discount_pct IN (
  SELECT discount_pct FROM
  `my_project_id.dim_dataset.dim_currency` AS temp-table
  WHERE
  temp-table.transaction_timestamp = `my_project_id.dim_dataset.dim_currency`.timestamp
  )
  

שימוש תקין בטבלאות שונות:

• אפשר להשתמש בהפניה ישירה לטבלה כשמשווים עמודות מטבלה שונה:

  discount_pct IN (
  SELECT discount_pct FROM
  `my_project_id.dim_dataset.dim_currency` AS temp-table
  WHERE
  temp-table.transaction_timestamp = `another_project.another_dataset.another_table`.timestamp
  )
  

ניפוי באגים בשאילתות

תצוגה מקדימה

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

כשיוצרים כלל, אפשר לכלול שאילתת ניפוי באגים שתופעל לצד הכלל. שאילתת ניפוי באגים היא הצהרת SQL שמחזירה עד 10 ערכים סקלריים. הערכים האלה יכולים לעזור באבחון הסיבה לכשל של הכלל. אפשר להוסיף לכל היותר שאילתת ניפוי באגים אחת לכל כלל, והיא לא יכולה להיות ארוכה מ-1,024 תווים.

לדוגמה, נניח שיש לכם כלל אימות SQL בטבלה example_project.example_dataset.table שבודק אם ההכנסה הממוצעת לכל פריט גבוהה מ-100:

SELECT
  *
FROM
  `example_project.example_dataset.table`
WHERE
  SUM(revenue) / COUNT(DISTINCT item_id) > 100

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

SELECT
  SUM(revenue),
  COUNT(DISTINCT item_id),
  SUM(revenue) / COUNT(DISTINCT item_id)
FROM `example_project.example_dataset.table`

הפעלת הכלל

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

זהות הביצוע

כברירת מחדל, Knowledge Catalog משתמש בסוכן שירות מרכזי ([e-mail]) כדי להריץ סריקות של איכות הנתונים.

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

• העקרון של הרשאות מינימליות: מעניקים רק את הרשאות ה-IAM המדויקות שנדרשות למשימות ספציפיות של איכות נתונים לחשבון שירות ייעודי, וכך מצמצמים את הגישה שניתנת מעבר לנדרש.
• בקרת גישה מדויקת: הגדרת הרשאות למשאבים ספציפיים, שמאפשרת שילוב עם מדיניות גישה ברמת השורה וברמת העמודה ב-BigQuery.
• שיפור יכולות הביקורת: הקצאת חשבונות שירות מותאמים אישית או פרטי כניסה של משתמש לסריקות ספציפיות, מה שהופך את המעקב אחר הפעילויות ואת הרישום שלהן ביומני הביקורת לברורים יותר.
• איחוד החיוב: כשמשתמשים בזהות ביצוע בהתאמה אישית, החיובים על העיבוד והאחסון מרוכזים ישירות ב-BigQuery (בלי לעבור דרך מק"טים של Knowledge Catalog Premium). כך תוכלו ליהנות מהנחות על BigQuery לארגונים ומהתחייבויות לשימוש במשבצות זמן.

הוראות להגדרת זהות הפעלה מותאמת אישית זמינות במאמר הגדרת זהות הפעלה.

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

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

טבלה מלאה

כל עבודה מאמתת את הטבלה כולה.

מצטבר

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

סינון נתונים

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

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

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

כללי סינון

כשמריצים סריקה של איכות הנתונים, אפשר להשתמש בתחביר של מסנן AIP-160 כדי להריץ באופן סלקטיבי כללים ספציפיים. ‫Knowledge Catalog מבצע סינון של המטא-נתונים של הכללים שהוגדרו בסריקה או של הכללים שמצורפים לרשומה בקטלוג דרך ההיבט data-rules.

תחביר של מסננים

תחביר המסנן תואם להנחיות AIP-160. אפשר להשתמש באופרטורים רגילים של AIP-160 (כמו =, ‏ !=, ‏ >, ‏ <, ‏ =~) ולשלב כמה תנאים באמצעות AND או OR.

כשמשתמשים במחרוזת פילטר AIP-160, צריך לבצע את הפעולות הבאות:

• במסוף Google Cloud : מזינים את המסנן ישירות באמצעות תחביר AIP-160, לדוגמה, name = "critical_check".
• בקריאה ל-API: מחרוזת המסנן היא לרוב ערך בתוך מחרוזת JSON מילולית אחרת. כדי לעשות את זה, צריך להוסיף תו בריחה (escape) למירכאות הכפולות במחרוזת AIP-160. לדוגמה, "filter": "name = \"critical_check\"".

שדות שניתן לסנן

אפשר לסנן לפי רוב השדות שזמינים בהגדרת הכלל:

• ‫name: השם המוצג של הכלל.
• dimension: מאפיין איכות הנתונים (לדוגמה, VALIDITY).
• ‫column: שם העמודה שהכלל חל עליה.
• ‫threshold: ערך הסף להעברה של הכלל.
• ‫ignore_null: ערך בוליאני. כשtrue, NULL שורות נחשבות כעוברות.
• ‫attributes: צמדים מותאמים אישית של מפתח/ערך שהוקצו לכלל.

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

סינון לפי שם

• התאמה מדויקת: name = "critical_check"
• התאמה לתבנית: name =~ "temp_.*"

סינון לפי מימד

• התאמה למאפיין ספציפי: dimension = "COMPLETENESS"
• התאמה של כמה מאפיינים: dimension = "VALIDITY" OR dimension = "ACCURACY"

סינון לפי עמודה וערך סף

• התאמה לעמודה ספציפית: column = "user_id"
• התאמה לסף: threshold > 0.95
• התאמה של טווח: threshold >= 0.8 AND threshold < 0.9

סינון לפי ignore_null

• התאמה לערך בוליאני: ignore_null = true

סינון לפי מאפיינים מותאמים אישית

• בודקים אם יש מפתח: attributes:environment
• מפתח וערך תואמים: attributes.environment = "prod"
• התאמה באמצעות ביטויים רגולריים: attributes.tag =~ "prio-.*"
• שילובים תואמים: attributes.environment = "prod" AND attributes.criticality = "high"

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

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

• ייצוא תוצאות ל-BigQuery

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

• פרסום התוצאות כמטא-נתונים של Knowledge Catalog

  אפשר לפרסם את תוצאות הסריקה של איכות הנתונים כמטא-נתונים ב-Knowledge Catalog. התוצאות האחרונות נשמרות ברשומה של Knowledge Catalog שמייצגת את טבלת המקור, בקטע data-quality-scorecard system aspect type. אפשר לראות את התוצאות במסוף, בכרטיסייה Data quality (איכות נתונים), בדפי BigQuery ו-Knowledge Catalog של טבלת המקור. Google Cloud אפשר גם לאחזר את התוצאות באמצעות ה-API.

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

  מידע נוסף על מטא-נתונים ב-Knowledge Catalog זמין במאמר מידע על ניהול מטא-נתונים ב-Knowledge Catalog.

• בדיקת ציוני איכות הנתונים

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

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

מעקב והתראות

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

• הגדרת התראות ב-Cloud Logging

  אפשר לעקוב אחרי משימות של איכות נתונים באמצעות היומנים data_scan ו-data_quality_scan_rule_result ב-Logs Explorer.

  עבור כל משימה של איכות נתונים, היומן data_scan עם השדה data_scan_type שמוגדר לערך DATA_QUALITY מכיל את הפרטים הבאים:

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

  כל משימה שהסתיימה בהצלחה מכילה data_quality_scan_rule_result יומן עם הפרטים הבאים לגבי כל כלל במשימה:

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

  המידע ביומנים זמין דרך ה-API ודרךGoogle Cloud המסוף. אתם יכולים להשתמש במידע הזה כדי להגדיר התראות. מידע נוסף זמין במאמר בנושא הגדרת התראות ב-Logging.

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

• שליחת דוחות של התראות באימייל

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

  • ציון איכות הנתונים נמוך מציון היעד שצוין
  • המשימה נכשלה
  • העבודה הסתיימה

  מגדירים דוחות התראות כשיוצרים סריקה של איכות הנתונים.

פתרון בעיות שקשורות לאיכות הנתונים

כשביצוע של כלל נכשל, Knowledge Catalog מספק שאילתה לקבלת הרשומות שנכשלו. מריצים את השאילתה הזו כדי לראות את הרשומות שלא תאמו לכלל. מידע נוסף זמין במאמר פתרון בעיות שקשורות לאיכות הנתונים.

הערה: השאילתה מחזירה את כל העמודות בטבלה, כולל העמודה failed.

מגבלות

• אי אפשר להשתמש בהמלצות של כללים ב-CLI של gcloud.
• הבחירה של המאפיינים קבועה, ומוגבלת לאחד משבעת המאפיינים המוגדרים מראש.
• מספר הכללים לכל סריקה של איכות הנתונים מוגבל ל-1,000.
• ציוני איכות הנתונים שמדווחים ברמת העמודה נתמכים רק ב-API.
• אפשר להריץ כללי איכות נתונים רק על טבלאות BigQuery וטבלאות Iceberg REST Catalog.

תמחור

מידע נוסף על תמחור זמין במאמר בנושא תמחור של Knowledge Catalog.

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

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