构建模型

要让非技术人员能够轻松地对您的数据提出问题，最有价值的做法是将您的数据塑造成一种能使提问变得直观的形态。

数据通常可能很混乱，尤其是对于初创公司而言。或者甚至不算是混乱：它可能是高度规范化的数据，为交易而非分析进行了优化。这意味着您的数据库中关于客户的数据可能分散在大量的表中，这使得那些还不熟悉数据库的人很难找到他们需要的信息（而且这还是假设他们了解连接是如何工作的）。

作为构建模块的模型

为了让您的数据对您的团队更直观，您可以在 Metabase 中创建派生数据集，称为模型，这些模型可以从不同的表中汇总数据。它们建立在 Metabase 问题的结果之上，您可以添加自定义的计算列，并为所有列添加元数据注释，这样人们就可以在查询构建器中将其作为起点来探索数据。

如果您已经是经验丰富的 Metabase 用户，您会知道可以从已保存问题的结果构建新问题。您可以将模型视为一种特殊类型的已保存问题，但这有些低估了它们。

为什么不在您的数据库中运行一个 ETL 任务来创建模型呢？

Metabase 模型和 ETL 并非相互排斥。您可以（也应该）同时利用这两者。原因如下

1. 模型将数据建模的工具交给了了解业务领域的人。这是一件大事。是的，数据工程师对数据管道中的底层结构了解更多，但他们不一定了解特定团队面临的问题，以及这些问题的各个部分应该如何定义（例如，什么才算是活跃用户？）。您组织中的各个团队应该是定义您业务的人，他们应该能够根据团队工作方式的变化、新产品、市场变化等情况来完善这些定义。有了模型，人们就不必通过数据团队来添加新的计算列或更新定义了。此外，不同团队会有不同的定义：您的销售团队对客户的模型可能与您的市场营销或客户成功团队不同。

2. 模型是灵活的。您可以随时创建模型、修改它们、切换它们——它们基本上就是查询和描述的组合。而且它们是 Metabase 中的一等公民，因此您可以将它们组织到集合中、链接到它们，并将它们选为新问题的起点，或将它们添加到仪表盘中。您还可以归档它们，或将它们变回已保存的问题（尽管您会丢失元数据）。相比之下，ETL 的工作量要大得多，通常由了解您的数据管道、知道如何编写代码、安排任务等的人员来控制。有一些很棒的工具可以帮助您编写 ETL，但它们通常是解决需要灵活方案的问题的重量级解决方案。

3. 模型是提高数据库性能的垫脚石。在 Metabase 中试验模型后，您可以将最受欢迎的模型“提升”为数据库中的物化视图。这里的“物化”指的是编写一个 ETL 任务，在数据库中创建并定期更新一个与您的模型相匹配的表（具有相同的列集），这样每次运行查询时就不需要计算结果了；数据库可以直接像从原始数据表中那样获取结果。一旦您在数据库中物化了该表，您可以在 Metabase 中将模型的原始查询替换为简单的 SELECT * FROM materialized_model，或者直接删除该模型，将物化表视为数据库中的任何其他表。（请注意，如果您更改了模型的底层查询，您需要更新每列的元数据）。

4. 模型可以索引单个记录，并使其在 Metabase 的搜索中可用。 您可以在搜索中展示单个记录，以便查找单个记录，如客户姓名。

一个模型示例

在考虑要在模型中包含哪些列时，最好先列出您期望人们会提出的问题类型，然后向模型中添加有助于回答这些问题的列。假设我们想为一个客户建模。通常，我们可能想要定义像活跃客户这样的东西，比如在过去一个月内至少访问过我们网站一次的人，或者我们希望定义的任何其他活跃客户标准。但为了简单起见，我们将使用 Metabase 附带的示例数据库来定义一个基本客户的模型。我们预计想了解关于客户的几件事：

• 他们居住的地方，包括州和邮政编码。
• 他们的来源（他们是如何了解到我们的）。
• 他们在我们这里花费的总金额。
• 他们下了多少个订单。
• 每个订单的平均总额。

