指标管理提问:数仓分层后,原子指标如何指定来源事实表

0 评论 805 浏览 4 收藏 6 分钟

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

开门见山,直接来个提问:

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

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

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

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

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

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

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

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

场景:严格遵照定义管理

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

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

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

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

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

写在最后

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

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

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

专栏作家

Lee,公众号:数据产品小lee,人人都是产品经理专栏作家。关注直播、短视频和文娱领域、擅长数据架构、CDP及数据治理相关工作。

本文原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!