פתרון בעיות בגילוי נתונים ב-Knowledge Catalog

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

הפרסום של טבלה ב-BigQuery נכשל (FAILED_BIGQUERY_TABLE_PUBLISH)

כשסריקת גילוי מופעלת, יכול להיות שהמערכת לא תצליח לפרסם טבלאות ב-BigQuery. במקרה כזה, הסריקה רושמת FAILED_BIGQUERY_TABLE_PUBLISH פעולה ב-Cloud Logging.

הבעיה הזו מתרחשת בגלל התנאים הבאים:

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

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

  • מאמתים את התפקידים של חשבון השירות: מוודאים שלחשבון השירות של Knowledge Catalog‏ service-PROJECT_NUMBER@gcp-sa-dataplex. יש את התפקיד Dataplex Discovery BigLake Publishing Service Agent‏ (roles/dataplex.discoveryBigLakePublishingServiceAgent).
  • בדיקת הרשאות החיבור: אם יוצרים טבלאות BigLake, צריך לוודא שלחשבון השירות של חיבור BigQuery יש הרשאת קריאה לדלי Cloud Storage (באמצעות roles/storage.objectViewer או roles/dataplex.discoveryServiceAgent).
  • בדיקת החיבור והמיקום של מערך הנתונים: צריך לוודא שהחיבור ל-BigQuery ומערך הנתונים ב-BigQuery נמצאים באותו אזור, ושהם תואמים למיקום של קטגוריה של Cloud Storage.
  • עיון ביומנים כדי לראות פרטים: אפשר לעיין ביומנים של עבודת DataScan ב-Cloud Logging. אם השגיאה מכילה את הערך BigQuery: Permission denied, צריך לבדוק את ההרשאות של חשבון השירות. אם הוא מכיל TABLE_CONFIG, צריך לוודא שקובצי הנתונים עומדים בדרישות של BigQuery.

יצירת טבלה ב-BigLake נכשלת עבור קטגוריות גדולות של Cloud Storage

כשסריקת גילוי מעבדת באקטים של Cloud Storage עם נפח גדול של נתונים או קבצים גדולים (לדוגמה, קובצי Avro גדולים מ-30MB), הסריקה יכולה ליצור בהצלחה את מערך הנתונים ב-BigQuery, אבל לא לפרסם את הטבלאות ב-BigLake.

במקרה כזה, יכול להיות שתראו את השגיאות הבאות ב-Cloud Logging:

  • FAILED_BIGQUERY_TABLE_PUBLISH
  • com.google.cloud.bigquery.BigQueryException: Read timed out

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

אי התאמות בסכימה של תיקיות ב-Cloud Storage

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

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

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

  • פורמט נתונים לא תקין (INVALID_DATA_FORMAT): נמצאו פורמטים לא עקביים של נתונים באותה תיקייה או במחיצות שונות (לדוגמה, ערבוב של קובצי .csv ו-.parquet באותה ספרייה).
  • הגדרת מחיצה לא תקינה (INVALID_PARTITION_DEFINITION): מפתחות המחיצה לא עקביים או חסרים. לדוגמה, שימוש ב-Year=2023/Mon=Jan בנתיב אחד וב-Year=2023/Dept=Sales בנתיב אחר.
  • סכימת נתונים לא תואמת (INCOMPATIBLE_DATA_SCHEMA): המערכת מזהה סכימות לא עקביות או לא תואמות בקבצים באותה תיקייה או טבלה.

בפורמטים עם הקלדה חזקה כמו Avro ו-Parquet, אי התאמות בסכימה מתרחשות בגלל:

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

כדי לפתור את הבעיה, צריך לבדוק את מבנה הקובץ ואת הגדרות הסכימה:

  • ארגון קבצים לפי סכימה ופורמט: מוודאים שלכל הקבצים בתיקייה יש את אותו פורמט ואת אותה מבנה סכימה. כדי שיהיה אפשר לרשום קבצים עם עמודות, סוגים פרימיטיביים או פורמטים שונים כטבלאות נפרדות, צריך להעביר אותם לתיקיות או לקידומות נפרדות.
  • שימוש בהגדרות עקביות של מחיצות: חשוב לוודא שמפתחות המחיצות והמבנים שלהן עקביים בכל תיקיות המחיצות (לדוגמה, שימוש עקבי ב-Year=YYYY/Month=MM/).
  • פועלים לפי כללי התפתחות הסכימה: כשמעדכנים סכימות (למשל, כשמוסיפים או מסירים שדות מקובצי Avro), תמיד מגדירים ערכי ברירת מחדל כדי ששירות הגילוי יוכל למזג את וריאציות הסכימה בהצלחה.
  • זיהוי קבצים פגומים: בודקים את הפלט או את היומנים של הסריקה כדי לזהות אם פענוח של קובץ מסוים נכשל. מעבירים קבצים באופן זמני כדי לבדוק אם קובץ ספציפי גורם לכך שהסריקה תיכשל.

טבלאות שזוהו לא מתעדכנות עם שינויים בסכימה

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

הבעיה הזו מתרחשת אם התווית metadata-managed-mode של הטבלה שפורסמה מוגדרת כ-user_managed. כברירת מחדל, טבלאות שמתפרסמות ב-Discovery הן מסוג discovery_managed. אם אתם או משתמש אחר עורכים ידנית את המאפיינים של סכימת הטבלה, אתם צריכים לשנות את התווית ל-user_managed כדי לחסום עדכונים אוטומטיים.

כדי לפתור את הבעיה, צריך לבדוק את תוויות הטבלה ב-BigQuery:

  1. במסוף Google Cloud , עוברים לדף BigQuery.
  2. בחלונית Explorer מרחיבים את הפרויקט, בוחרים את מערך הנתונים ולוחצים על הטבלה שהושפעה.
  3. לוחצים על הכרטיסייה פרטים.
  4. בקטע Labels (תוויות), בודקים את הערך של metadata-managed-mode key.

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

פנייה לתמיכה

אם אתם צריכים עזרה בפתרון בעיה שלא מוסברת במסמך הזה, תוכלו לפנות אל Cloud Customer Care.