大规模应用中的Metabase

将Metabase扩展到支持更多人员和数据库的最佳实践。

Metabase是一种可扩展、经过实战考验的软件,由数万家公司使用,以提供高质量的自我服务分析。它通过水平扩展提供高可用性,并且开箱即用:单核机器配备4GB内存即可将Metabase扩展到数百用户。

A single Metabase instance connected to multiple databases, as well as to its application database, which stores questions, dashboards, and other data specific to Metabase. You can easily add more Metabase instances as you grow.

本文提供了高级指导和建议,介绍了如何随着用户和数据源数量的增加,使Metabase在生产环境中运行顺畅。每个数据系统都是不同的,所以我们只能从高层次上讨论扩展策略,但你应该能够将这些策略应用到您特定的环境和用法中。

影响Metabase性能和可用性的因素

Metabase在垂直和水平方向上都具有良好的扩展性,但它只是您数据仓库的一个组件,系统的整体性能将取决于系统的组成和您的使用模式。影响您使用Metabase体验的主要因素包括:

  • 连接到Metabase的数据库数量。
  • 每个数据库中的表数量。
  • 您数据仓库的效率。
  • 仪表板中的问题数量。

例如,如果您需要运行一个查询,而您的数据库(们)需要30分钟才能完成,那么无论您运行多少个Metabase实例,这都需要30分钟。解决方案是重新评估您对那些数据的需求(您真的每次都需要所有这些信息吗?)或者找到改进数据库性能的方法,比如重新组织、索引或缓存您的数据。

数据库和表的数量也可能影响客户端性能,但这仅适用于大规模情况,例如您正在管理数百个数据库和/或数千个表,因为元数据本身可能需要大量查询。为了帮助即使在这样的大规模下也能保持性能流畅,您可以在需要时才管理Metabase与连接的数据库同步元数据。

现在让我们确保您的Metabase应用程序已经很好地调整以进行扩展。

垂直扩展

垂直扩展是一种简单粗暴的方法。给Metabase更多的核心和内存,它就会有更多的资源来做其工作。如果您遇到与应用程序本身相关的性能问题(即与您的数据库的广度和规模无关),在更强大的机器上运行Metabase可以改善性能。

对于每个20个并发用户,大致需要1个CPU核心和1GB的RAM

Metabase已经是高效的。起初,单核机器配2GB RAM对于单用户或小型团队来说应该已经足够了。

何时添加更多内存和核心:如果您看到您的服务器持续使用超过80%的当前资源(内存或计算)。

Metabase应用程序数据库应该对任何操作(不包括Metabase连接的数据仓库的响应时间)在不到一秒内做出响应。

具有4-8GB内存的机器可以处理数百个用户,如果需要,可以增加核心数和内存GB。

虽然添加更多核心和内存可能有效,但您通常最好使用水平扩展来支持更多用户。原因是每个Metabase实例都内置了数据库连接限制,以防止实例因请求而压垮您的数据仓库。您可以增加实例可用的连接数,但我们仍然建议使用多个实例。

水平扩展(推荐)

在增加运行 Metabase 的服务器大小而不是水平扩展时,涉及启动更多服务器,每个服务器都运行 Metabase,并将它们连接到相同的应用数据库。这样,您可以在负载均衡器的配合下运行多个 Metabase 实例以引导流量到这些实例。Metabase 默认支持水平扩展,因此您无需进行任何特殊配置即可运行多个 Metabase 实例。当 Metabase 服务器连接到现有的应用数据库时,它将将自己识别为集群的一部分。

水平扩展的主要用例是提高可靠性(也称为“高可用性”),但水平扩展也可以提高多用户性能。当负载均衡时,一个高流量、CPU 密集型的 Metabase 实例在部分流量被引导到其他实例时将表现得更好(更快),因为 CPU 负载将在多台机器之间分布。

Metabase 随附一个本地 H2 数据库 来存储您的应用程序数据(您所有的查询、仪表板、日志和其他 Metabase 数据),但在生产环境中运行时,您应升级到在单独服务器上运行的类似 PostgreSQL 的关系数据库。实际上,在水平扩展时,您必须使用在单独服务器上运行的关系数据库来存储应用程序数据。这样,所有 Metabase 实例都可以共享一个公共数据库。我们建议所有生产实例都使用单独服务器上的外部数据库,即使您只运行一个 Metabase 实例,外部数据库也不是水平扩展的额外成本。

