基于Apache Doris怎么构建数据中台(七)-数据指标管理

目录

指标体系定义

指标体系是将零散单点的具有相互联系的指标,系统化的组织起来,通过单点看全局,通过全局解决单点的问题。它主要由指标和体系两部分组成。

指标是指将业务单元细分后量化的度量值,它使得业务目标可描述、可度量、可拆解,它是业务和数据的结合,是统计的基础,也是量化效果的重要依据。

指标主要分为结果型和过程型:

  • 结果型指标 用于衡量用户发生某个动作后所产生的结果,通常是延后知道的,很难进行干预。结果型指标更多的是监控数据异常,或者是监控某个场景下用户需求是否被满足
  • 过程型指标 用户在做某个动作时候所产生的指标,可以通过某些运营策略来影响这个过程指标,从而影响最终的结果,过程型指标更加关注用户的需求为什么被满足或没被满足

体系是由不同的维度组成,而维度是指用户观察、思考与表述某事物的“思维角度”,维度是指标体系的核心,没有维度,单纯说指标是没有任何意义的。

维度主要分为定性维度和定量维度,定性维度,主要是偏文字描述类如城市、性别、职业等;定量维度,主要是数值类描述如收入、年龄等,对定量维度需要做数值分组处理

什么是数据指标

不是所有的数据都叫指标,指标必须对业务有参考价值。数据指标是针对业务需求,使用收集手段,直接获得或者间接计算出来的一系列统计数据。

数据指标贯穿整个设计流程,解释用户行为和业务变化,为设计提供依据,对结果加以验证

数据指标是数据化管理的核心内容之一,从事数据工作的同学相信都经历过以下场景:

  • 经营分析汇报会上,产品和运营的汇报内容都包含了App MAU指标,但是数据却不一样,老板:“什么情况,谁的数据是准的!”
  • 数据可视化平台上,经营概况页面上有一个指标叫券后营收,营销概况有一个指标叫优惠券抵扣营收,两个指标什么关系呢,数据相同(指标口径一样,名称不一样)。
  • 数据产品上很多指标看名称并不理解指标含义,指标文档维护、线下传播,想确认一个指标的统计逻辑要几经周转。

指标管理模块核心包括基础信息和技术信息管理,衍生信息包括关联指标、关联应用管理。基础信息对应的就是指标的业务信息,由业务人员填写,主要包括指标名称、业务分类、统计频率、精度、单位、指标类型、指标定义、计算逻辑、分析方法、影响因素、分析维度等信息;基础信息中还有一个比较重要的部分是监控配置,主要是配置指标的有效波动范围区间、同环比波动区间等,监控指标数据的正常运行。

技术信息构成比较复杂,包括数据类型、指标代码,但是核心部分是指标与模型的绑定关系,通过使用演进形成了当前系统两类绑定关系:绑定物理模型和构建虚拟模型。绑定物理模型是指标与模型管理中的物理模型字段绑定,并配置对应的计算公式,或还包含一些额外的高级配置,如二次计算、模型过滤条件等;创建虚拟模型是通过已有指标和其对应的物理模型,具体步骤首先配置已有指标的计算方式或指标维度的过滤,然后选择指标已绑定的物理模型,形成一个虚拟模型,虚拟模型的分析维度就是所选指标基础模型的公共维度。

衍生信息中的关联指标、关联应用管理,是为了方便观察指标被那些其他指标和数据应用使用,这是因为指标技术信息采用了严格权限控制,一旦被使用为了保证线上的运行安全是禁止变更的,只有解绑并审核通过后才可以编辑,所以这些衍生信息就是方便管理人员使用

为什么需要数据指标体系

img

  1. 相同指标名称,口径不一致
  2. 相同口径,指标名称不一致
  3. 不同限定词,描述相同事实过程的指标,相同事实部分口径不一致
  4. 指标口径描述不一致
  5. 指标命名难以理解
  6. 指标数据来源及计算逻辑描述不清楚

img

1. 同名不同义

指标名称相同,统计口径不一致,缺少命名规范限制。

不同业务仅从自己部门出发,缺少全局视角,如财务口径的营收要严格按照严谨的逻辑计算实收实付的每一分钱,而产品/运营端则更多考虑转化效果,但在各自的KPI监控报表中,都把指标命名为营收。

2. 同义不同名

指标统一逻辑一致,但不同产品命名不一致,不同阶段、或不同业务方/产品经理对指标命名不同,导致在不同数据产品页面,同一指标不同名。

3. 口径不清晰

只是同义词再复述一遍,如活跃用户数:访问用户数。

4. 命名难理解

表意不清模棱两可,或过于专业化仅指标创建人才可以懂。例如转化率指标,有创单转化率、成单转化率,直接叫转化率可读性就非常差。

5. 逻辑不准确

