数仓分层的意义
隔离原始数据
不论是数据的异常还是数据的敏感性，是真实数据于统计数据解藕开
清晰数据结构体系
每一个数据分层都有它的作用域，这样在使用表的时候能更方便的定位和理解。
数据血缘追踪
由于最终给业务呈现的是一个能直接使用的业务表，但是表的数据来源有很多，如果有一张来源表出问题了，我们希望能够快速准确的定位到问题，并清楚它的影响范围，从而及时给到业务方反馈，从而将损失降到最低。
减少重复开发和资源浪费
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算；
清晰明了的结构使得开发、维护的成本降低；
减少重复计算和存储的资源浪费；
复杂问题简单化
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
数仓各层级说明
层级 | 说明 | 描述 | 数据共享权限 |
ODS | 原始数据层 | 存放未经过处理的原始数据至数据仓库系统，结构上与源系统保持一致，是数据仓库的数据准备区，数据原则上全量保 | private |
DWD | 明细数据层 | 以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表。数据粒度一般保持和ODS层一样的，并且提供一定的数据质量保证。同时为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。同时在此层会采用明细宽表，复用关联计算，减少数据扫描（逻辑事实表） | public |
DWM | 中间明细层 | etl处理过程中的桥接表,临时表，另外一些业务域的聚合统计需求时，也建议放到这一层 | |
DWS | 公共汇总层 | 以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。 （汇总数据层 + 主题宽表） 公共汇总粒度事实层的表通常也被称为汇总逻辑表，用于存放派生指标数据。 {entity}_action_tablename nft_config | public |
DIM | 公共维度层 | 基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。维度层的表通常也被称为维度逻辑表。
一般是用户资料表、商品资料表等类似的资料表。数据量可能是千万级或者上亿级别。
一般是配置表，比如枚举值对应的中文含义，比如国家、城市、县市、街道等维表。数据量可能是个位数或者几千几万。 | public |
DM | 数据应用层 | 也叫DM(数据集市)或APP层等，面向实际的数据需求，可以直接给业务人员使用，以DWD或者DWS层的数据为基础，组成各种统计报表。除此之外还有一些直接的表现形式，例如主题大宽度表集市，以及横表转纵表等。 | public |
数仓各层级的注意事项和分层原则
ods层：
（1）保持数据原貌不做任何修改，起到备份数据的作用。
（2）数据采用压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
（3）创建分区表，防止后续的全表扫描
（4）增量数据，全量数据两种同步方式
dwd层：
明细事实表设计原则：
通常，一个明细粒度事实表仅和一个维度关联。
尽可能包含所有与业务过程相关的事实 。
只选择与业务过程相关的事实。
分解不可加性事实为可加的组件。
在选择维度和事实之前必须先声明粒度。
在同一个事实表中不能有多种不同粒度的事实。
事实的单位要保持一致。
谨慎处理Null值，建议用0填充。
使用退化维度提高事实表的易用性。
dws层：
公共汇总事实表设计原则：
数据公用性
比如，汇总的聚集表能否与他人公用？基于某个维度的聚集是否是数据分析或者报表中经常使用的？如果满足这些情况，我们就有必要把明细数据沉淀到汇总表中。
不跨数据域
数据域是在较高层次上对数据进行分类聚集的抽象，如交易统一划到交易域下，商品的新增、修改放到商品域下。
区分统计周期
表命名上要能说明数据的统计周期，如_1d 表示最近1天，_td 截止到当天，_nd 表示最近N天。
避免多个层级的数据
应该避免将不同层级的数据放在一起，比如，如果存在7天和30天的事实，我们可以选择用两列存放7天和30天的事实，但是需要在列名和字段注释上说明清楚。同时我们也可以使用两张表分别存储不同统计周期的数据加以区分。
聚集是不跨越事实的
聚集是针对原始星型模型进行的汇总，为了获取和查询原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨事实的。横向钻取(交叉探查)是针对多个事实基于一致性维度进行的分析，很多时候采用融合事实表，预先存放横向钻取的结果，从而提高查询性能。因此融合事实表是一种导出模式而不是聚集。
dim层：
在设计公共维度表时需要考虑：
维表中数据的稳定性。
例如，A公司电商会员通常不会出现消亡，但会员数据可能在任何时候更新，此时要考虑创建单个分区存储全量数据。如果存在不会更新的记录，您可能需要分别创建历史表与日常表。日常表用于存放当前有效的记录，保持表的数据量不会膨胀；历史表根据消亡时间插入对应分区，使用单个分区存放分区对应时间的消亡记录。
维表是否需要垂直拆分。
如果一个维表存在大量属性不被使用，或由于承载过多属性字段导致查询变慢，则需要考虑对字段进行拆分，创建多个维表。
维表是否需要水平拆分。
如果记录之间有明显的界限，可以考虑拆成多个表或设计成多级分区。
核心维表的产出时间。通常有严格的要求。
维度属性尽可能的齐全
ads层：（业务推动）
实现流程
理清需求，了解业务方对数据内容、使用方式(怎么交互的，报表、接口、即席查询、在线查询、指标查询、搜索)、性能的要求。
盘点现有的数仓表是否可以支持，看以前有没有类似的需求，有没有可以复用的接口、报表什么的。
代码实现，选择合适的存储引擎和查询引擎，配置线上监控然后交付。
使用场景与性能
针对业务方的使用场景，我们需要设计出高效，满足要求的ADS 层表；
如果是多维分析，为了减少连接，提升性能，我们一般采用大宽表设计，使用高性能引擎支撑；
如果是特定指标查询，一般采用KV的形式组织；
如果是搜索场景，一般采用搜索引擎；
数仓层级调用规范
禁止反向依赖（如DWS->DWD）
ODS 只能被 DWD 调用。
DWD 可以被 DWS 和 ADS 调用。
DWS 只能被 ADS 调用。
数据应用可以调用 DWD、DWM、DWS、ADS，但建议优先考虑使用汇总度高的数据。
ODS->DWD->DWS>ADS
ODS->DWD->ADS
