构建模型

为了让非技术人士能够直观地提出关于你的数据的问题，最宝贵的事情之一就是将你的数据整理成易于提问的格式。

数据通常很混乱，尤其是对于初创公司来说。或者甚至不是混乱的：它可能是高度规范化、优化于交易而非分析的数据。这意味着你可能有一个包含客户数据的数据库，这些数据分布在许多表中，这使得那些还不熟悉数据库的人很难找到他们想要的信息（而且假设他们甚至知道如何进行连接）。

模型作为构建块

为了使你的数据对你的团队更直观，在 Metabase 中，你可以创建派生数据集，称为 模型，它可以从不同的表中收集数据。它们建立在 Metabase 问题的结果之上，你可以添加自定义的计算列，并使用元数据注释所有列，以便人们可以将数据作为查询构建器的起点进行操作。

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

为什么不在数据库中运行 ETL 作业来创建模型呢？

Metabase 模型和 ETLs 不是相互排斥的。你可以（而且应该）利用两者。以下是一些原因

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

2. 模型是灵活的。你可以随时创建模型、修改它们、切换它们——它们基本上只是查询+描述。它们在 Metabase 中是一等公民，因此你可以将它们组织成集合、链接到它们，并将它们作为新问题的起点，或者将它们添加到仪表板中。你还可以存档它们，或将它们改回已保存的问题（尽管你会丢失你的元数据）。相比之下，ETLs 是一项工作量更大的工作，通常由了解你的数据管道、知道如何编写代码、安排作业的人进行。有一些优秀的工具可以帮助你编写 ETLs，但它们通常是针对需要灵活解决方案的问题的重量级解决方案。

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

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代码中放置变量。

如果您将模型添加到仪表板中，您会注意到您无法将其任何列映射到仪表板过滤器，即使您已经为这些过滤器设置了类型。要使用模型获得相同的结果，您可以

• 创建一个不带变量的模型。
• 基于模型保存一个问题。
• 将此问题添加到仪表板。
• 向仪表板添加一个过滤器。
• 将过滤器映射到问题的适当列。

有关更多信息，请参阅仪表板过滤器。

进一步阅读

• 创建和管理模型.