Metabase 使用外部 应用数据库 来存储用户会话数据,因此人们不必担心在 Metabase 的一个或所有实例出现故障时丢失保存的工作,管理员也不必配置粘性会话以确保人们连接到正确的 Metabase 实例。负载均衡器将引导人们到可用的实例,以便他们可以继续工作。

利用基于时间的水平扩展

一些客户根据一天中的时间调整 Metabase 实例的数量。例如,一些公司会在早上启动多个 Metabase 实例以处理人们登录并运行晨间仪表板时的流量激增,然后在下午(或晚上,或周末)关闭这些实例以节省云成本。

对于类似 KubernetesGoogle Cloud Platform 的环境,您需要参考每个系统的相应文档来设置类似的自动缩放规则。

简单的负载均衡

负载均衡器将流量引导到多个 Metabase 实例,以确保每个请求都获得最快的响应。如果一个 Metabase 实例暂时出现故障,负载均衡器会将请求引导到另一个可用的实例。

使用 Metabase 设置负载均衡器很简单。Metabase 的 API 提供了一个健康检查端点 /api/health,负载均衡器可以调用它以确定 Metabase 实例是否处于运行状态并对请求做出响应。如果实例是健康的,该端点将返回 HTTP 状态码 200 OK。否则,负载均衡器将知道将请求引导到另一个实例。

数据仓库调优

构建数据仓库超出了本文的范围,但您应该知道,在Metabase中,您的查询速度只能与数据库返回数据的速度一样快。如果您的问题需要大量数据,而数据库检索这些数据需要很长时间,那么这些查询时间将会影响您的体验,无论Metabase有多快。

以下是一些提高数据仓库性能的方法

  • 以预见人们将提出的问题的方式来组织数据。 识别您的使用模式,以使数据存储易于为组织中常见的问题返回结果。编写ETL来创建新的表,将来自多个来源的常用查询数据组合在一起。
  • 调整您的数据库。 阅读您数据库的文档,了解如何通过索引、缓存和其他优化来提高其性能。
  • 过滤您的数据。 鼓励人们在提问时过滤数据。他们还应该利用Metabase的数据探索工具(包括记录预览),以便他们只查询与试图回答的问题相关的数据。
  • 决定是否使用数据库或数据仓库。 人们经常使用MySQL或PostgreSQL等事务数据库开始使用Metabase。虽然这些数据库扩展得相当好,但它们通常没有针对Metabase将使用的分析查询类型进行优化。当达到一定规模时,像summax这样的操作可能会减慢。随着分析采用的增长,您可能需要探索像Amazon Redshift、Google BigQuery或Snowflake这样的专用数据仓库。

Metabase应用程序最佳实践

以下是一些策略,可以帮助您充分利用Metabase应用程序

只请求您需要的数據

如果人们运行大量返回大量记录的查询,那么Metabase的快速将无关紧要:用户的收据将仅以您的数据仓库能够返回请求记录的速度获得。有时人们会对仪表板进行过度设计:当带有(例如)50个问题的仪表板加载时,它会发送50个同时请求数据。根据数据库的大小,这些记录返回可能需要相当长的时间。

Example dashboard with filter widgets using data from the Sample Database included with Metabase.

但这并不是全部。Metabase不会因为您在仪表板上放入更多问题而变慢。如果您的查询不拉取大量数据,或者您的数据仓库可以在一秒内返回结果,那么50个问题将很快加载。

然而,一般来说,鼓励人们保持他们的仪表板集中。仪表板旨在讲述关于您数据的敌事,您只需用几个问题(甚至一个问题)就能讲一个好故事。利用Metabase的数据探索工具了解您的数据(例如,预览表格中记录的能力),这样您就可以仅关注回答您问题的记录。

所以请确保每个问题都是完成仪表板所必需的,并且特别关注跨时间或空间查询数据时,因为您可以通过限制问题到较短的时间段或较小的区域来过滤掉大量不必要的数据。

