排查常见的过滤器建议问题

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

过滤器建议的工作原理是什么？

当用户在过滤条件中输入值时，过滤条件建议可以节省时间，并确保用户选择数据中存在的选项。用户选择过滤条件框后，该字段下方会显示建议列表。在此示例中，从 Orders（订单）探索中，选择 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 会将查询结果缓存一小时。您可以使用 suggest_persist_for LookML 参数自定义过滤器建议的缓存长度。suggest_persist_for 参数的默认值为“6 小时”。建议有自己的缓存，无法从“探索”页面中手动清除。如果您需要清除缓存以获取建议，可以采用以下做法：

  • 如果探索是使用包含 sql_trigger 的数据组缓存的，您可以在 Looker 管理面板的数据组页面中手动重置整个数据组的缓存，但此操作会刷新使用该数据组保留的所有查询的缓存。
  • 您可以在字段级别使用 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 信息中心过滤条件，请确保过滤条件类型为 Field。其他过滤条件类型不会填充建议。

检查是否存在 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)，或者从浏览器顶部的 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 参数）。

查找 Looker 尝试运行的建议查询的证据

您可以查看 Looker 管理面板中的查询页面，确保生成过滤条件的查询（查询页面上的来源字段将显示过滤条件建议）不会生成错误。选择查询的详细信息按钮，然后选择 在 SQL Runner 中打开选项。验证 SQL 的语法是否正确。如果您发现某些异常情况，例如缺少字段名称或特殊字符有误，请检查您是否使用了 Liquid 参数或模板化过滤器。

  • 如果查询需要模板化过滤条件输入内容才能运行，系统不会填充任何过滤条件建议。
  • 如果查询使用包含 default_value 的参数，该值将插入过滤器建议查询中。在这种情况下，过滤器建议查询不会根据用户输入动态更新。这可能会导致系统不显示过滤条件建议，也可能造成过滤条件建议有误，具体取决于默认值。请考虑改用信息中心内关联的过滤条件。