数仓模型(模型优化与指标验证)

简介: 数仓模型(模型优化与指标验证)

640.jpg数仓模型是建设的目标,有以下评价规则:

1规范度衡量

采用表归类率。计算公式为“表归类率 = 有分层信息与主题域信息的表的数量占比”。
数仓分层规范:公共逻辑下沉。出现相同逻辑的时候可以在dwd或者做个中间层收口,万一口径发生变化,只需要在最底层修改逻辑,上层只需要回溯验证数据即可,而不是说到处修改用到的地方
任务命名规范:见名知义,遵循命名库表命名规范。

2完善度衡量

可以采用公共层的表引用率(ODS层的表直接被DWD层引用的表占所有ODS层活跃表的比例)、汇总层的查询比例(DWD / ADS层的查询占所有查询的比例)来衡量。
跨层依赖的占比;同层Level>2的占比;
ods层被app层直接使用的占比等量化指标

3复用度衡量

主要采用公共层的模型调用热度(DWD层的数据模型被DWS / ADS层调用并加工产出新模型的平均数量)来进行衡量。
只有复用能力上来了,响应速度才能提上来,体现在下游依赖、调用次数、核心字段覆盖率等指标上;

(4) 健壮性

除了电商等已经耕耘多年的领域外,绝大多数业务模型,都会快速的变化,
如何适应这种变化,就非常考验架构功底。

(5) 准确性/一致性

输出的指标数据质量能够保证;
数据可回滚,进行验证。确保一些经常变化的维度可以回滚,比如:当下游每天产出指标的时候,突然今天的指标值和昨天的差异性很大,这个时候我们就要去回滚昨天的数据,看今天数据是否异常还是逻辑错误等等
定义一致性指标、统一命名规范、统一业务含义、统一计算口径,专业的建模团队

(6)可扩展性

新增加的模型是否和老的模型出现冲突;

(7)稳定性

能否保证日常的sla(数据到岗时间);
如何尽量减少任务运行失败

(8)时效性

响应速度:数据架构的主要场景包括:业务开发、数据产品、运营分析三大类,不论是那种场景,数据架构均应该在尽可能短的时间内响应需求;
监控数仓任务的运行时长进行优化

(9)成本指标

避免烟囱式的重复建设,节约计算、存储、人力成本。
不做无意义的分层
复杂逻辑前置,降低业务方的使用门槛。通过冗余维度和事实表,进行公共计算逻辑下沉,明细与汇总共存等为业务提供灵活性

数仓指标一致性如何保证

(1)数据质量保证(可参考前文)

(2)统一数仓规范

词根梳理评审
指标评审及指标定义
指标命名规范
指标管理规范

(3)开发规范

清洗规范
单位统一,比如金额单位统一为元
字段类型统一
注释补全
空值用默认值或者中位数填充
时间字段格式统一,如2020-10-16,2020/10/16,20201016统一格式为2020-10-16
json数据解析
枚举值统一
过滤没有意义的数据
逻辑规范
表之间的关联关系,依赖与调用,sql检验

(4)建立/需求/模型评审机制

建立统一的需求评审机制,从需求承接时间、制定需求模板(业务背景、所需的数据指标等)等制定一套规范,严格把控需求质量,如果需求承接本身变得很混乱,例如需求不明确、需求没有统一管理,那么很可能会导致重复性的建设工作;模型评审主要评审模型设计的是否合理,表/字段命名是否规范、应该是全量表还是增量表、分层是否按照要求、公共指标应该放在dws层还是adm层等,保证模型的质量来避免以后出现的二义性。

(5)建立一致性维度

建立一致性维度,保证参与计算的数据来源一致,统一数据的计算口径。
另外可以提前对数据进行交叉验证,即明细层与不同维度层数据进行交叉验证,确保数据的一致性。

(6)离线、实时交叉验证

目前大多数情况下使用的数仓架构还是经典的Lambda架构,因此实时、离线指标不一致仿佛成为了数据开发人员的一个共识,导致出现一致性问题通常有以下几点原因:

  • 计算逻辑无法对齐,其原因有二:一、实时、离线是两个不同的数据团队成员开发,其对业务的理解不同;二、离线逻辑本身相对比较复杂,可以做很多补偿逻辑,实时处理却相对比较简单;
  • 数据源不一致,通常接入的数据源有日志与binlog,binlog基本都能保证一致,但是对于日志在一些场景不能做到完全一致,例如风控场景提供的点击日志提供下游使用,实时、离线反作弊模型差异导致风控过后的数据存在差异;
  • 离线、实时技术栈对一致性的支持程度不同,离线通常都是批处理的调度模式,当出现异常情况,只需要重新调度直接进行分区覆盖即可,而实时处理本身对消息处理的顺序性有比较高的要求,另外加上端到端一致性实现复杂等等,在某些场景并不能保证与离线同等的一致性。

