数仓分层
1、概述
数据仓库中,常见的分层包括ods、dwd、dws、dwt、ads、dim
等
2、传统上的数据分层
早期的大数据平台是以hadoop为核心,数据开发也是以MapReduce为主,hive等sql类开发很少见。
因为当数据从多个源头采集上来之后,格式化便成了原始数据。
原始数据经过MapReduce的开发之后,生成各个报表。然后统一导入到mysql或者oracle中,便可以直接看到报表。
在数据量相对较小并且看数据的人较少时,这种方式是非常高效且实用的。
但是,别的部门在看到hadoop的性能之后,放弃了原有编写的数据库脚本,转而将逻辑应用了进来,这时候平台就不可避免的增加负荷。各种逻辑杂糅使得逻辑变得模糊不清,这时候需要做功能上的耦合。
公司的规模一路飙升,数据团队也从几个人快速增长到了十几个人,架构也发生了更多的变化,这个时候你就意识到了,我们可能要有一套系统的理论来组织数据仓库了。
3、标准分层
阿里云数仓分层解决方案
4、命名规范
- 表命名
- ODS层命名为:ods_表名
- DWD层命名为:dwd_dim_表名、dwd_fact_表名
- DWS层命名为:dws_表名
- DWT层命名为:dwt_表名
- ADS层命名为:ads_表名
- 临时表命名为:表名_tmp
- 用户行为表命名为:表名_log
- 脚本命名
- 数据源_to_目标_db/log.sh
- 用户行为脚本以log为后缀
- 业务数据脚本以db为后缀
5、为什么要分层
- 把复杂问题简单化
将复杂的任务分解成多层来完成,每一层只处理简单的任务,方便定位问题
- 减少重复开发
规范数据分层,通过中间层数据,能够极大的减少重复计算,增加一次计算结果的复用性
- 隔离原始数据
不论是数据的异常还是数据敏感性,使真是数据与统计数据解耦。
6、各层详细解释
- ODS
- 保持数据原貌
- 采用压缩(压缩比一般100g数据压缩完10g左右)、列式存储
- 创建分区表
- DWD
- 数据清洗
- 去除空值
- 过滤核心字段无意义的数据(如:用户id为null)
- 清洗手段
- sql
- mr
- rdd
- kettle
- py
- 清洗掉多少数据算合理
- 1万数据清洗掉1条
- 脱敏
- 对手机号、身份证号、密码等敏感数据脱敏
- 维度退化
- 对业务数据传过来的表进行维度退化和降维(如:商品一级二级、省市县、年月日)
- 采用压缩、列式存储
- 创建分区表
- 数据清洗
- DWS
- 有3-10张宽表(能处理70%以上的需求)
- 用户行为宽表
- 商品宽表
- 登录注册宽表
- 用户购买商品明细宽表
- 购物车宽表
- 售后宽表
- 异常错误宽表
- 有3-10张宽表(能处理70%以上的需求)
- ADS
- 指标层
7、总结
- 关联范围广
在很多时候,有些数据是需要跨多个业务线的,每个业务线的数据都很大,这时候不仅是计算逻辑复杂无比,一个SQL几百行,而且对于数据倾斜的问题挑战更大,Hive运算的时间也非常长。这种情况下需要适当考虑在运算节点中加入一些MR的运算过程,以提高计算速度,单纯的优化Hive SQL并不是一个好主意。
- 血缘关系
尽管DWS是统计中间层的数据,但由于业务的变化多种多样,一个中间层需要关联几张甚至十几张表,每张表都有自身的业务逻辑,关联很多,这就导致了一张完整的中间表上游特别多,发现某个数据异常时非常难以追溯问题。这时候你需要额外的技术支持:元数据平台(atlas),通过分析这张表的上游关联关系,来进行问题的定位。
- 产出时间长
某些DWS表动辄需要几个小时的计算时间,对于数据的准时产出影响很大。同时如果需要做小时级的报表统计,那么太过于复杂的中间层设计就显得很累赘。建议这个过程有产品经理的介入,以梳理需求的重要性和优先级,如果非必要统计,尽量的就不要做中间层,开放一些sql查询的权限也是可以的,这里做好数据安全管理即可。
- 重构难度大
分层理论尽管听上去容易理解,但真的需要到这个理论时,你所搭建的数据平台势必已经非常大了,而需要适应这套理论,原有的统计逻辑大多数都要重写,这里花上几个月的时间都是很常见的,并且很可能需要双平台同时进行数据计算,以渡过重构的不稳定期。这个阶段的挑战就是如何解释投入产出比,要有充分的的信心,详情这项工作完成后,节省的开发时间至少是一个数量级的。原来1天的开发工作,因为有了数据分层,1小时甚至几分钟,都是可以开发完的。
参考1:https://mp.weixin.qq.com/s/aPTzSuD9RaE3dLQm-fXi1w
参考2:https://www.aliyun.com/solution/datavexpo/datawarehouse?spm=5176.12825654.h2v3icoap.550.56c82c4aPRC8FK