指标口径描述有误,例如UV指标,口径描述为“按照设备ID去重”,实际上不同平台去重逻辑并不一致,如微信小程序按照UnionID去重、APP按照DeviceID去重,PC和H5按照loginkey去重。

6. 数据难追溯

数据产品指标数据来源缺少直观的链路追踪能力,指标数据异常问题排查通过翻代码去看数据来源,路径长、耗时久,早上业务反馈指标问题,排查出结论后可能一上午就过去了。

7. 数据质量差

指标管理常见的问题综合在一起,往往会导致业务对数据指标的信任度大打折扣,发现数据波动后,第一反应是先和数据部门确认数据是不是有问题,而不是去考虑业务上有何变动

数据指标的构成

img

数据指标的组成:

img

img

数据指标体系构建方法论

img

img

数据指标管理系统设计思路

img

1)建立指标生产协同机制,指标的诞生要经过需求申请、审核、数据开发、上线应用流程,收口指标创建过程,避免指标建设的随意性带来的“污染”。

2)制定指标命名、口径说明规范,按照原子指标+业务限定+统计维度的方式,将规则集成到平台内,通过系统规则来把控指标输出。

3)指标字典线上化,解决线下文档管理指标存在的共享难、更新不及时、权限管控缺失等问题。

4)指标数据逻辑绑定,即除了维护指标的业务元数据外,还要建立指标的技术元数据,指标数据从哪个模型、哪个字段、何种计算逻辑得到。

5)指标输出,指标管理最大的价值还是为数据产品提供数据输出

指标系统数据开发,是指标的统一入口,通过定义原子、派生和复合指标,明确指标业务口径和技术口径,解决指标定义不一致、口径不一致和数据来源不一致的问题,实现规范定义,助力数据模型规范设计。

  1. 指标按业务过程划分主题管理(最多支持两级)
  2. 指标定义(原子指标、派生指标,符合指标)
  3. 指标修饰词管理
  4. 指标查看:查看指标定义,指标数据生产链路、指标关联数据表,指标使用(后续支持单个指标接口无代码访问)

数据指标管理的名字解释

img

指标主题域管理

指标主题域的构建是根据业务过程来创建,和数仓主题域管理感念一致,统一采用一套叫数据主题域,没有指标主题域这个概念,指标是挂在某个数据主题域下。

指标修饰词管理

修饰词是统计维度以外指标的业务场景限定抽象,修饰词属于一种修饰类型,如在日志域的访问终端类型下,有修饰词APP、PC端等

提供统一的指标修饰词管理维护。

指标管理

包括基础信息、技术信息和衍生信息,由不同角色进行维护管理。

  • 基础信息对应指标的业务信息,由业务管理人员、数据产品或BI分析师维护,主要包括归属信息(业务板块、数据域、业务过程),基本信息(指标名称、指标英文名称、指标定义、统计算法说明、指标类型(去重、非去重)),业务场景信息(分析维度,场景描述);
  • 技术信息对应指标的物理模型信息,由数据研发进行维护,主要包括对应物理表及字段信息;
  • 衍生信息对应关联派生或衍生指标信息、关联数据应用和业务场景信息,便于用户查询指标被哪些其它指标和数据应用使用,提供指标血缘分析追查数据来源的能力。

原子指标定义归属信息 + 基本信息 + 业务场景信息

派生指标定义时间周期 + 修饰词集合 + 原子指标

修饰类型主要包含类型说明、统计算法说明、数据源(可选)

img

指标明细

img

3.5.5 指标体系图谱模型

img

数据指标建模流程

在数据指标体系搭建项目启动前,需要与各业务方详细了解具体业务、梳理清楚关键业务流程。需求采集可分为定量、定性采集两种类型。

根据对业务需求、各个模块的业务流程进行分析,进行数据域的划分。数据域划分按照业务过程或者业务板块的功能模块划分。依据实际业务过程进行归纳、抽象得出数据域。

梳理了业务域、数据域、业务过程的整体框架之后,开始针对指标规范进行设计,完成总线矩阵设计。把行为不同的业务处理过程,即事实,在交叉点上打上标记表示该业务处理过程与该维度相关这个矩阵,称为总线矩阵总线架构和一致性维度、一致性事实共同组成了Kimball的多维体系结构的基础

img

3.5.7 数据指标开发评审流程

img

3.5.8 指标生产及加工

提供可视化的数据指标生产加工管理工具,并可以监控指标生产的过程,将指标的生产无缝的和任务调度系统进行融合,为数据指标的数据质量提供质量保证

img

指标生产:

img

指标生产血缘关系:

img

数据指标示例

img

打赏一个呗

取消

感谢您的支持,我会继续努力的!

扫码支持
扫码支持
扫码打赏,你说多少就多少

打开支付宝扫一扫,即可进行扫码打赏哦