מודעות מצטברת

סקירה כללית

‫Looker משתמש בלוגיקה של מודעוּת לצבירה כדי למצוא את הטבלה הקטנה והיעילה ביותר שזמינה במסד הנתונים שלכם להרצת שאילתה, תוך שמירה על הדיוק.

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

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

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

• בשאילתה לגבי סך המכירות החודשיות, Looker משתמש בטבלת הצבירה שמבוססת על מכירות חודשיות (sales_monthly_aggregate_table).
• בשאילתה לגבי הסכום הכולל של כל מכירה ביום מסוים, אין טבלה נצברת עם רמת הפירוט הזו, ולכן Looker מקבל את תוצאות השאילתה מטבלת מסד הנתונים המקורית (orders_database). (עם זאת, אם המשתמשים מריצים שאילתה מהסוג הזה לעיתים קרובות, אפשר ליצור בשבילה טבלה נצברת).
• בשאילתה על מכירות שבועיות, אין טבלת צבירה שבועית, ולכן Looker משתמש באפשרות הטובה ביותר הבאה, שהיא טבלת הצבירה שמבוססת על מכירות יומיות (sales_daily_aggregate_table).

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

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

אתם יכולים גם להשתמש בטבלאות מסכמות כדי לשפר באופן משמעותי את הביצועים של מרכזי הבקרה, במיוחד במשבצות ששולחות שאילתות לקבוצות נתונים גדולות. פרטים נוספים זמינים בקטע Getting aggregate table LookML from a dashboard בדף התיעוד של הפרמטר aggregate_table.

הוספת טבלאות מסכמות לפרויקט

מפתחי Looker יכולים ליצור טבלאות צבירה אסטרטגיות שיצמצמו את מספר השאילתות שנדרשות בטבלאות הגדולות במסד נתונים. צריך לשמור את הטבלאות המסכמות במסד הנתונים כדי שתהיה גישה אליהן לצורך מוּדעוּת לצבירת נתונים. לכן, טבלאות מסכמות הן סוג של טבלה נגזרת מתמידה (PDT).

טבלה מסכמת מוגדרת באמצעות הפרמטר aggregate_table מתחת לפרמטר explore בפרויקט של LookML.

דוגמה ל-explore עם טבלה מסכמת ב-LookML:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

כדי ליצור טבלה מסכמת, אתם יכולים לכתוב את ה-LookML מאפס, או לקבל LookML של טבלה מסכמת מ-Explore או ממרכז בקרה. בדף התיעוד של הפרמטר aggregate_table מפורטים הפרטים של הפרמטר aggregate_table ותת-הפרמטרים שלו.

עיצוב טבלאות מסכמות

כדי ששאילתת Explore תשתמש בטבלת צבירת נתונים, הטבלה צריכה להיות מסוגלת לספק נתונים מדויקים לשאילתת Explore. ‫Looker יכול להשתמש בטבלה מסכמת לשאילתת Explore אם כל התנאים הבאים מתקיימים:

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

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

גורמים בשטח

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

לדוגמה, אם שאילתה מקבצת לפי המאפיינים א' וב', צוברת לפי המדד ג' ומסננת לפי המאפיין ד', טבלת הצבירה חייבת לכלול לפחות את א', ב' וד' כמאפיינים ואת ג' כמדד.

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

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

גורמים שקשורים למסגרת הזמן

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

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

בנוסף, אותו היגיון חל על שאילתות עם מסננים של מסגרת זמן: אפשר להשתמש בטבלה מסכמת לשאילתה עם מסנן של מסגרת זמן, כל עוד מסגרת הזמן של הטבלה המסכמת כוללת רמת פירוט גבוהה יותר (או שווה) לזו של מסנן מסגרת הזמן שבו נעשה שימוש בשאילתה בכלי הניתוחים. לדוגמה, אפשר להשתמש בטבלה נצברת שיש בה מאפיין של מסגרת זמן יומית בשאילתת Explore שמסננת לפי יום, שבוע או חודש.

