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

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

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

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

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

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

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

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

זיהוי הכיוון

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

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

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

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

מהו תהליך של שושלת נתונים?

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

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

  CREATE TABLE `dataplex-docs.data_lineage_demo.total_green_trips_22_21`
  AS
  SELECT
      vendor_id,
      COUNT(*) AS number_of_trips
  FROM
      (
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2022`
          UNION ALL
          SELECT vendor_id
          FROM `dataplex-docs.data_lineage_demo.nyc_green_trips_2021`
      )
  GROUP BY
      vendor_id;

הפורמט של שם משאב REST לתהליך הוא projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID.

לדוגמה: projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6

מידע נוסף על המשאב process זמין במאמר הפניה למשאב Process.

מהי הפעלה של שושלת נתונים?

הרצה היא ביצוע יחיד של תהליך. יכולות להיות כמה הרצות לתהליך.

כל הרצה היא פעולה ייחודית שמאופיינת על ידי startTime,‏ endTime ומצב סופי, כמו COMPLETED,‏ FAILED או ABORTED.

לדוגמה, אם מריצים את שאילתת ה-SQL מהקטע Process בשעה 9:00 בבוקר, נוצרת הרצה ספציפית. אם מריצים את אותה שאילתה שוב בשעה 10:00, נוצרת ריצה חדשה ושונה. שתי ההרצות מקושרות לאותו תהליך אב.

הפורמט של שם משאב REST להרצה מראה שהיא צאצא של תהליך: projects/PROJECT_NUMBER/locations/LOCATION/processes/PROCESS_ID/runs/RUN_ID.

לדוגמה: projects/123456789123/locations/us/processes/sh-0548bbf4ff3c8072a6c7372ba1acafb6/runs/83dd03a51cd2ac80f465c9e267a950b1

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

מהו אירוע של שושלת נתונים?

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

לדוגמה, אם ההרצה מבצעת את שאילתת ה-SQL שמוסברת בקטע תהליך, אירוע של שושלת מתעד את השימוש בטבלאות המקור nyc_green_trips_2021 ו-nyc_green_trips_2022 כדי ליצור את טבלת היעד total_green_trips_22_21.

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

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

במאמר Column-level lineage מוסבר איך אירועים תומכים ב-lineage ברמת העמודה.

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

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

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

BigQuery

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

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

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

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

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

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

  • Cloud Data Fusion

    אי אפשר להגביל את מעקב המקורות רק ל-Cloud Data Fusion כש-Data Lineage API מופעל בפרויקט.

  • Dataflow

    אפשר לתעד אירועים של שרשרת מקורות נתונים באמצעות משימות Dataflow ולפרסם אותם ב-Data Lineage API.

  • Lakehouse for Iceberg REST catalog tables

  • ‫Looker (Google Cloud core) (גרסת Preview)

    יש תמיכה בהמחשה של מטא-נתונים של Looker (הליבה של Google Cloud) ממקורות BigQuery באמצעות מעקב אחר מקורות הנתונים. צריך להפעיל את מעקב מקורות הנתונים ברמת המשאב של Looker (Google Cloud core) וברמת שירות מעקב מקורות הנתונים.

  • Managed Service for Apache Airflow

    ב-Managed Airflow יש בקרה על שילוב של נתוני שושלת ברמת הסביבה. התכונה 'מקורות נתונים' מופעלת אוטומטית בכל סביבות Managed Airflow חדשות שעומדות בדרישות. בסביבות קיימות, משתמשים בהגדרות הסביבה כדי להפעיל או להשבית את השילוב של מעקב אחר מקורות נתונים. אתם יכולים להגדיר את ההטמעה של שושלת הנתונים ב-Managed Airflow כדי להפעיל או להשבית את ההטמעה האוטומטית של שושלת הנתונים.

  • ‫Managed Service for Apache Spark: אשכולות Apache Hive

    אתם יכולים לתעד אירועים של שרשרת מקורות נתונים באמצעות משימות Apache Spark Hive ב-Managed Service for Apache Spark ולפרסם אותם ב-Data Lineage API. אתם יכולים להגדיר את הטמעת שושלת הנתונים ב-Managed Service for Apache Spark כדי להפעיל או להשבית את הטמעת שושלת הנתונים באופן אוטומטי.

  • Managed Service for Apache Spark: אשכולות Apache Spark

    אתם יכולים לתעד אירועים של שרשרת מקורות נתונים באמצעות משימות Spark ב-Managed Service for Apache Spark ולפרסם אותם ב-Data Lineage API. אתם יכולים להגדיר את הטמעת שושלת הנתונים ב-Managed Service for Apache Spark כדי להפעיל או להשבית את הטמעת שושלת הנתונים באופן אוטומטי.

  • Managed Service for Apache Spark: פריסה ללא שרת

    אפשר לתעד אירועים של שרשרת מקורות באמצעות משימות של Managed Service for Apache Spark serverless ולפרסם אותם ב-Data Lineage API. אתם יכולים להגדיר את הטמעת שושלת הנתונים ב-Managed Service for Apache Spark כדי להפעיל או להשבית את הטמעת שושלת הנתונים באופן אוטומטי.

  • Vertex AI Feature Store

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

  • Vertex AI Pipelines

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

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

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

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

לדוגמה, מטען ייעודי (payload) של משאב תהליך עם מאפיין sql מותאם אישית:

{
  "displayName": "custom-sql-query",
  "attributes": {
    "sql": "SELECT user_id, SUM(amount) FROM `project.dataset.purchases` GROUP BY user_id"
  }
}

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

OpenLineage

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

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

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

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

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

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

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

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

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

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

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

שיקולים ומגבלות לגבי שושלת נתונים

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

אמצעי בקרה על שרשרת המקור ברמת המוצר

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

תאימות של שושלת הנתונים

  • שושלת הנתונים מתעדת מטא-נתונים על תנועת הנתונים, אבל לא מתעדת את הנתונים עצמם. מידע על השדות שנכללים במטא-נתונים מופיע במודל המידע של Data Lineage ובהפניה ל-Data Lineage API.
  • מקורות הנתונים כחלק מ-Knowledge Catalog תומכים ב-VPC-SC.
  • ב-Knowledge Catalog אין אפשרות להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) כדי להגן על מטא-נתונים של שושלת נתונים שנאספו.

מגבלות של שושלת הנתונים

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

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

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

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

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

  • המשאב נמצא בארגון אחר.
  • המשתמש לא חבר בארגון שמארח את המשאב.

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

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

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

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

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

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

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

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

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

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

תמחור

ב-Knowledge Catalog נעשה שימוש במק"ט של עיבוד פרימיום (שנמדד ביחידות של עיבוד נתונים, או DCU) כדי לחייב על שושלת הנתונים. לפרטים על התעריפים, אפשר לעיין בתמחור של Knowledge Catalog או להשתמש ב Google Cloud מחשבון התמחור.

גורמי עלות והשפעה על החיוב

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

  • הפעלה לכל פרויקט. ‫Data Lineage API פועל על בסיס כל פרויקט. מומלץ לבדוק את ההשפעה על החיוב לפני שמפעילים את התכונה הזו בתהליכי עבודה בפרויקטים שכוללים הרבה נתונים.
  • אחסון מטא-נתונים וחיפוש. מטא-נתונים של שושלת (תהליכים, הפעלות, אירועים וקישורים) שמאוחסנים במהלך חלון השמירה של 30 יום מחויבים במסגרת מק"ט האחסון של מטא-נתונים. צפייה ב-lineage במסוף Google Cloud לא גוררת חיובים על שאילתות או סריקות ב-BigQuery.
  • ‫BigQuery Omni. עיבוד שרשרת המקורות מבוצע באזורים ספציפיים, והעלויות תלויות באזורים שבהם העיבוד מתבצע.
  • מערכי נתונים מרובי אזורים ב-BigQuery. אם משתמשים במערכי נתונים במספר אזורים (לדוגמה, US במספר אזורים), מערכת BigQuery מנתבת באופן דינמי שאילתות באזורים פיזיים שונים של מרכזי נתונים. ה-Data Lineage פועל לצד ביצוע השאילתה במיקום הפיזי שבו העבודה בוצעה (לדוגמה, us-east1). כתוצאה מכך, בחשבונית שלכם בחיוב ב-Cloud יופיעו רשומות של מק"טים אזוריים של DCU Lineage.
  • סוגים מותאמים אישית של מקורות תנועה. אם קוראים ל-Data Lineage API Origin sourceType עם ערך שונה מ-CUSTOM, יחולו עלויות נוספות.

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

  • מגבלות על מדדים ב-Cloud Monitoring. צריכת יחידות DCU של מעקב אחר מקורות נתונים מתבצעת במחשוב ללא שרתים, ולא מפיקה מדדים של סדרות זמן בזמן אמת ב-dataplex.googleapis.com/* אל Cloud Monitoring.
  • סינון וציון מאפיינים של חיובים בחשבון לחיוב ב-Cloud. כדי להפריד בין חיובים על שושלת הנתונים לבין חיובים אחרים במק"ט של עיבוד פרימיום ב-Knowledge Catalog ולשייך אותם, צריך להשתמש בתווית goog-dataplex-workload-type עם הערך LINEAGE בדוח החיוב ב-Cloud או בייצוא נתוני החיוב ב-Cloud ל-BigQuery. דוגמאות מפורטות לשאילתות מופיעות במאמר מעקב אחרי עלויות של יחידות DCU ב-Knowledge Catalog ושיוך שלהן באמצעות ייצוא של נתוני החיוב ב-Cloud.
  • השבתה בפרויקטים של פיתוח. כדי למנוע עלויות עיבוד מיותרות, מפעילים את Data Lineage API רק בפרויקטים שבהם נדרש מעקב אחר שרשרת המקור.
  • הפסקת החיובים. השימוש ב-Data Lineage API כרוך בחיובים בנפרד מ-Dataplex API. השבתה של Dataplex API לא משביתה את Data Lineage API ולא מפסיקה את החיובים שלו. כדי להימנע מחיובים על שושלת הנתונים, צריך להשבית את שושלת הנתונים על ידי השבתת Data Lineage API.

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