מידע על מוצרי נתונים

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

יכולות עיקריות

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

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

מושגים מרכזיים

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

מוצר נתונים

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

נכס

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

קבוצת גישה

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

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

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

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

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

צרכן של מוצר נתונים

האדם, הצוות או סוכן ה-AI שמשתמשים במוצרי הנתונים כדי ליצור תובנות.

חוזה

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

תרחיש שימוש לדוגמה

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

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

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

  • נכסים

    • טבלאות ב-BigQuery‏ order_details ו-user_traffic (שמכילות נתונים היסטוריים של הזמנות ומקורות תנועה)
    • תצוגה מפורטת ב-BigQuery‏ user_demographics (מספקת פרטי משתמשים ללא פרטים אישיים מזהים)

  • קבוצות גישה

    • קבוצות מוגדרות מראש של Reader ו-Writer כדי לייעל את בקשות הגישה

  • חוזה

    • חוזה שמגדיר את תדירות רענון הנתונים (לדוגמה, כל שבוע בשעה 8:00 לפי שעון החוף המערבי)

  • הקשר

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

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

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

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

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

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

  • יצירה: מגדירים את מוצר הנתונים וכוללים נכסים. התהליך כולל את הפעולות הבאות:

    • מגדירים את השם הייחודי, הפרויקט, האזור והתיאור.
    • מוסיפים נכסים כמו טבלאות ב-BigQuery, מערכי נתונים או תצוגות.
    • כדי לפשט את ניהול ההרשאות, מגדירים קבוצות גישה (לדוגמה, Analyst או Reader) וממפים אותן לקבוצות Google או לחשבונות שירות בסיסיים.
    • אפשר להקצות תפקיד IAM כברירת מחדל לקבוצת גישה, כדי להעניק באופן אוטומטי הרשאות לכל הנכסים הנתמכים במוצר הנתונים.
    • מקצים לקבוצות הגישה את תפקידי ה-IAM הנדרשים לנכסים הספציפיים.
    • הוסיפו חוזה (היבט מערכתי) כדי להעביר באופן רשמי את הקצב, התדירות והסף המוסכמים לרענון הנתונים.

    מידע נוסף זמין במאמר יצירת מוצרי נתונים.

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

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

    מידע נוסף זמין במאמר ניהול מוצרי נתונים.

המסלול להמרת הלקוח במוצר הנתונים

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

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

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

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

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

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

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

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

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

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

נכסים נתמכים

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

  • מערכי נתונים ב-BigQuery
  • טבלאות ב-BigQuery
  • תצוגות ב-BigQuery
  • פונקציות ב-BigQuery
  • מודלים של BigQuery
  • טבלאות חיצוניות ב-BigQuery
  • מערכי נתונים של Gemini Enterprise Agent Platform
  • מודלים של Gemini Enterprise Agent Platform
  • קטגוריות של Cloud Storage
  • קטלוגים של קטלוג REST של Iceberg
  • מרחבי שמות של קטלוג REST של Iceberg
  • טבלאות של קטלוג REST של Iceberg
  • מרכזי בקרה ב-Looker (Google Cloud core)
  • רכיבים בלוח הבקרה של Looker (Google Cloud core)
  • תצוגות Looker (Google Cloud core)‎
  • ניתוחים ב-Looker (Google Cloud core)‎
  • פרויקטים של LookML ב-Looker (Google Cloud core)
  • מודלים של LookML ב-Looker (Google Cloud core)
  • תצוגות LookML ב-Looker (Google Cloud core)

מגבלות

  • מיקום: מוצרי הנתונים והנכסים הבסיסיים שלהם חייבים להיות באותו מיקום ב-Google Cloud .
  • מודלים של BigQuery: הגישה למודלים של BigQuery בתוך מוצר נתונים מנוהלת באמצעות תנאי IAM שחלים על מדיניות ה-IAM של מערך הנתונים הראשי. שיתוף מודלים של BigQuery כפוף למגבלות של תנאי IAM.

  • נכסי Looker (Google Cloud core): השימוש בנכסי Looker (Google Cloud core) במוצרי נתונים כפוף למגבלות הבאות:

    • אין תמיכה בחשבונות שירות: סנכרון קבוצות Google ב-Looker (Google Cloud core) תומך רק בזהויות של משתמשים אנושיים. קבוצות גישה שמוגדרות בנכסים של Looker (Google Cloud core) לא יכולות לכלול חשבון שירות כחשבון משתמש.
    • אין תמיכה בתפקידי IAM של קבוצת גישה שמוגדרים כברירת מחדל: תפקידי IAM שמוגדרים כברירת מחדל ברמת קבוצת הגישה לא חלים על נכסי Looker (Google Cloud core) ומסומנים כ-unsupported. צריך להגדיר באופן מפורש את הרשאות הגישה של הקבוצה בכל נכס של Looker (Google Cloud core).
    • סנכרון הרשאות ידני ב-Looker (Google Cloud core): שמות התפקידים שמוגדרים בנכס Looker (Google Cloud core) במוצר נתונים הם פלייסהולדרים של מידע לצרכנים. יוצרי הנתונים צריכים להגדיר ולתחזק באופן ידני את רמות הגישה לתיקיות ואת התפקידים ב-Looker של הקבוצה המשוכפלת במכונה של Looker (Google Cloud core).

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

  • אין תמיכה בקטגוריות אזוריות.

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