גורמים של סוג המדידה

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

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

• אמצעים עם סוגי אמצעים נתמכים
• מדדים שמוגדרים באמצעות ביטויי SQL
• מידות שלא מוגדרות באמצעות ${TABLE}
• מדדים שמעריכים ספירות נפרדות

אם שאילתת Explore משתמשת בסוג אחר של מדד, Looker ישתמש בטבלה המקורית, ולא בטבלת הצבירה, כדי להחזיר תוצאות. החריג היחיד הוא אם השאילתה של Explore היא התאמה מדויקת של שאילתת טבלה מסכמת, כמו שמתואר בקטע יצירת טבלאות מסכמות שתואמות בדיוק לשאילתות של Explore.

אחרת, Looker ישתמש בטבלה המקורית, ולא בטבלה המצטברת, כדי להחזיר תוצאות.

מדדים עם סוגי מדדים נתמכים

אפשר להשתמש במודעות מצטברת בשאילתות של Explore שמשתמשות במדדים עם סוגי המדדים הבאים:

• sum
• count
• min
• max
• average

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

במקרה של מדדים עם type: average, יש תמיכה במודעות לצבירת נתונים כי Looker משתמש בנתוני סכום וספירה כדי להפיק ערכים ממוצעים מדויקים מטבלאות מסכמות.

מדדים שמוגדרים באמצעות ביטויי SQL

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

• number
• date
• string
• yesno

התכונה "מודעות לצבירת נתונים" נתמכת במדדים שמוגדרים כשילובים של מדדים אחרים, כמו בדוגמה הזו:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

מודעות מצטברת נתמכת גם במדדים שבהם החישובים מוגדרים בפרמטר sql, כמו המדד הזה:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

בנוסף, יש תמיכה במודעוּת לצבירה במדדים שבהם הפעולות MIN, ‏ MAX ו-COUNT מוגדרות בפרמטר sql, כמו במדד הזה:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

מדדים שמתייחסים לשדות LookML

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

• הפניות בפורמט ${view_name.field_name}, שמציין שדות בתצוגות אחרות
• הפניות בפורמט ${field_name}, שמציין שדות באותה תצוגה

אין תמיכה במודעות לצבירה במדדים שמוגדרים באמצעות הפורמט ${TABLE}.column_name, שמציין עמודה בטבלה. (במאמר שילוב SQL והפניה לאובייקטים של LookML מוסבר איך להשתמש בהפניות ב-LookML).

לדוגמה, מדד שמוגדר עם הפרמטר sql לא נתמך בטבלה מסכמת, כי הוא משתמש בפורמט ${TABLE}.column_name:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

אם רוצים לכלול את המדד הזה בטבלה מסכמת, אפשר ליצור מאפיין שמוגדר בפורמט ${TABLE}.column_name, ואז ליצור מדד שמפנה למאפיין, למשל:

 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

עכשיו אפשר להשתמש במדד wholesale_value בטבלה המסכמת.

מדדים שמעריכים ספירות נפרדות

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

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

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

לאלגוריתם HyperLogLog יש שגיאה של כ-2%. הפרמטר allow_approximate_optimization: yes דורש ממפתחי Looker לאשר שזה בסדר להשתמש בנתונים משוערים למדד, כדי שניתן יהיה לחשב את המדד באופן משוער מטבלאות מסכמות.

מידע נוסף מופיע בדף התיעוד של הפרמטר allow_approximate_optimization וברשימת הדיאלקטים שתומכים בספירת ערכים ייחודיים באמצעות HyperLogLog.

גורמים שקשורים לאזור הזמן

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

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

מידע נוסף על האפשרויות האלה זמין בדף התיעוד שימוש בהגדרות אזור הזמן.

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

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

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

אם אחד מהתנאים האלה מתקיים, אתם יכולים להשמיט את הפרמטר timezone מהטבלאות המסכמות.

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

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

גורמי סינון

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

