אתם יכולים לאבחן ולפתור שגיאות ב-Lakehouse ללא גבולות ובמשאבים שמשויכים אליו, כולל בעיות בשאילתות של טבלאות מטא-נתונים, מגבלות על גודל הקבצים ב-metadata.json והגדרות של קטלוגים במספר אזורים.
טיפול בבעיות האלה יעזור לכם לשחזר את פעולות הטבלה ואת ביצוע השאילתות בעומסי העבודה של ה-lakehouse.
אי אפשר לשלוח שאילתות לטבלאות של מטא-נתונים
הבעיה הזו מתרחשת כששולחים שאילתות לטבלאות מטא-נתונים, כמו .snapshots או .files, בטבלאות Apache Iceberg שנתמכות בקטלוג הייעודי לזמן ריצה של Lakehouse ב-BigQuery, באמצעות מזהה שם שמורכב מחמישה חלקים.
כדי לפתור את הבעיה, צריך לשלוח שאילתות לטבלאות האלה באמצעות Apache Spark.
מגבלת הגודל של הקובץ metadata.json
גודל הקובץ של Apache Iceberg metadata.json מוגבל ל-1MB. המגבלה הזו חלה על קובץ המטא-נתונים שעוקב אחרי תמונות המצב של הטבלאות, הסכימות והמפרטים של המחיצות. אם קובץ המטא-נתונים חורג מהגודל הזה, יכול להיות שתיתקלו בשגיאות כשתבצעו פעולות בטבלה דרך נקודת הקצה של קטלוג REST של Apache Iceberg.
כדי לפתור את הבעיה, אתם יכולים לפנות לצוות התמיכה בחשבונות Google ולבקש להגדיל את המגבלה.
שגיאות מסוג NOT_FOUND בשאילתות לקטלוגים במספר אזורים
הבעיה הזו מתרחשת כשיוצרים קטלוג בקטלוג ייעודי לזמן ריצה של Lakehouse באמצעות קטגוריה של Cloud Storage במספר אזורים בלי לציין מיקום ראשי, ואז מנסים לשלוח שאילתה לקטלוג על ידי ציון אזור וירטואלי של BigQuery (כמו US או EU).
כשיוצרים קטלוג עם קטגוריה במספר אזורים, המטא-נתונים שלו מאוחסנים במיקומים אזוריים ספציפיים בתוך ההיקף הגיאוגרפי של מספר האזורים, ולא באזור הווירטואלי התואם של BigQuery. אם תאלצו שאילתה לפעול באזור וירטואלי שבו המטא-נתונים לא קיימים, השאילתה תיכשל ותופיע השגיאה NOT_FOUND.
כדי לפתור את הבעיה, צריך לציין את המיקום הראשי (לדוגמה, US או EU) כשיוצרים את הקטלוג. מידע נוסף זמין במאמר הגדרת אזורים ראשיים לאזורים מרובים בארה"ב ובאיחוד האירופי.
משימות אופטימיזציה של האחסון לא מופיעות ב-INFORMATION_SCHEMA.JOBS
הבעיה הזו מתרחשת כשמפעילים ניהול טבלאות בטבלת Apache Iceberg ומבצעים שינויים בנתונים (כמו הוספות או פקודות DML), אבל לא מופיעות משימות אופטימיזציה של האחסון (כמו CALL BQ.OPTIMIZE_STORAGE) בתצוגה INFORMATION_SCHEMA.JOBS. מידע נוסף על שליחת שאילתות לגבי המשימות האלה זמין במאמר קבלת משימות לאופטימיזציה של אחסון ב-Iceberg.
זו התנהגות רגילה כשמדלגים על אופטימיזציית האחסון. במסגרת ניהול הטבלאות, המערכת בודקת את פריסת הטבלה אחרי שינויים בנתונים, ומפעילה משימות אופטימיזציה רק כשצריך לדחוס או לארגן מחדש את קובצי הנתונים. מכיוון שמשימות הניהול של הטבלאות ברקע פועלות בפרויקט וצורכות משאבי מחשוב, BigQuery לא משכתב נתונים כשפריסת הטבלה כבר עברה אופטימיזציה. המערכת מדלגת על האופטימיזציה במקרים הבאים:
- הקבצים כבר אופטימליים: קובצי הנתונים הקיימים כבר קרובים לגודל קובץ היעד או גדולים ממנו (הגודל הממוצע ללא דחיסה הוא לפחות 50% מ-256MB).
- לא עומדים בתנאי הסף: בטבלה לא הצטברו מספיק קבצים קטנים או שהיא לא עומדת בתנאי הסף של הגודל (למשל, גודל הטבלה הכולל עולה על 1GB) שנדרש לדחיסה.
כשמדלגים על אופטימיזציית האחסון, לא מופעלת משימה ברקע ולא נרשמת רשומה ב-INFORMATION_SCHEMA.JOBS.
אם ביצועי השאילתות עומדים בדרישות שלכם והקבצים כבר בגודל המתאים, לא צריך לעשות כלום. אופטימיזציית האחסון פועלת באופן אוטומטי כשכתיבות עתידיות גורמות לפרגמנטציה מספקת של קבצים.
כדי לבחון משימות של אופטימיזציית אחסון בסביבת בדיקה, אפשר לדמות פרגמנטציה של קבצים על ידי הוספת כמה קבוצות קטנות של נתונים לאורך זמן לטבלה בגודל של יותר מ-1GB.