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

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

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

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

2.1 ods层模型说明2.2 dim层模型说明

2.2.1 json 解析打宽成json基础表与分类拆解或合并2.2.2 json基础表规范化处理与业务打宽2.2.3 不包含json等其他嵌套字符串业务打宽 2.3 dwd 层数据说明2.4 dws 层模型说明2.5 ads 层模型说明 3、存在的问题与解决方案4、遗留问题

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、遗留问题