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

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

指标体系定义


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


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


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


  • 结果型指标 用于衡量用户发生某个动作后所产生的结果,通常是延后知道的,很难进行干预。结果型指标更多的是监控数据异常,或者是监控某个场景下用户需求是否被满足


  • 过程型指标 用户在做某个动作时候所产生的指标,可以通过某些运营策略来影响这个过程指标,从而影响最终的结果,过程型指标更加关注用户的需求为什么被满足或没被满足


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


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


什么是数据指标


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


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


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


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


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


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


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


为什么需要数据指标体系

image.png



  1. 相同指标名称,口径不一致


  1. 相同口径,指标名称不一致


  1. 不同限定词,描述相同事实过程的指标,相同事实部分口径不一致


  1. 指标口径描述不一致


  1. 指标命名难以理解


  1. 指标数据来源及计算逻辑描述不清楚

image.png


1. 同名不同义


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


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


2. 同义不同名


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


3. 口径不清晰


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


4. 命名难理解


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


5. 逻辑不准确


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


6. 数据难追溯


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


7. 数据质量差


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


数据指标的构成

image.png


img

数据指标的组成:

image.png

img

image.png

img

数据指标体系构建方法论

image.png

img

image.png

img

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

image.png

img

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

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

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

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

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

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

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

数据指标管理的名字解释

image.png

img

指标主题域管理


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


指标修饰词管理


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


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


指标管理


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


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


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


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

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

image.png

img

指标明细

image.png

img

3.5.5 指标体系图谱模型


image.png

数据指标建模流程


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


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


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


image.png


3.5.7 数据指标开发评审流程

image.png


3.5.8 指标生产及加工


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

image.png


指标生产:

image.png


指标生产血缘关系:

image.png


数据指标示例

image.png




相关实践学习
使用CLup和iSCSI共享盘快速体验PolarDB for PostgtreSQL
在Clup云管控平台中快速体验创建与管理在iSCSI共享盘上的PolarDB for PostgtreSQL。
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
目录
相关文章
|
2月前
|
机器学习/深度学习 存储 人工智能
为什么AI处理私有数据,需要使用向量数据库
大语言模型通过概率和向量数据库查询来生成高质量内容,当预测概率低于阈值时,利用相似性从本地数据中获取信息,向量数据库通过向量化、表示、查询、搜索和解码等步骤,帮助模型处理未知数据。
|
4天前
|
弹性计算 自然语言处理 开发工具
基于阿里云向量检索 Milvus 版和 LangChain 快速构建 LLM 问答系统
本文介绍如何通过整合阿里云Milvus、阿里云DashScope Embedding模型与阿里云PAI(EAS)模型服务,构建一个由LLM(大型语言模型)驱动的问题解答应用,并着重演示了如何搭建基于这些技术的RAG对话系统。
|
4天前
|
SQL 人工智能 自然语言处理
利用LangChain构建的智能数据库操作系统
LangChain库简化了数据库与AI结合,通过LLM将自然语言转为SQL语句进行查询和数据分析。它降低了数据查询的门槛,支持创建基于数据库的问答机器人和数据分析面板。实战案例展示了如何使用LangChain进行查询并以自然语言形式返回结果。通过限制表名,可处理大量数据。总结:掌握LangChain在数据库操作、查询及结果自然语言转换的应用。
11 0
|
9天前
|
存储 SQL 关系型数据库
【LLM】基于pvVevtor和LangChain构建RAG(检索增强)服务
【5月更文挑战第4天】基于pgVector和LangChain构建RAG检索增强服务
|
16天前
|
Cloud Native 关系型数据库 MySQL
云原生数据仓库产品使用合集之在ADB中,如何将源数据的多表(数据结构一致)汇总到一张表
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
|
21天前
|
人工智能 Oracle 关系型数据库
【AI Agent系列】【LangGraph】0. 快速上手:协同LangChain,LangGraph帮你用图结构轻松构建多智能体应用
【AI Agent系列】【LangGraph】0. 快速上手:协同LangChain,LangGraph帮你用图结构轻松构建多智能体应用
47 0
|
21天前
|
数据采集 存储 人工智能
【AI大模型应用开发】【LangChain系列】实战案例4:再战RAG问答,提取在线网页数据,并返回生成答案的来源
【AI大模型应用开发】【LangChain系列】实战案例4:再战RAG问答,提取在线网页数据,并返回生成答案的来源
61 0
|
26天前
|
人工智能 自然语言处理 API
深入浅出LangChain与智能Agent:构建下一代AI助手
LangChain为大型语言模型提供了一种全新的搭建和集成方式,通过这个强大的框架,我们可以将复杂的技术任务简化,让创意和创新更加易于实现。本文从LangChain是什么到LangChain的实际案例到智能体的快速发展做了全面的讲解。
279767 57
深入浅出LangChain与智能Agent:构建下一代AI助手
|
27天前
|
消息中间件 存储 Java
深度探索:使用Apache Kafka构建高效Java消息队列处理系统
【4月更文挑战第17天】本文介绍了在Java环境下使用Apache Kafka进行消息队列处理的方法。Kafka是一个分布式流处理平台,采用发布/订阅模型,支持高效的消息生产和消费。文章详细讲解了Kafka的核心概念,包括主题、生产者和消费者,以及消息的存储和消费流程。此外,还展示了Java代码示例,说明如何创建生产者和消费者。最后,讨论了在高并发场景下的优化策略,如分区、消息压缩和批处理。通过理解和应用这些策略,可以构建高性能的消息系统。
|
2月前
|
关系型数据库 MySQL OLAP
PolarDB +AnalyticDB Zero-ETL :免费同步数据到ADB,享受数据流通新体验
Zero-ETL是阿里云瑶池数据库提供的服务,旨在简化传统ETL流程的复杂性和成本,提高数据实时性。降低数据同步成本,允许用户快速在AnalyticDB中对PolarDB数据进行分析,降低了30%的数据接入成本,提升了60%的建仓效率。 Zero-ETL特性包括免费的PolarDB MySQL联邦分析和PolarDB-X元数据自动同步,提供一体化的事务处理和数据分析,并能整合多个数据源。用户只需简单配置即可实现数据同步和实时分析。

推荐镜像

更多