שימוש בתובנות מנתונים לנתונים מובְנים

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

ב-BigQuery Studio, אפשר ליצור תובנות לגבי נתונים במערכי נתונים, בטבלאות, בתצוגות מפורטות, Google Cloud בטבלאות Lakehouse ובטבלאות חיצוניות של BigQuery.

ב-Knowledge Catalog, אפשר ליצור תובנות לגבי נתונים בטבלאות של קטלוג REST של Iceberg ב-Lakehouse.

לפני שמתחילים

לפני שמשתמשים בתובנות לגבי נתונים, צריך לוודא שמתקיימים התנאים המוקדמים הבאים:

התפקידים הנדרשים

כדי לקבל את ההרשאות שדרושות לשימוש בתובנות לגבי נתונים, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-IAM הבאים:

• קבלת גישת קריאה בלבד לתובנות שנוצרו: Dataplex DataScan DataViewer (roles/dataplex.dataScanDataViewer) בפרויקט שמכיל את המשאב
• קריאת נתוני טבלה מקטלוג REST של Iceberg: ‫BigLake Viewer (roles/biglake.viewer) במשאב
• פרסום תיאורים כהיבטים: Dataplex Catalog Editor (roles/dataplex.catalogEditor) on resource
• פרסום שאילתות כהיבטים: בעלים של רשומת Dataplex ושל EntryLink (roles/dataplex.entryOwner) במשאב

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

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

ההרשאות הנדרשות

כדי להשתמש בתובנות לגבי נתונים, צריך את ההרשאות הבאות:

• dataplex.datascans.create
• dataplex.datascans.get
• dataplex.datascans.getData
• dataplex.datascans.run

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

הפעלת ממשקי ה-API

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

• Dataplex API
• BigQuery API
• Gemini for Google Cloud API

תפקידים שנדרשים להפעלת ממשקי API

כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

הפעלת ממשקי ה-API

מידע נוסף על הפעלת Gemini for Google Cloud API זמין במאמר בנושא הפעלת Gemini for Google Cloud API בפרויקט. Google Cloud

הכנת הנתונים

במקרה של טבלאות Lakehouse, צריך לוודא שהנתונים נמצאים ב-Cloud Storage ושיצרתם טבלת Lakehouse. Google Cloud Google Cloud

בטבלאות של קטלוג REST של Iceberg, מוודאים שהטבלאות רשומות בקטלוג של זמן הריצה של Lakehouse.

יצירת תובנות ב-BigQuery

תובנות לגבי נתונים במערכי נתונים, בטבלאות, בתצוגות מפורטות, בטבלאות Lakehouse ובטבלאות חיצוניות של BigQuery נוצרות באמצעות Gemini ב-BigQuery, ואפשר ליצור אותן רק ב-BigQuery Studio.Google Cloud

קודם צריך להגדיר את Gemini ב-BigQuery, ואז ליצור תובנות. אחרי שיוצרים תובנות, אפשר לראות ולשנות אותן ב-Knowledge Catalog.

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

• סקירה כללית של תובנות מהנתונים
• יצירת תובנות לגבי טבלה
• יצירת תובנות לגבי מערך נתונים

הערה: Gemini ב-BigQuery הוא חלק מ-Gemini ל- Google Cloud ולא תומך באותם פתרונות תאימות ואבטחה כמו BigQuery. מומלץ להגדיר את Gemini ב-BigQuery רק עבור פרויקטים ב-BigQuery שלא נדרשים להם פתרונות תאימות שלא נתמכים על ידי Gemini ל- Google Cloud. מידע על השבתה של Gemini ב-BigQuery או על מניעת גישה אליו זמין במאמר השבתה של Gemini ב-BigQuery.

יצירת תובנות לגבי טבלאות בקטלוג REST של Iceberg

תצוגה מקדימה

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

1. במסוף Google Cloud , עוברים לדף Search ב-Knowledge Catalog.

   מעבר אל חיפוש

2. בקטע Filters, בוחרים באפשרות Lakehouse.

3. בוחרים את טבלת Iceberg REST Catalog שרוצים להפיק לגביה תובנות.

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

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

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

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

6. בוחרים אזור כדי ליצור תובנות ולוחצים על יצירה.

   יחלפו כמה דקות עד שהתובנות יופיעו.

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

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

8. כדי לראות את שאילתת ה-SQL שעונה על שאלה, לוחצים על השאלה.

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

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

1. נכנסים לדף Search ב-Knowledge Catalog במסוף Google Cloud .

   מעבר אל חיפוש

2. מחפשים את המשאב שרוצים לראות לגביו תובנות.

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

4. בודקים את התיאורים והשאילתות שנוצרו עבור המשאב שנבחר.

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

ניהול תובנות לגבי טבלאות

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

עדכון התיאורים שנוצרו לטבלה

אפשר לעדכן את תיאורי הטבלה והעמודות רק באמצעות Dataplex API. כדי לעשות את זה, משתמשים בשיטה entries.patch.

