支持OLAP的ETL和支持DW的ETL（OLAP'S ETL and DW'S ETL）
5 views
Skip to first unread message
daiyan
Nov 20, 2007, 10:59:56 AM11/20/07
to ttnn BI 观点
要首先申明，纯粹是怀着请教的目的发这个帖子的。
现在做的ETL可以全部定义为支持OLAP的ETL，相当一段时间之内，恐怕也是做支持OLAP的ETL，因为DW（Data Warehouse）是
另外一个专门的小组在做，成果的实用性还不是很显著，可能仍然限于一些数据集市（Data Mart）的应用。
对上文所言的"支持OLAP的ETL（OLAP'S ETL）"，是有真实的认识和一些开发维护的经验了，而所想象的"支持DW的ETL（DW'S
ETL）"，还只是一种想象而已，没有实际经验。这两个名词，相信也不是学术上的名词，甚至不是工程意义上的名词，本人兴之所致，脱口而出罢了，并使用
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，目标端直达各个指标（Measures），贯穿了ETL层级到OLAP Database、到
MDL、到Report的全流程，还有流程中的逻辑定义。
由于缺少自动化的工具，所以这些相当于一个手工工作，要一个一个地打开MDL和ETL，并去看OLAP Database和OLTP Database
端的各个相关Tables的结构和含义。这个笨重的工作已经出初步的结果了。这个过程中，一路做一路想来，总是觉得这些相互关系较多的ETLs，是不是
可以整合得更好，使得结果更接近DW、哪怕是Data Mart的要求呢？在目前的总体架构下，我们的OLAP'S ETL和其源头OLTP
Database的关系过于直接生硬，容易受到OLTP Database变化的影响，且，一般是大面积的和严重的影响----我想，这是一个缺点----依稀
记得，在大学的课堂里，老师讲到了DW多保存历史记录的相对静止性。
总结一下，我感觉到，我们目前的OLAP'S ETL存在两个明显的缺陷：其一、对目标端（Measures and Reports）需求数据的整合
性支持不足；其二，和源端（OLTP Database）揪扯不清的暧昧关系过于直接、浅薄，直接导致了被动地随之起舞。本质上，我认为这些缺陷都是
OLAP'S ETL和DW'S ETL之间在本质差异（或者说是"差距"）上的体现----虽然，一如前文多次强调的，我对DW'S ETL没有任何经
验，也没有更为亲密的理解。
这个短文写得有些乱，名词也说得不是很清楚，颇有自说自话的嫌疑。但是我能预感到，未来不长不短的一段时间，我还将不得不在"OLAP'S ETL和
DW'S ETL"这个问题上"挣扎"。
Regards,
DAI YAN
2007-11-20
Shenzhen.
现在做的ETL可以全部定义为支持OLAP的ETL，相当一段时间之内，恐怕也是做支持OLAP的ETL，因为DW（Data Warehouse）是
另外一个专门的小组在做，成果的实用性还不是很显著，可能仍然限于一些数据集市（Data Mart）的应用。
对上文所言的"支持OLAP的ETL（OLAP'S ETL）"，是有真实的认识和一些开发维护的经验了，而所想象的"支持DW的ETL（DW'S
ETL）"，还只是一种想象而已，没有实际经验。这两个名词，相信也不是学术上的名词，甚至不是工程意义上的名词，本人兴之所致，脱口而出罢了，并使用
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，目标端直达各个指标（Measures），贯穿了ETL层级到OLAP Database、到
MDL、到Report的全流程，还有流程中的逻辑定义。
由于缺少自动化的工具，所以这些相当于一个手工工作，要一个一个地打开MDL和ETL，并去看OLAP Database和OLTP Database
端的各个相关Tables的结构和含义。这个笨重的工作已经出初步的结果了。这个过程中，一路做一路想来，总是觉得这些相互关系较多的ETLs，是不是
可以整合得更好，使得结果更接近DW、哪怕是Data Mart的要求呢？在目前的总体架构下，我们的OLAP'S ETL和其源头OLTP
Database的关系过于直接生硬，容易受到OLTP Database变化的影响，且，一般是大面积的和严重的影响----我想，这是一个缺点----依稀
记得，在大学的课堂里，老师讲到了DW多保存历史记录的相对静止性。
总结一下，我感觉到，我们目前的OLAP'S ETL存在两个明显的缺陷：其一、对目标端（Measures and Reports）需求数据的整合
性支持不足；其二，和源端（OLTP Database）揪扯不清的暧昧关系过于直接、浅薄，直接导致了被动地随之起舞。本质上，我认为这些缺陷都是
OLAP'S ETL和DW'S ETL之间在本质差异（或者说是"差距"）上的体现----虽然，一如前文多次强调的，我对DW'S ETL没有任何经
验，也没有更为亲密的理解。
这个短文写得有些乱，名词也说得不是很清楚，颇有自说自话的嫌疑。但是我能预感到，未来不长不短的一段时间，我还将不得不在"OLAP'S ETL和
DW'S ETL"这个问题上"挣扎"。
Regards,
DAI YAN
2007-11-20
Shenzhen.
interstage
Nov 20, 2007, 11:55:34 PM11/20/07
to ttnn BI 观点
为什么要分OLAP'S ETL还是DW'S ETL呢. ETL概念本身是独立于OLAP概念和DW概念的. 至于通过ETL后产生数据是为了
REPORT还是DW,这不就是业内一直讨论的ODS的用途,究竟是不是可以在ODS直接出REPORT,还是REPORT只能在DM或DW中出.
REPORT还是DW,这不就是业内一直讨论的ODS的用途,究竟是不是可以在ODS直接出REPORT,还是REPORT只能在DM或DW中出.
Qing
Nov 21, 2007, 1:25:22 AM11/21/07
to tt...@googlegroups.com
能够刚入职不久就考虑这些问题，你是不是疯了？
谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从生产系统获取？那数据仓库用来干啥的？
至于暧昧关系，我可以建议一个能够偷懒的方法。
olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
On 11/20/07, daiyan <daiya...@gmail.com> wrote:
...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
kaikai
Nov 21, 2007, 4:53:26 AM11/21/07
to ttnn BI 观点
如果从一个完整的DW概念来说。OLAP在DW项目中是DW的前端展现层的东西。数据应该是来源于DW中的数据存储。但如果只是想有OLAP的分析效
果，不做DW也可以。但进起码要把OLAP的数据层从生产系统中分离开来，不然可以想像，不稳定的数据可以带来何种分析效果。
关于ETL，ETL输出端对应到DW还是DATAMART还是OLAP DB,无关紧要吧，倒是ETL的输入端是否稳定才是关键。
果，不做DW也可以。但进起码要把OLAP的数据层从生产系统中分离开来，不然可以想像，不稳定的数据可以带来何种分析效果。
关于ETL，ETL输出端对应到DW还是DATAMART还是OLAP DB,无关紧要吧，倒是ETL的输入端是否稳定才是关键。
cnzhangzhen
Nov 21, 2007, 7:57:38 AM11/21/07
to ttnn BI 观点
以为 OLAP 作为 与 OLTP 相对应的概念， 只是一个概念范围的划分。 所以不见得有OLAP table, 或者OLAP report的
概念。
report 就是report.
在我目前的项目中，对于来自OLTP的源数据，我们都是通过extractor抽取出来。既可以通过ETL向DW提供数据，也可以直接供给
上层的report。
当然，这种DirectAccess的方式会影响OLTP端的性能，但是用户可以在这两种方式之间切换 - 根据他自己的实际需求进行权衡。
关于ODS, 我们现在是可以直接在上面出report的. 现在的趋势是我们希望通过BI提供一个统一的report用户接口。
另外，关于Qing的问题， 对我们来说，直接从OLTP取数据是为了获得一些实时性非常强的报表。
概念。
report 就是report.
在我目前的项目中，对于来自OLTP的源数据，我们都是通过extractor抽取出来。既可以通过ETL向DW提供数据，也可以直接供给
上层的report。
当然，这种DirectAccess的方式会影响OLTP端的性能，但是用户可以在这两种方式之间切换 - 根据他自己的实际需求进行权衡。
关于ODS, 我们现在是可以直接在上面出report的. 现在的趋势是我们希望通过BI提供一个统一的report用户接口。
另外，关于Qing的问题， 对我们来说，直接从OLTP取数据是为了获得一些实时性非常强的报表。
interstage
Nov 21, 2007, 8:30:08 AM11/21/07
to ttnn BI 观点
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的意思 .
> > Shenzhen.- Hide quoted text -
>
> - Show quoted text -
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的意思 .
>
> - Show quoted text -
daiyan
Nov 21, 2007, 11:07:36 AM11/21/07
to ttnn BI 观点
谢谢Qing和其它几位朋友的分析。
可能我还需要提供更多的信息，才能获得各位更好的思想。
目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
果与实际情况的契合度等。
On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从生产系统获取？那数据仓库用来干啥的？
>
> 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
可能我还需要提供更多的信息，才能获得各位更好的思想。
目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
果与实际情况的契合度等。
On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从生产系统获取？那数据仓库用来干啥的？
>
> 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
Delin He
Nov 22, 2007, 8:43:48 AM11/22/07
to tt...@googlegroups.com
明白你们怎么搞的了， 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能领导觉得暂时也能满足固定的报表需求。 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营情况一目了然，说"干的不错" 我心里想，就着玩意，唉！我以后再也不干这样的事了
在07-11-22，daiyan <daiya...@gmail.com> 写道：
Chaoyang District, Beijing, 100029
Mailto: beij...@gmail.com
daiyan
Nov 22, 2007, 9:20:18 AM11/22/07
to ttnn BI 观点
逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
> 明白你们怎么搞的了，
> 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能领导觉得暂时也能满足固定的报表需求。
> 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营情况一目了然，说"干的不错"
> 我心里想，就着玩意，唉！我以后再也不干这样的事了
>
> 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
> Best regards！
>
> He Delin(何德琳)
> ----------------------------------
> Computer Department, STKM, BUCT
> Chaoyang District, Beijing, 100029
> Mailto: beiji...@gmail.com
On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
> 明白你们怎么搞的了，
> 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能领导觉得暂时也能满足固定的报表需求。
> 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营情况一目了然，说"干的不错"
> 我心里想，就着玩意，唉！我以后再也不干这样的事了
>
>
>
>
>
>
> > 谢谢Qing和其它几位朋友的分析。
>
> > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > 果与实际情况的契合度等。
>
> > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> > 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从生产系统获取？那数据仓库用来干啥的？
>
> > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> --
>
>
>
>
> > 谢谢Qing和其它几位朋友的分析。
>
> > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > 果与实际情况的契合度等。
>
> > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> > 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从生产系统获取？那数据仓库用来干啥的？
>
> > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> Best regards！
>
> He Delin(何德琳)
> ----------------------------------
> Computer Department, STKM, BUCT
> Chaoyang District, Beijing, 100029
> Mailto: beiji...@gmail.com
raullew
Nov 22, 2007, 9:21:46 AM11/22/07
to ttnn BI 观点
raullew
Nov 22, 2007, 9:27:59 AM11/22/07
to ttnn BI 观点
恩，主要在于面对复杂业务的应变能力
业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
> 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
>
>
> > 明白你们怎么搞的了，
> > 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能-领导觉得暂时也能满足固定的报表需求。
> > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营-情况一目了然，说"干的不错"
>
> > > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从-生产系统获取？那数据仓库用来干啥的？
>
> - 显示引用的文字 -
业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
> 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
>
>
> > 明白你们怎么搞的了，
> > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营-情况一目了然，说"干的不错"
> > 我心里想，就着玩意，唉！我以后再也不干这样的事了
>
> > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > 谢谢Qing和其它几位朋友的分析。
>
> > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > 果与实际情况的契合度等。
>
> > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> > > 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而-且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > 谢谢Qing和其它几位朋友的分析。
>
> > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > 果与实际情况的契合度等。
>
> > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
>
> > > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从-生产系统获取？那数据仓库用来干啥的？
>
> > > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> > --
> > Best regards！
>
> > He Delin(何德琳)
> > ----------------------------------
> > Computer Department, STKM, BUCT
> > Chaoyang District, Beijing, 100029
> > Mailto: beiji...@gmail.com- 隐藏被引用文字 -
> > > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> > --
> > Best regards！
>
> > He Delin(何德琳)
> > ----------------------------------
> > Computer Department, STKM, BUCT
> > Chaoyang District, Beijing, 100029
>
> - 显示引用的文字 -
daiyan
Nov 23, 2007, 9:06:16 AM11/23/07
to ttnn BI 观点
从你的话里，看得出来你在这方面经验丰富、理解颇深啊。
我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
破。
不知道raullew在这方面有什么建议呢？
Thanks
我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
破。
不知道raullew在这方面有什么建议呢？
Thanks
raullew
Nov 24, 2007, 4:02:57 AM11/24/07
to ttnn BI 观点
不敢。。。
我把OLAP理解为MART的一种存储和展现方式
MART的表结构根据需求来做（是从DW到MART还是从OLTP到MART取决于你们的DW整合进度），整理过报表需求后，MART的设计可以比较稳
定，很多维度派生字段和疙瘩的统计指标在这里做掉，存在关系型数据库里
一个主题的业务可能可以整合为一个MART，也许是几个事实表，多个维表
然后可以从MART拖拉多个CUBE和报表，从数据源到MART的逻辑可能时常要修改（DW上线后也可能会全盘改掉），但MART的设计不用改，而从
MART到OLAP的逻辑会很简练
On 11月23日, 下午10时06分, daiyan <daiyani...@gmail.com> wrote:
> 从你的话里，看得出来你在这方面经验丰富、理解颇深啊。
> 我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
> 破。
> 不知道raullew在这方面有什么建议呢？
> Thanks
>
> On 11月22日, 下午10时27分, raullew <raul...@hotmail.com> wrote:
>
>
>
> > 恩，主要在于面对复杂业务的应变能力
> > 业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
>
> > On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
>
> > > 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> > > On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
> > > > 明白你们怎么搞的了，
> > > > 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能--领导觉得暂时也能满足固定的报表需求。
> > > > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营--情况一目了然，说"干的不错"
>
> > > > > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从--生产系统获取？那数据仓库用来干啥的？
>
> - 显示引用的文字 -
我把OLAP理解为MART的一种存储和展现方式
MART的表结构根据需求来做（是从DW到MART还是从OLTP到MART取决于你们的DW整合进度），整理过报表需求后，MART的设计可以比较稳
定，很多维度派生字段和疙瘩的统计指标在这里做掉，存在关系型数据库里
一个主题的业务可能可以整合为一个MART，也许是几个事实表，多个维表
然后可以从MART拖拉多个CUBE和报表，从数据源到MART的逻辑可能时常要修改（DW上线后也可能会全盘改掉），但MART的设计不用改，而从
MART到OLAP的逻辑会很简练
On 11月23日, 下午10时06分, daiyan <daiyani...@gmail.com> wrote:
> 从你的话里，看得出来你在这方面经验丰富、理解颇深啊。
> 我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
> 破。
> 不知道raullew在这方面有什么建议呢？
> Thanks
>
> On 11月22日, 下午10时27分, raullew <raul...@hotmail.com> wrote:
>
>
>
> > 恩，主要在于面对复杂业务的应变能力
> > 业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
>
> > On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
>
> > > 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> > > On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
> > > > 明白你们怎么搞的了，
> > > > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营--情况一目了然，说"干的不错"
> > > > 我心里想，就着玩意，唉！我以后再也不干这样的事了
>
> > > > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > > > 谢谢Qing和其它几位朋友的分析。
>
> > > > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > > > > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > > > > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > > > > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > > > > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > > > > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > > > > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > > > > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > > > > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > > > 果与实际情况的契合度等。
>
> > > > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> > > > > 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而--且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾。
>
> > > > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > > > 谢谢Qing和其它几位朋友的分析。
>
> > > > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > > > > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
> > > > > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
> > > > > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
> > > > > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > > > > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
> > > > > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
> > > > > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management Center）----内部还没有把自己称为BI
>
> > > > > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > > > 果与实际情况的契合度等。
>
> > > > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
>
> > > > > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从--生产系统获取？那数据仓库用来干啥的？
>
> > > > > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > > > > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > > > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > > > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > > > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> > > > --
> > > > Best regards！
>
> > > > He Delin(何德琳)
> > > > ----------------------------------
> > > > Computer Department, STKM, BUCT
> > > > Chaoyang District, Beijing, 100029
> > > > Mailto: beiji...@gmail.com- 隐藏被引用文字 -
>
> > > - 显示引用的文字 -- 隐藏被引用文字 -
> > > > > > 至于暧昧关系，我可以建议一个能够偷懒的方法。
>
> > > > > olap结构、报表的变动在开发期间应该是变动不大的（虽然在开发完后可能变动频繁），你可以设计一套关系表结构，跟你的目标报表结构相似。这套关系表交给dw
> > > > > > etl，让他们定期往里面装数据。而你这边，只需要作一些简单映射的事情就拉到，不处理复杂逻辑。
>
> > > > > > 另外：建议ttnner用邮件来发帖子，通过web方式发的帖子总是有行被截断，看着很不通畅。
>
> > > > > > On 11/20/07, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > > > ...间，我还将不得不在"OLAP'S ETL和DW'S ETL"这个问题上"挣扎"。
>
> > > > --
> > > > Best regards！
>
> > > > He Delin(何德琳)
> > > > ----------------------------------
> > > > Computer Department, STKM, BUCT
> > > > Chaoyang District, Beijing, 100029
> > > > Mailto: beiji...@gmail.com- 隐藏被引用文字 -
>
>
> - 显示引用的文字 -
huangkan
Dec 11, 2007, 4:35:49 AM12/11/07
to tt...@googlegroups.com
我想我应该知道你是哪个公司。对你们来说，建立DW是一件势在必行的事情。你说的困惑其实追根溯源是由于这个问题造成的。MIS还会在相当一段时间内存在下去，我的建议是MIS应该和DW Team联合起来做一些事情，其实现在MIS做的事情是在做一些DataMart，需要慢慢融入到DW体系中去。另外，题外话，首先不必求把所有业务大融合，找到切入点，比如产险+寿险，半年前我曾经帮你们做个这个规划。
daiyan
Dec 12, 2007, 9:05:35 AM12/12/07
to ttnn BI 观点
huangkan：
您好！非常感谢您的回复。虽然没有见过您本人，但是您离开的时候应该正是我们入司的时候，听同事介绍过您的名气，挺敬仰您的！希望将来有更多、更有价值
的问题求教于您。
在这个帖子中，我很幼稚的一点想法是：在现有的正确架构下（毕竟改变是需要时间和成本的），即便在寿险的一个现有模块内部，还是可以有更好的架构的，相
当于是集市中同主题的小摊点会很好地汇集在一块一样----这个相当于是对现在架构的一个优化，是在没有架构好实用的DW之前也可以逐步实现的，成本和时间
预计在可以接受范围内；考虑到DW成熟完全取代现有架构还有待时日，这种模块（不太标准的集市）内部的优化还是有相当明显的价值。
往回看，我很感激过往同事们（虽然大多未曾谋面）的智慧和努力，否则，像我这样的一个还不算入门的新人怎么会有机会在此"品头论足"呢！所以，我在为了
自己的开发理解方便而整理的模块架构文档封面加了一句话："本文档是在试图理解前人智慧！"
再一次谢谢huangkan，还有Qing等其他所有为本帖出谋划策的ttnn前辈们！
Regards,
daiyan 2007-12-12
On 12月11日, 下午5时35分, huangkan <erichuangta...@gmail.com> wrote:
> 我想我应该知道你是哪个公司。对你们来说，建立DW是一件势在必行的事情。你说的困惑其实追根溯源是由于这个问题造成的。MIS还会在相当一段时间内存在下去，-我的建议是MIS应该和DW
> Team联合起来做一些事情，其实现在MIS做的事情是在做一些DataMart，需要慢慢融入到DW体系中去。另外，题外话，首先不必求把所有业务大融合，找-到切入点，比如产险+寿险，半年前我曾经帮你们做个这个规划。
>
> > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营---情况一目了然，说"干的不错"
>
> > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从---生产系统获取？那数据仓库用来干啥的？
您好！非常感谢您的回复。虽然没有见过您本人，但是您离开的时候应该正是我们入司的时候，听同事介绍过您的名气，挺敬仰您的！希望将来有更多、更有价值
的问题求教于您。
在这个帖子中，我很幼稚的一点想法是：在现有的正确架构下（毕竟改变是需要时间和成本的），即便在寿险的一个现有模块内部，还是可以有更好的架构的，相
当于是集市中同主题的小摊点会很好地汇集在一块一样----这个相当于是对现在架构的一个优化，是在没有架构好实用的DW之前也可以逐步实现的，成本和时间
预计在可以接受范围内；考虑到DW成熟完全取代现有架构还有待时日，这种模块（不太标准的集市）内部的优化还是有相当明显的价值。
往回看，我很感激过往同事们（虽然大多未曾谋面）的智慧和努力，否则，像我这样的一个还不算入门的新人怎么会有机会在此"品头论足"呢！所以，我在为了
自己的开发理解方便而整理的模块架构文档封面加了一句话："本文档是在试图理解前人智慧！"
再一次谢谢huangkan，还有Qing等其他所有为本帖出谋划策的ttnn前辈们！
Regards,
daiyan 2007-12-12
On 12月11日, 下午5时35分, huangkan <erichuangta...@gmail.com> wrote:
> 我想我应该知道你是哪个公司。对你们来说，建立DW是一件势在必行的事情。你说的困惑其实追根溯源是由于这个问题造成的。MIS还会在相当一段时间内存在下去，-我的建议是MIS应该和DW
> Team联合起来做一些事情，其实现在MIS做的事情是在做一些DataMart，需要慢慢融入到DW体系中去。另外，题外话，首先不必求把所有业务大融合，找-到切入点，比如产险+寿险，半年前我曾经帮你们做个这个规划。
>
> On 11/24/07, raullew <raul...@hotmail.com> wrote:
>
>
>
>
>
> > 不敢。。。
> > 我把OLAP理解为MART的一种存储和展现方式
> > MART的表结构根据需求来做（是从DW到MART还是从OLTP到MART取决于你们的DW整合进度），整理过报表需求后，MART的设计可以比较稳
> > 定，很多维度派生字段和疙瘩的统计指标在这里做掉，存在关系型数据库里
> > 一个主题的业务可能可以整合为一个MART，也许是几个事实表，多个维表
> > 然后可以从MART拖拉多个CUBE和报表，从数据源到MART的逻辑可能时常要修改（DW上线后也可能会全盘改掉），但MART的设计不用改，而从
> > MART到OLAP的逻辑会很简练
>
> > On 11月23日, 下午10时06分, daiyan <daiyani...@gmail.com> wrote:
> > > 从你的话里，看得出来你在这方面经验丰富、理解颇深啊。
> > > 我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
> > > 破。
> > > 不知道raullew在这方面有什么建议呢？
> > > Thanks
>
> > > On 11月22日, 下午10时27分, raullew <raul...@hotmail.com> wrote:
>
> > > > 恩，主要在于面对复杂业务的应变能力
> > > > 业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
>
> > > > On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> > > > > On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
> > > > > > 明白你们怎么搞的了，
>
> > 从实时备份库抽数据，ETL到OLAP数据库，然后就从这个OLAP数据库出固定报表，每天抽，每天报表不断刷新，这个玩意用了几年，报表每天也能看数据，可能---领导觉得暂时也能满足固定的报表需求。
> On 11/24/07, raullew <raul...@hotmail.com> wrote:
>
>
>
>
>
> > 不敢。。。
> > 我把OLAP理解为MART的一种存储和展现方式
> > MART的表结构根据需求来做（是从DW到MART还是从OLTP到MART取决于你们的DW整合进度），整理过报表需求后，MART的设计可以比较稳
> > 定，很多维度派生字段和疙瘩的统计指标在这里做掉，存在关系型数据库里
> > 一个主题的业务可能可以整合为一个MART，也许是几个事实表，多个维表
> > 然后可以从MART拖拉多个CUBE和报表，从数据源到MART的逻辑可能时常要修改（DW上线后也可能会全盘改掉），但MART的设计不用改，而从
> > MART到OLAP的逻辑会很简练
>
> > On 11月23日, 下午10时06分, daiyan <daiyani...@gmail.com> wrote:
> > > 从你的话里，看得出来你在这方面经验丰富、理解颇深啊。
> > > 我觉得这种水平是不可能持久的，我们内部也在主动寻求突破，但绝大多数的时间和精力被复杂多变的业务需求所占用了，很难的静下心来想问题，想如何突
> > > 破。
> > > 不知道raullew在这方面有什么建议呢？
> > > Thanks
>
> > > On 11月22日, 下午10时27分, raullew <raul...@hotmail.com> wrote:
>
> > > > 恩，主要在于面对复杂业务的应变能力
> > > > 业务对数据支持的需求高了，涉及种种不同维度指标与统计计算方法，就需要更多的数据处理过程了
>
> > > > On 11月22日, 下午10时20分, daiyan <daiyani...@gmail.com> wrote:
>
> > > > > 逻辑上应该与你所说无明显差别，差别在于规模、复杂度和对业务的支持能力----当然，这个在本质上是由业务决定的。
>
> > > > > On 11月22日, 下午9时43分, "Delin He" <beiji...@gmail.com> wrote:
>
> > > > > > 明白你们怎么搞的了，
>
>
> > 俺暑期是就这样搞了差不多一样的东西。我刚入职，上头要看报表，我们当时的基础为0，我就用开源工具加代码搞了这样一套东西，领导每天都能看到数据，网站的运营---情况一目了然，说"干的不错"
> > > > > > 我心里想，就着玩意，唉！我以后再也不干这样的事了
>
> > > > > > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > > > > > 谢谢Qing和其它几位朋友的分析。
>
> > > > > > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
>
> > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
>
> > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
>
> > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > > > > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
>
> > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
>
> > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > > > > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > > > > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management
> > Center）----内部还没有把自己称为BI
>
> > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > > > > > 果与实际情况的契合度等。
>
> > > > > > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > > > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
> > 谈谈我的理解。interstage说无需划分这两种etl，我想从架构上来说，可能不需要。但通常，在组织结构上，负责DW的跟负责OLAP的人又不一样，而---且DW的ETL处理的都是数据仓库内部数据的流动，而从DW到OLAP，可能涉及到不同的技术，其数据处理职责恐怕就单独拎出来给OLAP这个小组自己折腾-。
>
> > > > > > 在07-11-22，daiyan <daiyani...@gmail.com> 写道：
>
> > > > > > > 谢谢Qing和其它几位朋友的分析。
>
> > > > > > > 可能我还需要提供更多的信息，才能获得各位更好的思想。
>
> > 目前的工作环境，是通过ETL的JOB从业务系统数据库E-T-L数据到OLAP数据库（非常庞大惊人），这个OLAP数据库不同于业务系统的数据库，
>
> > 也达不到可以称道的数据仓库的标准（在网上看一些数据仓库建设的案例，我感觉也就达到我所说OLAP数据库的水平），这些个按照大类业务（寿险、产险、
>
> > 银行、财务等）划分开的OLAP数据库，我们内部只认为是数据仓库的雏形----所以部门里成立了专门的数据仓库组开发数据仓库。目前这些个OLAP数据库
>
> > 已经支持OLAP报表多年，公司对机构和个人的考核、算佣、年报等等一切需要指标数据都以我们的OLAP报表为标准，外部监管部门和战略合作伙伴也通过
> > > > > > > 我们获得数据----这个OLAP报表系统的实用性已经在总公司层级彻底替代了其他途径，获得了用户的认可和依赖。
>
> > 另外，我们的ETL是从一个生产库的快照库取数的，没有权限直接从业务系统生产库取数，这个快照库是生产库的完全一致（只存在可以忽略的时差）的备份
>
> > 库。开发人员有专门的开发测试库以供ETL和MDL的开发测试，运营测试和用户测试（开发完毕移交运营测试，通过之后正式部署到ETL货这MDL的生产
>
> > 环境）又是另外的环境----这些环节包括独立的硬件（主机、数据库和网络等）环境和相应同构的数据库环境（开发测试环境、运营/用户测试环境和OLAP生
> > > > > > > 产环境数据库是同构的，其中，运营/用户测试环境和OLAP生产环境在硬件上都是基本同构的）。
>
> > > > > > > 从前，我们部门被称为MIS（管理信息系统），现在，被称为数据管理部（Data Management
> > Center）----内部还没有把自己称为BI
>
> > 部门，大概也是因为我们在数据分析和挖掘上的不足----所以公司专管需求规划的部门一年前开始深入评估SAS----评估在业务中的实际表现，譬如趋势预测结
> > > > > > > 果与实际情况的契合度等。
>
> > > > > > > On 11月21日, 下午2时25分, Qing <happys...@gmail.com> wrote:
> > > > > > > > 能够刚入职不久就考虑这些问题，你是不是疯了？
>
>
> > 我想daiyan用的应该是MOLAP，是cognos吗？不过对于你说的源端是OLTP系统，这有点奇怪，你们的OLAP难道不是从数据仓库获取数据，还是从---生产系统获取？那数据仓库用来干啥的？
Reply all
Reply to author
Forward
0 new messages