פתרון בעיות בגישה לנתונים בין עננים שונים

במסמך הזה מוסבר איך לפתור בעיות נפוצות בשימוש ביכולת הגישה לנתונים בין עננים של Borderless Lakehouse.

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

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

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

כדי לבדוק את סטטוס רענון המטא-נתונים ברקע בקטלוג מאוחד, אפשר להיכנס לדף Lakehouse Google Cloud במסוף או להריץ את הפקודה הבאה ב-CLI של gcloud:

מעבר אל Lakehouse

gcloud alpha biglake iceberg catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

gcloud alpha biglake delta-sharing catalogs describe FEDERATED_CATALOG_NAME \
    --project="PROJECT_ID"

בעיות בקישוריות או בקביעת מסלול

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

  • מאמתים את הפצת הנתיבים: בודקים את Cloud Router ב-Google Cloud כדי לוודא שהוא למד את הקידומות של AWS VPC. בודקים את טבלאות הניתוב של AWS כדי לוודא שיש בהן מסלולים בחזרה ל- Google Cloud VPC.
  • בדיקת תקינות של איזון עומסים פנימי: במסוף Google Cloud , עוברים אל Network Services > Load balancing. בודקים אם שירות הקצה העורפי של איזון עומסים פנימי (ILB) תקין. אם הן לא מופיעות, צריך לוודא שיש חיבור לרשת ולבדוק את הכללים של קבוצת האבטחה ב-AWS.
  • בדיקת הקישוריות מ Google Cloud: מפעילים מכונה וירטואלית לבדיקה באותו Google Cloud VPC וברשת המשנה כמו נקודת הקצה של ILB או Service Directory ומנסים להתחבר לכתובות ה-IP של AWS ENI ביציאה 443 (לדוגמה, באמצעות curl או telnet).
  • פתרון בעיות בספריית השירותים: מוודאים שלחשבון השירות של הקטלוג יש הרשאות לפתרון נקודות קצה של ספריית השירותים (roles/servicedirectory.viewer, roles/servicedirectory.pscAuthorizedService).
  • קבוצות אבטחה וכללי חומת אש: מוודאים שכללי חומת האש וקבוצות האבטחה של AWS מאפשרים תעבורה ביציאת TCP‏ 443 בין טווחי כתובות ה-IP הרלוונטיים. Google Cloud

רענון הקטלוג של Snowflake נכשל עם קוד 16 (לא מאומת)

אם רענון המטא-נתונים ברקע של קטלוג Snowflake Horizon נכשל עם סטטוס Code 16 (UNAUTHENTICATED), צריך לוודא את הדברים הבאים:

  • פורמט המטען הייעודי (payload) של הסוד: צריך לוודא שאסימון הסוד ב-Secret Manager מכיל את מבנה ה-JSON הנדרש ({"client_secret": "<var>SNOWFLAKE_PAT_TOKEN</var>", "scope": "session:role:<var>SNOWFLAKE_ROLE</var>"}) ולא את המחרוזת הגולמית של אסימון הגישה האישי (PAT).
  • תוקף הטוקן וההרשאות: מוודאים שטוקן ה-PAT של Snowflake תקף, ושלהרשאות של המשתמש והתפקיד המשויכים יש מספיק הרשאות גישה לקטלוג ולמסדי הנתונים של היעד.
  • מדיניות רשת: אם מוגדרת מדיניות רשת של Snowflake, צריך לוודא שטווח כתובות ה-IP של יציאת הנתונים של Google מ-goog.json מופיע ברשימת ההיתרים.