排查常见的滤镜建议问题

过滤条件建议是 Looker 中的一项强大工具。了解过滤条件建议的来源和运作方式至关重要，这样您才能在过滤条件建议未按预期运作时有效进行问题排查。本页介绍了过滤条件建议的运作方式、可能出错的原因以及可能无法填充的原因。

过滤条件建议功能是如何运作的？

过滤建议可节省用户在过滤器中输入值的时间，并确保用户选择的数据中存在的选项。当用户选择过滤条件框时，该字段下方会显示建议列表。在此示例中，从订单探索中选择状态字段的过滤条件对应的复选框后，系统会显示一个下拉列表，其中包含“已取消”“已完成”和“待处理”值作为选项。

此建议列表从何而来？

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 会在过滤条件建议中显示这些结果中的前 1,000 个。

我可以更改系统填充的建议吗？

开发者可以使用各种 LookML 参数来更改和自定义显示的建议。如需了解详情，请参阅更改过滤条件建议文档页面。

建议是否会缓存？

默认情况下，Looker 会将查询结果缓存 1 小时。您可以使用 suggest_persist_for LookML 参数来自定义过滤条件建议的缓存时长。suggest_persist_for 参数的默认值为“6 小时”。建议有自己的缓存，无法从“探索”页面手动清除。如果您需要清除建议的缓存，可以尝试以下方法：

• 如果探索是使用 sql_trigger 的 datagroup 进行缓存的，您可以在 Looker 管理面板的 Datagroups 页面中手动重置整个 datagroup 的缓存，但这会刷新使用该 datagroup 持久保存的所有查询的缓存。
• 您可以在字段级层使用 suggest_persist_for 参数，并将其设置为“0 秒”，以清除相应字段的过滤条件建议缓存。

  缓存对所有用户都是全局的。一位用户刷新建议缓存会影响其他用户看到的结果。

为什么过滤条件建议不正确？

现在，您已经了解了过滤条件建议的填充方式，可以确定过滤条件建议可能出错的原因。最常见的解释是，在过滤条件建议缓存的时间与发现错误结果的时间之间，数据发生了更改或更新。

例如，假设用户 A 在早上醒来后立即运行探索。用户 A 从建议下拉列表中选择了一些过滤条件值。数据库的 ETL 流程会在大约半小时后完成。然后，用户 B 查看了用户 A 之前运行的同一探索。用户 B 想知道为什么过滤条件建议不正确。出现差异的原因是，缓存的建议查询未随数据库新完成的 ETL 流程进行更新，因此显示了意外结果。

在这种情况下，您可以使用本页前面建议是否会缓存？部分中介绍的方法刷新建议缓存。

为什么过滤条件建议未填充？

过滤条件建议未填充的原因可能有多种。以下问题排查步骤重点介绍了可能的原因：

1. 检查过滤条件类型。
2. 检查是否存在 access_filter 或 sql_always_where 限制建议。
3. 检查是否存在 suggest_dimension parameter。
4. 检查用户在过滤条件中选择或输入文字时，是否尝试加载建议。
5. 检查 Chrome 网络控制台。
6. 查找 Looker 尝试运行的建议查询的证据。

检查过滤条件类型

如果这是 LookML 信息中心过滤条件，请确保过滤条件类型为字段。其他过滤条件类型不会填充建议。

• 确保过滤字段在其 LookML 定义中属于 type: string。对 number 类型字段的过滤不会填充建议。
• 是匹配（高级）过滤条件吗？“匹配（高级）”过滤条件需要使用 Looker 表达式，因此系统不会填充建议。

检查是否存在限制建议的 access_filter 或 sql_always_where

通常，当使用 sql_always_where 或 access_filter 时，系统会限制相应探索的过滤条件建议。这样可以防止用户看到无法使用的过滤条件建议。如果您确定特定维度或过滤条件字段中没有任何可能会泄露敏感信息的值，则可以使用 bypass_suggest_restrictions 重新启用过滤条件建议。

检查是否存在 suggest_dimension parameter

使用 suggest_dimension 参数时，除非在探索中引用了建议的维度，且该维度的视图被定义为探索的基本视图，否则过滤条件建议不会填充。

对于建议维度视图不是基本视图的探索，请添加 suggest_explore 参数，并引用该视图是基本视图的探索。

检查在您选择或输入过滤条件中的文字时，是否尝试加载建议

检查当您在过滤条件框中选择或输入文字时，Looker 是否会尝试加载建议。Looker 应在过滤条件框的右侧显示旋转的加载圆圈。

如果不是，则 Looker 不会尝试填充建议。检查是否满足第一步中所述的条件，并确保未在 LookML 中的 field、view 或探索级别（使用 sql_always_where 或 access_filter）停用建议。请注意，Hadoop 方言默认会在所有视图文件中添加 suggestions: no。

如果系统尝试加载建议，请继续按照说明检查 Chrome 网络控制台。

检查 Chrome 网络控制台

Chrome 网络控制台可能会突出显示查询本身存在的错误，或显示是否从缓存返回了结果。

1. 使用快捷键 Ctrl + Shift + J（在 Windows 上）或 command + option + J（在 Mac 上）在浏览器中打开“Network”标签页，或者从浏览器顶部的 Chrome 选项栏中依次选择查看 > 开发 > 开发者工具。
2. 在 Look、探索或信息中心的过滤条件框中选择。
3. 开发者工具面板应会显示过滤条件建议请求，您可以选择该请求以了解更多信息。
4. 标头将显示 Looker 为检索建议值而发出的内部 API 请求。在此示例中，假设 Looker 正在发出以下 API 请求，其中 <yourinstance> 表示您的实例的网址：

   

   <yourinstance>/api/internal/models/the_look/views/order_items/fields/users.state/suggestions?term=

5. 在 API 请求中，检查 /models/ 后列出的模型是否存在。在此示例中，模型名为 the_look。
6. 虽然网址中显示的是 /views/，但这是指该字段的来源探索。检查 /views/ 后列出的探索是否存在。在此示例中，“探索”称为 order_items。
7. 检查 /fields/ 之后列出的字段是否存在。在此示例中，该字段为 users.state。

此 API 请求的响应将显示确切的错误消息。例如，建议的状态代码为 404 Not Found：

选择相应请求的回答，即可查看更多详情。

在这种情况下，您可以看到建议失败，因为根据对请求的响应找不到相应字段：

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

如果没有错误，但也没有出现预期中的建议，请检查建议查询是否从缓存中提取数据（网络控制台中的 cache: true）- 这可能表明需要使用提供建议的维度上的 suggest_persist_for 参数来清除缓存。