数据仓库建模方法 - 长表模式系统实践

* 数据仓库构建难点:

1.主题的准确划分,需要经常进行表的整合,有些表因为别人使用而无法废弃,表的数量越来越多

2.数据库每个主题都有多张表,对使用方需要维护一个表说明清单,查询指标需要依赖额外的工具平台(会查到很多非自身业务的无效信息)

3.不断增加的指标造成表的代码逻辑不断增大,关联表不断增加,性能下降,维护难度增加

4.多层次的模型,导致每增加一个指标都需要在多个层次的表中同步维护,人力成本高

5.hive无法删除字段,变更表结构要刷新分区

以上这些问题基本都是基于宽表造成的,所以可以换个思路用长表来解决。

* 设计思想:

一、数据仓库开发表

<1>开发层大长表

每个大主题有一张对应的长表,分支主题则基于label分区开发。一个主题下的所有特征都维护在一张长表中,多维度特征就整合为多层级的字典json格式。以最低的冗余度存储开发数据。

CREATE EXTERNAL TABLE `platform_dw.platform_dw_sr_dw_user_item_info`(

  `user_id` bigint COMMENT '用户ID',

  `attr_key` string COMMENT '项目名',

  `attr_value` string COMMENT '项目内容')

PARTITIONED BY (

  `dt` string,

  `label` string)

<2>特征维度表

将数据集市所有特征信息以字典形式人工维护到一张表,对使用方能提供统一的特征接口,不用维护额外的文档管理数据表。

特征维度表也为整个集市的监控和综合信息表服务。开发者基于这张表也能够避免重复特征的开发,以及差异化特征的集中说明。主题的划分也是其重要功能。

CREATE EXTERNAL TABLE `platform_dw.platform_dw_sr_dim_feature_info`(

  `feature_en` string COMMENT '特征英文名',

  `feature_cn` string COMMENT '特征中文名',

  `data_type` string COMMENT '数据类型',

  `is_json` int COMMENT 'json格式标识',

  `subject` string COMMENT '主题',

  `partition_dev` string COMMENT '开发分区',

  `task_id` string COMMENT '开发任务ID',

  `owner` string COMMENT '所属者',

  `update_time` string COMMENT '更新时间',

  `description` string COMMENT '描述')

PARTITIONED BY (

  `label` string)

<3>开发中难免需要落地一些实体表保留数据为后面提供支持

比如:

1.各大主题都需要一张控制数据量的主表,需要单独建立任务,方便后续依赖关系的维护

2.复用的轻度聚合表


二、综合信息表

基于前面的长表,建立一个将整个大主题汇总的表,除了主键其余字段全部拼接在一起处理为json格式(字典型),方便查询使用。

示例:

CREATE EXTERNAL TABLE `platform_dw.platform_dw_sr_dm_user_info`(

  `user_id` bigint COMMENT '用户ID',

  `info_json` string COMMENT '综合信息')

PARTITIONED BY (

  `dt` string)


三、大宽表

长表无法直观查看是其一大缺点,综合信息表因为拼接格式问题缺乏稳定性,加之使用方习惯使用宽表格式,所以按照仓库的习惯对外提供一张大宽表,使用长表作为数据源,可以简单的维护和拓展特征。

示例:

insert overwrite table platform_dw.platform_dw_sr_dm_user_info_wide partition (dt='${day}')

select

user_id,

cast(max(case when attr_key='age' then attr_value end) as int) as age,

cast(max(case when attr_key='order_amt' then attr_value end) as double) as order_amt

from dm_user_item_info

where dt='${day}'

group by user_id

;

说明:大宽表因为涉及刷数据的问题,所以定期更新,如果急需使用刚开发的特征,也可以用上面的逻辑从长表里提取使用。


四、监控体系

1.对特征维表和开发层特征的监控,防止维表维护缺失,以及开发层特征生产丢失

2.对特征重复值、覆盖量的监控,可以有效监控特征的有效性,和开发时的特征名、开发分区覆盖情况

3.对大宽表和应用表的监控,监控其数量、主键重复和指标空值情况

你可能感兴趣的:(数据仓库建模方法 - 长表模式系统实践)