Example question using a pin map to visualize latitude and longitude. Geospatial data can add up quickly, slowing query times, so it

使用托管关系数据库来存储您的Metabase应用程序数据

应用程序数据库存储了您所有的问题、仪表板、收藏夹、权限以及其他与Metabase应用程序相关的数据。您可以使用关系型数据库(如PostgreSQL或MySQL)来管理应用程序数据库,但我们推荐使用如AWS RDS这样的托管解决方案。RDS将自动化备份,并使您在扩展时轻松调整存储和计算,让您无需再为此担心。

缓存您的查询

您可以通过配置缓存来存储最近提出的问题的结果,这样它们就无需重新计算。Metabase将显示结果的时间戳,如果用户想要重新运行查询,他们可以手动刷新问题的结果。缓存适合不经常更新的结果。

Enable caching to store question results

寻找瓶颈

专业版和企业版计划提供Metabase分析,以便您监控应用程序的使用情况和性能。例如,您可以查看有多少问题被提出,由谁提出,以及问题运行了多长时间,这有助于识别需要关注的任何瓶颈。

Metabase analytics

增加对应用程序数据库的最大连接数

Metabase应用程序数据库的默认连接数由环境变量MB_APPLICATION_DB_MAX_CONNECTION_POOL_SIZE指定,目前默认设置为15。如果您的使用经常消耗所有这些连接,您可以通过增加最大连接数来提高性能。或者,您可以通过水平扩展(例如,如果您添加了额外的Metabase实例,您实际上为应用程序数据库增加了15个连接)来增加连接数。

您可以通过查看日志来检查连接数,并查找类似... 应用程序数据库连接:12/15的行。在示例中,Metabase正在使用15个可用应用程序数据库连接中的12个。

增加每个数据库的最大连接数

类似地,单个Metabase实例到每个数据库的默认最大连接数也是15。这意味着每个数据库有15个,如果您将Metabase连接到两个数据库,您将最多有30个连接。

您可以通过更改环境变量MB_JDBC_DATA_WAREHOUSE_MAX_CONNECTION_POOL_SIZE来增加每个数据库的最大连接数。与应用程序数据库连接一样,您也可以通过水平扩展来增加连接数。每个额外的Metabase实例都会增加最大连接数15(或您设置的任何最大值)。有关更多信息,请参阅我们的环境变量文档

仅在需要时与数据库同步

默认情况下,Metabase每小时执行一次轻量级同步。同步不会复制任何数据。Metabase仅确保其应用程序数据库中维护的表、列和行列表与数据库中的表、列和行保持最新。

您可以通过设置这些同步的时机和频率。对于大型数据库,您可能需要考虑限制Metabase执行同步的次数,并将这些同步限制在非高峰时段,特别是如果您不经常向数据库添加新表。

You can change when Metabase syncs with your databases, which can improve performance when you

升级到Metabase的最新版本

如果您尚未升级,我们建议您升级到最新的Metabase版本以获取最新的性能改进。

通过HTTP/2使用HTTPS服务Metabase

通过HTTPS和HTTP/2服务您的Metabase实例可以提高性能,因为HTTP/1.1浏览器对每个域的并发连接限制约为6个,而HTTP/2可以在单个连接上进行复用。更多的连接不会修复慢速数据库,或线程耗尽的过载Metabase实例,但至少您会知道浏览器没有限制您的连接。

保持您的浏览器更新

Metabase是一个Web应用,可以从Firefox、Chrome、Edge和Safari等浏览器的最新版本中受益。FirefoxChromeEdgeSafari

支持的部署方式

设置Metabase有很多种方法;我们最喜欢的包括

Google Cloud PlatformMicrosoft AzureDigital Ocean和其他云服务提供商为托管您的Metabase应用提供了其他优秀选择。

托管Metabase

如果您不想处理Metabase应用的维护和运营,Metabase提供了一种托管解决方案。您仍然需要确保您的数据源性能良好,但您不再需要管理运行Metabase应用。

获取帮助

如果您仍有疑问,很可能会有人已经提出过相同的问题。请查看Metabase讨论论坛并搜索您的问题。如果您找不到解决方案,可以提交您自己的问题。

下一步:与Metabase API一起工作

Metabase API简介。

下一篇文章