优化 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 运行程序查看每个表的索引，方法是点击表中的齿轮图标，然后选择显示索引。

    最常受益于索引的列是重要日期和外键。为这些列添加索引可提升几乎所有查询的性能。这也适用于 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、查询队列和线程池。由于这种共享基础设施，单个缓慢或过载的数据库连接可能会对所有其他连接上的查询性能产生负面影响。如果您发现性能普遍下降，请调查所有数据库连接的运行状况，而不仅仅是与运行缓慢的信息中心或探索直接相关的连接。
  • 分散安排预定递送，避免同时执行作业。如果多个 Look 或信息中心安排在同一分钟（尤其是整点）运行，突发的并发查询请求可能会耗尽实例资源、导致队列深度激增，并耗尽数据库连接池。这种并发瓶颈可能会导致计划的传送和交互式探索查询在查询初始化阶段停滞。使用以下策略可防止并发瓶颈：
    • 将计划作业错开 15 分钟或 30 分钟（或非整点分钟，例如 :15、:30 或 :45），而不是将所有作业都安排在整点。
    • 尽可能使用数据组触发基于 ETL 完成情况（而非基于时间的时间表）的传送，从而避免对未刷新的数据进行不必要的查询。
    • 对运行查询或触发传送的外部脚本和自动化 API 调用进行批处理或限制。
    • 如果突发的大量查询导致实例无响应或查询无限期旋转，您可以通过重启实例来清除正在处理的任务 （对于 Looker (Google Cloud Core) 实例，请参阅重启 Looker (Google Cloud Core) 实例）。

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