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

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
简介: 维度主要分为定性维度和定量维度,定性维度,主要是偏文字描述类如城市、性别、职业等;定量维度,主要是数值类描述如收入、年龄等,对定量维度需要做数值分组处理。

指标体系定义


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


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


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


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


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


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


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


什么是数据指标


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


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


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


  • 经营分析汇报会上,产品和运营的汇报内容都包含了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




相关实践学习
AnalyticDB PostgreSQL 企业智能数据中台:一站式管理数据服务资产
企业在数据仓库之上可构建丰富的数据服务用以支持数据应用及业务场景;ADB PG推出全新企业智能数据平台,用以帮助用户一站式的管理企业数据服务资产,包括创建, 管理,探索, 监控等; 助力企业在现有平台之上快速构建起数据服务资产体系
目录
相关文章
|
2月前
|
人工智能 缓存 监控
使用LangChain4j构建Java AI智能体:让大模型学会使用工具
AI智能体是大模型技术的重要演进方向,它使模型能够主动使用工具、与环境交互,以完成复杂任务。本文详细介绍如何在Java应用中,借助LangChain4j框架构建一个具备工具使用能力的AI智能体。我们将创建一个能够进行数学计算和实时信息查询的智能体,涵盖工具定义、智能体组装、记忆管理以及Spring Boot集成等关键步骤,并展示如何通过简单的对话界面与智能体交互。
659 1
|
2月前
|
人工智能 Java API
构建基于Java的AI智能体:使用LangChain4j与Spring AI实现RAG应用
当大模型需要处理私有、实时的数据时,检索增强生成(RAG)技术成为了核心解决方案。本文深入探讨如何在Java生态中构建具备RAG能力的AI智能体。我们将介绍新兴的Spring AI项目与成熟的LangChain4j框架,详细演示如何从零开始构建一个能够查询私有知识库的智能问答系统。内容涵盖文档加载与分块、向量数据库集成、语义检索以及与大模型的最终合成,并提供完整的代码实现,为Java开发者开启构建复杂AI智能体的大门。
966 58
存储 人工智能 机器人
56 0
|
2月前
|
人工智能 安全 数据库
构建可扩展的 AI 应用:LangChain 与 MCP 服务的集成模式
本文以LangChain和文件系统服务器为例,详细介绍了MCP的配置、工具创建及调用流程,展现了其“即插即用”的模块化优势,为构建复杂AI应用提供了强大支持。
|
3月前
|
机器学习/深度学习 算法 大数据
构建数据中台,为什么“湖仓一体”成了大厂标配?
在大数据时代,数据湖与数据仓库各具优势,但单一架构难以应对复杂业务需求。湖仓一体通过融合数据湖的灵活性与数据仓的规范性,实现数据分层治理、统一调度,既能承载海量多源数据,又能支撑高效分析决策,成为企业构建数据中台、推动智能化转型的关键路径。
|
4月前
|
数据采集 存储 分布式计算
一文读懂数据中台架构,高效构建企业数据价值
在数字化时代,企业面临数据分散、难以统一管理的问题。数据中台架构通过整合、清洗和管理数据,打破信息孤岛,提升决策效率。本文详解其核心组成、搭建步骤及常见挑战,助力企业高效用数。
1367 24
|
6月前
|
SQL 存储 OLAP
数据外置提速革命:轻量级开源SPL如何用文件存储实现MPP级性能?
传统交易型数据库在分析计算中常遇性能瓶颈,将数据迁至OLAP数据仓库虽可缓解,但成本高、架构复杂。SPL通过轻量级列存文件存储历史数据,提供强大计算能力,大幅简化架构并提升性能。它优化了列式存储、数据压缩与多线程并行处理,在常规及复杂计算场景中均表现优异,甚至单机性能超越集群。实际案例中,SPL在250亿行数据的时空碰撞问题上,仅用6分钟完成ClickHouse集群30分钟的任务。
数据外置提速革命:轻量级开源SPL如何用文件存储实现MPP级性能?
|
6月前
|
SQL 机器学习/深度学习 监控
构建数据中枢:数据中台指标体系如何赋能企业运营
杭州奥零数据科技有限公司成立于2023年,专注于数据中台业务,维护开源项目AllData并提供商业版解决方案。AllData提供数据集成、存储、开发、治理及BI展示等一站式服务,支持AI大模型应用,助力企业高效利用数据价值。
|
6月前
|
存储 机器学习/深度学习 人工智能
使用 LangChain + Higress + Elasticsearch 构建 RAG 应用
本文介绍了如何利用LangChain、Higress和Elasticsearch快速构建RAG(检索增强生成)应用,实现企业知识的智能检索与问答。首先通过LangChain解析Markdown文档并写入Elasticsearch,接着部署Higress AI网关并配置ai-search插件以整合私有知识库与在线搜索功能。最后,通过实际案例展示了RAG查询流程及结果更新机制,确保内容准确性和时效性。文章还提供了相关参考资料以便进一步学习。
631 38

热门文章

最新文章

推荐镜像

更多
下一篇
开通oss服务