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

סקירה כללית

‫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 יכול להשתמש אוטומטית בטבלאות מצטברות, אבל עדיין לצלול לעומק לנתונים ברמת הגרנולריות אם יש צורך בכך.

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

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

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

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

גורמים בשדה

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

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

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

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

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

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

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

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

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

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

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

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

אחרת, 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, שמציין עמודה בטבלה. (סקירה כללית על שימוש בהפניות ב-LookML מופיעה במאמר שילוב של SQL והפניה לאובייקטים של 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 שלכם לאשר שאין בעיה להשתמש בנתונים משוערים למדד, כדי שהמדד יוכל להיות מחושב בקירוב מטבלאות מצטברות.

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

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

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

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

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

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

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

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

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

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

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

גורמי סינון

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

בנוסף, כדאי לשים לב למסננים שמפתחי Looker אולי הטמיעו בכלי הניתוחים, כמו:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

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

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

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

-- 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 להשתמש בטבלת הצבירה.

כדי לפתור זאת, באפשרותך לבצע אחת מהפעולות הבאות:
  • הוסף את אותו מסנן לטבלת הצבירה שלך.
  • הוסף את השדה שבו משתמש המסנן לטבלת הצבירה שלך.
  • הסר את המסננים משאילתת החקירה.
לפרטים נוספים, עיינו בסעיף גורמי סינון בדף זה.
השאילתה מכילה את המידות הבאות שלא ניתן לסכם. השאילתה מכילה סוג אחד או יותר של מדד שאינם נתמכים עבור מודעות מצטברת, כגון distinct count (ספירה נפרדת), median (חציון) או percentile (אחוזון).

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

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

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

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

דברים שכדאי לקחת בחשבון

אגרגטים סימטריים עבור חקירות עם צירופים

דבר חשוב לציין הוא שב-Explore שמחבר מספר טבלאות מסד נתונים, Looker יכול לעבד מדדים מסוג SUM, COUNT ו-AVERAGE כ-SUM DISTINCT, COUNT DISTINCT ​​ו-AVERAGE DISTINCT, בהתאמה. Looker עושה זאת כדי למנוע חישובים שגויים של fanout. לדוגמה, אcount המידה מוצגת כ-count_distinct סוג המידה. זה כדי למנוע חישובים שגויים של fanout עבור איחודים, וזהו חלק מפונקציונליות הצבירה הסימטרית של 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, הדיאלקטים הבאים תומכים ב-Aggregate Awareness:

דיאלקט נתמך?
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
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+
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
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+
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