针对以上问题,提供两种思路:第一种是预先实时、离线指标对比,找到其中产生数据gap的原因并且解决, 尽量降低实时与离线之间的差异,同时也可以提前说明实时指标准确率;第二种流批一体的架构,流批一体可以从计算统一,也可以是存储统一,这里主要介绍流批一体的OLAP架构,只需要将数据实时或者离线写入OLAP存储引擎中,直接在OLAP进行分析,这种方式弱化了离线、实时的概念,例如Hologres 、Doris等


数仓指标一致性

如何保证

数仓指标一致性如何保证






相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
1天前
|
存储 SQL 分布式计算
闲侃数仓优化-大数据治理和优化
闲侃数仓优化-大数据治理和优化
9 0
|
16天前
|
存储 监控 数据挖掘
如何评估并优化OLAP系统的性能和可扩展性?
【5月更文挑战第14天】如何评估并优化OLAP系统的性能和可扩展性?
12 0
|
16天前
|
C++
数仓模型建设
数仓模型建设
|
16天前
|
数据挖掘 数据库
离线数仓6.0--- 数据仓库 ER模型-范式理论,维度模型、维度建模理论之事实表、维度建模理论之维度表
离线数仓6.0--- 数据仓库 ER模型-范式理论,维度模型、维度建模理论之事实表、维度建模理论之维度表
149 0
|
16天前
|
SQL OLAP 数据库
OLAP多维语义模型(一)
在使用Python创建OLAP多维数据模型并进行OLAP多维分析的过程中了解什么是OLAP多维语义模型。
45 0
OLAP多维语义模型(一)
|
6月前
|
运维 关系型数据库 OLAP
阿里云百炼 x AnalyticDB向量引擎, 搭积木式轻松开发专属大模型应用
对大模型应用跃跃欲试,但奈何技术栈复杂难以下手?已经进行试水,但缺乏调优手段无法保障召回率和问答准确度?自行搭建大模型、向量检索引擎、服务API等基础组件难以运维?大模型种类繁多,但缺乏行业模型和应用模板?阿里云百炼 x AnalyticDB向量引擎推出一站式企业专属大模型开发和应用平台,像搭积木一样轻松完成企业专属大模型应用的开发,提供应用API,可一键接入企业自己的业务应用对外提供服务。
926 0
|
9月前
|
存储 人工智能 大数据
向量数仓助力大模型应用落地三部曲
在第14届中国数据库技术大会(DTCC 2023)上,阿里云原生数据仓库 AnalyticDB PostgreSQL 版提出了向量数仓能力和解决方案,助力企业在大模型时代实现数据架构升级。根据真实用户落地经验,总结出企业落地大模型应用的三个阶段。下文将详述大模型应用落地不同阶段数据架构的设计与思考。
27734 14
向量数仓助力大模型应用落地三部曲
|
11月前
|
大数据 数据管理 数据库
数据仓库(3)数仓建模之星型模型与维度建模
维度建模是一种将数据结构化的逻辑设计方法,也是一种广泛应用的数仓建模方式,它将客观世界划分为度量和上下文。度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称之为维度。它与实体-关系建模有很大的区别,实体-关系建模是面向应用,遵循第三范式,以消除数据冗余为目标的设计技术。维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化的设计技术。
404 1
|
SQL 分布式计算 监控
《Apache Flink 案例集(2022版)》——2.数据分析——BIGO-BIGO使用Flink做OLAP分析及实时数仓的实践和优化(上)
《Apache Flink 案例集(2022版)》——2.数据分析——BIGO-BIGO使用Flink做OLAP分析及实时数仓的实践和优化(上)
457 0
|
消息中间件 SQL 大数据
《Apache Flink 案例集(2022版)》——2.数据分析——BIGO-BIGO使用Flink做OLAP分析及实时数仓的实践和优化(下)
《Apache Flink 案例集(2022版)》——2.数据分析——BIGO-BIGO使用Flink做OLAP分析及实时数仓的实践和优化(下)
495 0
http://www.vxiaotou.com