01.ODS--数据计算层，这一层作为原始数据层
目前命名 qmc_da qmc-dc qmc_dd
以后的命名方式
02.CDM层--
DWD层-公共明细层
DWS层- 公共汇总层
03.ADS层
应用层-- MySQL以及HBase
说明：
操作数据层--也就是我们放在Hive中的源表
公共维度模型层：
这层的话，我们是没有计算的
这层的话，会把一些维度--采用维度退化的方式吧数据放到 明细事实表中，减少计算的关联
主要是复用关联，减少数据的扫描
应用数据层： 这层是根据ODS直接计算得出的，以后可以根据ODS层以及CDM层计算出来
2.需要考虑的问题
01.ODS层
Hive目前采用的是内部表，存在误删除的潜在风险，容易造成数据丢失。可以加强的手段是权限控制。
目前考虑是否改成外部表，
如果有操作失误，比如删表之类的操作，外部表只删除元数据，不涉及处理后的源数据
02.CDM层的相关内容
CDM层这层目前没有，是把应用层往下移，还是怎么处理？
目前分层的情况，是否需要考虑之前的数据的迁移改变，还是说老表老办法，新表新办法，
CDM层的考虑的问题
01.数据是否分库以及如何分库
02.维度表的处理-
提取公共维度表
维度表中--把用户的原始数据推断出的新维度计算出来
缓慢变化维的处理方式：同一ID对应的维度值变化，是采用哪些方式处理
新增字段的处理
03.对流量表中常见的业务的处理
明细是否要将一些维度加在内？
明细的结构--如何抽象出
明细的计算：如何确保本层数据计算执行的稳定性以及故障发现和恢复
04.CDM确定的原则和方法
原则：
高内聚和低耦合
核心数据和扩展数据--数据分安全和价值等级
命名规范-易于开发和使用
方法：维度建模
步骤
需求调研--
一是和业务人员沟通，
二是对目前报表以及数据营销平台的报表进行分析
确定根据什么汇总，以及汇总哪些数据-明细和汇总数据如何设计
模型设计：
……
推断信息加入到原始流量表中--例如用户的年龄
事实表--维度退化
关于维度表
方式一：
如两三个表都有产品名这个维度，提出来。维度key，和对应的维度值
相应的字段- 表，维度和维度对应的key值
例如：
表 维度key 维度Value
act productName ltcp
act productName yccp
act platform iOS
….
方式二：
维度类型
维度类型 维度子ID 维度父ID
1 ltcp3 lt
1 ltcp5 lt
1 yccp yc
3.使用的方式：
数据调用服务--优先使用CDM数据，当这层没有的时候，评估是否需要创建，如果不需要，再使用ODS层
4.附录：
01.名词术语解释：
ODS <Operational Data Store> 操作数据层
CDM<Common Dimension Model > 公共维度模型层
DWD<Data Warehouse Detail>明细数据层
DWS<Data WareHouse Summary> 汇总数据层
ADS<Application Data Store> 应用数据层
02.维度建模
03.规范定义
表命名规范
特殊情况的考虑
缓慢变化维（Slowly Changing Dimensions）
指的是：维度表里面的数据并非是始终不变的，总会随着时间发生变化。
缓慢渐变类型一 (Type 1 SCD)：
在数据仓库中，我们可以保持业务数据和数据仓库中的数据始终处于一致。可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变化那么就将旧 的业务数据覆盖重写。
缓慢渐变类型二 (Type 2 SCD)：
**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**
**[需要这份系统化的资料的朋友，可以添加戳这里获取](https://gitee.com/vip204888)**
**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**
