2025 年 Metabase 社区数据栈报告

我们采访了 330 多个国家/地区的 330 多个团队，了解他们如何构建和使用他们的数据栈，从工具选择到人工智能的采用。这是我们学到的。

为 2025 年打造数据栈决策的社区资源

在本报告中，我们询问了团队如何构建他们的数据栈：他们选择什么工具，面临什么挑战，以及他们对未来的计划。我们的目标是建立一个社区驱动的开源资源，帮助人们就他们的数据工具做出明智的决定，并共同塑造现代数据实践。

2025 年，我们听取了 330 多个各种规模的团队的意见——从两人初创公司到拥有数百名员工的组织——来自 15 多个不同的行业和 50 多个国家。团队分享了他们的工具选择、采用时间、满意度以及人工智能如何改变他们工作方式。我们将所有这些智慧汇编成一份报告（当然，是用 Metabase 构建的），并将其提供给社区。

如果您想直接查看完整报告，请继续。

关键要点

大多数数据团队规模很小，即使在大公司里也是如此

我们调查中的大多数公司在发展到 20-50 人时就开始构建他们的数据栈——但同样，我们调查中的大多数公司也倾向于那个规模，所以要对此持保留态度。然而，我们发现数据团队的规模变化不大——即使在拥有数百名员工的公司里，大多数数据团队也只有 1-3 人。

PostgreSQL 主导着事务处理和分析工作负载

Postgres 是最受欢迎的事务数据库和最受欢迎的分析存储。无论他们的主要关注点是什么，人们最常选择它，而且大多数考虑更换当前工具的人都在考虑它作为替代品。在我们的受访者中，它也是评级最高的事务数据库，并且在分析存储工具的前 3 名中。

50% 的团队不使用数据仓库或数据湖来存储其分析数据

我们询问的几乎所有人都将分析数据与其事务数据分开，但是——也许令人惊讶的是——大约一半的受访者没有使用专门的工具（如数据仓库或数据湖）来存储他们的分析数据。我们不会评判：我们一直认为您不需要数据仓库（除非您需要）。

拥有更大团队的大公司更有可能使用数据仓库和数据湖，这可能是因为大公司的数据需求更强烈。

ETL 和转换工具作为数据成熟度指标

大约 60% 的人使用数据摄取/ETL 工具，大约 60% 的人使用建模/转换工具——其中大多数人同时使用这两种工具。反向 ETL 也排在前面：如果您的公司有反向 ETL 的需求（并非所有公司都有），那么您很可能也在使用数据摄取和建模工具。公司也倾向于在同一时间采用这些工具。因此，如果您正处于数据之旅中，并且正在考虑使用数据摄取工具——您可能需要评估一下是否是时候添加一个建模工具了。

令我们惊讶的是

AI 的信任度与 AI 的采用度不符

几乎所有行业、角色和公司规模的人都采用了 AI 查询和代码生成。这在 2025 年当然不算什么新闻，但令人惊讶的是，考虑到近乎普遍的采用率，人们对 AI 查询结果的信任度却很低。技术角色的人倾向于不太信任 AI 的结果。

工程师最难取悦

在整个数据栈中，软件工程师和数据工程师对他们工具的评分一直较低。唯一例外的是建模/转换工具，其工具的最终用户（如产品经理）对它们的评分远低于其他工具，而处理日常工作的（数据工程师）——则对它们的评分要高得多。

单个工具不如它们的协同作用重要

人们对他们数据栈中单个工具的评价普遍高于对整个数据栈的评价。我们认为这是因为，即使拥有世界上最好的工具来处理特定任务——如果无法确保数据在数据栈中的流动顺畅透明，那也无关紧要。评分最接近整个数据栈评分的工具是数据摄取/ETL 工具，其全部目的是促进数据在数据栈中的移动。

报告背后的方法论和分析流程

您可能不会感到惊讶，我们 Metabase 的人认为 Metabase 是分析和呈现调查结果的最佳工具。

我们的调查是通过 Typeform 表格进行的，它以 CSV 文件的形式提供了结果。然后，我们将该 CSV 上传到Metabase Cloud Storage 进行分析——甚至不需要设置数据库。

数据需要一些额外的格式设置和清理——例如重新标记答案以获得更好的呈现效果，处理不同的拼写，或将不同类型分析存储的答案合并到单个列中——因此我们使用Metabase 模型来基于原始 CSV 创建一个经过清理和转换的数据集。

Metabase 具有内置的图形化查询生成器，我们使用它来构建诸如“按角色计算平均满意度”之类的查询，这些查询基于我们增强的 CSV 模型，并无需编写任何代码即可构建可视化。

这足以满足我们感兴趣的所有探索——除了一项（您能猜到是哪项吗？）。一个问题需要更复杂的查询，因此为了处理这个问题，我们对 CSV 使用了 SQL：当您将数据上传到 Metabase Cloud Storage 时，您实际上是将其放入ClickHouse 数据库，因此您可以使用 Metabase 使用 SQL 查询 CSV 中的数据。在只有一个杂项问题的情况下，我们使用了 SQL 而不是图形化查询生成器，因为我们需要使用UNION。

在 Metabase，我们对构建仪表板的最佳实践有许多强烈意见，我们明智地应用了这些意见来构建一个传达我们认为有趣的见解的仪表板，同时确保不误导数据。

我们希望仪表板在视觉上脱颖而出，因此我们定义了一个自定义调色板，并将自定义字体上传到我们的 Metabase 实例，并在仪表板上使用了它。

仪表板准备好后，我们创建了一个公共嵌入，以便人们无需 Metabase 账户即可访问仪表板，并将其 iframe 嵌入到我们的网站。

探索完整报告

您可以查看完整报告，或者，如果您想自己运行调查数据的分析，我们已经为您设置了一个存储库，其中预先加载了匿名的调查数据并启动了 Metabase，因此您可以自己探索。

让我们开始讨论吧。发布您的见解并标记我们！我们喜欢看到您的 takeaways 应用于实践。