什么是数据仓库？
数仓，DataWarehouse，是一个 面向主题的、集成的、稳定的、与时间相关的 数据集合。
而这个数据集合的建立，是为了支持管理者的决策过程。
也就是说，我们通过建设数仓，为业务中的流程改进、成本计算，产出收入等环节，提供相应的决策指导及流程监控。
数仓有什么特点？
• 面向主题性
数仓中的所有数据，都是面向特定的业务域而产生的。
比如，某电商APP，就会有面向用户的数仓，面向订单的数仓，面向商品的数仓
我们在建设数仓时，需要在较高层次上把业务拆分为各个域，我们用数据的方式，去定义了这个域，就有了数仓中的面向主题性。
• 集成性
面向主题性中我们说到，我们的数据需要对应不同的业务域。
那每个业务域中的每个事件产生的数据，都会有最初的底层数据库。
怎么通过这些数据库，抽取我们想要的业务域，集成一个可描述的，有层级的，完整的数据集合，就是数据仓库的建立过程。
这个过程，其实就是抽取零散业务数据构建集合的过程。
所以，数据仓库具有集成性。
• 稳定性
物理上，数据存储需要稳定性。
业务上，我们要保证数仓建设的结构清晰，层次分明，从而保证整体数仓结构的稳定性。
通俗来说，就是保证数仓结构不要频繁变更。
• 与时间强相关
从物理存储上说，数据仓库随着时间和业务的变化，会不断往里追加数据内容，也会不断删掉旧的数据内容。数仓中的每个表格，都会有对应的"生命周期"。
从业务意义上说，数据仓库反应的是，某一段历史时间内，业务在数据上的表现情况。
数仓的建设方式有哪些？
• K 模式
大家可以去搜索一下 Ralph Kimball 这个大佬，他提出的数据仓库架构中的 key模式（敏捷模式），即：关键个体角色目标驱动。
这种方式总体来说，就是明确短期需求后，直接开干。
因为直接开干，所以前期我们整体投入小，见效快。
但是随着业务的发展和迭代，后期肯定需要重构。而重构的成本往往都很高。
• I 模式
这又是另一个大佬提出的架构理论，大家可以搜一下 Bill Inmon，他提出的information模式（瀑布模式），即：领域经验知识驱动。
这个和K模式相反，强调前期强规划，一定要想清楚长期目标和需求，再干活。
这种方式，前期投入的成本会高出很多，我们需要规划业务域，数据域，数据层次，表结构等等。
但是后期，整体效果会比K模式好，只是前期见效慢。
整体来说呢
建议前期业务初步发展阶段，先用 K 模式， 但是也要有一个I模式的规划
即：业务发展到什么节点，我们需要开始I模式的搭建。这个需要有个明确的规划。
笔者曾经就有 跑着K模式，后期重构了3次才全部切换成I模式的经历。所以一定要提前做规划。
数仓的层级有哪些？
开局先上图：
从图中我们可以看出，大致可以分为4层：ODS + DWD + DWS + ADS
其中，DWD 和 DWS 可以统一至 CDM层。
当然，我们还需要对应的维度数据：DIM层
ODS层：操作数据层（Operational Data Store），基本上是数据的源头，我们在这一层只做简单的数据清洗，不做业务逻辑处理，存储所有我们能够存储且需要存储的数据。
DWD层：明细数据层（Data Warehouse Detail），一般和ODS层一样，但是会采用维度退化的方法，将维度退化至事实表中，减少事实表格和维度表格的关联，提高表格的易用性。
DWS层：汇总数据层（Data Warehouse Summary），按照主题划分，采用宽表化的手段，构建对应主题下的数据，用于后续业务的查询。
ADS层：应用数据层（Application Data Store），主要存放数据需求中的个性化统计指标。这一层一般面向展示使用。不同需求下的，不同粒度的，个性化统计指标数据。
DIM层：维度表，一般会有2种数据。
一是业务相关的业务属性数据，如用户画像，商品价格。
二是数据中的配置属性数据，如在某表格的 类型 字段中存储了A，A代表的具体的含义，可以在这种 配置属性数据 的维度表格中映射出来。
分层咱们知道了，那么如何根据分层来构建规范的命名呢？
笔者抛砖引玉，提供一些参考。
我们在表名中，一般需要以下几个信息：
-
所属业务域：是什么业务线？是什么产品线？
-
所属主题域：是业务域中的用户数据？还是订单数据？
-
数据分层：在ODS/DWD/DWS/ADS/DIM中属于哪一层？
-
存储粒度：是全量还是增量？增量周期是多少？
-
自定义标签：当前数据的业务过程定义
... ...
举个例子（以某淘中的订单优惠券数据为例）：
mtao_dwd_orders_coupon_day
业务域 + 数据分层 + 主题域 + 自定义标签 + 存储粒度
当然，这仅是抛砖引玉，大家可以按照自己的业务情况，建设相关的规范，适合自己业务最重要。