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

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

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

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

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

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

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

כדי לקבל את ההרשאות שדרושות לשימוש בתובנות מנתונים, אתם צריכים לבקש מהאדמין להקצות לכם את תפקידי ה-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 and EntryLink Owner (roles/dataplex.entryOwner) on resource

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

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

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

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

  • 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). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin). כך מקצים תפקידים.

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

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

הכנת הנתונים

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

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

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

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

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

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

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

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

    מעבר אל חיפוש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  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, כדי להבטיח שמטא-נתונים ברמת ודאות גבוהה יישמרו על סמך המקור שלהם:

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

      1. USER (עריכות ידניות)
      2. TABLE_CONSTRAINTS
      3. QUERY_HISTORY
      4. AGENT (הצעות של LLM)
    • עדכניות של מודל שפה גדול (LLM): הקשרים שנגזרים מהמקור AGENT הם דינמיים. אם סריקה חוזרת לא ממליצה יותר על הקשר, הוא יוסר.

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

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

  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:

    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: שם העמודה שמשמשת לצירוף בטבלת היעד

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