ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 粗谈数据仓库的模型建设

粗谈数据仓库的模型建设

Linux操作系统 作者:penghaijun 时间:2014-03-01 23:32:47 0 删除 编辑

要换工作了, 趁今天休息,把上一个带的项目总结一下,发帖留念。数据仓库主要体现在模型的建设上,这里就主要说一下模型。

什么是模型

模型是所研究的系统、过程、事物或概念的一种表达形式,用以分析问题的概念、数学关系、逻辑关系和算法序列的表示体系。比如盖一工棚可不要模型,因为1个有经验的人独立或者带领1两人就可以改好,不需要和别人交流,但盖金茂大厦就不得不从设计图纸开始了。设计的图纸就是一个模型。模型是整个数据仓库系统建设的导航图,要实现一个稳定、灵活的数据仓库系统,模型是关键。

模型的设计

设计要求

涉及用户中,每个人关注的角度不同,公司决策者关注的是公司经营业务及相关的几个核心指标,各部门经理关注自己部门内管理使用的指标,不考虑与其他部门的统一。普通用户关注的是一张张报表的样式,而IT关注的是项目的预算,工作量等。总之要实施一个完整的数据系统,负责人就要能够站在全公司的高度,同时又要具备有效的融合业务需求和it技术的能力。设计人员要有较深的行业背景,了解行业先进和通用的标准和规范。同时又要结合公司内现有的信息系统情况,提出一个相对先进的模型。但不能太超前,脱离实际或者导致工期太长,也不能停留在现有公司的数据系统水平上,失去了建设的意义。要在管理,使用,扩展,维护等方面适度拔高。

三个阶段

从“自顶向下、逐步求情”的角度来看,建模在设计工程上可以分为三个阶段

概念模型;逻辑模型;物理模型

1.         概念模型设计:是为企业全局数据而建立的,集成了各个应用数据库的数据。主要基于原有数据库的数据,加以分析,组织。明确覆盖范围,对业务关系高度概括和归类,即明确主题域。该模型是由企业决策者,商务领域专家和IT专家共同跨领域分析的结果,是为逻辑模型的设计做准备的。过程并没有统一的标准,主要依靠设计者的经验。

2.         逻辑模型设计:是对概念模型的细化,是技术也业务人员很关心的一环,因为她能直接反应业务部门的需求,同时对物理模型实施有着指导作用。

3.         物理模型设计:对逻辑模型的物理实现,包括逻辑模型中表的落地,存储结构,软硬件的配置等

模型层次

下列描述主要用在ETL架构下,针对EL-T架构的工具和做法均不熟悉,这里不做评价。

标准的EDW模型层次总分为ODS+DW+DM,但这只是表面东西,做为设计者应该有更深一层的理解。

1.         Ods=ods_s+ods_t(过渡层+原子层)

 Ods_s:源数据处理层。主要是同步各源头系统数据,为ods_t层数据做准备。如无时间戳,可在一段时间内全量取;也可以采用一些软硬件工具根据日志来获得增量。不需要永久保留,如源头数据比较单一,数据戳比较完善,也可不需要这一层,直接到下一层。

 Ods_t:源数据汇总层。主要把数据相同但源不同的数据汇总到一起,并加上时间戳。保留历史数据和变化轨迹的基于源业务的三范式结构。时间戳分两对,一对表示源业务的有效期起止日期,一对表示进数据仓库的有效起止日期。

2.         Dw=dw_m+dw_f(通用语义层=扩展层+分析层)

dw_m:基于数据仓库的三范式结构。在一些小型的数据仓库项目中,可以把ods_s+ods_t+dw_m和为一层,他们的共性都是三范式结构。

dw_f:根据数据的产生频率和访问频率,设计出得一类事实表。和主题和行业和需求都有直接关系。是dm层数据运算的基础。针对使用目的的不同,这里包含两种类型表,概貌和实体。概貌为每条数据保留历史轨迹,实体为截止到指定时间的最新数据,从多个概貌表运算出来的结果。该层是面向分析主题的一种宽表的落地,也是一种列转行的一类关键信息记录。

举例:比如保险行业,针对保单可以分为承保清单(概貌),保单查询(实体)。

承保清单中保单批单分不同记录条数,并每条记录根据时间记录变化轨迹。保单查询根据保单号为主键,记录保单保费,最新保费,未到期保费,赔款以及其他维度等信息。

3.         Dm=dm_a+dm_r(集市层+应用层)

Dm_a:是面向一个部分或者一组分析做的一层汇总,可以理解为轻度汇总层。

Dm_f:是面向于具体应用或者某个报表的一层汇总,可以理解为高度汇总层。

在实际应用中,为了保证数据尽可能的被重用和较少更改,做了一个汇总粒度较小的一层,即dm_a层,为了速度,将生成静态数据,是基于MOLP技术的源头数据。Dm_r是为了保证计算的灵活性和满足特殊口径报表的一层,采用ROLP技术访问,主要面向dm_a不能瞒足,并且使用范围不广的报表。 

设计总结

1.       不需要辩解是数据驱动还是需求驱动,咱们不是大师,不是在做学问,不需要提出旗帜鲜明的论理和概念。结合实际资源,完成业务需求是最主要得,归结为业务驱动。反正既要了解数据也要了解需求才能做好。技术细节到可以归结为问题驱动,比如dw_f的设计,就为了解决数据过慢和数据不一致等问题增加的考虑。两对时间记录变化轨迹是为了解决历史时间点数据不一致等问题需要的。

2.       数据项目不像应用项目,不能简单的在行业内照搬。应由甲方主导开发,因为在通常项目的时间和人力资源情况下,无法达到乙方真正主导的地步。

3.       基于项目的复杂和特殊性,最好成立bidw前台和后台两个项目。另外毕竟数据分析和模型都是比较核心部分,这样也更好地保护了公司的建设成果。

4.       数据仓库建设是一个过程,是一个需要反复和迭代的不断的完善的过程。需要统筹规划,但有侧重的实施。

5.       满足用户的需求,并在使用上去引导用户。同时,也要明确不是所有需求都能在这个项目中能够实现的。

6.       业务的口径定义和解释在之前应该有专门的部门或组织尽可能的细化和确定。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7420308/viewspace-1097891/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2008-03-31

  • 博文量
    1
  • 访问量
    4857