קבוצת נתונים

Usage

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}
היררכיה
datagroup
ערך ברירת המחדל
ללא

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

הגדרה

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

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

אפשר להוסיף תווית ותיאור לקבוצת הנתונים:

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

מציינים את הפרטים של מדיניות השמירה במטמון וההתמדה באמצעות פרמטרי המשנה datagroup:

  • ‫max_cache_age: מחרוזת שמגדירה תקופת זמן. אם משך הזמן שחלף מאז שהשאילתה נשמרה במטמון חורג מתקופת הזמן, Looker מבטל את התוקף של המטמון. בפעם הבאה שהשאילתה תופעל, Looker ישלח את השאילתה למסד הנתונים כדי לקבל תוצאות עדכניות. פרטים נוספים מופיעים בקטע max_cache_age בדף הזה.
  • ‫sql_trigger: מציינת שאילתת SQL שמחזירה שורה אחת עם עמודה אחת. אם הערך שמוחזר על ידי השאילתה שונה מהתוצאות הקודמות של השאילתה, קבוצת הנתונים עוברת למצב מופעל. פרטים נוספים מופיעים בקטע sql_trigger בדף הזה.
  • ‫interval_trigger: מציין את לוח הזמנים להפעלת קבוצת הנתונים, כמו "24 hours". פרטים נוספים מופיעים בקטע interval_trigger בדף הזה.

לרוב, הפתרון הכי טוב הוא להשתמש ב-max_cache_age בשילוב עם sql_trigger או interval_trigger. מציינים ערך של sql_trigger או interval_trigger שתואם לטעינת הנתונים (ETL) למסד הנתונים, ואז מציינים ערך של max_cache_age שיבטל את הנתונים הישנים אם ה-ETL ייכשל. הפרמטר max_cache_age מבטיח שאם המטמון של קבוצת נתונים לא ינוקה על ידי sql_trigger או interval_trigger, תוקף הרשומות במטמון יפוג אחרי פרק זמן מסוים. כך, מצב הכשל של קבוצת נתונים יהיה שליחת שאילתה למסד הנתונים במקום הצגת נתונים לא עדכניים ממטמון Looker.

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

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

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

max_cache_age

הפרמטר max_cache_age מציין מחרוזת שמכילה מספר שלם ואחריו את המילים seconds,‏ minutes או hours. התקופה הזו היא התקופה המקסימלית שבה אפשר להשתמש בתוצאות שנשמרו במטמון בשאילתות של ניתוח נתונים שמשתמשות בקבוצת הנתונים.

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

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

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

sql_trigger

משתמשים בפרמטר sql_trigger כדי לציין שאילתת SQL שמחזירה בדיוק שורה אחת עם עמודה אחת. מערכת Looker מריצה את שאילתת ה-SQL במרווחי זמן שמוגדרים בשדה Datagroup and PDT Maintenance Schedule של חיבור מסד הנתונים. אם השאילתה מחזירה ערך שונה מהתוצאה הקודמת, קבוצת הנתונים עוברת למצב מופעל. אחרי שהקבוצה datagroup מופעלת, Looker בונה מחדש את כל ה-PDT שצוינה בהם הקבוצה datagroup בפרמטר datagroup_trigger. אחרי שהבנייה מחדש של ה-PDT מסתיימת, קבוצת הנתונים עוברת למצב מוכן ו-Looker מבטל את התוקף של התוצאות שנשמרו במטמון של כל ניתוח באמצעות קבוצת הנתונים הזו.

בדרך כלל, sql_trigger מציין שאילתת SQL שמציינת מתי התרחש טעינה חדשה של נתונים (ETL), למשל על ידי שליחת שאילתה ל-max(ID) בטבלה. אפשר גם להשתמש ב-sql_trigger כדי לציין שעה מסוימת ביום. לשם כך, צריך לשלוח שאילתה לגבי התאריך הנוכחי ולהוסיף לחותמת הזמן שעות נוספות לפי הצורך כדי להגיע לשעה הרצויה, למשל 4:00.

