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