בנוסף, חשוב לשים לב למסננים שמפתחי Looker הוסיפו ל-Explore, למשל:

• ‫access_filters: החלת הגבלות על נתונים ספציפיים למשתמש.
• ‫always_filter: דורשים מהמשתמשים לכלול קבוצה מסוימת של מסננים בשאילתת Explore. המשתמשים יכולים לשנות את ערך ברירת המחדל של המסנן בשאילתה, אבל הם לא יכולים להסיר את המסנן לגמרי.
• ‫conditionally_filter: מגדיר קבוצה של מסנני ברירת מחדל שהמשתמשים יכולים לשנות אם הם מחילים לפחות מסנן אחד מרשימה שנייה שמוגדרת גם היא ב-Explore.

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

לדוגמה, הנה ניתוח עם מסנן גישה שמבוסס על השדה orders.region:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

כדי ליצור טבלה מסכמת שתשמש לניתוח הזה, הטבלה המסכמת חייבת לכלול את השדה שעליו מבוסס מסנן הגישה. בדוגמה הבאה, מסנן הגישה מבוסס על השדה orders.region, והשדה הזה נכלל כמאפיין בטבלה המסכמת:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

מכיוון שהשאילתה של הטבלה המסכמת כוללת את המאפיין orders.region, Looker יכול לסנן באופן דינמי את הנתונים בטבלה המסכמת כך שיתאימו למסנן מהשאילתה של Explore. לכן, Looker עדיין יכול להשתמש בטבלה המסכמת לשאילתות של ה-Explore, למרות של-Explore יש מסנן גישה.

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

יצירת טבלאות מסכמות שתואמות בדיוק לשאילתות בכלי הניתוחים

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

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

איך לקבוע באיזו טבלה מסכמת להשתמש בשאילתה

משתמשים עם הרשאות see_sql יכולים להשתמש בהערות בכרטיסייה SQL של Explore כדי לראות באיזו טבלה מסכמת ייעשה שימוש בשאילתה. ההערות בכרטיסייה SQL מוצגות גם ב-Development Mode, כך שמפתחים יכולים לבדוק טבלאות מסכמות חדשות כדי לראות איך Looker משתמש בהן לפני שמעבירים טבלאות חדשות לסביבת הייצור.

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

מההערות הבאות בכרטיסייה SQL, אפשר לראות ש-Looker משתמש בטבלה המסכמת sales_monthly בשאילתה הזו, ומידע על הסיבה לכך שטבלאות מסכמות אחרות לא שימשו לשאילתה:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

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

אומדני חיסכון בחישובים למודעות מצטברת

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

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

אחרי שהשאילתה תרוץ, בחלון Explore תוצג הטבלה המסכמת ששימשה כדי לענות על השאילתה, ליד הלחצן Run.

החיסכון המצטבר מוצג לחיבורים למסדי נתונים שמופעלות בהם הערכות עלות. מידע נוסף זמין בדף התיעוד בחינת נתונים ב-Looker .

‫Looker מאחד נתונים חדשים עם טבלאות מסכמות

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

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

‫Looker יכול לאחד נתונים עדכניים עם הנתונים בטבלה המסכמת בנסיבות הבאות:

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

לדוגמה, בטבלה מסכמת הבאה יש מאפיין שמבוסס על השדה orders.created_date, ומסנן זמן ("3 days") שמבוסס על אותו שדה:

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

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

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

צריך לשמר את הטבלאות המסכמות

כדי שהטבלה המסכמת תהיה נגישה למודעות מצטברת, היא צריכה להיות שמורה במסד הנתונים. אסטרטגיית השמירה מצוינת בפרמטר materialization של הטבלה המסכמת. טבלאות מסכמות הן סוג של טבלה נגזרת מתמידה (PDT), ולכן יש להן את אותן דרישות כמו ל-PDT. פרטים נוספים זמינים בדף התיעוד טבלאות נגזרות ב-Looker.

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

