home ユーザーガイド 基本情報 ヘルプセンター ドキュメンテーション コミュニティ トレーニング 認証
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
テンプレートフィルタとLiquidパラメーター

本ページの内容は、SQLとLookMLの充分な知識をすでにお持ちの方向けのトピックです。

Lookerでは、ユーザーがディメンションおよびメジャーに基づくフィルタの作成によりクエリを操作できます。この簡単な方法は多くのユースケースを満たしますが、すべての分析ニーズには対応できません。テンプレートフィルタとLiquidパラメーターにより、対応可能なユースケースが大幅に拡張されます。

SQLの視点からは、ディメンションおよびメジャーが変更できるのはクエリの最も外側のWHEREまたはHAVING句のみです。しかし、ユーザーによってはSQLの他の部分を操作したい場合もあるでしょう。テンプレートフィルタおよびLiquidパラメーターを使用することで、派生テーブルの一部調整、クエリ対象となるデータベーステーブルの調整、多目的なディメンションやフィルタの作成を始めとする多数の機能を実現できます。

テンプレートフィルタおよびLiquidパラメーターでは、SQLクエリへのユーザー入力の挿入にLiquidテンプレート作成言語を使用します。まず、LookMLパラメーターを使用してユーザーの操作対象となるフィールドを作成します。次に、ユーザー入力をSQLクエリへ挿入するLiquid変数を使用します。

テンプレートフィルタおよび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_idlifetime_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パラメーターを使用した動的メジャーの作成

pantsの販売数を合計する、フィルタされたメジャーについて考えます。

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

これは単純ですが、数十個のカテゴリがある場合、それぞれに対してメジャーを作成するのは厄介です。加えて、Exploreのユーザーエクスペリエンスが混乱する可能性があります。

代わりに、次のような動的メジャーを作成できます。

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

詳細なステップ別の解説は以下を参照してください。

基本的な使用方法

ステップ1:ユーザーの操作対象の作成

いずれの例でも、これらのフィールドは、ユーザーのフィールドピッカーの[Filter-Only Fields]セクションに表示されます。

filterparameterの両フィールドには一連の子パラメーターを入力して、操作方法をカスタマイズできます。一覧についてはフィールドパラメーターのドキュメンテーションページを参照してください。parameterフィールドについてはオプションが2つあります。

1つ目は、parameterフィールドには、unquotedという特別なタイプを使用できる点です。

parameter: table_name { type: unquoted }

このタイプを使用することで、ストリングのように引用符で囲まなくとも値をSQLに挿入できます。テーブル名などのSQL値を挿入する必要があるときなどに使用できます。

2つ目は、parameterフィールドには、挿入する値にユーザーフレンドリーな名前を関連付けることのできるallowed valuesというオプションがある点です。次に例を示します。

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" } }

ステップ2:ユーザー入力の適用

2番目のステップでは、Liquidを使用して、希望に応じてテンプレートフィルタやLiquidパラメーターを追加します。

テンプレートフィルタ

テンプレートフィルタの構文は次のとおりです。

{% condition filter_name %} sql_or_lookml_reference {% endcondition %}

上記の例では次を使用しています。

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

Liquidタグとそれらの間に記述するSQLの相互作用を理解することが重要です。テンプレートフィルタタグは常に論理式へ変換されます。例えば、ユーザーがorder_regionフィルタに”Northeast”と入力した場合、Lookerはこれらのタグをorder.region = 'Northeast'に変換します。言い換えると、Lookerがユーザー入力を理解して適切な論理式を生成します。

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 %}

例えば、上記ステップ1の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パラメーターを使用します。

Top