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