שימוש בכלי למעקב אחרי שאילתות ב-Explore ובחלונית הביצועים כדי לעקוב אחרי ביצועי שאילתות

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

מעקב אחרי שאילתות ב-Explore

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

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

מעקב השאילתות מוצג כשמתבצעת חקירה, כל עוד החלונית Visualization או החלונית Data של החקירה פתוחה.

הכרת החלונית ביצועים

כדי לראות את החלונית Performance ב-Explore, לוחצים על הקישור See performance details, שזמין בכל שאילתת Explore שהופעלה.

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

שלבי השאילתה

כשמריצים שאילתת מסד נתונים ב-Explore ב-Looker, השאילתה מופעלת בשלושה שלבים:

שלב האתחול של השאילתה

בשלב Query Initialization, מערכת Looker מבצעת את כל המשימות שנדרשות לפני שהשאילתה נשלחת למסד הנתונים. השלב Query Initialization כולל את המשימות הבאות:

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

אם נתקלתם בבעיות בביצועים או בשאילתות שנמשכות זמן רב בשלב Query Initialization, בצעו את הפעולות הבאות:

  • הגדרת מרווחים בין מסירות מתוזמנות: כשמפעילים בו-זמנית הרבה דוחות Look או מרכזי בקרה מתוזמנים (במיוחד בתחילת השעה), פרץ פתאומי של בקשות שאילתה בו-זמניות יכול להציף את משאבי המכונה ולהרוות את מאגרי החיבורים. צוואר הבקבוק הזה של בו-זמניות גורם לשאילתות להמתין או להסתובב ללא הגבלת זמן במהלך האתחול. כדאי לפרוס את התוכן המתוזמן במרווחים של 15 או 30 דקות (לדוגמה, בשעות :15, :30 או :45) במקום לתזמן את כל התוכן לשעה :00. פרטים נוספים זמינים במאמר אופטימיזציה של ביצועי השרת של Looker.
  • שימוש בקבוצות נתונים לתזמונים: כשאפשר, כדאי להפעיל מסירות מתוזמנות באמצעות קבוצות נתונים שתואמות למחזור ה-ETL, במקום להשתמש בטריגרים מבוססי-זמן. שימוש בקבוצות נתונים מאפשר לפזר את הרצת השאילתות ומונע הרצה של שאילתות מיותרות על נתונים שלא רועננו.
  • הפעלת קריאות ל-API באצווה ובוויסות: אם סקריפטים אוטומטיים או כלים חיצוניים מפעילים שאילתות או דוחות דרך Looker API, כדאי להפעיל בקשות באצווה או להוסיף עיכובים כדי למנוע עומס יתר בתורים של הפעלת השאילתות.
  • ניקוי תהליכים תקועים: אם עלייה פתאומית במספר המשתמשים בו-זמנית גורמת לשאילתות להיתקע ולמכונה להפסיק להגיב, הפעילו מחדש את המכונה כדי לנקות את המשימות שבתהליך ולאפס את התורים הפנימיים.

שלב הרצת השאילתה

בשלב הרצת השאילתה, Looker יוצר קשר עם מסד הנתונים, שולח אליו שאילתה ומחזיר את התוצאות שלה. בעיות בביצועים בשלב הזה יכולות להצביע על בעיה במסד הנתונים החיצוני, כמו טבלאות PDT שלוקח הרבה זמן לבנות מחדש וצריך לבצע להן אופטימיזציה, או טבלאות של מסד נתונים חיצוני שצריך לבצע להן אופטימיזציה. השלב Running Query כולל את המשימות הבאות:

  • יצירת טבלאות PDT במסד הנתונים שנדרשות לשאילתת ה-Explore
  • הרצת השאילתה המבוקשת במסד הנתונים

בדף התיעוד הסבר על מדדי הביצועים של שאילתות מוסבר איך להשתמש ב-Explore של מדדי הביצועים של שאילתות בפעילות המערכת כדי להציג פירוט של שאילתה. השלב Running query של מעקב השאילתות כולל את האירועים שמתוארים בשלב Main queries של ה-Explore Query Performance Metrics.

