构建模型

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

让非技术人员能够轻松地对您的数据提出问题，最有价值的事情就是将您的数据整理成一种直观易于提问的形状。

数据通常可能很混乱，尤其对于初创公司而言。或者甚至不混乱：它可能是高度规范化的、为事务而非分析优化的数据。这意味着您的数据库中可能有客户数据分散在大量表格中，这使得不熟悉数据库的人难以找到他们正在寻找的信息（而且这还是假设他们甚至知道联接是如何工作的）。

模型作为构建块

为了让您的团队更直观地理解数据，在 Metabase 中，您可以创建派生数据集，称为**模型**，它们可以将来自不同表的数据整合在一起。它们基于 Metabase 查询的结果构建，您可以添加自定义计算列，并用元数据注解所有列，以便人们可以将数据作为起点在查询构建器中进行操作。

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

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

Metabase 模型和 ETL 并非互斥。您可以（也应该）同时利用它们。以下是原因：

模型将数据建模工具交到了解业务领域的人员手中。 这意义重大。是的，数据工程师可能更了解数据管道的内部机制，但他们不一定了解特定团队面临的问题以及这些问题的各个部分应如何定义（例如，什么才算活跃用户？）。贵组织的各个团队应该定义您的业务，并且他们应该能够根据团队工作方式、新产品、市场变化等方面的变化来完善这些定义。有了模型，人们无需通过数据团队来添加新的计算列或更新定义。此外，不同的团队会有不同的定义：您的销售团队可能对客户的定义与您的市场或客户成功团队不同。
模型是灵活的。您可以即时创建模型、修改它们、切换它们——它们本质上只是查询 + 描述。而且它们是 Metabase 中的一流公民，因此您可以将它们组织到集合中、链接到它们、并选择它们作为新问题的起点，或将它们添加到仪表盘中。您还可以归档它们，或将它们变回已保存查询（尽管您会丢失元数据）。相比之下，ETL 工作量大得多，通常由了解数据管道、知道如何编写代码、安排任务等的人员控制。有一些很棒的工具可以帮助您编写 ETL，但对于需要灵活解决方案的问题，它们通常是一种重量级解决方案。
模型是提升数据库性能的垫脚石。在 Metabase 中对模型进行实验后，您可以将最受欢迎的模型“提升”为数据库中的物化视图。这里的物化意味着编写一个 ETL 任务，在数据库中创建并定期更新一个与您的模型匹配的表（具有相同的列集），这样每次运行查询时就不需要重新计算结果；数据库可以直接像从原始数据表中一样获取结果。（请注意，如果您更改了模型的基础查询，则需要更新每个列的元数据）。
模型可以索引单个记录并使其在 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 基础

提升您的数据技能

备忘单