Zenn
🐕

Looker の full_suggestions と bypass_suggest_restrictions の紹介

2024/02/13に公開
GCP
Google Cloud
Looker
記事投稿キャンペーン2024 Google Cloud
#
fullsuggestions
tech

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

以下、サジェストクエリ実行先の確認手順です。
（次章に検証用コードを記載するので詳しくはそちらを参考にしてください）

  1. Explore 画面でフィルタに test_m.nm3_m を選択し、フィルタ候補値を表示する
    1
  2. 「管理者 ＞ データベース ＞ クエリ」画面に遷移し、サジェストクエリの内容を確認する
    2
  3. サジェストクエリの内容から何に対してクエリを実行しているのか判断する

4.2. 検証に使用したコード

以下、本検証に使用した view と model です。
full_suggestions, bypass_suggest_restrictions, パラメータ は、検証条件によって適宜 yes/no 、コメントアウト/アンコメントを行います。

view 検証用コード
test_m.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 する
  }

}
test_t.view
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 検証用コード
test.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 と パラメータ: あり が定義された場合、サジェストクエリを実行しない挙動になります。

2

条件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