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