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

תובנות מנתונים שמבוססות על 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 (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, טבלאות חיצוניות ב-BigQuery ומרחבי שמות של Apache Iceberg. אפשר ליצור תובנות לגבי המשאבים האלה רק ב-BigQuery Studio.

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

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

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

הערה: Gemini ב-BigQuery הוא חלק מ-Gemini ל- 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: בקטע Systems בוחרים באפשרות Lakehouse (BigLake)‎, ובקטע Type aliases בוחרים באפשרות Table.
   • למרחבי שמות של Apache Iceberg: בקטע Systems, בוחרים באפשרות Lakehouse (BigLake)‎, ובקטע Type aliases בוחרים באפשרות Namespace.

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

4. לוחצים על הכרטיסייה תובנות.

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

5. כדי ליצור תובנות, לוחצים על יצירה.

6. בוחרים את סוג התובנה:

   • ‫BigQuery SQL: יוצר שאילתות GoogleSQL רגילות. יש תמיכה גם בטבלאות וגם במרחבי שמות.
   • ‫Spark SQL: יצירת שאילתות Spark SQL. נתמך רק בטבלאות של קטלוג REST של BigLake Iceberg.

7. בוחרים את תנאי הפרסום:

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

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

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

8. אופציונלי: בשדה Custom instructions, מספקים הנחיות והקשר של הדומיין כדי להתאים אישית את האופן שבו Gemini יוצר תובנות שנוצרו על ידי AI.

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

   LANGUAGE: Always write column descriptions in uppercase.
   
   DOMAIN_CONTEXT:
   - This dataset supports the Order-to-Cash process for the EMEA commercial
     sales team.
   - Primary consumers are finance analysts and regional sales managers, not
     engineers.
   
   RELATIONSHIPS:
   - returns.order_item_id → order_items.id (one-to-one; use LEFT JOIN to
     preserve unreturned items)
   

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

10. לוחצים על יצירה.

    יצירת התובנות נמשכת כמה דקות.

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

    • בטבלאות: בודקים את התיאורים ואת השאילתות לדוגמה שנוצרו על ידי 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, הפעלות עתידיות של יצירת תובנות לא יחליפו את השינויים. אם Source נשאר Agent, יכול להיות שהשאילתה תוחלף במהלך יצירה מחדש.

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

REST

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

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

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

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

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

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

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

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

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

המסוף

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

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

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

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

5. ניהול הבעלות: כברירת מחדל, המקור מוגדר כנציג. אם משנים שאילתה ומשנים את המקור ל-User, הפעלות עתידיות של יצירת תובנות לא יחליפו את השינויים. אם Source נשאר 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: שם העמודה שמשמשת לצירוף בטבלת היעד

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

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

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