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

0 评论 1053 浏览 7 收藏 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. 目前还没评论,等你发挥!
专题
45035人已学习10篇文章
什么是社群运营?社群运营怎么做?社群运营哪些坑?
专题
13381人已学习12篇文章
人力资源管理系统,帮助企业管理和维护其人力资源。本专题的文章分享了人力资源管理系统的设计指南。
专题
14822人已学习14篇文章
痛点是什么?为什么用户会有痛点?如何抓住用户痛点?优先解决哪些用户痛点?本专题的文章分享了以上的问题详解。
专题
11586人已学习13篇文章
2023年已结束,你的年终总结写好了吗?本专题的文章分享了如何做好年终总结。
专题
15932人已学习16篇文章
私域模式已完成从探索到落地的转换,许多企业也纷纷落局。而基于私域衍生出的SCRM工具,也成为私域运营必不可少的利器之一。本专题的文章分享了SCRM工具的搭建以及相关业务运用场景。
专题
11430人已学习12篇文章
数据管理系统在后期能够为企业提供基础数据服务,保证企业往更好的方向运营。本专题的文章分享了如何做好数据管理。