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

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

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

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

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

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

• גישה לקריאה בלבד לתובנות שנוצרו על ידי AI: Dataplex DataScan DataViewer (roles/dataplex.dataScanDataViewer) בפרויקט שמכיל את המשאב
• קריאת נתוני טבלאות של Apache Iceberg,‏ Apache Hive או SAP BDC: BigLake Viewer (roles/biglake.viewer) במשאב
• פרסום תיאורים כהיבטים: Dataplex Catalog Editor (roles/dataplex.catalogEditor) במשאב
• פרסום שאילתות כהיבטים: הבעלים של Dataplex Entry ו-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, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

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

איך מפעילים את Gemini for Google Cloud API בפרויקט ב- Google Cloud

הכנת הנתונים

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

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

יצירת תובנות שנוצרו על ידי AI ב-BigQuery

ב-BigQuery Studio, אתם יכולים להשתמש ב-Gemini ב-BigQuery כדי ליצור תובנות מנתונים ב-BigQuery לגבי מערכי נתונים, טבלאות, תצוגות,Google Cloud טבלאות BigLake, טבלאות חיצוניות ומרחבי שמות של Apache Iceberg. אפשר ליצור תובנות לגבי המשאבים האלה רק ב-BigQuery Studio.

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

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

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

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

יצירת תובנות לגבי טבלאות ומרחבי שמות של Apache Iceberg

תצוגה מקדימה

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

ב-Knowledge Catalog, אתם יכולים ליצור תובנות מנתונים לגבי טבלאות ומרחבי שמות של Apache Iceberg,‏ Apache Hive ו-SAP BDC שמנוהלים על ידי Lakehouse ללא גבולות של Google Cloud.

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

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

   מעבר לחיפוש

2. במסננים, מאתרים את סוג הנכס:

   • לטבלאות Apache Iceberg: בוחרים באפשרות Lakehouse.
   • למרחבי שמות של Apache Iceberg: מגדירים את המסנן system לערך BIGLAKE ואת המסנן type לערך namespace.

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

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

5. בוחרים אפשרות ליצירת תמונות:

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

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

   למידע נוסף על ההבדלים בין המצבים Generate and publish ו-Generate without publishing, קראו את המאמר מצבים ליצירת תובנות מנתונים.

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

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

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

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

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

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

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

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

   מעבר לחיפוש

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

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

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

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

REST

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

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

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

REST

כדי לעדכן שאילתות של קבוצת נתונים, משתמשים ב-method‏ 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 (הצעות של LLM)

  • עדכניות של מודל ה-LLM: הקשרים שנגזרים מהמקור 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 של הקישור לרשומה המטורגטת, משתמשים ב-method‏ 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: שם העמודה שמשמשת לצירוף בטבלת היעד

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

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

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