数仓架构、模型设计与优化、开发规范

数仓架构

1、数仓架构分3部分:业务层、数仓层(细分:ods/dwd[dim]/dws/ads)、业务调用层
2、数仓层只做数据清洗、数仓建模,不涉及业务调用相关的内容
w’t# 模型设计思路总结
1、设计单一业务过程事实表扩展计算某个指标[事实表可能会进行维度退化,要结合查询性能和数据存储考虑(详细说说?待补充)]
2、设计大宽表计算跨多个业务过程的复杂指标[要考虑下游模型调用的频次、存储空间、查询性能来判断(详细说说?待补充)
3、周期快照表设计方式?(分区、字段设计),应用场景?
4、拉链表的设计方式?(分区、字段设计),应用场景?

5、设计大宽表时,把每个表的主键id加进去,方便排查和追溯
6、dws 层计算尽量不要要多事实表关联聚合,若需要跨多业务过程计算指标可以考虑库设计dwd明细宽表(特别是实时数仓,可以避免业务过程数据频繁更新导致状态过大和数据乱序问题)

数据存储设计

1、ods层:尽量与业务模型保持一致,使用行式存储与压缩(采用行级存储压缩的原因是因为dwd基于ods的计算一般都是全表扫描,使用行级存储可以加快查询与计算性能)
2、dwd层只包括明细指标、按列式存储压缩(dws基于dwd计算大多数情况下,只会查询部分字段进行聚合,而且可能会提前过滤数据,用列式存储可以加快数据过滤(因为列式存储有索引))
3、dws层:按通用维度做轻度聚合、按列存储压缩
4、ads层:因为提供外部应用查询,一般是按行查询,可以使用行式存储
行列存储参考:https://blog.csdn.net/weixin_36755535/article/details/126579818

开发规范

表名定义规范

/

字段命名(字段类型)规范

1、ods层尽量与业务保持一致
2、dwd层一定一定要进行字段命名、数据类型一致性命名和设计,保证数仓独一份,避免同名不同义的情况

指标一致性规范

1、业务过程打标或明细指标只能沉淀在明细层,下游只能使用不能重新定义,若是紧急开发可以先开发,后续必须迭代沉淀到明细层
2、跨多个业务过程的指标,建议构建公共模型并进行沉淀,统一指标计算口径

维度一致性规范

1、维度表要设计到最细粒度,而且一个维度只能再一个维度表中存在,若有特殊情况要特别说明原因或独立一个维度表,特殊使用

离线数仓模型构建的简单见解

1、业务数据与架构变化情况说明

1、历史数据可以做更新、删除操作 ,当前数据会与历史数据有关联关系
2、业务数据库表表结构经常变动
3、业务库非公共字段存储为json字符串
4、业务库架构不稳定,经常出现业务库模型重构
5、不同业务线,业务库表数据会出现:一表一类或一表多类或两者并存的数据
6、json 字符串中会嵌套json数组
7、针对大表, 业务库分当前表+历史表

2、数据分层说明

2.1 ods层模型说明

1、业务事实数据说明:
	1.1 存在当前表+历史表
	1.2 表数据存在json、ltree(树形结构)等特殊类型
	1.3 json 字符串中会嵌套json数组
2、操作说明:同步业务库数据,不做其他操作

2.2 dim层模型说明

分两层计算:json字符串解析打宽;业务库表数据合并的进行拆解成多表或合并为单表
2.2.1 json 解析打宽成json基础表与分类拆解或合并
1、解析json字符串, 展开成一行或多行【若出现json数组,根据业务分析是展开数据还是不展开数据】 ; 此处一般不展开或业务
2、字段命名不变, 便于验证数据一致性
3、json字符串展开一行,便于验证数据一致性
4、增加筛选条件,过滤脏数据
5、若ods表不存在多表关联打宽维度表的情况,则需要规范化字段命名、数据类型等(见名知意),方便dwd 、dws 层调用,
6、若多种分类字段差别不大,可以合并在一起(union all)
7、维度表存储多种分类,且json存储的字段存在比较大的差异,就拆解成多个分类,分类解析并写入到不同的维度表
2.2.2 json基础表规范化处理与业务打宽
1、若出现json基础表多表关联维度打宽时, 需要规范化字段命名、数据类型等(见名知意),方便dwd 、dws 层调用
2.2.3 不包含json等其他嵌套字符串业务打宽
1、单表出维度表,需要规范化字段命名、数据类型等(见名知意),方便dwd 、dws 层调用
2、直接使用ods层表,多表打宽出维度表 , 需要规范化字段命名、数据类型等(见名知意),方便dwd 、dws 层调用

2.3 dwd 层数据说明

1、基于ods存在 当前表 + 历史表 , 数据分两步处理:
	1.1 表合并:当前表+历史表合并,且去脏数据;
	1.2 数据ETL操作:字段命名、数据类型等规范化

2、表可能存在json数据, 解析逻辑参考:dim 层的json处理逻辑 ;针对json数组, 尽量只展开一行,方便计算与数据验证 ; 只展开一行,减少了数据重复,减少了数据犯错的可能性

	说个题外话:ods 存在json数组, dwd 解析json成单行,dws 解析成多行, 原始需求是:根据json数组中的某个维度拆解成多行计算统计报表(dws统计所得),, 后期业务需求变更成按外部表维度字段统计,在报表不能下线的前提下要快速解决:
	解决方案:直接从 dwd 表出,数据验证,通过发布,一个人半个小时解决(5个报表的修改、验证)

2.4 dws 层模型说明

1、若dwd 表字段数据已经全部展开,关联dim 、dwd 表按维度打宽;尽量包含更多的维度字段;[离线可以把维度名称加上去,实时计算最好不要把维度名称加上去, 减少因名称修改导致数据回撤重算问题(下一篇再写dim 表存在维度名称实时数据回撤重算的解决方案)]

2、若dwd 存在未完成解析展开的json数组或其他特殊字段,直接对按维度展开统计

2.5 ads 层模型说明

/

3、存在的问题与解决方案

/

4、遗留问题

/

模型设计与优化

1、事实表优化 - 解决聚合列空值数据数据倾斜

现象说明:当某一列用于聚合计算时,若列中有空值,会出现数据倾斜
优化方法:聚合列空值使用”“零值或其他字符串填充

2、模型设计 - 代理键设计

自然键:业务表的主键
代理键:表的主键,一般由业务表的多个自然键拼接组成(实时数仓)
代理键设计:新增一列作为表代理键,减少数仓对业务模型的依赖;减少数仓后期维护成本,同时减少后期返工工作

3、维度表模型 - 维度属性设计(扁平化)

1、针对固定深度的维度层次,建议采用扁平化设计,尽量避免使用雪花模型(雪花模型不利于查询性能);
2、扁平化设计的好处:维度表属性占用的空间一般对于事实表占用的空间相对比较小,可以牺牲空间来改善性能和可用性(多维度过滤不用关联多个表查询)

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值