חשוב לשים לב לנקודות הבאות לגבי sql_trigger:

  • אי אפשר להשתמש ב-sql_trigger אם החיבור למסד הנתונים משתמש ב-OAuth או במאפייני משתמש והשבתתם את ה-PDT לחיבור. הסיבה לכך היא ש-Looker צריך נתוני כניסה סטטיים כדי לגשת למסד הנתונים ולהריץ את השאילתה שצוינה בפרמטר sql_trigger. כשמפעילים PDT, אפשר להשתמש בשדות PDT Overrides כדי לספק ל-Looker פרטי כניסה סטטיים נפרדים לתהליכי PDT, גם אם החיבור משתמש בפרטי כניסה דינמיים כמו OAuth או מאפייני משתמש. אבל אם השבתתם את ה-PDT, ואם החיבור שלכם משתמש ב-OAuth או במאפייני משתמש, לא תוכלו לספק ל-Looker את פרטי הכניסה הסטטיים של המשתמש שנדרשים לשאילתות sql_trigger.
  • ‫Looker לא מבצע המרה של אזור זמן עבור sql_trigger. אם רוצים להפעיל את קבוצת הנתונים בשעה ספציפית ביום, צריך להגדיר את ההפעלה באזור הזמן שבו מוגדר מסד הנתונים.

בדוגמאות האלה מתוך מאמר העזרה בנושא הפרמטר sql_trigger אפשר למצוא רעיונות להגדרת שאילתות SQL להפעלת קבוצת נתונים.

interval_trigger

אפשר להשתמש בתת-פרמטר האופציונלי interval_trigger כדי לציין משך זמן לבנייה מחדש. בפרמטר interval_trigger מעבירים מחרוזת שמכילה מספר שלם ואחריו את המילים seconds,‏ minutes או hours.

label וגם description

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

פרמטרי המשנה האלה מוצגים בדף Datagroups בקטע Database בחלונית Admin. מידע נוסף על אופן ההצגה של הנתונים האלה זמין בדף התיעוד בנושא הגדרות אדמין – קבוצות נתונים.

דוגמאות

בדוגמאות הבאות מודגשים תרחישי השימוש של datagroup, כולל:

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

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

  • משתמשים בקבוצת הנתונים orders_datagroup (בקובץ המודל) כדי לתת שם למדיניות השמירה במטמון.
  • משתמשים בפרמטר sql_trigger כדי לציין את השאילתה שמציינת שיש נתונים עדכניים: select max(id) from my_tablename. בכל פעם שהנתונים מתעדכנים, השאילתה הזו מחזירה מספר חדש.
  • משתמשים בהגדרה max_cache_age כדי לבטל את תוקף הנתונים אם הם נשמרו במטמון למשך 24 שעות.
  • אפשר להשתמש בפרמטרים האופציונליים label ו-description כדי להוסיף תווית בהתאמה אישית ותיאור של קבוצת הנתונים.
datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

כדי להשתמש במדיניות השמירה במטמון orders_datagroup כברירת המחדל לניתוחים ב-Explore במודל, צריך להשתמש בפרמטר persist_with ברמת המודל ולציין את orders_datagroup:

persist_with: orders_datagroup

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

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

כדי להשתמש במדיניות שמירת הנתונים במטמון של קבוצת הנתונים orders_datagroup לבנייה מחדש של PDT, אפשר להוסיף את datagroup_trigger מתחת לפרמטר derived_table ולציין את orders_datagroup:

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

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

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

  1. יוצרים קבוצת נתונים באמצעות הצהרת SQL כדי להפעיל אותה בסוף כל חודש:

    datagroup: month_end_datagroup {
sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
description: "Triggered on the last day of each month"
}

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

    הצהרת ה-SQL הזו מחזירה את החודש שבו יהיה מחר – ביום האחרון של החודש, מחר יהיה בחודש הבא – ולכן קבוצת הנתונים תופעל. ביום אחר, מחר הוא באותו חודש, ולכן קבוצת הנתונים לא מופעלת.

  2. בוחרים את קבוצת הנתונים בלוח זמנים חדש או קיים.

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

