我曾经和一个业务系统负责人聊起数据仓库，他感到很疑惑，“我们数据库里不是有现成的数据吗？你们数据分析师直接用就好了，为什么还要花人力物力去建设什么数据仓库”，最后甚至直接说“我们的数据库就是你要的数据仓库”。
为什么公司要建立数据仓库，而不直接使用业务系统保存的数据？
回答这个问题之前，我们先来看看业务系统数据库和数据仓库的区别。
业务系统需要确保自身的正常运转，并能快速的处理事务，因此一般是一次处理一个事务。通过与用户的交互，将注册信息、订单信息、活动状态、用户投诉等信息记录下来。业务系统只要根据既定的业务过程完成相应的任务即可，因此，业务系统通常不用维护历史数据，只需修改数据以反映业务的最新状态。
如：我续费了一年的视频会员，在我付完款后，视频App里的会员状态就要及时更新
而数据仓库用于分析企业的运营状况，计算新成交的订单金额，对比过去一个月找到成交金额波动的原因，通过用户提交的投诉找到用户不满意的根源。数据仓库不会一次只处理一个事务，因为用户的一次查询通常需要搜索成千上万条事务，并将查询结果放入到一个查询集合中。而且，为了满足更广阔的分析需求，数据仓库通常需要保存历史数据，以便于能精确评估公司在某一段时间内的经营情况。
如：用户每次续费视频会员时，数据仓库需要记录下每次状态的改变，以用于后续场景的复现和分析。
因此，业务系统和数据仓库面向的用户及其需求是完全不一样的。
业务系统的数据库设计基本满足三范式，因此取数分析时需要关联很多的数据表才能得到想要的数据，比较麻烦，而且数据还无法复用，导致分析效率比较低。
基于业务系统数据的特性，往往不能支持某些场景的分析。业务系统不记录历史数据，只保留当前状态，比如我们想知道某个视频会员从试用、开通、使用、到期这段时间内的完整情况，但是业务系统里只有最新的会员等级和到期时间，是无法支持这种场景下的分析的。
你可能经常在企业经营管理者口中听到这些：
1）我们收集了海量的数据，但是一直无法充分利用起来
2）我们需要以各种方式方便的对数据进行处理
3）业务/运营/销售/分析/算法需要更加方便的获取数据
4）我需要随时随地了解企业的经营状况， 并将最值得关注的内容展示给我
5）会议自始至终争论的是谁的数据正确，而不是聚焦于分析和决策
6）希望管理者能够使用数据来制定基于事实的决策
而以上问题构成了数据仓库系统的基本需求。
数据总是用于两个目的，业务系统的应用和分析决策的制定。将数据纵向分层，将一个复杂的数据处理任务拆解成多个步骤来完成，每一层只处理一个步骤，简单且容易理解。
将数据仓库分为三层：
数据引入层（ODS）：与目前业务数据库中的数据保持一致，方便核对数据，追溯源头。
数据公共层（CDM）：维度表（DIM）、公共汇总层（DWS）、明细事实表（DWD）
以维度模型方法作为理论基础，提高明细数据表的易用性，提升公共指标的复用性，减少重复加工。
数据应用层（ADS）：数据产品和数据报表的数据来源
数据分析师一般使用的是公共层，里面有维度数据，明细数据和轻度汇总数据，基本能满足各类分析需求。
ODS层中的数据与业务数据库中的数据基本保持一致。业务系统是按照流程组织数据的，为保证流程的完整和使用的方便，并没有按照业务的本质来组织数据，不适合做分析和挖掘。
对于数仓来说，最重要的就是CDM公共层，从业务完整性的角度出发，不考虑系统流程，重新组织数据。公共层的目标是建设一套覆盖全业务域、涵盖所有历史数据的企业数据体系，利用这套数据体系可以还原企业在任意时刻的业务运转状态。
建设CDM公共层最常用的技术就是维度建模，因为它更适合大数据时代数据量巨大的特点。简单来说，就是一张事实表+多张维度表。
当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故也将该模型称为星型模型。
与业务系统的数据结构对比，我们可以发现，维度建模有以下特点：
1）模型简单易理解
站在业务的角度上，用“一张事实表+多张维度表”的模式组织数据，仅有维度、事实两种类型数据。可以简单的理解星型模型，就是我们把where和group后面的字段放入维度表中，把sum和count中的字段放入事实表中，并在事实表中加入维度的键值用于关联。
2）可扩展性好
可以在不改变数据粒度的情况下，方便地增加新的分析维度和事实，不会影响正在使用的报表和数据应用。
4）数据冗余
构建维度表和事实表都需要大量的数据预处理，导致大量的ETL工作，并且可以看出，相比业务系统的精简，星型模型明显是“用空间换易用和效率”，存在大量的数据冗余。
京公网安备 11010802035086号