在现实生活中的模型中，您可能想回答更多的问题，这将需要更多的列来回答（比如客户的年龄，他们在网站上花费了多长时间，从购物车中添加和移除的商品，或者您认为您的团队会想提问的所有其他数据点）。模型的理念是把所有将这些数据汇集在一起的样板代码都处理掉，这样人们就可以直接开始探索他们真正感兴趣的数据。

所以这是我们使用查询构建器构建的问题

对于我们的数据，我们选择了 Orders 表，将其连接到 People 表，汇总了订单总额的总和，计算了行数，并使用自定义表达式计算了平均订单总额：= Sum([Total]) / Count。接下来我们按以下字段分组：User_ID、People.Created_At、State、Zip 和 Source。

我们保存该问题，点击问题标题以调出问题侧边栏（您可能需要刷新浏览器），然后点击模型图标（三个堆叠成三角形的积木）将问题转换为模型。

为模型添加元数据是关键

这是模型的超能力，对于使用 SQL 查询构建的模型尤其有用，因为 Metabase 不知道 SQL 查询返回的列类型。

点击模型的名称将调出模型侧边栏，这为我们提供了自定义元数据的选项。在这里，我们可以给列起更友好的名称，为列添加描述（鼠标悬停时会显示），并告诉 Metabase 该列包含什么类型的数据。

如果我们改用 SQL 查询 来创建那个相同的客户模型（见上面的一个模型示例），Metabase 将无法自动执行其通常的钻取魔法。

但是，如果我们在模型的列中添加一些元数据（即，添加到模型定义（其查询）返回的字段中），我们就可以恢复钻取菜单和所有其他的 Metabase 魔法。

例如，如果这是定义我们模型的查询

SELECT
    orders.user_id              AS id,
    people.created_at           AS join_date,
    people.state                AS state,
    people.source               AS source,
    Sum(orders.total)           AS total,
    Count(*)                    AS order_count,
    Sum(orders.total)/Count(*)  AS avg_total
FROM orders
LEFT JOIN people
   ON orders.user_id = people.id
GROUP  BY
    id,
    city,
    state,
    zip,
    source

Metabase 不会自动知道 state 或 total 或任何其他列的数据类型是什么。然而，如果我们在模型的元数据中为每个结果列手动设置类型，Metabase 就能够在图表上呈现钻取菜单，并且知道应该为该列使用哪种类型的筛选器（例如，数字筛选器的选项将不同于日期或类别的筛选器）。

模型可以在搜索中显示单个记录

模型的另一个巧妙的元数据功能是：您可以选择从模型中索引值，使它们出现在 Metabase 的搜索结果中。

在这里，我们正在打开“通过匹配此列在搜索中显示单个记录”的选项（右下角）

例如，您可以在模型中索引一个包含客户姓名的列，这样人们就可以输入像 Hudson Borer 这样的客户姓名，然后直接跳转到该客户的详细视图。

通过在模型中索引记录，您还可以对它们进行 X 射线分析。更多详情请参见关于模型的文档。

跳过 SQL 变量

这里有一个值得指出的微妙之处。如果您习惯于使用已保存的问题和 SQL 变量（如字段筛选器）来创建“模型”，以便人们可以将这些问题连接到仪表盘筛选器，那么模型在这里采取了不同的方法。模型不使用变量，因为它们不需要。一旦您告诉 Metabase 模型的列类型，您就可以从该模型开始一个问题，保存它，并能够将其连接到仪表盘筛选器。无需在您的 SQL 代码中放置变量。

如果您将一个模型添加到仪表盘，您会注意到，即使在为这些筛选器设置了类型之后，您也无法将其任何列映射到仪表盘筛选器。要使用模型获得相同的结果，您可以：

• 创建一个没有变量的模型。
• 基于该模型保存一个问题。
• 将该问题添加到仪表盘。
• 向仪表盘添加一个筛选器。
• 将筛选器映射到问题上相应的列。

更多信息，请参见仪表盘筛选器。

延伸阅读

• 创建和管理模型.