「06」数据仓库基础知识

上周我们简单介绍了埋点相关的基础知识。

按照数据链路的走向，咱们今天来讲讲数据仓库的基础知识 。

什么是数据仓库？

数仓，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代表的具体的含义，可以在这种 配置属性数据 的维度表格中映射出来。

分层咱们知道了，那么如何根据分层来构建规范的命名呢？

笔者抛砖引玉，提供一些参考。

我们在表名中，一般需要以下几个信息：

1. 所属业务域：是什么业务线？是什么产品线？

2. 所属主题域：是业务域中的用户数据？还是订单数据？

3. 数据分层：在ODS/DWD/DWS/ADS/DIM中属于哪一层？

4. 存储粒度：是全量还是增量？增量周期是多少？

5. 自定义标签：当前数据的业务过程定义

... ...