מידע על שושלת נתונים

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

אפשר לראות את המפה המלאה הזו של מסלול הנתונים ישירות במסוף של נכסים שנוצרו במוצרים כמו Knowledge Catalog (לשעבר Dataplex Universal Catalog),‏ BigQuery (כולל טבלאות חיצוניות שנוצרו עבור Iceberg REST Catalog) ו-Vertex AI.Google Cloud מכיוון שלרוב תהליכי העבודה מתפרסים על פני כמה אזורים, Knowledge Catalog תומך בשיוך למקורות במספר אזורים, ומספק תצוגה מאוחדת של מסלול הנתונים במערכת האקולוגית הגלובלית של Google Cloud . משתמשים מתקדמים יכולים גם לאחזר את המידע הזה באמצעות Data Lineage API.

למה צריך שושלת נתונים

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

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

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

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

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

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

איך פועל מעקב אחר מקורות נתונים

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

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

    • Google Cloud שירותים: כש-Data Lineage API מופעל, שירותים נתמכים כמו BigQuery ו-Dataflow מדווחים אוטומטית על אירועי שושלת בכל פעם שנתונים מועברים או משתנים.

    • מקורות מותאמים אישית: במערכות שלא נתמכות אוטומטית על ידיGoogle Cloud שילובים, אפשר להשתמש ב-Data Lineage API כדי לתעד באופן ידני מידע על מקורות הנתונים. מומלץ לייבא אירועים בפורמט שמותאם לתקן OpenLineage.

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

    • ‫Data Lineage API: ה-API הזה משמש כנקודת כניסה יחידה לכל המידע על מקורות הנתונים הנכנסים. הוא משתמש במודל נתונים היררכי שמורכב משלושה מושגי ליבה: תהליך, הרצה ואירוע.

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

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

    • עיון חזותי: במסוף Google Cloud , שירות קצה קדמי מאחזר ומעבד את שושלת הנתונים כתרשים או כרשימה אינטראקטיביים. התמיכה הזו זמינה ב-Knowledge Catalog, ב-BigQuery, ב-Lakehouse (לטבלאות של Iceberg REST Catalog), בשכבה הפיזית (Cloud Storage) וב-Vertex AI (למודלים, למערכי נתונים, דרך צינורות, לתצוגות של מאגר תכונות ולקבוצות תכונות). התכונה הזו מצוינת לבדיקה ויזואלית של מסלול הנתונים. מידע נוסף מופיע במאמר תצוגות של שושלת נתונים במסוף Google Cloud .

    • גישה פרוגרמטית: באמצעות לקוח API, אפשר לתקשר ישירות עם Data Lineage API כדי לבצע אוטומציה של ניהול שושלת הנתונים. כך תוכלו לכתוב מידע על שושלת נתונים ממקורות בהתאמה אישית. בנוסף, אפשר לקרוא את נתוני השושלת המאוחסנים ולשאול עליהם שאילתות כדי להשתמש בהם באפליקציות אחרות או כדי ליצור דוחות בהתאמה אישית.

באיזה API צריך להשתמש כדי לעקוב אחרי מקורות הנתונים?

כדי לבצע בדיקות מיידיות ברמה אחת, משתמשים ב-API‏ SearchLinks. כדי ליצור תרשים מלא של שושלת נתונים או לבצע ניתוח השפעות מעמיק (עד 100 רמות), צריך להשתמש ב-API‏ SearchLineageStreaming.

בהתאם לתרחיש השימוש, בוחרים את השיטה המתאימה ביותר:

תכונה SearchLinks SearchLineageStreaming
עומק רמה אחת (שכנים מיידיים) עד 100 רמות
הרצה סינכרוני סטרימינג בזמן אמת
תרחיש לדוגמה חיפושים פשוטים של מקורות או יעדים ישירים יצירת גרף מלא של שושלת נתונים או ביצוע ניתוח השפעות

זיהוי הכיוון

  • Upstream (Origins):
    • ב-SearchLinks, מגדירים את השדה target ל-FQN של הנכס.
    • ב-SearchLineageStreaming, מגדירים את direction לערך UPSTREAM.
  • Downstream (Destinations):
    • ב-SearchLinks, מגדירים את השדה source ל-FQN של הנכס.
    • ב-SearchLineageStreaming, מגדירים את direction לערך DOWNSTREAM.

אילו מקורות נתונים נתמכים לצורך מעקב אחר מקורות הנתונים?

אפשר לאכלס את פרטי שושלת הנתונים ב-Knowledge Catalog בדרכים הבאות:

  • באופן אוטומטי משירותים משולבים Google Cloud
  • באופן ידני, באמצעות Data Lineage API למקורות מותאמים אישית
  • ייבוא אירועים מ-OpenLineage

BigQuery

כשמפעילים את התכונה 'מקורות נתונים' בפרויקט BigQuery, ב-Knowledge Catalog מתועדים באופן אוטומטי מקורות הנתונים של הרכיבים הבאים:

משימות העתקה, שאילתה וטעינה ב-BigQuery מיוצגות כתהליכים.

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

כל תהליך מכיל את job_id של BigQuery ברשימת attributes של משימת BigQuery האחרונה.

שירותים נוספים

התכונה 'מקורות נתונים' תומכת בשילוב עם השירותים הבאים:Google Cloud

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

אתם יכולים להשתמש ב-Data Lineage API כדי לתעד באופן ידני מידע על שרשרת מקורות הנתונים של כל מקור נתונים שמערכות משולבות לא תומכות בו.

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

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

OpenLineage

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

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

כשמפעילים את Data Lineage API, Google Cloud מערכות שתומכות ב-Data Lineage מתחילות לדווח על תנועת הנתונים שלהן. כל מערכת משולבת יכולה לשלוח מידע על מקורות נתונים שונים.

