(יצא משימוש) מדריך למשתמשים ב-Data Mesh

ה-Data Mesh for Cortex Framework מרחיב את בסיס הנתונים כדי לאפשר משילות מידע, יכולת גילוי ובקרת גישה באמצעות מטא-נתונים של BigQuery וKnowledge Catalog. ההטמעה מתבצעת על ידי אספקת קבוצת בסיס של משאבי מטא-נתונים והערות לנכסי BigQuery שאפשר להתאים אישית, ואפשר גם לפרוס אותם לצד תשתית הנתונים. המפרטים הבסיסיים האלה מספקים הגדרה מותאמת אישית שהיא הבסיס למטא-נתונים, כדי להשלים את תשתית הנתונים של Cortex Framework. לפני שממשיכים לקרוא את המדריך הזה, מומלץ לעיין במושגים שקשורים ל-Data Mesh.

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

ארכיטקטורת Data Mesh ל-Cortex Framework

איור 1. ארכיטקטורת Data Mesh ל-Cortex Framework.

עיצוב

ה-Data Mesh של Cortex מתוכנן באופן דומה לבסיס הנתונים הכולל, והוא מורכב משלושה שלבים עם רכיבי משנה שונים שמנוהלים על ידי Cortex או על ידי המשתמשים:

  1. עדכון מפרטי משאבי הבסיס: בכל מהדורה, Cortex מעדכן את מפרטי משאבי הבסיס, ומספק בסיס סטנדרטי למטא-נתונים של Data Mesh.
  2. התאמה אישית של מפרטי המשאבים: לפני הפריסה, המשתמשים יכולים להתאים את מפרטי המשאבים לתרחישי השימוש ולדרישות הספציפיות שלהם.
  3. פריסה ועדכונים של Data Mesh: המשתמשים יכולים להפעיל את Data Mesh בקובץ ההגדרות של Cortex. הוא נפרס אחרי נכסי הנתונים במהלך הפריסה של Cortex. בנוסף, המשתמשים יכולים לפרוס את Data Mesh באופן עצמאי כדי לקבל עדכונים נוספים.

תכנון של Data Mesh עבור Cortex Framework

איור 2. עיצוב Data Mesh ל-Cortex Framework.

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

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

עומס עבודה מקור נתונים נתיב בספרייה
תפעולי SAP ECC src/SAP/SAP_REPORTING/config/ecc
SAP S/4 HANA src/SAP/SAP_REPORTING/config/s4
‫Salesforce Sales Cloud‏ (SFDC) src/SFDC/config
Oracle EBS src/OracleEBS/config
שיווק CM360 src/marketing/src/CM360/config
Google Ads src/marketing/src/GoogleAds/config
Meta src/marketing/src/Meta/config
‫Salesforce Marketing Cloud‏ (SFMC) src/marketing/src/SFMC/config
טיקטוק src/marketing/src/TikTok/config
YouTube (עם DV360) src/marketing/src/DV360/config
‫Google Analytics 4 src/marketing/src/GA4/config

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

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

הפעלת ממשקי API ואימות הרשאות

שינוי ערכי ברירת המחדל של Data Mesh מאפשר לכם להטמיע תכונות מעבר לתיאורים. אם אתם צריכים לשנות את ערכי ברירת המחדל של Data Mesh ב-config.json כדי להטמיע תכונות מעבר לתיאורים, אתם צריכים לוודא שהגדרתם את ממשקי ה-API הנדרשים והרשאות הגישה כמו שמתואר בטבלה הבאה. כשפורסים את Data Mesh עם שכבת הבסיס של הנתונים, צריך להעניק הרשאות למשתמש הפורס או לחשבון Cloud Build. אם הפריסה כוללת פרויקטים שונים של מקור ויעד, צריך לוודא שממשקי ה-API וההרשאות האלה מופעלים בשני הפרויקטים בכל מקום שבו נעשה שימוש בתכונות האלה.

התכונה תפקידי הרשאה מסמכי תיעוד
גישה לנכסים ולשורות ב-BigQuery בעלים של נתונים ב-BigQuery מידע נוסף זמין במאמר בנושא התפקידים הנדרשים לתפקידים של נכסים, ובמאמר בנושא ההרשאות הנדרשות לתפקידים של שורות.
גישה לעמודות ב-BigQuery Policy Tag Admin מידע נוסף זמין במאמרים תפקידים שמשמשים לבקרת גישה ברמת העמודה והגבלת גישה באמצעות בקרת גישה ברמת העמודה.
תגי קטלוג הבעלים של TagTemplate ב-Data Catalog מידע נוסף זמין במאמרים תיוג טבלה ב-BigQuery באמצעות Data Catalog וIAM ב-Data Catalog.
Knowledge Catalog Lakes Dataplex Editor מידע נוסף זמין במאמר בנושא יצירת אגם.

