指标管理提问：数仓分层后，原子指标如何指定来源事实表
在做指标管理时，我们需要保证数据的一致性，后续思考相关问题时，我们也可以基于这一准则做出解答。这篇文章里，作者就针对“数仓分层后，原子指标如何指定来源事实表”这一问题做出解答，一起来看看吧。
开门见山，直接来个提问：
背景1：数仓已经分层，现有两张表，一张是天粒度的表dwd.order_d（放在了DWD层），一张是周粒度的表dws.order_w（放在了DWS层），两张表里面都有指标订单金额。
背景2：你现在负责建设或管理指标管理系统，当中有个模块叫原子指标管理。界面和功能类似下图的华为产品（DataArts Studio_新建原子指标)
提问：新增「订单金额」这个原子指标的时候，应该设置哪个表为原子指标的来源表？指标后续要统一从哪一层出呢？比如，要汇总月订单指标的时候，应该从哪个表来汇总呢
来，思考3秒，3…2…1，给出你的答案。这个问题，很容易陷入当中给出的两个选项：天粒度 or 周粒度？
我先提醒你牢记，做指标管理有一个核心关注点：保证数据的一致性。我的答案是：原子指标要基于最原始、粒度最细的数据来定义，当然，这是理想的做法。
对于订单这个动作来说，什么是最原始、粒度最细的数据呢？
下订单就增加一条记录的那张表，不管下单是最终成功还是失败，系统都会记录，这张表就是最细粒度的表。这个最原始的销售订单事实表，里面通常包含每一笔订单的详细信息，如交易时间、金额、客户信息等。而且基于这张表进行多种聚合计算，如按天、周、月等不同时间粒度或者其他维度（如商品类别、地区等）来汇总数据。
而在实践中，就如提问的背景说的那样，你进入某新公司，数仓已经建好了，表也建好了，就等利用管理系统来科学管理指标了，这时候，可能会根据使用场景的不同选择不同的表来作为指标计算的基础。
场景：严格遵照定义管理
如果是为了保持最大的灵活性和精确度，你应当找到那张最细粒度的销售订单事实表去定义原子指标。这保证了指标的灵活性和准确性，因为原子指标应该代表最基础的事实，允许在此基础上构建更加复杂的计算和分析。
场景：从实际业务需求出发
如果业务需求明确主要关注天或周的销售趋势，分析场景里没有比天更细的粒度，且这些聚合表是可靠的数据来源，可以直接使用这些聚合表作为指标的数据来源。
- 天粒度的表：是对原始事实表中的数据按照天来进行预先聚合的结果。如果业务需求主要关注日常运营分析，以天作为标准时间单位，则天粒度表能够快速提供所需数据。
- 周粒度的表：则更进一步将数据聚合到周级别，适用于那些关注周趋势的分析场景。
不管是哪种场景，我们的目标重点是保持清晰的指标定义和一致的取数口径，即使在不同的聚合层级之间，销售金额指标的计算规则也应该是一致的，比如都包括或排除退货、折扣等因素。
写在最后
无论是从事实表还是某个聚合表中取数，结果都应该是相互验证且一致的。
之前写了事实表里没有原子指标，结果实际在系统里管理原子指标的时候，又要指定它的来源表，这是咋回事呢？
原子指标定义的是取数的逻辑和部分计算表达式（完全SQL取数里面的计算表达式部分），后续再来讲讲~
专栏作家
Lee，公众号：数据产品小lee，人人都是产品经理专栏作家。关注直播、短视频和文娱领域、擅长数据架构、CDP及数据治理相关工作。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议