עדכון שאילתות שנוצרו לטבלה

אפשר לעדכן את השאילתות שנוצרו לטבלה באמצעות מסוף Google Cloud ו-Dataplex API.

המסוף

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

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

3. בקטע Queries לוחצים על Edit.

4. מעדכנים את תיאור השאילתה לפי הצורך.

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

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

REST

כדי לעדכן שאילתות לטבלה, משתמשים בשיטה entries.patch.

עדכון קשרים שנוצרו עבור טבלה

אפשר לעדכן את הקשרים רק באמצעות Dataplex API. כדי לעשות את זה, משתמשים בשיטה entries.patch.

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

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

עדכון תיאורים שנוצרו עבור מערך נתונים

אפשר לעדכן את תיאורי מערכי הנתונים רק באמצעות Dataplex API. כדי לעשות את זה, משתמשים בשיטה entries.patch.

עדכון שאילתות שנוצרו עבור מערך נתונים

אפשר לעדכן את השאילתות שנוצרו עבור מערך נתונים באמצעות Google Cloud המסוף ו-Dataplex API.

המסוף

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

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

3. בקטע Queries לוחצים על Edit.

4. מעדכנים את התיאור לפי הצורך.

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

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

REST

כדי לעדכן שאילתות של מערך נתונים, משתמשים בשיטה entries.patch.

עדכון קישורים שנוצרו להזנת נתונים במערך נתונים

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

כדי לערוך את הקשרים האלה או לספק שינויים ידניים, צריך להשתמש ב-Dataplex API.

עדכון אופן הפעולה של קישורי הכניסה

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

• עדכונים ידניים (התנהגות ברמת ה-API): ה-API‏ UpdateEntryLink משתמש ב-method‏ PATCH כדי לבצע החלפה ברמת ההיבט:

  • החלפה מלאה של מאפיין: אם כוללים את המאפיין schema-join בבקשת העדכון, Knowledge Catalog מחליף את כל המאפיין הקיים במאפיין החדש שסיפקתם.

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

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

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

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

    1. USER (עריכות ידניות)
    2. TABLE_CONSTRAINTS
    3. QUERY_HISTORY
    4. AGENT (הצעות של מודל שפה גדול)

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

עדכון קישורי הכניסה

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

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

• ‫userManaged: true: מגדירים את התכונה הזו ברמת ההיבט כדי להנחות את Knowledge Catalog לדלג על כל העדכונים האוטומטיים של הקשר הזה.
• ‫inferenceSource: "USER": אפשר להגדיר את הערך הזה בתוך רשומות הצטרפות ספציפיות כדי לזהות אותן כמאומתות באופן ידני, וכך להגן עליהן במהלך תהליכי מיזוג רגילים.

1. מזהים את הקישור לרשומה.

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

   gcurl -X GET "https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/entryGroups/@bigquery/entryLinks?filter=entry_references.name=\"TABLE_ENTRY_NAME\""
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
   • ‫LOCATION: האזור שבו מופעלת סריקת הנתונים
   • ‫TABLE_ENTRY_NAME: שם המשאב המלא של רשומת הטבלה ב-BigQuery (לדוגמה, bigquery.googleapis.com/projects/my-project/datasets/my_dataset/tables/my_table)

2. מעדכנים את קישור הכניסה.

   כדי לשנות את ההיבט schema-join של קישור הכניסה הממוקד, משתמשים בשיטה PATCH:

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

   gcurl -X PATCH "https://dataplex.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/entryGroups/@bigquery/entryLinks/ENTRYLINK_ID?aspectKeys=dataplex-types.global.schema-join" \
   -d '{
     "aspects": {
       "dataplex-types.global.schema-join": {
         "data": {
           "joins": [
             {
               "source": { "name": "PROJECT_ID.DATASET_ID.SOURCE_TABLE", "fields": ["SOURCE_FIELD"] },
               "target": { "name": "PROJECT_ID.DATASET_ID.TARGET_TABLE", "fields": ["TARGET_FIELD"] },
               "type": "JOIN",
               "inferenceSource": "USER"
             }
           ],
           "userManaged": false
         }
       }
     }
   }'
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ENTRYLINK_ID: מזהה קישור הכניסה שאוחזר בשלב הזיהוי הקודם
   • ‫DATASET_ID: המזהה של מערך הנתונים ב-BigQuery
   • ‫SOURCE_TABLE: השם של טבלת המקור
   • ‫SOURCE_FIELD: שם העמודה שמשמשת לצירוף בטבלת המקור
   • ‫TARGET_TABLE: השם של טבלת היעד
   • ‫TARGET_FIELD: שם העמודה שמשמשת לצירוף בטבלת היעד

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

• מידע נוסף על תובנות מהנתונים לגבי נתונים מובְנים

• איך משתמשים בסריקת גילוי לנתונים לא מובנים

• איך משתמשים בפרופיל נתונים לנתונים לא מובְנים