Looker のドキュメントを表示していることに注意してください。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

フィルタの候補に関する一般的な問題のトラブルシューティング

フィルタ候補は、Looker の強力なツールです。フィルタの候補が想定どおりに動作しない場合に効果的にトラブルシューティングできるように、ソースとその仕組みを理解しておくことが重要です。このページでは、フィルタ候補の仕組み、間違いの理由、表示されない理由について説明します。

フィルタの候補の仕組み

フィルタの候補を使用すると、ユーザーがフィルタに値を入力する際の時間を短縮し、データに存在するオプションを確実に選択できます。ユーザーがフィルタボックスを選択すると、フィールドの下に候補のリストが表示されます。この例では、[Orders] Explore で [Status] フィールドのフィルタのボックスを選択すると、プルダウンリストでオプションとして [cancelled]、[complete]、[pending] の値が表示されます。

提案リストはどこから取得されますか？

Looker はデータベースに対して SELECT distinct <field> クエリを実行し、そのフィールドで可能なすべてのオプションを取得します。クエリは次の SQL のようになります。

SELECT DISTINCT <field_name>
FROM <table>
WHERE (<field_name> LIKE '%' OR <field_name> LIKE '% %')
GROUP BY 1
ORDER BY 1
LIMIT 1000

ユーザーがフィルタボックスに文字を入力すると、Looker が WHERE 句に適切な条件を置き換えて、結果をフィルタします。その後、Looker は、それらの結果のうち最初の 100 件をフィルタ候補に表示します。

表示される候補を変更できますか？

デベロッパーは、さまざまな LookML パラメータを使用して、表示される候補を変更およびカスタマイズできます。詳しくは、フィルタ候補の変更に関するドキュメントページをご覧ください。

候補はキャッシュに保存されますか？

デフォルトでは、Looker はクエリ結果を 1 時間キャッシュに保存します。suggest_persist_for LookML パラメータを使用して、フィルタ候補のキャッシュの長さをカスタマイズできます。suggest_persist_for パラメータのデフォルト値は「6 時間」です。候補には独自のキャッシュがあり、Explore ページから手動でクリアできません。候補のキャッシュを消去する必要がある場合は、次の方法を使用できます。

Explore が sql_trigger でデータグループを使用している場合は、Looker の [管理] パネルの [データグループ] ページで手動でデータグループ全体のキャッシュをリセットできますが、これによって、そのデータグループを使用して永続化されているすべてのクエリのキャッシュが更新されます。
フィールドレベルで suggest_persist_for パラメータを使用して「0 秒」に設定すると、そのフィールドのフィルタ候補のキャッシュを無効化できます。
キャッシュはすべてのユーザーに対してグローバルです。1 人のユーザーが提案のキャッシュを更新すると、他のユーザーに表示される結果に影響します。

フィルタの候補が間違っているのはなぜですか？

フィルタ候補が表示される仕組みを理解したところで、フィルタの候補が間違っている理由を判断できるようになりました。最も一般的な原因は、フィルタの候補がキャッシュに保存されてから間違った結果が検出されるまでの間に、データが変更されたか、更新されたことです。

たとえば、ユーザー A が朝最初に Explore を実行したとします。ユーザー A が、候補のプルダウンリストからいくつかのフィルタ値を選択します。データベースの ETL 処理は 30 分程度で完了します。次に、ユーザー B がユーザー A が以前に実行したのと同じ Explore を表示します。ユーザー B が、フィルタの候補が間違っている理由について疑問を抱きます。不一致の理由は、キャッシュに保存された候補クエリがデータベースの新しく完了した ETL プロセスで更新されていないため、予期しない結果が表示されたことです。

この場合は、前述の候補はキャッシュされますか？で説明されている方法を使用して、候補のキャッシュを更新できます。

フィルタの候補が表示されない理由

フィルタの候補が表示されない理由はいくつか考えられます。次のトラブルシューティング手順では、考えられる原因について説明します。

フィルタタイプを確認する。
制限する候補に access_filter または sql_always_where があるかどうかを確認する。
suggest_dimension parameter があるかどうかを確認する。
ユーザーがフィルタでテキストを選択または入力したときに、候補を読み込もうとしているかどうかを確認する。
Chrome ネットワークのコンソールを確認する。
Looker が実行しようとしている候補クエリのエビデンスを見つけます。

フィルタタイプを確認する

LookML ダッシュボードフィルタの場合は、フィルタタイプが [フィールド] であることを確認します。他のフィルタタイプでは、候補が表示されません。

LookML 定義でフィルタフィールドが type: string であることを確認します。number タイプのフィールドに対するフィルタでは、候補が入力されません。
Matches（Advanced）フィルタかどうか。Matches（Advanced）フィルタには Looker 式が必要になるため、候補は表示されません。

