פתרון בעיות באמצעות סכימת מידע

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

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

פתרון בעיות בסכימת מידע לפי משימה

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

משימה	תרחישים לדוגמה	תצוגות של סכימת מידע
ביצועי שאילתות ושגיאות	זיהוי שאילתות שצורכות הרבה משבצות ויקרות. לצבור את הסיבות לשגיאות במשימות ואת דפוסי הכשלים. ניתוח של זמני הביצוע ושל הבייטים שנשפכו בכל שלב.	JOBS_BY_PROJECT JOBS_BY_ORGANIZATION JOBS_BY_FOLDER JOBS_BY_USER
קיבולת עומס עבודה ועימות	זיהוי של תחרות על משבצות זמן, הגבלת קצב העברת נתונים וזמני המתנה בתור. מעקב אחרי ניצול הזיכרון של מיון הנתונים בזיכרון. ביקורת על בסיס ההזמנה ועל השימוש במשבצות של התאמה אוטומטית לעומס. בודקים את ההקצאות של ההזמנות של הפרויקט והתיקייה.	JOBS_TIMELINE_BY_* RESERVATIONS_TIMELINE_BY_* RESERVATIONS_BY_* ASSIGNMENTS_BY_* CAPACITY_COMMITMENTS_BY_*
עלויות אחסון וארכיטקטורת נתונים	זיהוי טבלאות עם נפח אחסון פיזי או לוגי גדול מדי. זיהוי של תופעת 'מסע בזמן' וניפוח של נפח האחסון בגיבויים. אבחון הטיה בחלוקה למחיצות וטבלאות שמתקרבות למגבלות החלוקה למחיצות. אפשר לגלות טבלאות שתוקפן פג או שנמחקו בחלונות של מסע בזמן.	TABLE_STORAGE_BY_* PARTITIONS TABLES TABLE_OPTIONS
בקרת גישה ומשילות	ביקורת על הענקות מפורשות של תפקידים ב-IAM בטבלאות ובמערכי נתונים. פתרון בעיות שקשורות לשגיאות 'הגישה נדחתה' אצל משתמשים וחשבונות שירות. מעקב אחר שיתוף של מערכי נתונים בין פרויקטים ושימוש אנליטי.	OBJECT_PRIVILEGES SHARED_DATASET_USAGE
פייפליינים להעברת נתונים	מעקב אחר קצב העברת הנתונים ושגיאות ב-Storage Write API. אבחון של זמן האחזור של הזנת זרם נתונים ומגבלות הקצב. מזהים את הסטרימינג שנכשל לפי סוג הסטרימינג וקוד השגיאה.	WRITE_API_TIMELINE_BY_* STREAMING_TIMELINE_BY_*
למידת מכונה וחיפוש וקטורי	מעקב אחרי משך האימון של המודל וצריכת המשאבים. בודקים את סטטוס ה-build של אינדקס הווקטורים ואת אחוז הכיסוי. פתרון בעיות בבנייה של תהליכים מאוחסנים ופונקציות מוגדרות על ידי המשתמש (UDF) ב-Python.	VECTOR_INDEXES ROUTINES ‫JOBS_BY_* (סינון לפי סוגי הצהרות של ML)
תובנות לגבי אופטימיזציה של עומסי עבודה	בודקים את ההמלצות לגבי חלוקה למחיצות וקיבוץ לאשכולות. לזהות טבלאות מועמדות לתצוגות מהותיות.	RECOMMENDATIONS_BY_* INSIGHTS_BY_*

עקרונות לפתרון בעיות באמצעות סכימת מידע

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

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

  • תמיד מציינים את המוקדמות האזוריות הנכונות (לדוגמה, region-REGION.INFORMATION_SCHEMA.JOBS_BY_PROJECT) או את המוקדמות של מערך הנתונים.

  • בוחרים את רמת ההיררכיה המתאימה (BY_PROJECT,‏ BY_USER,‏ BY_FOLDER או BY_ORGANIZATION) בהתאם לסוג הבעיה שאתם בודקים: בעיה שקשורה למשתמש יחיד, עומס עבודה שספציפי לפרויקט או בעיה שמשפיעה על כל הדייר.

• התאמה בין הביקוש למשאבי מחשוב לבין הקיבולת. לרוב, ביצועי שאילתות איטיים הם תוצאה של תחרות על משבצות ולא רק של SQL לא יעיל. משווים בין בקשות למשאבי משרה (period_estimated_runnable_units) לבין משבצות זמן שהוקצו להזמנות (period_slot_ms) בחלונות זמן זהים, כדי להבחין בין הזדמנויות לשיפור השאילתה לבין בעיות שנובעות מקיבולת לא מספקת.

• צריך להביא בחשבון את רמת הפירוט של הטלמטריה ואת מגבלות השמירה. תצוגות שונות של סכימת המידע פועלות במרווחי רענון שונים ובחלונות שונים של שמירת נתונים. מטא-נתונים של משימות בתצוגה JOBS זמינים למשך 180 ימים, ואילו מדדי ציר זמן ברזולוציה גבוהה בתצוגות JOBS_TIMELINE ו-RESERVATIONS_TIMELINE נשמרים לתקופות קצרות יותר (בדרך כלל 14 עד 30 ימים). לצורך ביקורת לטווח ארוך וניתוח מגמות, כדאי לייצא את נתוני הטלמטריה לטבלאות מחולקות.

• הימנעות מעיוות מדדים בשאילתות עם כמה הצהרות. סקריפטים עם כמה הצהרות (SQL פרוצדורלי שמכיל DECLARE, IF או WHILE) יוצרים משימת אב עם statement_type = 'SCRIPT' ומשימות צאצא נפרדות לכל הצהרה. כשמצטברים מדדים כמו total_slot_ms או total_bytes_billed, צריך לסנן את statement_type = 'SCRIPT' כדי למנוע ספירה כפולה.

• סינון לפי עמודות של מחיצות. כדי לצמצם את זמן הביצוע של השאילתה ולמנוע עלויות מיותרות של סריקה בניתוח על פי דרישה, תמיד כדאי לכלול מסנני זמן מגבילים בעמודות של מחיצות, כמו creation_time, ‏ job_start_time או period_start.

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

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