הסבר על מפרטי משאבים בסיסיים

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

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

בקטעים הבאים מופיעות דוגמאות בסיסיות לכל סוג של מפרט והסבר על אופן ההתאמה האישית שלהם. המפרטים הבסיסיים מסומנים בתג ## CORTEX-CUSTOMER במקומות שבהם צריך לשנות אותם כדי להתאים לפריסה, אם אפשרות הפריסה המשויכת מופעלת. לשימושים מתקדמים, אפשר לעיין בהגדרה הקנונית של סכימות המפרט האלה ב-src/common/data_mesh/src/data_mesh_types.py.

מקורות מידע על מטא-נתונים

משאבי המטא-נתונים הם ישויות משותפות שקיימות בפרויקט שאפשר להחיל על הרבה נכסי נתונים. רוב המפרטים כוללים שדה display_name שכפוף לקריטריונים הבאים:

  • הוא יכול לכלול רק מספרים ואותיות, קווים תחתונים, מקפים ורווחים בתקן Unicode.
  • לא יכול להתחיל או להסתיים ברווחים.
  • האורך המרבי הוא 200 תווים.

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

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

Knowledge Catalog Lakes

האגמים, האזורים והנכסים של Knowledge Catalog משמשים לארגון הנתונים מנקודת מבט הנדסית. לאגמים יש region ולאזורים יש location_type. שניהם קשורים למיקום של Cortex ‏(config.json > location). המיקום של Cortex מגדיר איפה מאוחסנים מערכי הנתונים של BigQuery, והוא יכול להיות באזור אחד או במספר אזורים. האזור location_type צריך להיות מוגדר כ-SINGLE_REGION | MULTI_REGION כדי להתאים לזה. עם זאת, אזורי Lake חייבים להיות תמיד אזור יחיד. אם המיקום והאזור של Cortex location_type הם אזורים מרובים, בוחרים אזור יחיד בתוך הקבוצה הזו עבור אזור האגם.

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

מקרה לדוגמה ב-lakes.yaml:

המשאבים האלה מוגדרים בקובצי YAML שמציינים את data_mesh_types.Lakes.

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

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

השדה display_name של התבנית משמש כמזהה השדה וחייב לעמוד בדרישות של TagTemplate.fields שצוינו ב-Class TagTemplate. מידע נוסף על סוגי השדות הנתמכים זמין במאמר סוגי שדות ב-Data Catalog.

ב-Cortex Data Mesh, כל תבניות התגים נוצרות כקריאות באופן ציבורי. בנוסף, נוסף level מושג חדש למפרטים של תבניות ליצירת תגים, שקובע אם צריך להחיל תג על נכס שלם, על שדות בודדים בנכס או על שניהם. הערכים האפשריים הם: ASSET | FIELD | ANY. בשלב הזה, אין אכיפה קפדנית של הדרישה הזו, אבל בעתיד יכול להיות שייערכו בדיקות אימות כדי לוודא שתגים מוחלים ברמה המתאימה במהלך הפריסה.

דוגמה

תבניות מוגדרות בקובצי YAML שמציינים data_mesh_types.CatalogTagTemplates.

תגי קטלוג הם מקרים של התבניות, והם מפורטים בהמשך בקטע 'הערות לנכסים'.

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

ב-Cortex Framework אפשר להפעיל בקרת גישה ברמת הנכס או העמודה בכל הארטיפקטים שמשויכים לתבנית של תג קטלוג. לדוגמה, אם משתמשים רוצים להעניק גישה לנכסים על סמך תחום עסקי, הם יכולים ליצור asset_policies עבור line_of_business Catalog Tag Template עם חשבונות משתמשים שונים שצוינו לכל תחום עסקי. כל מדיניות מקבלת filters שאפשר להשתמש בהן רק כדי להתאים תגים עם ערכים ספציפיים. במקרה הזה, נוכל להתאים את ערכי domain. שימו לב: האופרטורים האלה של filters תומכים רק בהתאמה של שוויון ולא באופרטורים אחרים. אם מפורטים כמה מסננים, התוצאות צריכות לעמוד בכל המסננים (לדוגמה, filter_a AND filter_b). קבוצת המדיניות הסופית של הנכס היא איחוד של המדיניות שהוגדרה ישירות בהערות ושל המדיניות מתבניות.

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

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

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

