数仓构建流程

这并不是一篇教你如何建设数据仓库的技术干货，但是不管你目前在的公司有没有数据仓库，就职于业务部门还是数据部门，相信数仓的构建思路都能给到你一定的启发。

如：我续费了一年的视频会员，在我付完款后，视频app里的会员状态就要及时更新

如：用户每次续费视频会员时，数据仓库需要记录下每次状态的改变，以用于后续场景的复现和分析。

因此，业务系统和数据仓库面向的用户及其需求是完全不一样的。

• 关联取数效率低

业务系统的数据库设计基本满足三范式，因此取数分析时需要关联很多的数据表才能得到想要的数据，比较麻烦，而且数据还无法复用，导致分析效率比较低。

• 无法支持某些分析场景

基于业务系统数据的特性，往往不能支持某些场景的分析。业务系统不记录历史数据，只保留当前状态，比如我们想知道某个视频会员从试用、开通、使用、到期这段时间内的完整情况，但是业务系统里只有最新的会员等级和到期时间，是无法支持这种场景下的分析的。

1）我们收集了海量的数据，但是一直无法充分利用起来

2）我们需要以各种方式方便的对数据进行处理

3）业务/运营/销售/分析/算法需要更加方便的获取数据

4）我需要随时随地了解企业的经营状况， 并将最值得关注的内容展示给我

5）会议自始至终争论的是谁的数据正确，而不是聚焦于分析和决策

6）希望管理者能够使用数据来制定基于事实的决策

而以上问题构成了数据仓库系统的基本需求。

数据总是用于两个目的，业务系统的应用和分析决策的制定。将数据纵向分层，将一个复杂的数据处理任务拆解成多个步骤来完成，每一层只处理一个步骤，简单且容易理解。

• 数据引入层（ODS，Operational Data Store）

• 数据公共层（CDM，Common Dimenions Model）

• 数据应用层（ADS，Application Data Store）

数据公共层（CDM）：维度表（DIM）、公共汇总层（DWS）、明细事实表（DWD）

以维度模型方法作为理论基础，提高明细数据表的易用性，提升公共指标的复用性，减少重复加工。

数据应用层（ADS）：数据产品和数据报表的数据来源

ODS层中的数据与业务数据库中的数据基本保持一致。业务系统是按照流程组织数据的，为保证流程的完整和使用的方便，并没有按照业务的本质来组织数据，不适合做分析和挖掘。

对于数仓来说，最重要的就是CDM公共层，从业务完整性的角度出发，不考虑系统流程，重新组织数据。公共层的目标是建设一套覆盖全业务域、涵盖所有历史数据的企业数据体系，利用这套数据体系可以还原企业在任意时刻的业务运转状态。

建设CDM公共层最常用的技术就是维度建模，因为它更适合大数据时代数据量巨大的特点。简单来说，就是一张事实表+多张维度表。

与业务系统的数据结构对比，我们可以发现，维度建模有以下特点：

1）模型简单易理解

站在业务的角度上，用“一张事实表+多张维度表”的模式组织数据，仅有维度、事实两种类型数据。可以简单的理解星型模型，就是我们把where和group后面的字段放入维度表中，把sum和count中的字段放入事实表中，并在事实表中加入维度的键值用于关联。

2）可扩展性好

可以在不改变数据粒度的情况下，方便地增加新的分析维度和事实，不会影响正在使用的报表和数据应用。

4）数据冗余