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

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

אתם יכולים לראות את המפה המלאה הזו של מסלול הנתונים ישירות במסוף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 רמות), משתמשים ב-method‏ SearchLineageStreaming.

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

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

זיהוי הכיוון

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

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

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

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

מהו תהליך של שרשרת מקורות מידע?

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

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

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

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

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