כדי להבין את המפרט של התכונה המתקדמת הזו, אפשר לעיין בהגדרות של הפרמטרים asset_policies ו-field_policies ב-data_mesh_types.CatalogTagTemplate.

מילון מונחים בנושא קטלוגים

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

טקסונומיות ותגים של מדיניות

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

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

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

דוגמה

טקסונומיות של מדיניות מוגדרות בקובצי YAML שמציינים את data_mesh_types.PolicyTaxonomies.

הערות לנכסים

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

  • תיאורי נכסים
  • תיאורי השדות
  • תגי קטלוג
  • בקרת גישה ברמת הנכס, השורה והעמודה

השכבה התחתונה של הנתונים ב-Cortex Framework מציעה הערות (תיאורים) שהוגדרו מראש לעומסי העבודה הבאים.

  • SAP ECC (נתונים גולמיים, נתונים מ-CDC ודיווח)
  • ‫SAP S4 HANA (נתונים גולמיים, CDC ודיווח)
  • SFDC (דיווח בלבד)
  • Oracle EBS (דיווח בלבד)
  • ‫CM360 (דיווח בלבד)
  • ‫Google Ads (דיווח בלבד)
  • Meta (דיווח בלבד)
  • SFMC (דיווח בלבד)
  • טיקטוק (דיווח בלבד)
  • ‫YouTube (עם DV360) (דיווח בלבד)
  • ‫Google Analytics 4 (דיווח בלבד)

דוגמה

ההערות מוגדרות בקובצי YAML שמציינים את data_mesh_types.BqAssetAnnotation.

תגי קטלוג

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

הערכים של TIMESTAMP צריכים להיות באחד מהפורמטים הבאים:

  "%Y-%m-%d %H:%M:%S%z"
  "%Y-%m-%d %H:%M:%S"
  "%Y-%m-%d"

דוגמה

הגדרה של מפרט מופיעה בdata_mesh_types.CatalogTag.

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

שליטה בגישה לנתוני BigQuery ב-Cortex Framework באמצעות מדיניות גישה. במדיניות הזו מוגדרים מי (חשבונות משתמשים) יכולים לגשת לנכסי נתונים ספציפיים, לשורות בנכס או אפילו לעמודות ספציפיות. הגורמים המורשים צריכים לפעול לפי פורמט ספציפי שמוגדר על ידי חבר IAM Policy Binding.

גישה ברמת הנכס

אתם יכולים להעניק גישה לנכסי BigQuery שלמים עם הרשאות שונות:

  • READER: צפייה בנתונים בנכס.
  • WRITER: לשנות ולהוסיף נתונים לנכס.
  • OWNER : שליטה מלאה בנכס, כולל ניהול הגישה.

ההרשאות האלה מקבילות להצהרה GRANT DCL ב-SQL.

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

דוגמה

הגדרה של מפרט מופיעה בdata_mesh_types.BqAssetPolicy.

גישה ברמת השורה

אפשר להעניק גישה לקבוצות של שורות על סמך מסננים של ערכים בעמודות מסוימות. כשמציינים את מדיניות הגישה לשורות, מחרוזת המסנן שצוינה תווסף ל-CREATE DDL statement. אם הדגל overwrite מופעל, המערכת משמיטה את כל כללי המדיניות הקיימים לגישה לשורות לפני שהיא מחילה כללי מדיניות חדשים.

כמה נקודות שכדאי לזכור לגבי גישה ברמת השורה:

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

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

דוגמה

הגדרה של מפרט מופיעה בdata_mesh_types.BqRowPolicy.

גישה ברמת העמודה

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

דוגמה

הגדרה של מפרט מופיעה בdata_mesh_types.PolicyTagId.

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

אפשר לפרוס את רשת הנתונים כחלק מפריסת בסיס הנתונים, או בנפרד. בכל מקרה, המערכת משתמשת בקובץ config.json של Cortex כדי לקבוע משתנים רלוונטיים, כמו שמות של מערכי נתונים ב-BigQuery ואפשרויות פריסה. כברירת מחדל, פריסת Data Mesh לא תסיר או תחליף משאבים או הערות קיימים, כדי למנוע אובדן לא מכוון של נתונים. עם זאת, יש גם אפשרות לדרוס משאבים קיימים כשפורסים אותו לבד.

