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

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

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

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

• בנו את ה-Explores באמצעות צירופי many_to_one כשזה אפשרי. בדרך כלל, צירוף תצוגות מהרמה המפורטת ביותר לרמה הגבוהה ביותר של הפרטים (many_to_one) מספק את ביצועי השאילתה הטובים ביותר.
• כדאי למקסם את השימוש במטמון כדי לסנכרן עם מדיניות ה-ETL שלכם בכל מקום שאפשר, וכך להפחית את תנועת השאילתות במסד הנתונים. כברירת מחדל, Looker שומר שאילתות במטמון למשך שעה. אתם יכולים לשלוט במדיניות השמירה במטמון ולסנכרן את רענון הנתונים ב-Looker עם תהליך ה-ETL באמצעות קבוצות נתונים בתוך כלי הניתוח, בעזרת הפרמטר persist_with. כך Looker יכול להשתלב בצורה הדוקה יותר עם צינור הנתונים של ה-Backend, כדי למקסם את השימוש במטמון בלי הסיכון לניתוח נתונים לא עדכניים. אפשר להחיל מדיניות עם שמות של שמירת נתונים במטמון על מודל שלם ו/או על ניתוחים נפרדים וטבלאות נגזרות קבועות (PDT).
• משתמשים בפונקציונליות של aggregate awareness ב-Looker כדי ליצור סיכומי נתונים או טבלאות סיכום ש-Looker יכול להשתמש בהן לשאילתות כשזה אפשרי, במיוחד לשאילתות נפוצות של מסדי נתונים גדולים. אפשר גם להשתמש במודעות מצטברות כדי לשפר באופן משמעותי את הביצועים של לוחות בקרה שלמים. מידע נוסף זמין במדריך בנושא מודעות מצטברת.
• כדי להריץ שאילתות מהר יותר, כדאי להשתמש בPDT. להמיר ניתוחים עם הרבה הצטרפויות מורכבות או לא יעילות, או מאפיינים עם שאילתות משנה או בחירות משנה, ל-PDT כדי שהתצוגות יהיו מוכנות לפני זמן הריצה.
• אם דיאלקט מסד הנתונים תומך ב-PDT מצטבר, כדאי להגדיר PDT מצטבר כדי לקצר את הזמן ש-Looker משקיע בבנייה מחדש של PDT.
• מומלץ להימנע מצירוף תצוגות ל-Explores במקרים של מפתחות ראשיים משורשרים שמוגדרים ב-Looker. במקום זאת, מצטרפים לשדות הבסיס שמרכיבים את המפתח הראשי המשורשר מהתצוגה. אפשרות אחרת היא ליצור מחדש את התצוגה כ-PDT עם המפתח הראשי המשורשר שמוגדר מראש בהגדרת ה-SQL של הטבלה, ולא ב-LookML של התצוגה.
• כדי לבצע השוואה בין ביצועים, אפשר להשתמש בכלי Explain in SQL Runner. ‫EXPLAIN יוצר סקירה כללית של תוכנית ההרצה של שאילתת מסד הנתונים עבור שאילתת SQL נתונה, ומאפשר לכם לזהות רכיבי שאילתה שאפשר לבצע בהם אופטימיזציה. מידע נוסף זמין בפוסט לקהילה איך לבצע אופטימיזציה של SQL באמצעות EXPLAIN.
• מצהירים על האינדקסים. אפשר לראות את האינדקסים של כל טבלה ישירות ב-Looker מתוך SQL Runner. לשם כך, לוחצים על סמל גלגל השיניים בטבלה ואז בוחרים באפשרות הצגת אינדקסים.
  העמודות הכי נפוצות שיכולות להפיק תועלת מאינדקסים הן תאריכים חשובים ומפתחות זרים. הוספת אינדקסים לעמודות האלה תשפר את הביצועים של כמעט כל השאילתות. הדבר נכון גם לגבי PDT. אפשר להחיל פרמטרים של LookML, כמו indexes,‏ sort keys ו-distribution, בצורה מתאימה.
• כדי לשפר את הביצועים של השאילתות, כדאי להגדיל את הזיכרון, את ליבות המעבד ואת קצב העברת הנתונים (I/O) של מסדי נתונים עם חומרה לא מספקת או עם משאבים מוקצים (כמו AWS) שנדרשים לעיבוד של קבוצות נתונים גדולות.

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

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

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

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