Metabase学习教程：系统管理-8 数据模型

dazdata

Metabase中的模型
创建模型，为人们提供新问题的良好起始数据集。
为了让非技术人员更容易地询问有关您的数据的问题，您可以做的最有价值的事情是将您的数据放入一个使提问更直观的形状。
数据往往很混乱，尤其是对于初创企业。就算不凌乱，它可能是高度标准化数据针对事务而不是分析进行优化。这意味着您可以拥有一个数据库，其中客户的数据分布在大量的表中，这使得那些还不熟悉数据库的人很难找到他们要查找的信息（假设他们甚至知道）.
模型作为构建块
为了使您的数据更直观，您可以创建问题，在查询生成器或者SQL编辑器，以在Metabase中创建派生表，调用模型，可以从不同的表中提取数据。您可以添加自定义列、计算列，并用元数据注释所有列，以便人们可以在查询生成器中将数据作为起点。
如果你已经是一个经验丰富的Metabase用户，你知道你可以从保存问题的结果。你可以把模型看作是一种特殊类型的保留问题，但这还不是模型的全部价值。
为什么不运行ETL作业在数据库中创建模型？
模型和ETL作业不是相互排斥的，各有各的作用，你可以（也应该）两者兼得。为了说明原因：

模型将建模数据的工具交给了解业务领域的人。这是件大事。是的，数据工程师会更了解数据管道中的管道，但他们不一定知道特定团队面临的问题以及这些问题的各个部分应该如何定义（例如，什么才是活动用户？）。组织中的不同团队应该是定义您业务的团队，他们应该能够根据团队工作方式、新产品供应、市场变化等方面的变化来改进这些定义。有了模型，人们就不必经过数据团队来添加新的计算列或更新定义。不同的团队会有不同的定义：你的销售团队对于客户的模式可能与你的营销团队或成功团队不同。
模型是灵活的。你可以动态地创建模型，修改它们，切换它们——它们基本上只是查询+描述。他们是Metabase的一等公民，所以你可以把他们组织成集合，链接它们，并选择它们作为新问题的起点，或将它们添加到仪表板。您也可以将其存档，或将其更改回已保存的问题（尽管您会丢失元数据）。相比之下，etl的工作量要大得多，而且通常由了解数据管道、知道如何编写代码、调度作业等的人控制。有一些很好的工具可以帮助您编写etl，但对于需要灵活解决方案的问题，它们通常是一个重量级的解决方案。
模型是提高数据库性能的垫脚石。在Metabase中使用模型后，可以将最流行的模型“升级”成物化视图到你的数据库里。这里的物化意味着编写一个ETL作业，在数据库中创建并定期更新与模型匹配的表（具有相同的列集），这样就不需要每次运行查询时都计算结果；数据库可以像从原始数据表中获取结果一样。一旦在数据库中具体化了表，就可以用一个简单的SELECT FROM 物化模型，或者只删除模型并像对待数据库中的任何其他表一样对待物化表。（请注意，如果更改模型的基础查询，则需要更新每个列的元数据）。
典型例子
在考虑要在模型中包含哪些列时，最好先列出希望人们提出的问题类型，然后在模型中添加有助于回答这些问题的列。假设我们要为客户建模。通常情况下，我们可能需要定义活动客户，可能是在过去一个月至少访问过我们网站一次的人，或者无论如何，我们希望定义活动客户。但为了简单起见，我们将使用Metabase中包含的示例数据库为基本客户定义一个模型。我们希望了解客户的一些情况：
• 他们住的地方，包括州政府和邮编。
• 他们的来源（他们是如何发现我们的）。
• 他们和我们一起花了多少钱。
• 他们下了多少订单。
• 每个订单的平均总数。
在真实的模型中，您可能会有更多的问题需要回答，这将需要更多的列来回答（例如客户的年龄、他们在网站上花了多长时间、从购物车中添加和删除的项目，或者您认为您的团队将要问问题的所有其他数据点）。模型的想法是让所有的样板代码把所有这些数据聚集在一起，这样人们就可以开始玩他们真正感兴趣的数据了。
下面是我们的问题，使用查询生成器构建：

图1。查询编辑器中的查询。
对于我们的数据，我们选择Orders表，连接到People表中，汇总了订单总数的总和，计算了行数，并使用自定义表达式计算了平均订单总额：= Sum([Total]) / Count。接下来，我们按：User_ID, People.Created_At, State, Zip，和Source.
我们保存该问题，单击问题标题以显示问题侧栏（您可能需要刷新浏览器），然后单击模型图标（三个构建块堆叠在一个三角形中）将问题转换为模型。

图2.将问题转化为模型。
向模型中添加元数据是关键
这是模型的超能力，对于使用SQL查询构建的模型特别有用，因为Metabase不知道SQL查询返回的列类型。

图3。重命名列，添加说明，并为每个列设置元数据。
单击模型的名称将显示模型侧栏，它为我们提供了自定义元数据。在这里，我们可以为列提供更友好的名称，向列添加描述（将在悬停时显示），并告诉Metabase该列包含的数据类型。

图4。将鼠标悬停在列上会触发带有列说明的弹出窗口。
如果我们使用SQL查询来创建相同的客户模型（请参见典型例子上图），如下所示：
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结果中的每一列是什么类型的数据，否则Metabase将无法执行其通常的魔术。因此，一定要为每个列设置类型，以便Metabase能够在图表上显示操作菜单，并知道它应该为该列使用哪种筛选器（例如，数字筛选器对数字的选项与对日期或类别的选项不同）。
跳过SQL变量
这里有一个微妙的问题值得我们指出。如果你习惯用保存的问题和SQL变量（比如字段筛选器)为了让人们能够接受这些问题并将它们与仪表板过滤器联系起来，模型在这里采取了不同的方法。模型不处理变量，因为它们不需要。一旦告诉Metabase模型的列类型，就可以从该模型开始一个问题，保存它，并能够将其连接到仪表板筛选器。不需要在SQL代码中放入变量。
如果将模型添加到仪表板，您会注意到，即使在为这些过滤器设置了类型之后，也无法将其任何列映射到仪表板筛选器。要获得与模型相同的结果，您可以：
• 创建一个没有变量的模型。
• 根据模型保存问题。
• 将该问题添加到仪表板。
• 向仪表板添加筛选器。
• 将筛选器映射到问题的相应列。
更多信息，请参见仪表板筛选器.