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

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

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

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

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

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

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

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

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

הגדרת הכלל

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

שימוש בהמלצות מפרופיל הנתונים של Dataplex Universal Catalog
שימוש בכללים שהוגדרו מראש
יצירת כללי SQL בהתאמה אישית

כללים מוגדרים מראש

‫Dataplex Universal Catalog תומך בקטגוריות הבאות של כללים מוגדרים מראש:

ברמת השורה

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

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

במצטבר

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

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

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

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

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

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

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

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

תנאי השורה

ברמת השורה

סוג הכלל	כלל ברמת השורה או כלל מצטבר	תיאור	סוגי העמודות הנתמכים	פרמטרים ספציפיים לכלל	דוגמה
תנאי השורה	ברמת השורה	מגדירים ציפייה לכל שורה באמצעות הגדרת ביטוי SQL בסעיף `WHERE`. הערך של ביטוי ה-SQL צריך להיות `true` (עבר) או `false` (נכשל) בכל שורה. הקטלוג האוניברסלי של Dataplex מחשב את אחוז השורות שעומדות בדרישה הזו, ומשווה את הערך הזה לאחוז הסף של השורות שעומדות בדרישה כדי לקבוע אם הכלל הצליח או נכשל. הביטוי יכול לכלול הפניה לטבלה אחרת, למשל כדי ליצור בדיקות של שלמות רפרנציאלית.	כל העמודות	חובה: תנאי 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 בסעיף WHERE. הערך של ביטוי ה-SQL צריך להיות true (עבר) או false (נכשל) בכל שורה.

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

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

כל העמודות

חובה:

תנאי 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.

מידות

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

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

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

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

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

סוג	פורמטים נתמכים	דוגמאות
בינארי	ערך בקידוד Base64	YXBwbGU=
חותמת הזמן	YYYY-[M]M-[D]D[( \|T)[H]H:[M]M:[S]S[.F]] [time_zone] או 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()} בכלל, במקום לציין במפורש את טבלת המקור והמסננים שלה. ‫Dataplex Universal 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()})

‫Dataplex Universal 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
)

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

כשיוצרים כלל, אפשר לכלול שאילתת ניפוי באגים שתופעל לצד הכלל. שאילתת ניפוי באגים היא הצהרת 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`

הרצת כלל

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

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

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

סינון נתונים

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

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

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

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

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

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

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

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

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

מידע נוסף על מטא-נתונים ב-Dataplex Universal Catalog זמין במאמר מידע על ניהול מטא-נתונים ב-Dataplex Universal 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.

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

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

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

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

מגבלות

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

תמחור

למידע נוסף על תמחור, ראו תמחור של Dataplex Universal Catalog.

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

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

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

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

הגדרת הכלל

כללים מוגדרים מראש

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

מידות

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

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

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

הרצת כלל

סינון נתונים

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

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

מעקב והתראות

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

מגבלות

תמחור

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

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