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

סקירה כללית

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 מכילה מאפיין או מדד שלא נמצאים בטבלה מסכמת, Looker לא יכול להשתמש בטבלה המסכמת וישתמש במקום זאת במסד הנתונים הטבלאי.

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

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

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

גורמים שקשורים ללוח הזמנים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 בטבלה המסכמת.

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

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

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

אפשרות נוספת היא להשתמש בקירובים לספירות נפרדות. בניבים שתומכים בשרטוטי 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 ‏(NDT) שמשתמשת ב-bind_filters, השאילתה של Explore יכולה להשתמש בטבלה מסכמת רק אם לכל השדות שנעשה בהם שימוש בפרמטר bind_filters של הטבלה הנגזרת מבוססת LookML ‏(NDT) יש בדיוק את אותם ערכי סינון בשאילתה של 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, כמו שמתואר בקטע איך קובעים באיזו טבלה מסכמת השאילתה תשתמש בדף התיעוד הזה.

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

החיסכון המצטבר מוצג בחיבורים למסדי נתונים שמופעלות בהם הערכות עלות. מידע נוסף זמין בדף התיעוד בחינת נתונים ב-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.

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

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

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

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

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

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

כדי לפתור את הבעיה, בודקים את הסוג של כל מדד בשאילתה ומוודאים שהוא אחד מסוגי המדדים הנתמכים. בנוסף, אם ב-Explore יש צירופים, צריך לוודא שהמדדים לא מומרים למדדים נפרדים (צבירה סימטרית) באמצעות צירופים מורחבים. הסבר מופיע בקטע צבירה סימטרית ל-Explores עם צירופים בדף הזה.
טבלה מסכמת אחרת התאימה יותר לאופטימיזציה. היו כמה טבלאות מסכמות שאפשר להשתמש בהן בשאילתה, ו-Looker מצא טבלה מסכמת אופטימלית יותר לשימוש. במקרה כזה לא צריך לעשות כלום.
מערכת Looker לא ביצעה קיבוץ (בגלל פרמטר primary_key או cancel_grouping_fields), ולכן לא ניתן לצבור את השאילתה. השאילתה מפנה למאפיין שמונע ממנה לכלול פסוקית GROUP BY, ולכן Looker לא יכול להשתמש בטבלה מסכמת כלשהי בשאילתה.

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

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

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

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

צבירה סימטרית ל-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, הניבים הבאים תומכים במודעות לצבירת נתונים:

ניב יש תמיכה?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

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

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

ניב יש תמיכה?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica