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

数仓架构

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、扁平化设计的好处：维度表属性占用的空间一般对于事实表占用的空间相对比较小，可以牺牲空间来改善性能和可用性（多维度过滤不用关联多个表查询）