优化 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 可生成指定 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 实例的响应速度变慢。
  • 当存在大量视图文件时，限制模型中包含的视图数量。在单个模型中包含所有视图可能会降低性能。如果项目中有大量视图，请考虑仅在每个模型中包含所需的视图文件。考虑为视图文件名使用战略性命名惯例，以便在模型中包含视图组。includes 参数文档中概述了一个示例。
  • 避免在信息中心图块和 Look 中默认返回大量数据点。返回数千个数据点的查询会消耗更多内存。通过以下方式尽可能限制数据：在信息中心、Look 和探索中应用前端 过滤条件，以及在 LookML 级别使用 required filters、conditionally_filter 和 sql_always_where 参数。
  • 请谨慎使用所有结果选项下载或传送查询，因为有些查询可能非常大，在处理时会使 Looker 服务器不堪重负。
  • 了解连接性能对整个 Looker 实例的影响。Looker 使用共享资源来处理来自所有数据库连接的查询。这些资源包括 Kubernetes pod、查询队列和线程池。由于这种共享的基础设施，单个缓慢或过载的数据库连接可能会对所有其他连接上的查询性能产生负面影响。如果您发现性能普遍下降，请调查所有数据库连接的健康状况，而不仅仅是与速度缓慢的信息中心或探索直接相关的连接。

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