在做指标管理时，我们需要保证数据的一致性，后续思考相关问题时，我们也可以基于这一准则做出解答。这篇文章里，作者就针对“数仓分层后，原子指标如何指定来源事实表”这一问题做出解答，一起来看看吧。

开门见山，直接来个提问：

背景1：数仓已经分层，现有两张表，一张是天粒度的表dwd.order_d（放在了DWD层），一张是周粒度的表dws.order_w（放在了DWS层），两张表里面都有指标订单金额。

背景2：你现在负责建设或管理指标管理系统，当中有个模块叫原子指标管理。界面和功能类似下图的华为产品（DataArts Studio_新建原子指标)

提问：新增「订单金额」这个原子指标的时候，应该设置哪个表为原子指标的来源表？指标后续要统一从哪一层出呢？比如，要汇总月订单指标的时候，应该从哪个表来汇总呢

来，思考3秒，3…2…1，给出你的答案。这个问题，很容易陷入当中给出的两个选项：天粒度 or 周粒度？

我先提醒你牢记，做指标管理有一个核心关注点：保证数据的一致性。我的答案是：原子指标要基于最原始、粒度最细的数据来定义，当然，这是理想的做法。

对于订单这个动作来说，什么是最原始、粒度最细的数据呢？

下订单就增加一条记录的那张表，不管下单是最终成功还是失败，系统都会记录，这张表就是最细粒度的表。这个最原始的销售订单事实表，里面通常包含每一笔订单的详细信息，如交易时间、金额、客户信息等。而且基于这张表进行多种聚合计算，如按天、周、月等不同时间粒度或者其他维度（如商品类别、地区等）来汇总数据。

而在实践中，就如提问的背景说的那样，你进入某新公司，数仓已经建好了，表也建好了，就等利用管理系统来科学管理指标了，这时候，可能会根据使用场景的不同选择不同的表来作为指标计算的基础。

场景：严格遵照定义管理

如果是为了保持最大的灵活性和精确度，你应当找到那张最细粒度的销售订单事实表去定义原子指标。这保证了指标的灵活性和准确性，因为原子指标应该代表最基础的事实，允许在此基础上构建更加复杂的计算和分析。

场景：从实际业务需求出发

如果业务需求明确主要关注天或周的销售趋势，分析场景里没有比天更细的粒度，且这些聚合表是可靠的数据来源，可以直接使用这些聚合表作为指标的数据来源。

• 天粒度的表：是对原始事实表中的数据按照天来进行预先聚合的结果。如果业务需求主要关注日常运营分析，以天作为标准时间单位，则天粒度表能够快速提供所需数据。
• 周粒度的表：则更进一步将数据聚合到周级别，适用于那些关注周趋势的分析场景。

不管是哪种场景，我们的目标重点是保持清晰的指标定义和一致的取数口径，即使在不同的聚合层级之间，销售金额指标的计算规则也应该是一致的，比如都包括或排除退货、折扣等因素。

写在最后

无论是从事实表还是某个聚合表中取数，结果都应该是相互验证且一致的。

之前写了事实表里没有原子指标，结果实际在系统里管理原子指标的时候，又要指定它的来源表，这是咋回事呢？

原子指标定义的是取数的逻辑和部分计算表达式（完全SQL取数里面的计算表达式部分），后续再来讲讲~