构建模型

创建模型，为用户提供新问题的良好起始数据集。

为了让非技术人员更容易提问数据相关的问题，您能做的最有价值的事情就是将您的数据整理成易于直观提问的形状。

数据通常会很混乱，尤其是对于初创公司而言。或者甚至不是混乱：它可能是高度规范化的数据，针对事务进行了优化，而不是分析。这意味着您可能拥有一个数据库，其中关于客户的数据分散在大量的表格中，这使得尚不熟悉数据库的人难以找到他们正在寻找的信息（前提是他们甚至知道连接是如何工作的）。

模型作为构建块

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

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

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

Metabase 模型和 ETL 并非互斥。您可以（并且应该）同时利用两者。只是为了阐明原因：

模型将数据建模工具交到了解业务领域的人手中。 这非常重要。是的，数据工程师会更了解数据管道中的管道，但他们不一定知道特定团队面临的问题以及应如何定义这些问题的各个部分（例如，什么符合活跃用户的条件？）。您组织中的各个团队应该是定义您的业务的人，并且他们应该能够根据团队工作方式的变化、新产品、市场变化等来改进这些定义。有了模型，人们不必通过数据团队来添加新的计算列或更新定义。不同的团队会有不同的定义：您的销售团队可能对客户的模型与您的营销或成功团队不同。
模型非常灵活。您可以即时创建、修改、切换模型 - 它们基本上只是查询 + 描述。并且它们是 Metabase 中的一等公民，因此您可以将它们组织到集合中，链接到它们，并将它们选为新问题的起点，或将它们添加到仪表盘。您还可以存档它们，或将它们改回已保存的问题（尽管您会丢失元数据）。相比之下，ETL 的工作量要大得多，并且通常由了解您的数据管道、知道如何编写代码、安排作业等等的人员负责把关。有一些很棒的工具可以帮助您编写 ETL，但对于需要灵活解决方案的问题，它们通常是重量级的解决方案。
模型是提高数据库性能的垫脚石。在 Metabase 中试验模型后，您可以将最流行的模型“提升”为数据库中的物化视图。此处的物化意味着编写 ETL 作业以在数据库中创建并定期更新与您的模型匹配的表（具有相同的列集），以便每次运行查询时都不需要计算结果；数据库可以像从原始数据表中获取结果一样获取结果。一旦您将表物化到数据库中，您可以将 Metabase 中模型的原始查询替换为简单的 SELECT * FROM materialized_model，或者只是删除模型并将物化表像对待数据库中的任何其他表一样对待。（请注意，如果您更改模型的底层查询，则需要更新每个列的元数据）。
模型可以索引单个记录并使其在 Metabase 的搜索中可用。 您可以浮出水面单个记录以进行搜索，以便您可以查找单个记录，例如客户姓名。

模型示例

在考虑模型中包含哪些列时，最好首先列出您期望人们提出的问题类型，然后向模型添加有助于回答这些问题的列。假设我们要为客户建模。通常，我们可能想要定义类似活跃客户之类的东西，也许是过去一个月至少访问过我们网站一次的人，或者我们想要如何定义活跃客户。但为了简单起见，我们将使用 Metabase 附带的示例数据库为基本客户定义一个模型。并且我们预计想了解有关我们客户的一些信息：

他们居住在哪里，包括州和邮政编码。
他们的来源（他们如何了解我们）。
他们在我们这里总共花了多少钱。
他们下了多少订单。
每个订单的平均总额。

在实际模型中，您可能需要回答更多问题，这将需要更多列来回答（例如客户的年龄、他们在网站上花费的时间、添加到购物车和从购物车中删除的商品，或者您认为您的团队想要询问的所有其他数据点）。模型的想法是将所有将这些数据整合在一起的样板代码排除在外，以便人们可以开始摆弄他们实际感兴趣的数据。

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

The query in the query builder.

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

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

向模型添加元数据是关键

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

Renaming columns, adding descriptions, and setting metadata for each column.

单击模型名称将调出模型侧边栏，这使我们可以选择自定义元数据。在这里，我们可以为列提供更友好的名称，向列添加描述（将在悬停时显示），并告诉 Metabase 列包含的数据类型。

Hovering over a column will trigger a popup with the column description.

如果我们改为使用 *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 的搜索结果中。

在这里，我们开启了“通过与此列匹配来浮出水面搜索中的单个记录”选项（右下角）：

Indexing an entity name column in a model so that the values are searchable in Metabase

例如，您可以在模型中索引包含客户姓名的列，以便用户可以输入像 Hudson Borer 这样的客户，并直接跳转到该客户的详细视图。

通过索引模型中的记录，您还可以对它们进行 X 射线分析。有关更多详细信息，请参阅模型文档。

跳过 SQL 变量

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

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

创建不带变量的模型。
保存基于模型的问题。
将该问题添加到仪表盘。
向仪表盘添加过滤器。
将过滤器映射到问题上的相应列。

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

进一步阅读

创建和管理模型.

商业智能

嵌入式分析

文档

学习

课程

Metabase 基础

提升您的数据技能

速查表