指标管理提问:数仓分层后,原子指标如何指定来源事实表
开门见山,直接来个提问:
背景1:数仓已经分层,现有两张表,一张是天粒度的表dwd.order_d(放在了DWD层),一张是周粒度的表dws.order_w(放在了DWS层),两张表里面都有指标订单金额。
背景2:你现在负责建设或管理指标管理系统,当中有个模块叫原子指标管理。界面和功能类似下图的华为产品(DataArts Studio_新建原子指标)
提问:新增「订单金额」这个原子指标的时候,应该设置哪个表为原子指标的来源表?指标后续要统一从哪一层出呢?比如,要汇总月订单指标的时候,应该从哪个表来汇总呢
来,思考3秒,3…2…1,给出你的答案。这个问题,很容易陷入当中给出的两个选项:天粒度 or 周粒度?
我先提醒你牢记,做指标管理有一个核心关注点:保证数据的一致性。我的答案是:原子指标要基于最原始、粒度最细的数据来定义,当然,这是理想的做法。
对于订单这个动作来说,什么是最原始、粒度最细的数据呢?
下订单就增加一条记录的那张表,不管下单是最终成功还是失败,系统都会记录,这张表就是最细粒度的表。这个最原始的销售订单事实表,里面通常包含每一笔订单的详细信息,如交易时间、金额、客户信息等。而且基于这张表进行多种聚合计算,如按天、周、月等不同时间粒度或者其他维度(如商品类别、地区等)来汇总数据。
而在实践中,就如提问的背景说的那样,你进入某新公司,数仓已经建好了,表也建好了,就等利用管理系统来科学管理指标了,这时候,可能会根据使用场景的不同选择不同的表来作为指标计算的基础。
场景:严格遵照定义管理
如果是为了保持最大的灵活性和精确度,你应当找到那张最细粒度的销售订单事实表去定义原子指标。这保证了指标的灵活性和准确性,因为原子指标应该代表最基础的事实,允许在此基础上构建更加复杂的计算和分析。
场景:从实际业务需求出发
如果业务需求明确主要关注天或周的销售趋势,分析场景里没有比天更细的粒度,且这些聚合表是可靠的数据来源,可以直接使用这些聚合表作为指标的数据来源。
- 天粒度的表:是对原始事实表中的数据按照天来进行预先聚合的结果。如果业务需求主要关注日常运营分析,以天作为标准时间单位,则天粒度表能够快速提供所需数据。
- 周粒度的表:则更进一步将数据聚合到周级别,适用于那些关注周趋势的分析场景。
不管是哪种场景,我们的目标重点是保持清晰的指标定义和一致的取数口径,即使在不同的聚合层级之间,销售金额指标的计算规则也应该是一致的,比如都包括或排除退货、折扣等因素。
写在最后
无论是从事实表还是某个聚合表中取数,结果都应该是相互验证且一致的。
之前写了事实表里没有原子指标,结果实际在系统里管理原子指标的时候,又要指定它的来源表,这是咋回事呢?
原子指标定义的是取数的逻辑和部分计算表达式(完全SQL取数里面的计算表达式部分),后续再来讲讲~
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!