Looker の full_suggestions と bypass_suggest_restrictions の紹介
1. はじめに
こんにちは、クラウドエース データソリューション部 の尾杉です。
今回は、 Technical Tips & Tricks で挙がっている Looker の full_suggestions と bypass_suggest_restrictions について紹介します。
full_suggestions
と bypass_suggest_restrictions
は、 Looker のフィルタ候補値を制御する機能になります。これらは、sql_always_where
, always_join
および access_filter
(以下、パラメータ
とする) と組み合わせることで、フィルタ候補値を取得する Filter Suggestion クエリ (以下、サジェストクエリとする) の実行先を制御します。
本記事は、full_suggestions
と bypass_suggest_restrictions
、パラメータ
を組み合わせたときのサジェストクエリの挙動を理解したい方向けです。
またLooker の基本的な使用方法を把握している方向けの説明になりますので、基本的な操作方法等の説明がないことについてご了承ください。
時間がない方向けのまとめ
サジェストクエリの挙動
下表は、次章以降で実施した検証結果です。
full_suggestions
と bypass_suggest_restrictions
、パラメータ
を組み合わせたとき、サジェストクエリが何に対して実行されているのかをまとめています。
条件 | full_suggestions | パラメータ | bypass_suggest_restrictions | クエリ実行対象 |
---|---|---|---|---|
条件1 | no | あり | no | - |
条件2 | no | あり | yes | view |
条件3 | no | なし | no | view |
条件4 | no | なし | yes | view |
条件5 | yes | あり | no | Explore |
条件6 | yes | あり | yes | Explore |
条件7 | yes | なし | no | Explore |
条件8 | yes | なし | yes | Explore |
条件9 | なし | あり | no | Explore |
条件10 | なし | あり | yes | view |
条件11 | なし | なし | no | view |
条件12 | なし | なし | yes | view |
2. full_suggestions とは
full_suggestions
は、 Looker のフィルタ候補値を制御する機能になります。
以下のルールにもとづき サジェストクエリの実行先を制御します。
-
full_suggestions: yes
の場合、サジェストクエリが Explore に対して実行される -
full_suggestions: no
の場合、サジェストクエリが view に対して実行される -
full_suggestions
を定義しない場合、full_suggestions: no
の扱いになりサジェストクエリが view に対して実行される
上記の full_suggestions: no
の条件には注意が必要です。この条件が適用されるのは、パラメータ
が定義されていないシンプルな Explore の場合に限ります。
パラメータ
が定義された Explore の場合、full_suggestions: no
と定義した時とデフォルト (full_suggestions: no
と定義していない) の時で、サジェストクエリの実行先が異なります。その場合、以下のルールにもとづきサジェストクエリの実行先を制御します。
-
full_suggestions: no
と定義した場合、サジェストクエリは実行されない - デフォルトの場合、
full_suggestions: no
からyes
に変わり、サジェストクエリが Explore に対して実行される
3. bypass_suggest_restrictions とは
bypass_suggest_restrictions
は、パラメータ
による制御を制限し full_suggestions: no
に変えます。そのため、view に対してサジェストクエリを実行することができます。
もし、Explore で パラメータ
が定義されているとき、view に対してサジェストクエリを実行したい場合は bypass_suggest_restrictions
を利用すると可能ということです。
4. 検証
本章では、full_suggestions
と bypass_suggest_restrictions
、パラメータ
を組み合わせたとき、何に対してサジェストクエリが実行されているのか調査しました。
詳細な検証内容については、次節に記載します。
4.1. 検証内容
下表に示す12パターンの条件で、何に対してサジェストクエリが実行されているのか検証します。
条件 | full_suggestions | パラメータ | bypass_suggest_restrictions |
---|---|---|---|
条件1 | no | あり | no |
条件2 | no | あり | yes |
条件3 | no | なし | no |
条件4 | no | なし | yes |
条件5 | yes | あり | no |
条件6 | yes | あり | yes |
条件7 | yes | なし | no |
条件8 | yes | なし | yes |
条件9 | なし | あり | no |
条件10 | なし | あり | yes |
条件11 | なし | なし | no |
条件12 | なし | なし | yes |
以下、サジェストクエリ実行先の確認手順です。
(次章に検証用コードを記載するので詳しくはそちらを参考にしてください)
- Explore 画面でフィルタに
test_m.nm3_m
を選択し、フィルタ候補値を表示する
- 「管理者 > データベース > クエリ」画面に遷移し、サジェストクエリの内容を確認する
- サジェストクエリの内容から何に対してクエリを実行しているのか判断する
4.2. 検証に使用したコード
以下、本検証に使用した view と model です。
full_suggestions
, bypass_suggest_restrictions
, パラメータ
は、検証条件によって適宜 yes/no 、コメントアウト/アンコメントを行います。
view 検証用コード
view: test_m {
derived_table: {
sql:
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "A" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "B" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "C" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "D" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "E" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "full time" AS nm2_m, "F" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "contract" AS nm2_m, "G" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "contract" AS nm2_m, "H" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "contract" AS nm2_m, "I" AS nm3_m
UNION ALL
SELECT "role1" AS nm1_m, "contract" AS nm2_m, "J" AS nm3_m
;;
}
dimension: nm1_m {
type: string
sql: ${TABLE}.nm1_m ;;
}
dimension: nm2_m {
type: string
sql: ${TABLE}.nm2_m ;;
}
dimension: nm3_m {
type: string
sql: ${TABLE}.nm3_m ;;
suggest_persist_for: "0 seconds" # サジェストクエリのキャッシュを効かないようにするため
full_suggestions: yes # 適宜 yes or no, コメント/アンコメント する
bypass_suggest_restrictions: no # 適宜 yes or no する
}
}
view: test_t {
derived_table: {
sql:
SELECT "role1" AS nm1_t, "full time" AS nm2_t, "A" AS nm3_t, 1 AS num_t
UNION ALL
SELECT "role1" AS nm1_t, "full time" AS nm2_t, "B" AS nm3_t, 2 AS num_t
UNION ALL
SELECT "role1" AS nm1_t, "contract" AS nm2_t, "G" AS nm3_t, 3 AS num_t
UNION ALL
SELECT "role1" AS nm1_t, "contract" AS nm2_t, "J" AS nm3_t, 4 AS num_t
;;
}
dimension: pk {
primary_key: yes
sql: CONCAT(${nm3_t}) ;;
}
dimension: nm1_t {
type: string
sql: ${TABLE}.nm1_t ;;
}
dimension: nm2_t {
type: string
sql: ${TABLE}.nm2_t ;;
}
dimension: nm3_t {
type: string
sql: ${TABLE}.nm3_t ;;
}
measure: num_t {
type: sum
sql: ${TABLE}.num_t ;;
}
}
model 検証用コード
connection: "XXXXX"
include: "/views/*.view.lkml"
explore: test_t {
label: "zenn test"
join: test_m {
type: left_outer
relationship: many_to_one
sql_on: ${test_m.nm3_m} = ${test_t.nm3_t} ;;
}
# sql_always_where: ${test_m.nm3_m} = "A" ;; # 適宜 コメントアウト/アンコメント する
}
4.3. 検証結果
下表は検証結果をまとめたものです。
条件 | full_suggestions | パラメータ | bypass_suggest_restrictions | クエリ実行対象 |
---|---|---|---|---|
条件1 | no | あり | no | - |
条件2 | no | あり | yes | view |
条件3 | no | なし | no | view |
条件4 | no | なし | yes | view |
条件5 | yes | あり | no | Explore |
条件6 | yes | あり | yes | Explore |
条件7 | yes | なし | no | Explore |
条件8 | yes | なし | yes | Explore |
条件9 | なし | あり | no | Explore |
条件10 | なし | あり | yes | view |
条件11 | なし | なし | no | view |
条件12 | なし | なし | yes | view |
条件1 では、サジェストクエリが実行されませんでした。これは、章「2. full_suggestions とは」に記載した full_suggestions: no
と パラメータ: あり
が定義された場合、サジェストクエリを実行しない挙動になります。
条件6, 8 より、サジェストクエリを作成する際は full_suggestions
-> bypass_suggest_restrictions
のような優先度があることが分かりました。
full_suggestions
が定義された場合は、bypass_suggest_restrictions
より優先されて実行されます。
5. おわりに
今回は Looker の full_suggestions
と bypass_suggest_restrictions
について紹介しました。
full_suggestions
、bypass_suggest_restrictions
を上手に使えれば、例えば view に対してサジェストクエリを投げることで Explore にクエリを投げるよりもクエリパフォーマンスが改善できたり、パラメータ
で絞り込んでる値をフィルタ候補値に表示したい要件があったときなどに対応できます。
本記事が full_suggestions
、bypass_suggest_restrictions
の挙動を把握するのにお役に立てれば幸いです。
Discussion