制限する候補に `access_filter` または `sql_always_where` があるかどうかを確認する

通常、sql_always_where または access_filter が使用されている場合、フィルタ候補はその Explore に限定されます。これにより、ユーザーがアクセスできないフィルタ候補が表示されなくなります。特定のディメンションフィールドまたはフィルタフィールドに機密情報を示す値がないことが確実な場合は、bypass_suggest_restrictions を使用してフィルタの候補を再び有効にできます。

`suggest_dimension parameter` があるかどうかを確認する

suggest_dimension パラメータを使用している場合、提案されたディメンションが、そのディメンションのビューが Explore のベースビューとして定義されている Explore で参照されている場合を除き、フィルタの候補が入力されません。

提案されたディメンションのビューがベースビューではない Explore の場合は、suggest_explore パラメータを追加し、そのビューがベースビューである Explore を参照します。

フィルタでテキストを選択または入力したときに、候補を読み込もうとしているかどうかを確認する

フィルタボックスにテキストを選択または入力したときに、Looker が候補の読み込みを試行するかどうかを確認します。Looker のフィルタボックスの右側に読み込み中の円アイコンが表示されます。

対応していない場合、Looker は候補を入力しようとしていません。最初の手順で説明されている条件が満たされ、field、view、または LookML の Explore レベル（sql_always_where または access_filter）で候補がオフになっていないことを確認してください。Hadoop 言語は、デフォルトですべてのビューファイルに suggestions: no を追加します。

提案を読み込もうとしている場合は、Chrome ネットワークコンソールの確認に進みます。

Chrome ネットワークのコンソールを確認する

Chrome ネットワークコンソールは、クエリ自体でエラーをハイライト表示する場合や、キャッシュから返された結果があることを示す場合があります。

ショートカット Ctrl+Shift+J キー（Windows）または Command+Option+J キー（Mac）を使用するか、ブラウザの上部にある Chrome オプションバーで [View] > [Develop] > [Developer tools] を選択して、ブラウザで [Network] タブを開きます。
Look、Explore、ダッシュボードのフィルタボックスで選択します。
デベロッパーツールパネルに、フィルタ候補のリクエストが表示されます。このリクエストを選択すると詳細が表示されます。
このヘッダーは、候補値を取得するために Looker が行う内部 API リクエストを表示します。この例では、Looker が次の API リクエストを作成しているとします。ここで、<yourinstance> はインスタンスの URL を表します。
```
<yourinstance>/api/internal/models/the_look/views/order_items/fields/users.state/suggestions?term=
```
API リクエストで、/models/ の後にリストされているモデルが存在することを確認します。この例では、モデルは the_look です。
URL に /views/ と表示されていますが、これはフィールドの取得元である Explore を示しています。/views/ の後に表示される Explore が存在することを確認します。この例では、Explore は order_items です。
/fields/ の後に表示されるフィールドが存在することを確認します。この例では、フィールドは users.state です。

この API リクエストに対するレスポンスには、正確なエラーメッセージが表示されます。たとえば、候補のステータスコードは [404 Not Found] です。

詳細については、このリクエストのレスポンスを選択してください。

この場合、リクエストへのレスポンスに基づいてフィールドが見つからないため、候補が失敗したことがわかります。

{"class":"FieldNotFound","text":"Field not found."}

エラーはないが、想定どおりの候補がない場合は、候補のクエリがキャッシュから pull されているかを確認します（ネットワークコンソールの cache: true）。これは、候補を提供しているディメンションで suggest_persist_for パラメータを使用して、キャッシュを無効にする必要があることを示しています。

Looker が実行しようとしている候補クエリのエビデンスを見つける

Looker の [Admin] パネルで [Queries] ページを確認して、フィルタを生成しているクエリ（[Queries] ページの [Source] フィールドに、[Filter Suggestion] と表示される）によってエラーが生成されないことを確認します。クエリの [詳細] ボタンを選択し、[SQL Runner で開く] オプションを選択します。SQL が構文的に正しいことを確認します。フィールド名の欠落や誤った特殊文字などの異常が見つかった場合は、Liquid パラメータまたはテンプレートフィルタを使用していないことを確認します。

クエリを実行するためにテンプレート化されたフィルタの入力が必要な場合、フィルタの候補は表示されません。
クエリで default_value を指定してパラメータを使用する場合、その値がフィルタ候補クエリに挿入されます。このシナリオでは、フィルタ候補クエリがユーザー入力に基づいて動的に更新されることはありません。デフォルト値によっては、これによりフィルタ候補が何も表示されないか、間違ったフィルタ候補が表示されます。代わりに、ダッシュボードでリンクされたフィルタを使用することを検討してください。