优化 Looker 性能

这些最佳实践反映了由经验丰富的 Looker 组成的跨职能团队分享的建议。这些洞见来自多年与 Looker 客户合作的经验，涵盖从实现到长期成功的各个阶段。这些实践适用于大多数用户和情况，但在实施时，您应做出最佳判断。

优化查询性能

您可以按照以下前端和后端提示，确保针对数据库构建和执行的查询达到最佳效果：

  • 尽可能使用 many_to_one 联接构建探索。将视图从最精细的粒度级别联接到最高细节级别 (many_to_one)，通常可提供最佳查询性能。
  • 尽可能最大程度利用缓存，并使其与您的 ETL 政策保持同步，以减少数据库查询流量。默认情况下，Looker 会将查询缓存一小时。您可以使用 persist_with 参数在探索中应用 数据组 ，从而控制缓存政策，并使 Looker 数据刷新与您的 ETL 流程同步。这样，Looker 就可以与后端数据流水线更紧密地集成，从而最大程度利用缓存，同时避免分析过时数据的风险。命名缓存政策可以应用于整个模型，也可以应用于各个探索和 永久性派生表 (PDT)。
  • 使用 Looker 的 汇总感知 功能创建汇总表或摘要表，以便 Looker 尽可能用于查询，尤其是在查询大型数据库时。您还可以利用汇总感知功能大幅提升整个信息中心的性能。如需了解详情，请参阅汇总感知教程。
  • 使用 PDT 可加快查询速度。将包含许多复杂或低效联接的探索，或包含子查询或子选择的维度转换为 PDT，以便在运行时之前预先联接视图并做好准备。
  • 如果您的 数据库方言支持增量 PDT，请配置 增量 PDT，以减少 Looker 重建 PDT 所花费的时间。
  • 避免在探索中联接 Looker 中定义的串联 主键。请改为联接视图中构成串联主键的基本字段。或者，将视图重新创建为 PDT，并在表的 SQL 定义中预定义串联主键，而不是在视图的 LookML 中预定义。
  • 使用 SQL Runner 中的“Explain”工具 进行基准评测。EXPLAIN 会生成给定 SQL 查询的数据库查询执行计划概览，让您能够检测可优化的查询组件。如需了解详情，请参阅社区帖子如何使用 EXPLAIN 优化 SQL。
  • 声明索引。您可以通过以下方式直接在 Looker 的 SQL Runner 中查看每个表的索引：点击表中的齿轮图标，然后选择 显示索引。

    最常见的可受益于索引的列是重要日期和外键。向这些列添加索引将提高几乎所有查询的性能。这也适用于 PDT。您可以适当应用 LookML 参数，例如 indexes、sort keys 和 distribution。
  • 对于硬件不足或未预配必要资源（例如 AWS）来处理大型数据集的数据库，请增加其内存、核心数和 I/O（输入/输出），以提高查询性能。

优化 Looker 服务器性能

您还可以采取措施，确保 Looker 服务器和应用以最佳状态运行：

  • 限制单个信息中心内的元素数量。没有明确的规则来定义数量，因为每个元素的设计都会受到多种因素的影响，从而影响内存消耗；不过，包含 25 个或更多图块的信息中心往往会出现性能问题。
  • 有策略地使用信息中心自动刷新功能。如果信息中心使用自动刷新功能，请确保其刷新速度不快于在后台运行的 ETL 流程。
  • 有策略地使用数据透视，并避免在信息中心图块和 Look 中过度使用数据透视。包含数据透视维度的查询会消耗更多内存。数据透视的维度越多，加载内容（探索、Look 或信息中心）时消耗的内存就越多。
  • 谨慎使用自定义字段和表计算等功能。这些功能旨在用作概念验证，以帮助您设计模型。最佳实践是在 LookML 中对任何常用计算和函数进行硬编码，这将生成要在数据库中处理的 SQL。过多的计算可能会争用 Looker 实例上的 Java 内存，导致 Looker 实例响应速度变慢。
  • 对于 合并结果查询，请尽可能使用 数据库内合并查询。数据库内合并查询会在数据库中处理，而不是在 Looker 内存中处理。
  • 当存在大量视图文件时，限制模型中包含的视图数量。在单个模型中包含所有视图可能会降低性能。如果项目中存在大量视图，请考虑仅在每个模型中包含所需的视图文件。考虑为视图文件名使用策略性命名惯例，以便在模型中包含视图组。includes 参数文档中提供了一个示例。
  • 避免在信息中心图块和 Look 中默认返回大量数据点。返回数千个数据点的查询会消耗更多内存。请尽可能通过以下方式限制数据：向信息中心、Look 和探索应用前端 过滤器，并在 LookML 级别使用 required filters、conditionally_filter 和 sql_always_where 参数。
  • 谨慎使用**所有结果**选项下载或传送查询，因为某些查询可能非常大，在处理时可能会使 Looker 服务器不堪重负。
  • 了解连接性能对整个 Looker 实例的影响。Looker 使用共享资源来处理来自所有数据库连接的查询。这些资源包括 Kubernetes pod、查询队列和线程池。由于这种共享基础架构，单个速度较慢或过载的数据库连接可能会对所有其他连接的查询性能产生负面影响。如果您发现性能普遍下降，请调查所有数据库连接的运行状况，而不仅仅是与速度较慢的信息中心或探索直接相关的连接。

如需获得更多帮助来确定性能问题的来源，请查看性能概览最佳实践页面。