OLAP’S ETL and DW’S ETL

  作者:kaiyun体育官方人口
2007/11/29 9:41:29
本文关键字: OLAP ETL 数据库环境 MIS

作者: daiyan 20071120

要首先申明,纯粹是怀着请教的目的发这个帖子的。

现在做的ETL可以全部定义为支持OLAP的ETL,相当一段时间之内,恐怕也是做支持OLAP的ETL,因为DW(Data Warehouse)是另外一个专门的小组在做,成果的实用性还不是很显著,可能仍然限于一些数据集市(Data Mart)的应用。

对上文所言的”支持OLAP的ETL(OLAP’S ETL)”,是有真实的认识和一些开发维护的经验了,而所想象的”支持DW的ETL(DW’SETL)”,还只是一种想象而已,没有实际经验。

这两个名词,相信也不是学术上的名词,甚至不是工程意义上的名词,本人兴之所致,脱口而出罢了,并使用OLAP’S ETL和DW’S ETL这两个符号来简洁地标识她们。

但是,些目前支持OLAP的ETL过渡到支持DW,是必然的趋势。始终在思索一个问题,我的OLAP’S ETLs应该如何升级到DW’S ETLs呢?

一个或者多个指标构(Measures)成的一个或一组OLAP报表(Reports),是一个或者一组ETLs(跟多的时候,是一组)产生和存在的基础,这是目前我观察到的情况----我想,也有经验丰富的同事经意或不经意间指点过,要从目标数据需求的角度来研究、设计和理解一个ETL。

入职以来两个月了,负责这个模块的老员工刚刚换了部门,一个模块就这样交给我,面对的是一堆新问题,和同样多的老问题,譬如MDL和ETL效率优化(这个另外一个话题)等等。因为面临这样的压力,我着手整理整个模块的所有ETL、OLAP Table、MDL和REPORTS,利用功能强大的EXCEL整理网络关系图,源端在OLTP System Database,目标端直达各个指标(Mea-sures),贯穿了ETL层级到OLAP Database、到MDL、到Report的全流程,还有流程中的逻辑定义。

由于缺少自动化的工具,所以这些相当于一个手工工作,要一个一个地打开MDL和ETL,并去看OLAP Database和OLTP Database端的各个相关Tables的结构和含义。这个笨重的工作已经出初步的结果了。这个过程中,一路做一路想来,总是觉得这些相互关系较多的ETLs,是不是可以整合得更好,使得结果更接近DW、哪怕是Data Mart的要求呢?在目前的总体架构下,我们的OLAP’S ETL和其源头OLTP Database的关系过于直接生硬,容易受到OLTP Da-tabase变化的影响,且,一般是大面积的和严重的影响----我想,这是一个缺点----依稀记得,在大学的课堂里,老师讲到了DW多保存历史记录的相对静止性。

总结一下,我感觉到,我们目前的OLAP’S ETL存在两个明显的缺陷:其一、对目标端(Measures and Reports)需求数据的整合性支持不足;其二,和源端(OLTP Database)揪扯不清的暧昧关系过于直接、浅薄,直接导致了被动地随之起舞。本质上,我认为这些缺陷都是OLAP’S ETL和DW’S ETL之间在本质差异(或者说是”差距”)上的体现----虽然,一如前文多次强调的,我对DW’S ETL没有任何经验,也没有更为亲密的理解。

这个短文写得有些乱,名词也说得不是很清楚,颇有自说自话的嫌疑。但是我能预感到,未来不长不短的一段时间,我还将不得不在”OLAP’S ETL和DW’S ETL”这个问题上”挣扎”。

作者: interstage 20071121

为什么要分OLAP’S ETL还是DW’S ETL呢. ETL概念本身是独立于OLAP概念和DW概念的. 至于通过ETL后产生数据是为了REPORT还是DW,这不就是业内一直讨论的ODS的用途,究竟是不是可以在ODS直接出REPORT,还是REPORT只能在DM或DW中出。

作者: Qing 20071120

能够刚入职不久就考虑这些问题,你是不是疯了?

谈谈我的理解。interstage说无需划分这两种etl,我想从架构上来说,可能不需要。但通常,在组织结构上,负责DW的跟负责OLAP的人又不一样,而且DW的ETL处理的都是数据仓库内部数据的流动,而从DW到OLAP,可能涉及到不同的技术,其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。

我想daiyan用的应该是MOLAP,是cognos吗?不过对于你说的源端是OLTP系统,这有点奇怪,你们的OLAP难道不是从数据仓库获取数据,还是从生产系统获取?那数据仓库用来干啥的?
至于暧昧关系,我可以建议一个能够偷懒的方法。

olap结构、报表的变动在开发期间应该是变动不大的(虽然在开发完后可能变动频繁),你可以设计一套关系表结构,跟你的目标报表结构相似。这套关系表交给dw etl,让他们定期往里面装数据。而你这边,只需要作一些简单映射的事情就拉到,不处理复杂逻辑。

作者: kaikai 20071121

如果从一个完整的DW概念来说。OLAP在DW项目中是DW的前端展现层的东西。数据应该是来源于DW中的数据存储。但如果只是想有OLAP的分析效果,不做DW也可以。但进起码要把OLAP的数据层从生产系统中分离开来,不然可以想像,不稳定的数据可以带来何种分析效果。关于ETL,ETL输出端对应到DW还是DATAMART还是OLAP DB,无关紧要吧,倒是ETL的输入端是否稳定才是关键。

