需要指标层的迹象
“仪表板 A、B 和 C 上的用户数量不同。你能解释一下是怎么回事吗？”
“这个报告中这个计数的定义已经过时了。我们能尽快修复这个问题吗？”
这些问题是我作为商业智能分析师每周甚至每天都会被问到的一些常见问题。这表明指标已经失控，为基于这些指标做出决策的最终用户造成了混乱。尽管我们创造了它，但这给数据团队带来了更多的工作。随着业务的增长和变化，它所跟踪的指标也在变化。随着收集的数据变得越来越丰富，其复杂性也在增加。
考虑一下计算用户的简单场景。听起来很简单，对吧？但这里是我工作中遇到的一些常见问题
- 我在哪个时间段内计算用户数量？是每日、每周还是每月？
- 我是按地理区域划分的吗？它是如何定义的（州、县、MSA）？
- 我如何知道在计数用户时是否有重复？我在什么粒度级别上进行去重？
- 我只想要活跃用户。我如何确定一个用户是否活跃？是否有标记列，或者如果在一定时间后没有交易，我就认为该用户不活跃？这个时间是多少？
- 在计数用户时，我还需要注意数据中的其他标记或过滤器吗？我需要打开还是关闭它们？根据你的领域，可能还有无数其他的注意事项。
在分析中，计数实际上相当困难。当多个消费渠道上同一指标的数据不一致时，用户开始对数据失去信任，这会给数据团队追踪问题带来头痛。
什么是指标层？
但是，这个领域正在出现一种增长中的解决方案：指标层的概念（这个概念的另一种说法是无头BI或指标存储）。
你知道GitHub是项目代码库的中心仓库吗？或者数据仓库是数据的唯一真相来源？指标层可以是组织中定义指标的中心、唯一真相来源。
指标层应该位于你的数据存储和消费之间，以便统一定义
你的组织有多个仪表板。可能还有多个商业智能（BI）工具。你真的希望在每一个出口都重新定义你的指标的业务逻辑吗？如果业务增长，逻辑发生变化怎么办？这会增加某个实例稍微不准确或过时的可能性，等到有人查看并做出决策时。但一个单一、一致的定义，在多个地方使用，可以解决这个难题，并且是DRY原则（不要重复自己）的一个很好的例子。
你如何开始定义一个指标层？
一开始不一定需要是一个完全设计好的功能。首先定义指标应该如何计算。写出一个SQL查询或一系列用于创建指标的操作，并将其保存在一个多个用户可以参考和提供意见的地方（但请注意不要将代码复制粘贴到各种工具中）。然后将它移动到一个多个工具可以访问定义的地方。你可以基于SQL查询创建一个表或视图，并将其存储在数据仓库中。
当你准备好了，定义一个指标层，你可以从集中位置共享指标（截至撰写本文时，Metabase在即将推出的功能中具有此功能）。一些工具允许各种BI解决方案连接到API以访问指标，并让您在保持指标定义不变的情况下进行交换（因此有了“无头BI”这个术语）。
你如何定义一个指标层？
多个工具可以帮助你填补现代数据堆栈中缺失的这一部分。一般框架是
1) 确定你想跟踪的指标。听起来很简单，但就像我在开始示例中概述的那样，它会很快失控。你想测量什么，你想如何聚合，你想通过哪些维度来切片数据？你希望在指标中包含任何过滤器/约束吗？
2) 根据您选择的工具来实现指标层，您需要定义这些配置。在一些工具中，您将在YAML文件中设置这些定义。
3) 现在您已经定义了您的指标，是时候对其进行测试了。指标层的灵活性意味着您不需要预先聚合所有可能的度量指标和维度的组合，只需定义可能性，然后让工具处理它，这样无论谁在您使用的任何BI工具中提取指标，最终都能得到相同的数字。上述工具提供的API可以用于提取指标。
指标层是BI领域的一项令人兴奋的发展，可以解决分析师许多头痛问题和重复性问题。与其将定义锁定在所有数据消费工具中，并重复复杂的业务逻辑，不如尝试在您的组织中定义指标的“单一事实来源”!