שליטה בהטמעה של היסטוריית השינויים

כדי לנהל את העלויות ואת מדיניות השליטה, אתם יכולים להפעיל או להשבית את יצירת שושלת נתונים לשירותים ספציפיים. Google Cloud אפשר להגדיר את ההטמעה הזו באופן מרכזי ברמת הארגון, התיקייה והפרויקט. במהלך תקופת הטרום-השקה, התכונה הזו תומכת בהגדרת הטמעה של שושלת נתונים בשירותים הבאים: Managed Service for Apache Spark,‏ BigQuery ו-Managed Service for Apache Airflow.

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

  • אם מגדירים הגדרה ברמת הפרויקט, Knowledge Catalog משתמש בזה.
  • אם לא מוגדרת הגדרה ברמת הפרויקט, Knowledge Catalog משתמש בהגדרה מהתיקייה הקרובה ביותר ברמת ההורה עם הגדרה מפורשת.
  • אם לא מוגדרת תצורה ברמת הפרויקט או התיקייה, Knowledge Catalog משתמש בתצורה ברמת הארגון.
  • אם לא מוגדרת הגדרה באף אחת מהרמות האלה, Knowledge Catalog משתמש בברירת המחדל של המערכת לשילוב. ברירת המחדל להגדרת הפעלת שושלת נתונים יכולה להיות מופעלת או מושבתת. ב-Managed Service for Apache Spark, ‏ BigQuery ו-Managed Service for Apache Airflow, האפשרות 'הוספת נתוני שושלת' מופעלת כברירת מחדל אם Data Lineage API פעיל.

לדוגמה, נניח שיש ארגון test-org עם ההגדרות הבאות של שושלת הנתונים ב-Managed Service for Apache Spark:

  • ארגון test-org: מופעל
    • תיקייה folder-a: מושבת
      • פרויקט project-a: לא הוגדרה הגדרה
    • תיקייה folder-b: מופעל
      • פרויקט project-b: מושבת

במקרה כזה, ההגדרות הרלוונטיות הן:

  • ב-project-a, הטמעת נתוני השושלת מושבתת. Knowledge Catalog מתחיל להעריך מ-project-a, לא מוצא הגדרה, עובר ל-folder-a ומחיל את ההגדרה Disabled מ-folder-a.
  • ב-project-b, הטמעת נתוני השושלת מושבתת. החל מ-project-b, Knowledge Catalog מתחיל להעריך ומחיל את ההגדרה מושבת, תוך עקיפת ההגדרות ב-folder-b וב-test-org.

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

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

שושלת נתונים במספר אזורים

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

ככל שארכיטקטורות נתונים מודרניות של ארגונים גדלות, תהליכי עבודה של צינורות נתונים חוצים לעיתים קרובות גבולות של פרויקטים ואזורים. לדוגמה, צינור טרנספורמציה של BigQuery שפועל ב-us-central1 עשוי לקרוא טבלת מקור ב-us-east1 ולהפיק מדדים מצטברים לקטגוריה של Cloud Storage שנמצאת ב-europe-west1.

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

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

מגבלות

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

  • כל פרטי השושלת נשמרים במערכת למשך 30 ימים בלבד.

  • פרטי השושלת נשמרים גם אחרי שמוחקים את מקור הנתונים שקשור אליהם. לדוגמה, אם מוחקים טבלה ב-BigQuery, עדיין אפשר לראות את שושלת הנתונים שלה דרך ה-API והמסוף למשך עד 30 יום.

  • ב-BigQuery, שושלת הנתונים לא מתעדת באופן אוטומטי מידע על שושלת ישירה של נתונים בשגרות. אם משתמשים בשגרה בשאילתה, נרשם ב-Data Lineage קשר בין הטבלאות שהשגרה קוראת כהסתמכויות של טבלאות שהשאילתה כותבת.

מגבלות על שושלת נתונים ברמת העמודה

אלו הגבלות נוספות שחלות על שושלת נתונים ברמת העמודה:

  • אין איסוף של שושלת נתונים ברמת העמודה עבור משימות טעינה או עבור שגרות ב-BigQuery.

  • השיוך (lineage) ברמת העמודה במעלה הזרם לא נאסף עבור טבלאות חיצוניות.

  • אם עבודה יוצרת יותר מ-1,500 קישורים ברמת העמודה, לא נאסף מידע על שושלת נתונים ברמת העמודה. במקרים כאלה, נאספת רק שושלת נתונים ברמת הטבלה.

  • התמיכה ב-CLL מוגבלת לעמודות ברמה העליונה בטבלאות של BigQuery. אין תמיכה בשדות מקוננים בתוך סוגים מורכבים (כמו STRUCT או JSON).

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

  • התמיכה בטבלאות עם מחיצות מוגבלת, כי עמודות של מחיצות כמו _PARTITIONDATE ו-_PARTITIONTIME לא מזוהות בגרף של שרשרת המקור.

  • מגבלות של מסוף Google:

    • המעבר בתרשים של שרשרת המקור מוגבל לעומק של 20 רמות ול-10,000 קישורים בכל כיוון.

תמחור

  • ב-Knowledge Catalog משתמשים במק"ט של עיבוד פרימיום כדי לחייב על שושלת נתונים. מידע נוסף מפורט בקטע תמחור.

  • כדי להפריד בין החיובים על שושלת הנתונים לבין חיובים אחרים במק"ט של עיבוד פרימיום ב-Knowledge Catalog, משתמשים בתווית goog-dataplex-workload-type עם הערך LINEAGE בדוח החיוב ב-Cloud.

  • אם קוראים ל-Data Lineage API Origin sourceType עם ערך שונה מ-CUSTOM, יחולו עלויות נוספות.

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