אפשרויות פריסה

אפשר להפעיל או להשבית את אפשרויות הפריסה הבאות בהתאם לצרכים של המשתמש ולאילוצים של ההוצאות בconfig.json > DataMesh.

אפשרות הערות
deployDescriptions זו האפשרות היחידה שמופעלת כברירת מחדל, והיא פורסת הערות של BigQuery עם תיאורים של נכסים ועמודות. לא נדרשת הפעלה של ממשקי API או הרשאות נוספים.
deployLakes פריסת אגמים ואזורים.
deployCatalog פריסה של משאבי Catalog Template והתגים המשויכים שלהם בהערות לנכסים.
deployACLs פריסת משאבים של טקסונומיית מדיניות ומדיניות של בקרת גישה ברמת הנכס, השורה והעמודה באמצעות הערות לנכס. היומנים מכילים הודעות שמציינות איך מדיניות הגישה השתנתה.

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

כברירת מחדל, config.json > deployDataMesh מאפשר פריסה של תיאורי נכסים של Data Mesh בסוף כל שלב בניית עומס עבודה. הגדרת ברירת המחדל הזו לא מחייבת הפעלה של ממשקי API או תפקידים נוספים. אפשר להטמיע תכונות נוספות של Data Mesh עם שכבת הבסיס של הנתונים. לשם כך, צריך להפעיל את אפשרויות ההטמעה, את ממשקי ה-API והתפקידים הנדרשים ולשנות את מפרטי המשאבים המשויכים.

פריסה לבד

כדי לפרוס את Data mesh בלבד, המשתמשים יכולים להשתמש בקובץ common/data_mesh/deploy_data_mesh.py. הכלי הזה משמש במהלך תהליכי הבנייה כדי לפרוס את רשת הנתונים (data mesh) של עומס עבודה אחד בכל פעם, אבל כשמפעילים אותו ישירות, אפשר להשתמש בו גם כדי לפרוס כמה עומסי עבודה בו-זמנית. צריך להפעיל את עומסי העבודה של המפרטים שרוצים לפרוס בקובץ config.json. לדוגמה, צריך לוודא ש: deploySAP=true אם פורסים את Data Mesh עבור SAP.

כדי לוודא שאתם פורסים עם החבילות והגרסאות הנדרשות, אתם יכולים להריץ את כלי השירות מאותו אימג' שבו נעשה שימוש בתהליך הפריסה של Cortex באמצעות הפקודות הבאות:

  # Run container interactively
  docker container run -it gcr.io/kittycorn-public/deploy-kittycorn:v2.0

  # Clone the repo
  git clone https://github.com/GoogleCloudPlatform/cortex-data-foundation

  # Navigate into the repo
  cd cortex-data-foundation

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

  python src/common/data_mesh/deploy_data_mesh.py -h

דוגמה להפעלה ב-SAP ECC:

  python src/common/data_mesh/deploy_data_mesh.py \
    --config-file config/config.json \
    --lake-directories \
        src/SAP/SAP_REPORTING/config/ecc/lakes \
    --tag-template-directories \
        src/SAP/SAP_REPORTING/config/ecc/tag_templates \
    --policy-directories \
        src/SAP/SAP_REPORTING/config/ecc/policy_taxonomies \
    --annotation-directories \
        src/SAP/SAP_REPORTING/config/ecc/annotations

מידע על מיקומי ספריות זמין בקטע ספריות של רשת נתונים.

החלפה

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

כשמחליפים משאבי מטא-נתונים כמו Lakes, ‏ Catalog Tag Templates ו-Policy Tags, כל המשאבים הקיימים עם אותם שמות נמחקים, אבל משאבים קיימים עם שמות שונים לא משתנים. המשמעות היא שאם מפרט משאב מוסר לגמרי מקובץ ה-YAML ואז רשת הנתונים נפרסת מחדש עם החלפה מופעלת, מפרט המשאב לא יימחק כי לא תהיה התנגשות בשמות. הסיבה לכך היא שפריסת Cortex Data Mesh לא תשפיע על משאבים קיימים שאולי נמצאים בשימוש.

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

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

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

עיון ב-Data Mesh

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

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

שושלת נתונים

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

לכל בקשה שקשורה ל-Cortex Data Mesh או ל-Cortex Framework, אפשר לעבור לקטע תמיכה.