משתמש עם הרשאת develop יכול לשנות את הגדרות השמירה ולבנות מחדש את כל הטבלאות המסכמות של שאילתה כדי לקבל את הנתונים העדכניים ביותר. כדי לבנות מחדש את הטבלאות הנגזרות של שאילתה, בוחרים באפשרות Rebuild Derived Tables & Run בתפריט גלגל השיניים Explore actions.

האפשרות הזו תהיה זמינה רק אחרי שהשאילתה ב"ניתוחים" תיטען.

האפשרות Rebuild Derived Tables & Run בונה מחדש את כל הטבלאות הנגזרות שיש אליהן הפניה בשאילתה, וגם את כל הטבלאות הנגזרות שהטבלאות בשאילתה תלויות בהן. זה כולל טבלאות מסכמות, שהן בעצמן סוג של טבלה נגזרת מתמידה.

למשתמש שמפעיל את האפשרות Rebuild Derived Tables & Run, השאילתה תמתין לבנייה מחדש של הטבלאות הנגזרות לפני טעינת התוצאות. שאילתות של משתמשים אחרים עדיין ישתמשו בטבלאות הקיימות. אחרי שהטבלאות לשימוש חוזר נוצרות מחדש, כל המשתמשים ישתמשו בטבלאות שנוצרו מחדש.

מידע נוסף על האפשרות Rebuild Derived Tables & Run זמין בדף התיעוד טבלאות נגזרות ב-Looker.

פתרון בעיות

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

בכרטיסייה SQL יש גם הערות שמסבירות למה לא נעשה שימוש בטבלאות מסכמות בשאילתה, אם זה המצב. בטבלאות מסכמות שלא נעשה בהן שימוש, ההערה תתחיל כך:

Did not use [explore name]::[aggregate table name];

לדוגמה, הנה הערה שמסבירה למה לא נעשה שימוש בטבלה המסכמת sales_daily שהוגדרה ב-Explore‏ order_items בשאילתה:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

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

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

מה כדאי לקחת בחשבון?

צבירה סימטרית ל-Explores עם שאילתות איחוד (join)

חשוב לציין שב-Explore שמצרף כמה טבלאות של מסדי נתונים, Looker יכול להציג מדדים מסוג SUM,‏ COUNT ו-AVERAGE בתור SUM DISTINCT,‏ COUNT DISTINCT ו-AVERAGE DISTINCT, בהתאמה. ‫Looker עושה את זה כדי למנוע חישובים שגויים של fanout. לדוגמה, מדד count מוצג כסוג מדד count_distinct. כך אפשר להימנע מחישובים שגויים של fanout בשאילתות איחוד (join), וזה חלק מהפונקציונליות של צבירה סימטרית ב-Looker. הסבר על התכונה הזו של Looker זמין בדף שיטות מומלצות לצבירה סימטרית.

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

סוגי המדדים שנתמכים במודעות מצטברת הם sum,‏ count ו-average. ‫Looker יעבד את סוגי המדדים האלה כ-DISTINCT אם:

• המדד הוא מהתצוגה "אחד" של צירוף רבים לאחד או אחד לרבים.
• המדד הוא מכל אחת מהתצוגות של צירוף רבים לרבים.

הסבר על סוגי הצירופים האלה מופיע בדף התיעוד של הפרמטר relationship.

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

בנוסף, אם יש לכם ניב SQL שתומך בשרטוטי HyperLogLog, אתם יכולים להוסיף את הפרמטר allow_approximate_optimization: yes למדד. כשמדד ספירה מוגדר באמצעות allow_approximate_optimization: yes, Looker יכול להשתמש במדד למודעות מצטברת, גם אם הוא מוצג כספירה נפרדת.

לפרטים נוספים, עיינו בדף התיעוד של הפרמטר allow_approximate_optimization וברשימה של הדיאלקטים של SQL שתומכים בשרטוטי HyperLogLog.

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

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

תמיכה בדיאלקט ליצירה מצטברת של טבלאות צבירה

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