אופטימיזציה של הביצועים ב-Looker

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

אופטימיזציה של ביצועי השאילתות

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

• כשאפשר, כדאי ליצור ניתוחים באמצעות צירופי 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, לפי הצורך.
• כדי לשפר את ביצועי השאילתות, כדאי להגדיל את הזיכרון, הליבות והקלט/פלט (I/O) של מסדי נתונים עם חומרה לא מספקת או משאבים מוקצים נחוצים (כמו AWS) לעיבוד קבוצות נתונים גדולות.

אופטימיזציה של ביצועי השרת של Looker

אתם יכולים גם לנקוט אמצעים כדי לוודא שהשרת והאפליקציה של Looker פועלים בצורה אופטימלית:

• הגבילו את מספר הרכיבים במרכז בקרה מסוים. אין כלל מדויק להגדרת המספר, כי העיצוב של כל רכיב משפיע על צריכת הזיכרון על סמך מגוון גורמים. עם זאת, מרכזי בקרה עם 25 משבצות או יותר נוטים להיות בעייתיים מבחינת הביצועים.
• השתמשו בתכונה רענון אוטומטי של מרכז הבקרה באופן אסטרטגי. אם מרכז הבקרה משתמש ברענון אוטומטי, צריך לוודא שהוא לא מתרענן מהר יותר מתהליכי ה-ETL שפועלים מאחורי הקלעים.
• השתמשו בצירים באופן אסטרטגי, והימנעו משימוש יתר בצירים בתוך משבצות של מרכזי בקרה ו-Looks. שאילתות עם מאפיינים שהופכים לציר יצרכו יותר זיכרון. ככל שיש יותר מאפיינים שעוברים המרה, כך נצרך יותר זיכרון כשהתוכן (חקירה, Look או מרכז בקרה) נטען.
• השתמשו בתכונות כמו שדות בהתאמה אישית וחישובים בטבלה, אבל לא יותר מדי. התכונות האלה נועדו לשמש כהוכחות היתכנות שיעזרו לכם לתכנן את המודל. מומלץ להגדיר ב-LookML חישובים ופונקציות שמשתמשים בהם לעיתים קרובות, כדי ליצור SQL שיעובד במסד הנתונים. חישובים רבים מדי יכולים להתחרות על זיכרון Java במכונה של Looker, ולגרום למכונה של Looker להגיב לאט יותר.
• בשאילתות של תוצאות ממוזגות, השתמשו בשאילתות מיזוג בתוך מסד הנתונים כשאפשר. שאילתות מיזוג בתוך מסד הנתונים מעובדות במסד הנתונים, ולא בזיכרון של Looker.
• להגביל את מספר התצוגות שכלולות במודל כשיש מספר גדול של קובצי תצוגה. הכללת כל התצוגות במודל אחד עלולה להאט את הביצועים. אם יש מספר גדול של תצוגות בפרויקט, כדאי לכלול רק את קובצי התצוגה שנדרשים בכל מודל. כדאי להשתמש במוסכמות שמות אסטרטגיות לשמות של קובצי תצוגה, כדי לאפשר הכללה של קבוצות של תצוגות בתוך מודל. דוגמה מפורטת בתיעוד של הפרמטר includes.
• כדאי להימנע מהחזרת מספר גדול של נקודות על הגרף כברירת מחדל בתוך משבצות של מרכז הבקרה וב-Looks. שאילתות שמחזירות אלפי נקודות על הגרף יצרכו יותר זיכרון. כדי להבטיח שהנתונים מוגבלים ככל האפשר, צריך להחיל מסננים של ממשק משתמש על מרכזי בקרה, על Looks ועל Explores, וברמת LookML עם הפרמטרים required filters,‏ conditionally_filter ו-sql_always_where.
• השתמשו באפשרות All Results (כל התוצאות) כדי להוריד או לשלוח שאילתות רק כשצריך, כי חלק מהשאילתות יכולות להיות גדולות מאוד ולהעמיס על שרת Looker בזמן העיבוד.
• להבין את ההשפעה של ביצועי החיבור על כל המכונה של Looker. Looker משתמש במשאבים משותפים כדי לעבד שאילתות מכל החיבורים למסדי הנתונים. המשאבים האלה כוללים פודים של Kubernetes, תורי שאילתות ומאגרי שרשורים. בגלל התשתית המשותפת הזו, חיבור אחד איטי או עמוס למסד נתונים יכול להשפיע לרעה על הביצועים של שאילתות בכל החיבורים האחרים. אם אתם מבחינים בירידה נרחבת בביצועים, בדקו את התקינות של כל החיבורים למסד הנתונים, ולא רק את אלה שקשורים ישירות למרכזי הבקרה או לניתוחים האיטיים.
• לפזר את המסירות המתוזמנות ולהימנע מהרצת משימות בו-זמנית. כשמתזמנים כמה דוחות Look או מרכזי בקרה לפעול בדיוק באותה דקה (במיוחד בתחילת השעה), העומס הפתאומי של בקשות השאילתות בו-זמנית יכול להציף את משאבי המכונה, להגדיל את עומק התור ולרוקן את מאגרי החיבורים של מסד הנתונים. צוואר הבקבוק הזה יכול לגרום לעיכובים גם במסירות המתוזמנות וגם בשאילתות האינטראקטיביות ב-Explore במהלך שלב האתחול של השאילתה. כדי למנוע צווארי בקבוק של בו-זמניות, מומלץ להשתמש באסטרטגיות הבאות:
  • כדאי לפרוס את המשימות המתוזמנות במרווחים של 15 או 30 דקות (או דקות שלא בתחילת השעה, כמו :15, :30 או :45) במקום לתזמן את כל המסירות בתחילת השעה.
  • בכל פעם שאפשר, השתמשו בקבוצות נתונים כדי להפעיל מסירות שמבוססות על השלמת ETL במקום על לוחות זמנים שמבוססים על זמן, כדי למנוע שאילתות מיותרות על נתונים שלא רועננו.
  • הפעילו סקריפטים חיצוניים וקריאות אוטומטיות ל-API שמריצות שאילתות או מפעילות העברות נתונים באצוות או בהגבלת קצב.
  • אם עומס פתאומי של שאילתות גורם למכונה לא להגיב או לשאילתות להסתובב ללא הגבלת זמן, אתם יכולים לנקות משימות בתהליך על ידי הפעלה מחדש של המכונה (ראו הפעלה מחדש של מכונה של Looker (Google Cloud core) למכונות של Looker (Google Cloud core)).

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