作者: cnzhangzhen 20071121

以为 OLAP 作为 与 OLTP 相对应的概念, 只是一个概念范围的划分。 所以不见得有OLAPtable, 或者OLAP report的概念。report 就是report. 在我目前的项目中,对于来自OLTP的源数据,我们都是通过extractor抽取出来。既可以通过ETL向DW提供数据,也可以直接供给上层的report。

当然,这种DirectAccess的方式会影响OLTP端的性能,但是用户可以在这两种方式之间切换 - 根据他自己的实际需求进行权衡。

关于ODS, 我们现在是可以直接在上面出report的. 现在的趋势是我们希望通过BI提供一个统一的report用户接口。

另外,关于Qing的问题, 对我们来说,直接从OLTP取数据是为了获得一些实时性非常强的报表。

作者: interstage 20071121

ODS是否可以提供数据给report,还是report数据只能来自DW或DM,这个争论我们是没有办法讨论清楚的,因为这也是imnom和kimball争论最多的地方。

dianyan这个题目的描述”OLAP’s ETL还是DW’s ETL”,从内容上来看,就是讲report数据来源是否可以不通过DW,直接从OLTP DB通过ETL实现OLAP report,如果是这个方式要实现,那ETL数据流向就是从OLTP DB 到ODS,由ODS到OLAP(MOLAP或者ROLAP)这种方式, 这就是ODS的一直讨论的焦点之一. 至于实时性报表,就是OLAP报表和OLTP的实时报表整合可以采用EII来实现。

如果采用了EII,那ETL和EII的争论又可以开始了.我曾经在一个项目中就是哪些应用选择EII,哪些应用采用ETL,差点被搞死。

不知道以上理解是不是dianyan的意思。

作者:daiyan 20071121

谢谢Qing和其它几位朋友的分析。

可能我还需要提供更多的信息,才能获得各位更好的思想。

目前的工作环境,是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库(非常庞大惊
人),这个OLAP数据库不同于业务系统的数据库,也达不到可以称道的数据仓库的标准(在
网上看一些数据仓库建设的案例,我感觉也就达到我所说OLAP数据库的水平),这些个按照大类业务(寿险、产险、银行、财务等)划分开的OLAP数据库,我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库已经支持OLAP报表多年,公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准,外部监管部门和战略合作伙伴也通过我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径,获得了用户的认可和依赖。

另外,我们的ETL是从一个生产库的快照库取数的,没有权限直接从业务系统生产库取数,这个快照库是生产库的完全一致(只存在可以忽略的时差)的备份库。开发人员有专门的开发测试库以供ETL和MDL的开发测试,运营测试和用户测试(开发完毕移交运营测试,通过之后正式部署到ETL货这MDL的生产环境)又是另外的环境----这些环节包括独立的硬件(主机、数据库和网络等)环境和相应同构的数据库环境(开发测试环境、运营/用户测试环境和OLAP生产环境数据库是同构的,其中,运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的)。

从前,我们部门被称为MIS(管理信息系统),现在,被称为数据管理部(Data Manage-ment Center)----内部还没有把自己称为BI部门,大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现,譬如趋势预测结果与实际情况的契合度等。

作者: Delin 20071122

明白你们怎么搞的了, 从实时备份库抽数据,ETL到OLAP数据库,然后就从这个OLAP数据库出固定报表,每天抽,每天报表不断刷新,这个玩意用了几年,报表每天也能看数据,可能领导觉得暂时也能满足固定的报表需求。 俺暑期是就这样搞了差不多一样的东西。我刚入职,上头要看报表,我们当时的基础为0,我就用开源工具加代码搞了这样一套东西,领导每天都能看到数据,网站的运营情况一目了然,说”干的不错” 我心里想,就着玩意,唉!我以后再也不干这样的事了

作者: raullew 20071122

恩,主要在于面对复杂业务的应变能力业务对数据支持的需求高了,涉及种种不同维度指标与统计计算方法,就需要更多的数据处理过程了这是个架构问题,看你怎么看待DW和MART的功能差异。

作者:daiyan 20071123

从你的话里,看得出来你在这方面经验丰富、理解颇深啊。我觉得这种水平是不可能持久的,我们内部也在主动寻求突破,但绝大多数的时间和精力被复杂多变的业务需求所占用了,很难的静下心来想问题,想如何突破。

不知道raullew在这方面有什么建议呢?

作者: raullew 20071124

不敢……

我把OLAP理解为MART的一种存储和展现方式MART的表结构根据需求来做(是从DW到MART还是从OLTP到MART取决于你们的DW整合进度),整理过报表需求后,MART的设计可以比较稳定,很多维度派生字段和疙瘩的统计指标在这里做掉,存在关系型数据库里一个主题的业务可能可以整合为一个MART,也许是几个事实表,多个维表然后可以从MART拖拉多个CUBE和报表,从数据源到MART的逻辑可能时常要修改(DW上线后也可能会全盘改掉),但MART的设计不用改,而从MART到OLAP的逻辑会很简练 。

责编:姜玲
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

著作权声明:kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918
Baidu
map