加快仪表盘的速度

如何让您的仪表板加载更快。

关于仪表板性能,主要有四种方法可以使仪表板加载更快:

An example dashboard with three filter widgets that uses the Sample Database included with Metabase.

以下是关于如何让您的仪表板加载更快的一些通用指导。这些指导的大部分将集中在第三点,即如何组织数据以预设数据最常用于回答的常见问题。

“过早优化是万恶之源”的常见警告也适用。我们的建议假定您已经探索数据一段时间,并从数据产生的见解中获得了实质性收益。只有到那时,您才应该问:“如何让这个仪表板加载更快?”

减少数据请求量

这一点几乎显而易见,以至于经常被忽视,但它应该是开始的第一步。您真的需要查询的所有数据吗?即使您确实需要所有数据,您多久需要一次?

您可以通过限制查询的数据量来节省大量时间,例如在仪表板上添加默认过滤器。尤其要注意跨越时间和空间的数据:您真的需要每天查看上个季度的数据吗?或者您真的需要每个国家/地区的每笔交易吗?

即使您_确实_需要知道这些信息,您每天都需要吗?您可以将该问题移到通常每周或每月才查看的另一个仪表板吗?

在探索数据集时,我们应该对所有数据保持开放,但一旦我们确定了组织需要做出的决策类型以及我们需要哪些数据来为这些决策提供信息,我们就应该毫不留情地排除那些不能显著改善我们分析的数据。

缓存问题答案

如果数据已加载,您无需等待。管理员可以设置 Metabase 来缓存查询结果,这将存储问题的答案。如果您有一组仪表板,每个人在早上打开电脑时都会运行,那么请提前运行该仪表板,仪表板中的问题将使用保存的结果在后续运行中加载,只需几秒钟。人们可以选择刷新数据,但通常这是不必要的,因为大多数情况下,人们只需要查看前一天及更早的数据。

管理员可以在“管理面板”的“性能”选项卡中配置缓存规则。您可以选择将缓存保留数小时、使用固定计划使缓存失效,或使用查询的平均执行时间来确定缓存结果的时长。

Enable caching to store the results of queries that take a long time to run.

专业版和企业版计划中,您还可以为单个仪表板和问题设置特定的缓存策略。

您可以使用 Metabase 的使用分析来确定人们通常何时运行各种查询,然后使用Metabase 的 API 创建脚本,以编程方式提前运行这些查询(从而缓存其结果)。这样,当人们登录并导航到他们的仪表板时,结果会在几秒钟内加载。即使不采取额外的“预热”步骤,当第一个人加载那个缓慢的查询时,它也会为其他人缓存。

组织数据以预设常见问题

您可以做的第二件最好的事情是组织数据,使其能够预测将要提出的问题,这将使您的数据库更容易检索数据。

除了下面的最后一部分,所有其他部分都假设您正在使用传统的关系型数据库,如 PostgreSQL 或 MySQL。最后一部分是关于迁移到完全不同类型的专门用于处理分析的数据库,这应该是您的最后选择,特别是对于初创公司。

为频繁查询的列创建索引

为数据库添加索引可以显著提高查询性能。但就像给书的所有内容都编制索引没有意义一样,索引也会带来一些开销,因此应策略性地使用它们。

如何策略性地使用索引?找到您查询最多的表,以及这些表中查询最频繁的列。您可以查阅您的单个数据库以获取此元数据。例如,PostgreSQL 通过其 pg_stat_statements 模块提供查询数量和性能的元数据。

请记住做一些简单的工作,询问您的 Metabase 用户哪些问题和仪表板对他们很重要,以及他们是否也遇到任何“缓慢”问题。最常需要索引的字段要么是基于时间的,要么是基于 ID 的——例如事件数据上的时间戳,或分类数据上的 ID。

另外,在专业版和企业版计划中,您可以使用 Metabase 的使用情况分析,它可以轻松查看谁正在运行哪些查询、频率以及这些查询返回记录所需的时间。

一旦您确定了要索引的表和列,请查阅您数据库的文档以了解如何设置索引(例如,这是PostgreSQL 中的索引)。

索引的设置(和删除)都很简单。以下是 CREATE INDEX 语句的基本格式

CREATE INDEX index_name ON table_name (column_name)

例如

CREATE INDEX orders_id_index ON orders (id)

尝试使用索引来查看如何提高查询性能。如果您的用户经常在单个表上使用多个过滤器,请考虑使用复合索引。

复制数据库

如果您使用数据库同时处理操作(例如,下单、更新个人资料信息等应用程序事务)和分析(例如,用于为 Metabase 仪表板提供支持的查询),请考虑创建该生产数据库的副本,用作仅用于分析的数据库。将 Metabase 连接到该副本,每晚更新副本,并让您的分析师自由查询。分析师的长时间运行查询不会干扰您生产数据库的日常操作,反之亦然。

除了让您的仪表板加载更快之外,为数据分析保留一个副本数据库也是一种好习惯,可以避免潜在的长时间运行的分析查询影响您的生产环境。

非规范化数据

