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