מסננים מבוססי-תבנית ופרמטרים של Liquid

זהו נושא מתקדם שמיועד למשתמשים שיש להם ידע טוב ב-SQL וב-LookML.

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

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

מסננים מבוססי-תבניות ופרמטרים של Liquid משתמשים בשפת התבניות Liquid כדי להוסיף קלט של משתמשים לשאילתות SQL. קודם כל, משתמשים בפרמטר LookML כדי ליצור שדה שהמשתמשים יכולים ליצור איתו אינטראקציה. לאחר מכן, משתמשים במשתנה Liquid כדי להוסיף את קלט של משתמשים לשאילתות SQL.

דוגמאות

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

יצירת טבלה נגזרת דינמית עם מסנן מבוסס-תבנית

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

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,                        -- Can be made a dimension
        SUM(sale_price) AS lifetime_spend   -- Can be made a dimension
      FROM
        order
      WHERE
        region = 'northeast'                -- Can NOT be made a dimension
      GROUP BY 1
    ;;
  }
}

בשילוב הזה של שאילתה, אפשר ליצור מאפיינים מ-customer_id ומ-lifetime_spend. עם זאת, נניח שרציתם שהמשתמש יוכל לציין את region, במקום להגדיר אותו כקבוע ל-northeast. אי אפשר לחשוף את region כמאפיין, ולכן המשתמש לא יכול לסנן אותו כרגיל.

אפשרות אחת היא להשתמש במסנן מבוסס-תבנית, שייראה כך:

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition order_region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  filter: order_region {
    type: string
  }
}

הוראות מפורטות זמינות בקטע שימוש בסיסי.

יצירת מדד דינמי באמצעות פרמטר Liquid

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

measure: pants_count {
  filters: [category: "pants"]
}

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

אפשרות אחרת היא ליצור מדד דינמי באופן הבא:

measure: category_count {
  type: sum
  sql:
    CASE
      WHEN ${category} = '{% parameter category_to_count %}'
      THEN 1
      ELSE 0
    END
  ;;
}

parameter: category_to_count {
  type: string
}

הוראות מפורטות מופיעות בקטע שימוש בסיסי.

שימוש בסיסי

שלב ראשון: יצירת תוכן שהמשתמש יכול לקיים איתו אינטראקציה

  • לפילטרים מבוססי-תבנית, מוסיפים filter.
  • לפרמטרים של Liquid, מוסיפים parameter.

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

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

קודם כול, לשדות parameter יכול להיות סוג מיוחד שנקרא unquoted:

parameter: table_name {
  type: unquoted
}

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

שנית, לשדות parameter יש אפשרות שנקראת ערכים מותרים, שמאפשרת לשייך שם ידידותי למשתמש לערך שרוצים להוסיף. לדוגמה:

  parameter: sale_price_metric_picker {
    description: "Use with the Sale Price Metric measure"
    type: unquoted
    allowed_value: {
      label: "Total Sale Price"
      value: "SUM"
    }
    allowed_value: {
      label: "Average Sale Price"
      value: "AVG"
    }
    allowed_value: {
      label: "Maximum Sale Price"
      value: "MAX"
    }
    allowed_value: {
      label: "Minimum Sale Price"
      value: "MIN"
    }
  }

שלב שני: החלת קלט של משתמשים

השלב השני הוא להשתמש ב-Liquid כדי להוסיף את המסנן או את פרמטר Liquid הרצויים.

מסננים מבוססי-תבניות

התחביר של מסננים מבוססי-תבניות הוא כזה:

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}
  • המילים condition ו-endcondition לא משתנות אף פעם.
  • מחליפים את filter_name בשם המסנן שיצרתם בשלב הראשון. אפשר גם להשתמש במאפיין אם לא יצרתם שדה של מסנן בלבד.
  • מחליפים את sql_or_lookml_reference ב-SQL או ב-LookML שצריך להגדיר כ'שווה' לקלט של המשתמש (הסבר מפורט יותר על כך מופיע בהמשך הקטע הזה). אם משתמשים ב-LookML, צריך להשתמש ב${view_name.field_name}תחביר LookML.

בדוגמה הקודמת, יצירת טבלת נתונים דינמית נגזרת עם מסנן מבוסס-תבנית, השתמשנו ב:

{% condition order_region %} order.region {% endcondition %}

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

order.region = 'Northeast'

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

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

NOT ({% condition order_region %} order.region {% endcondition %})

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

view: customer_facts {
  derived_table: {
    sql:
      SELECT
        customer_id,
        SUM(sale_price) AS lifetime_spend
      FROM
        order
      WHERE
        {% condition region %} order.region {% endcondition %}
      GROUP BY 1
    ;;
  }

  dimension: region {
    type: string
    sql: ${TABLE}.region ;;
}

פרמטרים של Liquid

התחביר של פרמטרים של Liquid נראה כך:

{% parameter parameter_name %}
  • המילה parameter אף פעם לא משתנה.
  • מחליפים את parameter_name בשם parameter שיצרתם בשלב הראשון.

לדוגמה, כדי להחיל את הקלט מהשדה parameter בשלב הראשון, אפשר ליצור מדד כזה:

  measure: sale_price_metric {
    description: "Use with the Sale Price Metric Picker filter-only field"
    type: number
    label_from_parameter: sale_price_metric_picker
    sql: {% parameter sale_price_metric_picker %}(${sale_price}) ;;
    value_format_name: usd
  }

בחירה בין מסננים מבוססי-תבניות לבין פרמטרים של Liquid

למרות שפילטרים מבוססי-תבנית ופרמטרים של Liquid דומים, יש ביניהם הבדל חשוב:

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

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