OLAP’S ETL and DW’S ETL

作者: 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的逻辑会很简练 。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友