שימוש בקבוצת נתונים עם טבלאות PDT מדורגות

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

לדוגמה, הנה חלק מקובץ מודל שמגדיר קבוצת נתונים בשם user_facts_etl וניתוח נתונים באמצעות Explore בשם user_stuff. האפשרות user_stuff ניתוח נתונים נשמרת עם קבוצת הנתונים user_facts_etl:

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

התצוגה user_stuff Explore מצטרפת לתצוגה user_facts_pdt_1 עם התצוגה user_facts_pdt_2. שתי התצוגות האלה מבוססות על PDT שמשתמש ב-user_facts_etl datagroup כטריגר של התמדה. הטבלה הנגזרת user_facts_pdt_2 מפנה לטבלה הנגזרת user_facts_pdt_1, ולכן אלה טבלאות PDT מדורגות. הנה קטע מ-LookML מקבצי התצוגה של ה-PDT האלה:

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

אם יש לכם PDTs מדורגים, אתם צריכים לוודא של-PDTs אין מדיניות לא תואמת של שמירת נתונים במטמון של קבוצת נתונים.

הכלי Looker regenerator בודק את הסטטוס ומתחיל לבנות מחדש את טבלאות ה-PDT האלה באופן הבא:

  • כברירת מחדל, הגנרטור מחדש של Looker בודק את השאילתה של קבוצת הנתונים sql_trigger כל חמש דקות (האדמין של Looker יכול לציין את המרווח הזה באמצעות ההגדרה Datagroup and PDT Maintenance Schedule בחיבור למסד הנתונים).
  • אם הערך שמוחזר על ידי השאילתה sql_trigger שונה מהתוצאה של השאילתה בבדיקה הקודמת, קבוצת הנתונים עוברת למצב מופעל. בדוגמה הזו, אם בטבלה etl_jobs יש ערך חדש ID, מופעלת קבוצת הנתונים user_facts_etl.

  • אחרי שהטריגר מופעל ב-datagroup‏ user_facts_etl, המערכת של Looker regenerator בונה מחדש את כל טבלאות ה-PDT שמשתמשות ב-datagroup (כלומר, את כל טבלאות ה-PDT שמוגדרות עם datagroup_trigger: user_facts_etl). בדוגמה הזו, המערכת של regenerator בונה מחדש את user_facts_pdt_1, ואז בונה מחדש את user_facts_pdt_2.

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

  • כשהכלי ליצירה מחדש בונה מחדש את כל ה-PDT בקבוצת הנתונים, הוא מוציא את קבוצת הנתונים user_facts_etl ממצב ההפעלה.

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

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

שיטות מומלצות לשימוש ב-PDT עם קינון עמוק

כשעובדים עם מבני PDT מוטמעים עמוק (שרשראות של PDT מדורגים עם כמה רמות של תלות), הגדרה של תקופות שמירת מטמון קצרות (לדוגמה, 15 דקות) עלולה לגרום למרוץ תהליכים שיוביל לשגיאה 409 Conflict במהלך הרענון.

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

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

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

שיתוף של קבוצות נתונים בין קובצי מודלים

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

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

יצירת קובץ של קבוצות נתונים

יוצרים קובץ .lkml נפרד שיכיל את קבוצות הנתונים. אפשר ליצור קובץ של קבוצת נתונים .lkml באותה דרך שבה יוצרים קובץ Explore נפרד .lkml.

בדוגמה הזו, השם של קובץ datagroups הוא datagroups.lkml:

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

הכללת קובץ של קבוצות נתונים בקבצים של המודל

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

לדוגמה, שני קובצי המודל הבאים include את הקובץ datagroups.lkml.

שם הקובץ הוא ecommerce.model.lkml. קבוצת הנתונים daily משמשת ברמה explore כדי שהיא תחול רק על orders Explore:

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

הקובץ הבא נקרא inventory.model.lkml. קבוצת הנתונים daily משמשת ברמה model, כך שהיא חלה על כל הניתוחים בקובץ המודל:

include: "datagroups.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}