אם נתקלים בבעיות בביצועים בשלב הזה, אפשר לנסות את הפעולות הבאות:

  • כשאפשר, כדאי ליצור ניתוחים באמצעות צירופי many_to_one. בדרך כלל, צירוף תצוגות מהרמה הכי מפורטת לרמה הכי פחות מפורטת (many_to_one) מספק את ביצועי השאילתה הכי טובים.
  • כדי להפחית את תנועת השאילתות במסד הנתונים, כדאי להגדיל את השמירה במטמון כך שתסתנכרן עם כללי המדיניות של ה-ETL בכל מקום שאפשר. כברירת מחדל, Looker שומר שאילתות במטמון למשך שעה. אתם יכולים לשלוט במדיניות השמירה במטמון ולסנכרן את רענון הנתונים ב-Looker עם תהליך ה-ETL שלכם, על ידי החלת קבוצות נתונים בתוך חקירות באמצעות הפרמטר persist_with. הגדלת השימוש במטמון מאפשרת ל-Looker להשתלב בצורה הדוקה יותר עם פייפליין הנתונים בקצה העורפי, כך שאפשר להגדיל את השימוש במטמון בלי להסתכן בניתוח נתונים לא עדכניים. אפשר להחיל מדיניות שמירה במטמון עם שם על מודל שלם או על חקירות ספציפיות וטבלאות נגזרות מתמידות (PDT).
  • השתמשו בתכונה מודעות לצבירת נתונים של Looker כדי ליצור טבלאות סיכום או סיכומים ש-Looker יכול להשתמש בהם לשאילתות כשאפשר, במיוחד לשאילתות נפוצות של מסדי נתונים גדולים. אתם יכולים גם להשתמש במודעות לצבירת נתונים כדי לשפר באופן משמעותי את הביצועים של מרכזי בקרה שלמים. מידע נוסף זמין במדריך בנושא מוּדעוּת לצבירת נתונים.
  • כדי להריץ שאילתות מהר יותר, אפשר להשתמש ב-PDT. כדאי להמיר ל-PDT ניתוחים עם הרבה איחודים מורכבים או לא יעילים, או מאפיינים עם שאילתות משנה או בחירות משנה, כדי שהתצוגות יאוחזרו מראש ויהיו מוכנות לפני זמן הריצה.
  • אם הדיאלקט של מסד הנתונים תומך ב-PDT מצטברים, מגדירים PDT מצטברים כדי לצמצם את הזמן שנדרש ל-Looker לבנות מחדש טבלאות PDT.
  • הימנעו מצירוף תצוגות ל-Explores במפתחות ראשיים משורשרים שמוגדרים ב-Looker. במקום זאת, צריך לבצע איחוד (join) בשדות הבסיס שמרכיבים את המפתח הראשי המשורשר מהתצוגה. לחלופין, אפשר ליצור מחדש את התצוגה כ-PDT עם המפתח הראשי המשורשר שמוגדר מראש בהגדרת ה-SQL של הטבלה, במקום ב-LookML של התצוגה.
  • כדי לבצע השוואה, אפשר להשתמש בכלי Explain ב-SQL Runner. ‫EXPLAIN יוצר סקירה כללית של תוכנית הביצוע של השאילתה במסד הנתונים לשאילתת SQL נתונה, ומאפשר לזהות רכיבי שאילתה שאפשר לבצע להם אופטימיזציה. מידע נוסף זמין בפוסט לקהילה How to optimize SQL with EXPLAIN.
  • הצהרה על אינדקסים. אפשר להסתכל על האינדקסים של כל טבלה ישירות ב-Looker מ-SQL Runner. לוחצים על סמל גלגל השיניים בטבלה ובוחרים באפשרות Show Indexes.

    העמודות הנפוצות ביותר שיכולות להפיק תועלת מאינדקסים הן תאריכים חשובים ומפתחות זרים. הוספת אינדקסים לעמודות האלה תשפר את הביצועים כמעט בכל השאילתות. הדבר נכון גם לגבי טבלאות PDT. אפשר להחיל פרמטרים של LookML, כמו indexes,‏ sort keys ו-distribution, לפי הצורך.

שלב עיבוד התוצאות

בשלב Processing Results, המערכת של Looker מעבדת ומציגה את תוצאות השאילתה. השלב תוצאות העיבוד כולל את המשימות הבאות:

בדף התיעוד הסבר על מדדי הביצועים של שאילתות מוסבר איך להשתמש ב-Explore של מדדי הביצועים של שאילתות בפעילות המערכת כדי להציג פירוט של שאילתה. השלב Processing Results של מעקב השאילתות כולל את האירועים שמתוארים ב-Post-query phase של מדד לבדיקת ביצועים של שאילתות Explore.

אם נתקלים בבעיות בביצועים בשלב הזה, אפשר לנסות את הפעולות הבאות:

  • השתמשו בתכונות כמו מיזוג תוצאות, שדות בהתאמה אישית וחישובים בטבלה רק כשצריך. התכונות האלה נועדו לשמש כהוכחות היתכנות שיעזרו לכם לתכנן את המודל. מומלץ להגדיר ב-LookML חישובים ופונקציות שמשתמשים בהם לעיתים קרובות, כדי ליצור SQL שיעובד במסד הנתונים. חישובים רבים מדי יכולים להתחרות על זיכרון Java במכונה של Looker, ולגרום למכונה של Looker להגיב לאט יותר.
  • אם יש מספר גדול של קובצי תצוגה, הגבילו את מספר התצוגות שאתם כוללים במודל. הכללת כל התצוגות במודל אחד עלולה להאט את הביצועים. אם יש מספר גדול של תצוגות בפרויקט, כדאי לכלול רק את קובצי התצוגה שנדרשים בכל מודל. כדאי להשתמש במוסכמות שמות אסטרטגיות לשמות של קובצי תצוגה כדי לאפשר הכללה של קבוצות של תצוגות בתוך מודל. דוגמה מפורטת בתיעוד של הפרמטר includes.
  • כדאי להימנע מהחזרת מספר גדול של נקודות על הגרף כברירת מחדל בתוך משבצות של מרכז הבקרה וב-Looks. שאילתות שמחזירות אלפי נקודות על הגרף יצרכו יותר זיכרון. כדי להגביל את הנתונים ככל האפשר, צריך להחיל מסננים של ממשק המשתמש על מרכזי בקרה, על Looks ועל Explores, וברמת LookML עם הפרמטרים required filters,‏ conditionally_filter ו-sql_always_where.
  • השתמשו באפשרות All Results כדי להוריד או לשלוח שאילתות רק כשצריך, כי חלק מהשאילתות יכולות להיות גדולות מאוד ולהעמיס על שרת Looker בזמן העיבוד.