在某些情况下,非规范化某些表(即,将多个表合并为一个具有更多列的更大表)可能是有意义的。您最终会存储一些冗余数据(例如,每次用户下单时都包含用户信息),但分析师无需连接多个表即可获取回答问题所需的数据。

物化视图:创建新表来存储查询结果

使用物化视图,您将把原始的非规范化数据保留在它们的表中,并创建新表(通常在非工作时间)来存储查询结果,这些查询结果以预测分析师将提出的问题的方式组合来自多个表的数据。

例如,您可能将订单和产品信息存储在不同的表中。您可以每晚创建(或更新)一个物化视图,该视图组合了这两个表中查询最频繁的列,并将该物化视图连接到 Metabase 中的问题。如果您同时使用一个数据库进行生产和分析,除了消除组合数据所需的连接过程外,您的查询将不必与这些表上的生产读写竞争。

物化视图与公共表表达式(CTE,有时称为视图)的区别在于,物化视图将其结果存储在数据库中(因此可以建立索引)。CTE 本质上是子查询,每次都会计算。它们可能会被缓存,但不会存储在数据库中。

但是,物化视图将消耗数据库中的资源,并且您必须手动更新视图(refresh materialized view [name])。

使用汇总表提前聚合数据

这里的想法是使用物化视图——甚至是一组单独的表——来创建汇总表,以最大程度地减少计算。假设您有包含一百万行的表,并且您想要聚合多个列中的数据。您可以基于一个或多个表的聚合创建物化视图,这将执行初始的(耗时的)计算。与其让仪表板在一天中多次查询和计算原始数据,不如创建查询该汇总表的问题,以获取前一天晚上计算的数据。

例如,您可以有一个包含所有订单的订单表,以及一个每晚更新并存储汇总和其他聚合数据(例如每周、每月订单总额等)的订单汇总表。如果有人想查看用于计算该聚合的单个订单,您可以使用自定义目的地将用户链接到查询原始数据的问题或仪表板。

将数据从 JSON 中提取出来并将其键放入列中

我们经常看到组织将 JSON 对象存储在像 MySQL 或 PostgreSQL 这样的关系型数据库的单个列中。通常,这些组织存储来自事件分析软件(如 SegmentAmplitude)的 JSON 有效载荷。

尽管某些数据库可以索引 JSON(例如,PostgreSQL 可以索引 JSON 二进制文件),但即使您只对对象中的单个键值对感兴趣,也仍然需要每次都获取完整的 JSON 对象。相反,请考虑从这些 JSON 对象中提取每个字段,并将这些键映射到表中的列。

考虑一个针对分析优化的数据库

如果您已完成上述所有操作,但仪表板加载时间过长仍然影响您及时做出决策的能力,那么您应该考虑使用专门用于处理分析查询的数据库。这些数据库被称为在线分析处理 (OLAP) 数据库(有时也称为数据仓库)。

PostgreSQL 和 MySQL 等传统关系型数据库旨在进行事务处理,并归类为在线事务处理 (OLTP) 数据库。这些数据库更适合用作操作数据库,例如存储 Web 或移动应用程序的数据。它们非常擅长处理以下场景:有人向您的网站提交了一条深思熟虑、相关且绝不煽动性的评论,您的应用程序向后端发出 POST 请求,后端将评论和元数据路由到数据库进行存储。OLTP 数据库可以处理大量并发事务,例如评论发布、购物车结账、个人资料更新等。

OLAP 和 OLTP 系统之间的主要区别在于,OLAP 数据库优化了对大量数据的求和、聚合和其他分析操作等分析查询,以及批量导入(通过 ETL),而 OLTP 数据库必须平衡来自数据库的大量读取与其他事务类型:小量插入、更新和删除。

OLAP 通常使用列式存储。传统的(OLTP)关系型数据库按行存储数据,而使用列式存储的数据库(不出所料)按列存储数据。这种列式存储策略在读取数据时为 OLAP 数据库带来了优势,因为查询不必筛选不相关的行。这些数据库中的数据通常组织在事实表维度表中,其中(通常是巨大的)事实表包含事件。每个事件都包含属性列表和对维度表的外键引用,维度表包含有关这些事件的信息:涉及的人员、发生的事情、产品信息等等。

Metabase 支持多种流行的数据仓库Google BigQueryAmazon RedshiftSnowflakeApache Druid(专门从事实时分析)。Metabase 还支持 Presto,它是一个查询引擎,可以与各种不同的数据存储配对,包括 Amazon S3

当您开始使用 Metabase 时,不要太担心底层数据存储。但随着数据量的增长和 Metabase 采用率的提高,请留意可能需要调查使用数据仓库的迹象。例如,Redshift 可以查询 PB 级数据,并扩展到查询 Amazon S3 中的历史数据。Snowflake 允许您随着组织的增长动态扩展计算资源。

延伸阅读

有关提高性能的更多技巧,请查看我们关于Metabase 扩展SQL 查询最佳实践的文章。

如果您已经提高了组织仪表板的性能,您可以在我们的论坛上分享您的技巧。

这有帮助吗?

感谢您的反馈!
分析师每周技巧
获取可行的见解
关于 AI 和数据的资讯,直接发送到您的收件箱
© . This site is unofficial and not affiliated with Metabase, Inc.