体验混合架构的来源
13 views
Skip to first unread message
innovate511
May 13, 2008, 11:13:14 AM5/13/08
to ttnn BI 观点
最初在05年初期接触这种项目，该项目的多维模型设计由Kimabll先生亲自咨询指导。EDW由行业规范产生，由行业专家建设而成，而数据源是来自由
行业最知名的软件，这个EDW Kimball先生没有参与咨询指导。
最初进入项目前是架构和建模思想培训1月，然后才是ETL开发，到现在，还有以前一起战斗过的老同事还战斗在这个项目，并且被美国方任命为项目新CDW
架构的主架构师之一。
从项目开发来看，EDW模块非常稳定，很少有开发和升级需求，随着越来越接近前端BI应用，开发需求越大。CDW核心存储并非一次性就是完全是星型模
型，而是大多数维表和事实表直接关联，而有层级关系的维，采用雪花模型关联，这样方便扩展和适应维的定义以及可能的组织层级变化。所有事实表和维表都有
一个生成、维护的一个存储层级，然后和辅助支撑变化的模型放入统一层级，多维数据仓库没有根据某些BI需求而汇总的事实表，他们是基础的、含盖企业级需
求的维和度量。而计划、预算系统的计算结果也将返回多维数据仓库，最后在统一维度层找到他们的位置。
和DM对接的是统一维度层级，由于DM是迎合BI需求的前端数据存储层，所以需要提供更多的、个性化的、方便展现的模型。于是会衍生出桥梁表---
factless fact table、事实表退化维的生成（比如0-18岁，18到30岁....这个也可以生成一个维，但依附于事实表，故成为退
化维，纯粹为了分析需要）、模型纯星型模型化（维结构层次的变化需求已在CDW处理掉）、汇总、宽表需求等等。
该多维模型经过Kimball先生的指导，虽然经历过公司业务重组、最终用户增多，个性化需求越来越多的各种变化，依然近10年不倒。同时跨国公司实力
强，不但划分四大组件，各部分独立设计、独立ETL开发，而且分为两种集成测试，一种是一个组件的内部集成测试，充分保障接口数据的数据质量，另一种才
是贯通系统的大集成测试。
Kimball 的Life cycle那本书是团队镇队之宝，我们一直在一边做项目一边研究其架构的独特思考，因为EDW并非多维数据仓库，而从多维
数据仓库到DM，是一个很严密的Kimball设计方案，各种设计技巧和细节一环扣一环，而且在书中都能找到其理论依据。这对我之后的独立设计有很大的
启发和经验积累效果，而项目中的同事也快速成长，有的留下来，有的后来也离开这个象教科书一样的经典项目，他们都各有自己的成绩。
跨国公司已经把两种观点融合在一起成功实现了混合架构，并有近10年经验，而且在很多项目都或多或少有影响。在TTNN倒却成了怪物，不但有的人没有看
过，而且说我想从两个大师之间形成第三个架构。难道没看出来这个架构的演变过程？他们是两个宗派在同一个公司的合作成绩，其中多维这块是大师当年亲自操
刀咨询，何来是对他们的权威挑战呢？某些人挖苦讥讽完后，还大惊小怪，不知道是见识少，还是理解有问题。我可从没说过这是全新的，脱离两者权威的架
构。
某些人粗浅地认为多维模型的核心是维和粒度，其实这是很表面的理解，而他们的实质问题是迎合业务源变化、分析业务需求变化，同时平衡公司级定义和最终部
门级需求，所以才在架构方面总结了下我的理解，就是为了迎合变化、能更好地管理、维护和扩展，这也是有的架构能支撑10年，而有的只有1年既被放弃。
行业最知名的软件，这个EDW Kimball先生没有参与咨询指导。
最初进入项目前是架构和建模思想培训1月，然后才是ETL开发，到现在，还有以前一起战斗过的老同事还战斗在这个项目，并且被美国方任命为项目新CDW
架构的主架构师之一。
从项目开发来看，EDW模块非常稳定，很少有开发和升级需求，随着越来越接近前端BI应用，开发需求越大。CDW核心存储并非一次性就是完全是星型模
型，而是大多数维表和事实表直接关联，而有层级关系的维，采用雪花模型关联，这样方便扩展和适应维的定义以及可能的组织层级变化。所有事实表和维表都有
一个生成、维护的一个存储层级，然后和辅助支撑变化的模型放入统一层级，多维数据仓库没有根据某些BI需求而汇总的事实表，他们是基础的、含盖企业级需
求的维和度量。而计划、预算系统的计算结果也将返回多维数据仓库，最后在统一维度层找到他们的位置。
和DM对接的是统一维度层级，由于DM是迎合BI需求的前端数据存储层，所以需要提供更多的、个性化的、方便展现的模型。于是会衍生出桥梁表---
factless fact table、事实表退化维的生成（比如0-18岁，18到30岁....这个也可以生成一个维，但依附于事实表，故成为退
化维，纯粹为了分析需要）、模型纯星型模型化（维结构层次的变化需求已在CDW处理掉）、汇总、宽表需求等等。
该多维模型经过Kimball先生的指导，虽然经历过公司业务重组、最终用户增多，个性化需求越来越多的各种变化，依然近10年不倒。同时跨国公司实力
强，不但划分四大组件，各部分独立设计、独立ETL开发，而且分为两种集成测试，一种是一个组件的内部集成测试，充分保障接口数据的数据质量，另一种才
是贯通系统的大集成测试。
Kimball 的Life cycle那本书是团队镇队之宝，我们一直在一边做项目一边研究其架构的独特思考，因为EDW并非多维数据仓库，而从多维
数据仓库到DM，是一个很严密的Kimball设计方案，各种设计技巧和细节一环扣一环，而且在书中都能找到其理论依据。这对我之后的独立设计有很大的
启发和经验积累效果，而项目中的同事也快速成长，有的留下来，有的后来也离开这个象教科书一样的经典项目，他们都各有自己的成绩。
跨国公司已经把两种观点融合在一起成功实现了混合架构，并有近10年经验，而且在很多项目都或多或少有影响。在TTNN倒却成了怪物，不但有的人没有看
过，而且说我想从两个大师之间形成第三个架构。难道没看出来这个架构的演变过程？他们是两个宗派在同一个公司的合作成绩，其中多维这块是大师当年亲自操
刀咨询，何来是对他们的权威挑战呢？某些人挖苦讥讽完后，还大惊小怪，不知道是见识少，还是理解有问题。我可从没说过这是全新的，脱离两者权威的架
构。
某些人粗浅地认为多维模型的核心是维和粒度，其实这是很表面的理解，而他们的实质问题是迎合业务源变化、分析业务需求变化，同时平衡公司级定义和最终部
门级需求，所以才在架构方面总结了下我的理解，就是为了迎合变化、能更好地管理、维护和扩展，这也是有的架构能支撑10年，而有的只有1年既被放弃。
interstage
May 13, 2008, 12:54:46 PM5/13/08
to ttnn BI 观点
哈哈,谈了这么长时间,终于挤出一点意思来,原来说了半天,你在还讲为什么在CIF架构EDW组件和MD架构中Staging Area组件中需要一个
CDW组件?,我印象中这是IBM Insurance Information Warehouse 中提出.这个不需要再你讲了,TTNN的人基本
都清楚了,因为CDW组件的作用在IBM这么大厂商的10年的推广下已经被业绩认可了,但IBM并没有因为提出CDW组件而产生独立于2大理论性架构的
第三个理论架构,为什么呢.
说的也巧,我在SYBASE工作的时候搞数据仓库就是2个产品:SYBASE IQ和IWS,SYBASE IWS for Finance很
多情况下是写到这样的话: The CDW runs the Sybase IQ database in the IBM UNIX (AIX)
operating system environment. 当时SYBASE负责数据仓库的高手就告诉我:SYBASE IQ最适合CDW,而
TereData最适合EDW,其他RDB(当然包括SYBASE ASE)只能适合在Staging Area或者DM上.
所以对于CDW,我还是很有自己深刻的认识和想法,CDW只所以最早被IBM提出,决不是IBM因为2大架构之争为了取得平衡为起点,是因为
Data from corporate systems are extracted and loaded into the CDW on a
periodic basis depending on the system in question,也就是说IBM接了某金融机构的BI项目,
需要从该金融机构corporate systems中直接extracted and loaded到Corporate Data
Warehouse (CDW被定义了),CDW is an environment for storage and retrieval of
corporate systems data, both current and historical. The goal of the
CDW is to provide easy access to integrated, accurate, and timely
information through interfaces that facilitate querying and reporting
by end users(CDW的原始功能是什么,清楚了吧). 而SYBASE IQ为什么最适合CDW,是因为CDW的本质是希望把基础数据尽
可能的多放在CDW中,又让最终用户可以直接在CDW中快速做查询,而这种CDW组件在DW架构中近乎无理的要求(因为如果选RDB做CDW组件的数据
库,一直存在时间和空间的矛盾,既然存储数据量大又要快速查询),却由于SYBASE IQ最独立的列存储机制变的可行了.这就是CDW的起点,但当时
作为SYBASE的DW高手非常不屑IBM的做法,利用SYBASE IQ软件产品的特性,把corporate systems中的基础数据全部放在
所谓的CDW上,同时直接就在CDW出查询报表,和2大架构的经典理论不符合.
可惜,历史的真相就是因为IBM的强势被修改了,一个美丽的谎话出来了,为了弥补EDW组件和Staging Area组件,IBM搞出了CDW
组件.并把他们做的体系叫"Spoke and Hub"体系. 我真不知道发明bitewise位索引机制的那个技术人员会不会苦笑. 这几年来,随
着其他RDB都开始支持列存储,CDW组件以后可以选择更多的RDB被别人记住
原来,innovate一直非常神秘的以"混合架构"面貌出现,是为了向TTNN的人们深刻介绍CDW的组件功能呀,哎,你早说呀,我把CDW出
现的历史一讲,TTNN就深刻记住了,CDW组件就是IBM在做金融机构的DW项目时,搞了一个叫corporate Data Warehouse的
数据库,该数据库的功能是为了直接放基于四种模型的海量数据(当然以雪花,雪暴,星型,星座模型存放,这其实是IQ讲数据模型的时候最早讲的),又想直
接让最终用户做查询.一举2得.而IQ太独特了,就是一个列存储机制,完全不符合2位大师的架构模式和组件,所以为了掩盖真相,IBM就定义了CDW.
为什么呢,就是应该数据库技术的发展使符合DW的数据库逐步由传统行存储变成了列存储,这样导致海量和查询的矛盾逐渐被解决,使2大架构产生的RBD技
术矛盾(就是时间和空间矛盾)被缓解,这样现在很多的DW建设不在遵守2大架构了.因为数据库产品的技术发展了.
OK,原来innovate给我们TTNN开了一个玩笑,是为了更好的介绍CDW,看来就不是架构之争了.以后直接说,别在搞复杂的理论做帽子
了.
CDW组件?,我印象中这是IBM Insurance Information Warehouse 中提出.这个不需要再你讲了,TTNN的人基本
都清楚了,因为CDW组件的作用在IBM这么大厂商的10年的推广下已经被业绩认可了,但IBM并没有因为提出CDW组件而产生独立于2大理论性架构的
第三个理论架构,为什么呢.
说的也巧,我在SYBASE工作的时候搞数据仓库就是2个产品:SYBASE IQ和IWS,SYBASE IWS for Finance很
多情况下是写到这样的话: The CDW runs the Sybase IQ database in the IBM UNIX (AIX)
operating system environment. 当时SYBASE负责数据仓库的高手就告诉我:SYBASE IQ最适合CDW,而
TereData最适合EDW,其他RDB(当然包括SYBASE ASE)只能适合在Staging Area或者DM上.
所以对于CDW,我还是很有自己深刻的认识和想法,CDW只所以最早被IBM提出,决不是IBM因为2大架构之争为了取得平衡为起点,是因为
Data from corporate systems are extracted and loaded into the CDW on a
periodic basis depending on the system in question,也就是说IBM接了某金融机构的BI项目,
需要从该金融机构corporate systems中直接extracted and loaded到Corporate Data
Warehouse (CDW被定义了),CDW is an environment for storage and retrieval of
corporate systems data, both current and historical. The goal of the
CDW is to provide easy access to integrated, accurate, and timely
information through interfaces that facilitate querying and reporting
by end users(CDW的原始功能是什么,清楚了吧). 而SYBASE IQ为什么最适合CDW,是因为CDW的本质是希望把基础数据尽
可能的多放在CDW中,又让最终用户可以直接在CDW中快速做查询,而这种CDW组件在DW架构中近乎无理的要求(因为如果选RDB做CDW组件的数据
库,一直存在时间和空间的矛盾,既然存储数据量大又要快速查询),却由于SYBASE IQ最独立的列存储机制变的可行了.这就是CDW的起点,但当时
作为SYBASE的DW高手非常不屑IBM的做法,利用SYBASE IQ软件产品的特性,把corporate systems中的基础数据全部放在
所谓的CDW上,同时直接就在CDW出查询报表,和2大架构的经典理论不符合.
可惜,历史的真相就是因为IBM的强势被修改了,一个美丽的谎话出来了,为了弥补EDW组件和Staging Area组件,IBM搞出了CDW
组件.并把他们做的体系叫"Spoke and Hub"体系. 我真不知道发明bitewise位索引机制的那个技术人员会不会苦笑. 这几年来,随
着其他RDB都开始支持列存储,CDW组件以后可以选择更多的RDB被别人记住
原来,innovate一直非常神秘的以"混合架构"面貌出现,是为了向TTNN的人们深刻介绍CDW的组件功能呀,哎,你早说呀,我把CDW出
现的历史一讲,TTNN就深刻记住了,CDW组件就是IBM在做金融机构的DW项目时,搞了一个叫corporate Data Warehouse的
数据库,该数据库的功能是为了直接放基于四种模型的海量数据(当然以雪花,雪暴,星型,星座模型存放,这其实是IQ讲数据模型的时候最早讲的),又想直
接让最终用户做查询.一举2得.而IQ太独特了,就是一个列存储机制,完全不符合2位大师的架构模式和组件,所以为了掩盖真相,IBM就定义了CDW.
为什么呢,就是应该数据库技术的发展使符合DW的数据库逐步由传统行存储变成了列存储,这样导致海量和查询的矛盾逐渐被解决,使2大架构产生的RBD技
术矛盾(就是时间和空间矛盾)被缓解,这样现在很多的DW建设不在遵守2大架构了.因为数据库产品的技术发展了.
OK,原来innovate给我们TTNN开了一个玩笑,是为了更好的介绍CDW,看来就不是架构之争了.以后直接说,别在搞复杂的理论做帽子
了.
interstage
May 13, 2008, 1:33:33 PM5/13/08
to ttnn BI 观点
可能TTNN被我刚才一些话说迷糊了,我再整理一下,描述如下:
1,CIF架构和MD架构当时出现和认可的时候,RDB还是以行存储方式,所以一直存在在时间和空间的矛盾,导致CIF架构和MD架构在定义时,除了包
含业务管理层面,也在数据库技术上冗余的海量数据和数据模型中一直寻找着平衡.
2,1998年,SYBASE IQ的成熟,是列存储方式的RDB数据库出现(98年前,IQ还不支持SQL 语句,只支持Bitwise技术),列存
储方式打破了传统的时间和空间的矛盾,又解决了RDB中数据膨胀的问题,是基于复杂数据模型冗余海量数据放在一个数据库中,实现快速查询成为现实.
3,IBM接了一个金融企业的DW项目,需求就是在复杂的corporate systems中导到一个DW中,让最终用户快速实现查询,接着IBM采
用了这种列存储方式的数据库,当然在模型设计上非常辛苦的以4种方式建模.最终达到了客户的要求,这样就把这个方式单独定义了一个名字叫
corporate Data Warehouse
4,曾几何时,使CDW作为DW架构的工业组件被很多DW技术人员推荐,很多DW技术人员都说是为了平衡2大架构的矛盾,07年底ORACLE的数据库
产品,如果被选择做数据仓库的DB,可支持了列存储,所以CDW组件变成事实.
5,CDW的本质,不是架构的问题,也不是管理上的问题,就是以数据库存储方式的突破引起的.
可笑的是,我做的80%的BI项目中,不同程度都会采用SYBASE IQ这种列存储方式的数据库,不是直接做CDW做查询后再生成CUBE,就是直接
做CDW连ROLAP分析,更牛比的一个做法,直接用PB的Datawindow连IQ,实现海量数据下的查询速度很快.
这就是CDW的真相.
1,CIF架构和MD架构当时出现和认可的时候,RDB还是以行存储方式,所以一直存在在时间和空间的矛盾,导致CIF架构和MD架构在定义时,除了包
含业务管理层面,也在数据库技术上冗余的海量数据和数据模型中一直寻找着平衡.
2,1998年,SYBASE IQ的成熟,是列存储方式的RDB数据库出现(98年前,IQ还不支持SQL 语句,只支持Bitwise技术),列存
储方式打破了传统的时间和空间的矛盾,又解决了RDB中数据膨胀的问题,是基于复杂数据模型冗余海量数据放在一个数据库中,实现快速查询成为现实.
3,IBM接了一个金融企业的DW项目,需求就是在复杂的corporate systems中导到一个DW中,让最终用户快速实现查询,接着IBM采
用了这种列存储方式的数据库,当然在模型设计上非常辛苦的以4种方式建模.最终达到了客户的要求,这样就把这个方式单独定义了一个名字叫
corporate Data Warehouse
4,曾几何时,使CDW作为DW架构的工业组件被很多DW技术人员推荐,很多DW技术人员都说是为了平衡2大架构的矛盾,07年底ORACLE的数据库
产品,如果被选择做数据仓库的DB,可支持了列存储,所以CDW组件变成事实.
5,CDW的本质,不是架构的问题,也不是管理上的问题,就是以数据库存储方式的突破引起的.
可笑的是,我做的80%的BI项目中,不同程度都会采用SYBASE IQ这种列存储方式的数据库,不是直接做CDW做查询后再生成CUBE,就是直接
做CDW连ROLAP分析,更牛比的一个做法,直接用PB的Datawindow连IQ,实现海量数据下的查询速度很快.
这就是CDW的真相.
innovate511
May 13, 2008, 8:59:43 PM5/13/08
to ttnn BI 观点
有的人就那么自以为是，你自己做过近10年历史的DW么？按照规范自己规划、设计过DW并正常使用2、3年么，做过组件基于上层组件的重组么？
以前我已经聊过这种架构，但是这次特别的地方就是虚拟化思想，从目前很多成功案例看，他们的各个组件都是分开独立开发，而且有的还是不同公司的团队开
发，以接口形式完成集成。于是我后来自己在2个项目成功实施虚拟对接架构，在不同时期满足客户不同的架构需求，现在规划完一个大的架构项目，正在逐步实
施中。这种体会，TTNN谁人有，有的话请站出来说说感受，免得某些人老那么二。
CDW只是混合架构中重要的一部分，并非全部，就拿我跟很多想设计出优秀多维数据仓库的人交流来说，他们对多维数据仓库的侧重点，和为什么他的想法不合
理，怎样才更合理，完全心里没数，他们不也看过Inmon,Kimball的书么？
知道某些厂商的DW产品和思路又如何呢？IBM,ORACLE的行业模型又不是没见过，但我见得最多的是，行业模型来过来硬套，架构很不合理，这就是属
于对一些细节了解还不够，经验积累尚需时日。只有合理利用行业模型，架构才能稳固，行业模型也才能体现出已有的功效。
某些人多次说些很2的话，从表面上讲，很多东西殊途同归，道理当然相通的，经某些人那么一讲，就没必要深入下去了，因为是个人都知道怎么做，看来我国
DW建设水平都很高啊，就差某些人的持续改善的管理方案，然后就能世界顶级了。
某些人一再说DW的理论已经很成熟，没什么好讨论的，但是根据我和多名3-5年DW经验的朋友交流，细节还非常模糊，无法确定多维数据仓库和数据集市具
体功能，以及技术上如何支持分析闭环。于是某些人早已完全脱离技术，靠仅有的老理论、产品介绍、过去的一些经验就觉得DW不过如此，没啥好发展的。
某些人除了知道点DW的故事和理论，还做过什么呢？难怪已经“精通DW”，就显得那么2了。还是老老实实搞好你的持续改善BI推广吧，这玩意一听起来就
是在大道理基础上想做事实，只能两个字---太难，以后可以建议做BI的毕业生先学管理学，而且是指定管理学，然后再学BIDW的技术基础，这样就能持
续改善了。
某些自以为精通DW很二的人，能不能让看一个道，让别人从细节上交流下？每每如此搅乱，没人能深入讨论，就像一个神经病，不管你说什么都要否定几句。更
何况数据基础的讨论，并不影响某些人的思想，除了说某些人针对人外，别无其他解释。
如果TTNN很欣赏这种无理挖苦讥讽的作风，那我也可以帮TTNN热闹一下，挖苦讥讽谁不会呢？谁的描述没有半点漏洞或不够清晰的地方呢？越是成功案例
少的，越是偏理论的，可挖苦和讥讽的地方越多。
那好，我退出TTNN的发帖者，成为回帖者，不再成为主角，也就不再接受任何“质疑和挑战”，到其他需要我的地方发帖讲解。同时，TTNN我已有发帖不
再理会，不再回任何人的帖子，专心在向某些人发质疑和挑战，才符合TTNN精神。这样的话，我在TTNN的回帖很可能多是挖苦讥讽的词语，让有些人也换
个角度感受一下，这样才更公平一点。
以前我已经聊过这种架构，但是这次特别的地方就是虚拟化思想，从目前很多成功案例看，他们的各个组件都是分开独立开发，而且有的还是不同公司的团队开
发，以接口形式完成集成。于是我后来自己在2个项目成功实施虚拟对接架构，在不同时期满足客户不同的架构需求，现在规划完一个大的架构项目，正在逐步实
施中。这种体会，TTNN谁人有，有的话请站出来说说感受，免得某些人老那么二。
CDW只是混合架构中重要的一部分，并非全部，就拿我跟很多想设计出优秀多维数据仓库的人交流来说，他们对多维数据仓库的侧重点，和为什么他的想法不合
理，怎样才更合理，完全心里没数，他们不也看过Inmon,Kimball的书么？
知道某些厂商的DW产品和思路又如何呢？IBM,ORACLE的行业模型又不是没见过，但我见得最多的是，行业模型来过来硬套，架构很不合理，这就是属
于对一些细节了解还不够，经验积累尚需时日。只有合理利用行业模型，架构才能稳固，行业模型也才能体现出已有的功效。
某些人多次说些很2的话，从表面上讲，很多东西殊途同归，道理当然相通的，经某些人那么一讲，就没必要深入下去了，因为是个人都知道怎么做，看来我国
DW建设水平都很高啊，就差某些人的持续改善的管理方案，然后就能世界顶级了。
某些人一再说DW的理论已经很成熟，没什么好讨论的，但是根据我和多名3-5年DW经验的朋友交流，细节还非常模糊，无法确定多维数据仓库和数据集市具
体功能，以及技术上如何支持分析闭环。于是某些人早已完全脱离技术，靠仅有的老理论、产品介绍、过去的一些经验就觉得DW不过如此，没啥好发展的。
某些人除了知道点DW的故事和理论，还做过什么呢？难怪已经“精通DW”，就显得那么2了。还是老老实实搞好你的持续改善BI推广吧，这玩意一听起来就
是在大道理基础上想做事实，只能两个字---太难，以后可以建议做BI的毕业生先学管理学，而且是指定管理学，然后再学BIDW的技术基础，这样就能持
续改善了。
某些自以为精通DW很二的人，能不能让看一个道，让别人从细节上交流下？每每如此搅乱，没人能深入讨论，就像一个神经病，不管你说什么都要否定几句。更
何况数据基础的讨论，并不影响某些人的思想，除了说某些人针对人外，别无其他解释。
如果TTNN很欣赏这种无理挖苦讥讽的作风，那我也可以帮TTNN热闹一下，挖苦讥讽谁不会呢？谁的描述没有半点漏洞或不够清晰的地方呢？越是成功案例
少的，越是偏理论的，可挖苦和讥讽的地方越多。
那好，我退出TTNN的发帖者，成为回帖者，不再成为主角，也就不再接受任何“质疑和挑战”，到其他需要我的地方发帖讲解。同时，TTNN我已有发帖不
再理会，不再回任何人的帖子，专心在向某些人发质疑和挑战，才符合TTNN精神。这样的话，我在TTNN的回帖很可能多是挖苦讥讽的词语，让有些人也换
个角度感受一下，这样才更公平一点。
interstage
May 13, 2008, 11:10:19 PM5/13/08
to ttnn BI 观点
哎,有句话说的好,只有创造出来的东西是最美的,真实的东西往往不美丽. CDW组件被IBM的定义出来的时候,它并不美丽,的确是隐含了它本来的面
目,其实当时它根本就不符合CIF和MD架构. 但由于IBM的强势和努力,使CDW变的美丽了,变的有价值了,也是由于CDW的存在是CIF和MD2
大架构存在理论上的缺陷了.现在我们回头去看CDW组件,它目前至少在以下层面上有价值:
1,CDW往往比EDW数据量大,我曾经见过一个变态的国外例子,4个EDW数据通过ETL放入CDW,所以CDW是放基础数据的,所以目前牛人只见到
过CDW数据量只有几T,真的是不大.
2,CDW对EDW的冲击不大,但对MD的Staging Area组件的替代性很强,因为CDW的数据存储方式,基本上以多维模型进行设计的.
3,CDW在多维模型设计上使Kimball的模型实现有了极大的用武之地. 我以前针对于Sybase IWS和SAFE实施方法论,有过研究,其实
也是非常深刻说明如何提供更多的个性化的方便展现的行业模型,当然在行业模型上为了解决退化维等问题,IWS在模型了不仅有事实表,维度,也用很多视图
(因为VIEW有逻辑可以进行处理了,但实际上是虚表)和存储过程(根据时间和逻辑的变化,调整事实表和维表的数据)
在这个价值下,CDW脱离了原来的起点,形成了新的有价值的组件,但可惜的是,在理论层面上,2位大师一直没有把CDW组件归入其中,导致项目实施的过
程中和实际理论的缺陷.至于为什么不归纳入其中,我个人也没想明白,曾经问过一些高手,也曾经反思过,得到的答案总结如下:
1,从CDW组件的逻辑功能上来讲,2大架构都存在了
2,从CDW组件的管理层面来讲,的确很难在放入2大架构其中
3,本身CDW的出现,是数据库技术的发展造成的,而2大架构是基于原来相对固化数据库设计出来的,没有预期到这个数据库技术的出现,所以把2大架构的
设计基础给打破了
但我相信,既然CDW组件已经存在了近10年,随着数据库技术的继续发展(主要是网格计算和列存储的成熟),一定会出现,基于新的数据库技术的新的DW
架构.
所以，这就是我一直盯着牛人来展开混合架构的原因,就是他所谓的混合架构究竟是他在设计上的突破,还是由于CDW组件引起.
至于牛人说我知道点DW的故事和理论,就已经"精通DW",这个你实在太抬举我了. 我学习任何知识,都是这样的方式(以CDW组件为例):
1,CDW组件是如何发生的,因为你知道它的起点,就会知道它的价值
2,CDW组件目前的功能和价值,因为你知道它的现状,就能知道它的发展轨迹
3,CDW组件为什么会发展成这样,因为你知道它发展的原因,就能知道它未来的走向
所以,我一直说,对于DW也好,BI也好,我的方向是清晰的把握它技术的走向,对于技术细节的实施和技巧,的确,我已经开始疏远了.谈不上精通,但至少
凭着对DW技术的走向的判断,可以对你所谓的架构提出质疑. 不是不允许你提架构,是想看看,你的架构的起点是什么,是不是能符合未来DW的方向.
我个人认为单纯为了CDW组件的历史地位来创立新的架构,估计可能性不大.新架构的出现,一定是基于以下2点:
1,设计上的提高,这个和管理思路有关系
2,数据库技术的继续发展,这个是DW技术的根本.
目,其实当时它根本就不符合CIF和MD架构. 但由于IBM的强势和努力,使CDW变的美丽了,变的有价值了,也是由于CDW的存在是CIF和MD2
大架构存在理论上的缺陷了.现在我们回头去看CDW组件,它目前至少在以下层面上有价值:
1,CDW往往比EDW数据量大,我曾经见过一个变态的国外例子,4个EDW数据通过ETL放入CDW,所以CDW是放基础数据的,所以目前牛人只见到
过CDW数据量只有几T,真的是不大.
2,CDW对EDW的冲击不大,但对MD的Staging Area组件的替代性很强,因为CDW的数据存储方式,基本上以多维模型进行设计的.
3,CDW在多维模型设计上使Kimball的模型实现有了极大的用武之地. 我以前针对于Sybase IWS和SAFE实施方法论,有过研究,其实
也是非常深刻说明如何提供更多的个性化的方便展现的行业模型,当然在行业模型上为了解决退化维等问题,IWS在模型了不仅有事实表,维度,也用很多视图
(因为VIEW有逻辑可以进行处理了,但实际上是虚表)和存储过程(根据时间和逻辑的变化,调整事实表和维表的数据)
在这个价值下,CDW脱离了原来的起点,形成了新的有价值的组件,但可惜的是,在理论层面上,2位大师一直没有把CDW组件归入其中,导致项目实施的过
程中和实际理论的缺陷.至于为什么不归纳入其中,我个人也没想明白,曾经问过一些高手,也曾经反思过,得到的答案总结如下:
1,从CDW组件的逻辑功能上来讲,2大架构都存在了
2,从CDW组件的管理层面来讲,的确很难在放入2大架构其中
3,本身CDW的出现,是数据库技术的发展造成的,而2大架构是基于原来相对固化数据库设计出来的,没有预期到这个数据库技术的出现,所以把2大架构的
设计基础给打破了
但我相信,既然CDW组件已经存在了近10年,随着数据库技术的继续发展(主要是网格计算和列存储的成熟),一定会出现,基于新的数据库技术的新的DW
架构.
所以，这就是我一直盯着牛人来展开混合架构的原因,就是他所谓的混合架构究竟是他在设计上的突破,还是由于CDW组件引起.
至于牛人说我知道点DW的故事和理论,就已经"精通DW",这个你实在太抬举我了. 我学习任何知识,都是这样的方式(以CDW组件为例):
1,CDW组件是如何发生的,因为你知道它的起点,就会知道它的价值
2,CDW组件目前的功能和价值,因为你知道它的现状,就能知道它的发展轨迹
3,CDW组件为什么会发展成这样,因为你知道它发展的原因,就能知道它未来的走向
所以,我一直说,对于DW也好,BI也好,我的方向是清晰的把握它技术的走向,对于技术细节的实施和技巧,的确,我已经开始疏远了.谈不上精通,但至少
凭着对DW技术的走向的判断,可以对你所谓的架构提出质疑. 不是不允许你提架构,是想看看,你的架构的起点是什么,是不是能符合未来DW的方向.
我个人认为单纯为了CDW组件的历史地位来创立新的架构,估计可能性不大.新架构的出现,一定是基于以下2点:
1,设计上的提高,这个和管理思路有关系
2,数据库技术的继续发展,这个是DW技术的根本.
Qing
May 14, 2008, 1:13:38 AM5/14/08
to tt...@googlegroups.com
我晕，虽然讨论前进了一步，但依然是困难重重。好像这个混合架构的核心变成cdw之争了，有没有第三个人站出来来说说cdw？
昨天还有朋友问我cdw是啥玩意儿，我不知道，确实不知道，为什么两位都认为在ttnn每个人都知道这些呢？关于这些概念的东西，也许个人认识有所差异，但如果谈谈他的历史，比如谁提出的？为了解决什么问题提出的概念？
按照interstage的说法，cdw是ibm的一个保险行业的信息模型中提出的概念，这是不是就是innovate参与的那个项目呢？至于说ibm整出cdw是因为要弥补edw跟staging area的不足，是弥补哪方面的不足呢？另外，为什么说，列式存储就解决了cdw的问题了呢？如果说是解决时间和空间的矛盾（通俗点就是要速度还是要容量吧），难道cdw就是为了缓解这个矛盾的吗？——也就是说，cdw的存在是为了访问数据更快一点吗？也就是说cdw是一种比较贴近分析查询的汇总层吗？
于是我产生一个疑问，如果是为了解决时间与空间的矛盾，那么现在的分布式数据库也能查询，是不是也相当于解决cdw的问题了呢？
关于这个问题，我想还是得翻开以往的帖子，来看看innovate怎么对这四层理解的，今年三月份时候的一次讨论提到的比较归纳：
逻辑架构规划，首先看看未来趋势，是否采用哪种架构。我个人觉得最好的方式是有ODS，有范式模型的EDW，也有客户化维度型数据仓库（CDW，由范式到多维，采用统一维度建模思想），然后是数据集市。其中ODS需要有如下功能：数据清洗/准备、业务数据集成过渡（供业务系统数据集成过渡使用）、即时BI数据源；EDW主要功能还是在数据整合集成方面，但不直接给BI使用，中长远看，EDW是必须的，他不但可以最好地管理数据，管理历史数据，而且能保持最细的数据，没有业务转换的数据，意味着哪怕维度模型有天翻地覆的变化，EDW也能做最好的支撑。有的项目EDW也支持最细节的复杂查询，我觉得这个要看情况去理解具体需求了。CDW也是必须的，BI分析不能没有维度模型，但多个主题的分析，要解决业务数据一致性、统一性，必须统一建模。它也需要有一定历史数据，来支撑分析，但是更大的特点是，周期性特强，日、周、月、季、年，分别可有自己的周期汇总数据。数据集市(DM)主要是为BI提供数据，由于BI分析的多样性，所以一般来说，数据集市的模型会比统一维度的还要详细许多，扩展许多，个性化分析需求的字段也需要根据情况扩展。各种展现效率、安全管理、业务变化，都得有充分的设计。
从这个归纳看，edw跟cdw的区别，是前者超级稳定，能够容忍业务变化，一般不让查询。而后者，是面向分析主题的，是汇总的。一般查询都从这里出。但他们是否有严格的区分界限呢？
以上的一些疑问，有些是向interstage求证，有些是向innovate请教的，再汇总一下：
1、cdw最初提出的理由是什么？大概是哪一年？
2、cdw的真正作用是什么？为了解决什么问题而存在（具体点）
3、edw跟cdw的严格区别在何处？所谓严格，就是他们各自能干什么，不能干什么，最好不要功能重叠。
4、分布式数据库是否能解决性能问题，从而可以直接访问edw而舍弃cdw？（这个问题可能本身提法就有问题，得根据前面的答案来。）
2008/5/14 interstage buer...@gmail.com:
。。。 所以对于CDW,。。。CDW is an environment for storage and retrieval of corporate systems data, both current and historical. The goal of the CDW is to provide easy access to integrated, accurate, and timely information through interfaces that facilitate querying and reporting by end users(CDW的原始功能是什么,清楚了吧).。。。
interstage
May 14, 2008, 1:32:39 AM5/14/08
to ttnn BI 观点
1,从架构之争变成到CDW之争,很正常,因为innovate所提的架构是来自于他的经验,而他的经验的核心是参与了一个国外的DW建设,这个DW建
设采用了CDW组件,而在中国很少有DW项目用CDW组件的,所以他提出新架构的资本了.
2,CDW组件的出现是晚于2大架构的,但奇怪的是,CDW组件到现在也存在了10年,居然2大架构没有融合它进来(期间DW2.0还修正过),所以这
也是我一直想知道的原因,难道是CDW组件的出现只是技巧性的,不存在对架构中各组件逻辑功能的再补充.
3,CDW目前的真正作用,我个人感觉是将CIF架构中EDW组件的部分功能和MD架构中Staging Area组件的全部功能合并.所以,你看
innovate的新架构中没有Staging Area组件了,而且看上去是混合2个架构.
4,CDW有一个认识陷阱,就是以为CDW比EDW小,但实际上是相反的,在数据膨胀的角度考虑,CDW一定是超过EDW的.
5,你说到一个经典的技术思路方向,就是分布式(不管是网格还是云计算)的继续推进,未来在逻辑和物理上都不可能有CDW的位置存在.但EDW和
Staging Area在逻辑上还是可以分解,可能在物理上是一个.
这就是本次架构之争的焦点,不管是从架构定义描述上,设计方向上,技术发展上,我真的一点都没感觉架构创新的影子. 可能唯一剩下的是CDW组件实现的
方法论和数据模型设计的经验呀.但这个很早前,有公司已经总结出来,叫什么产品包,去买钱了.
On 5月14日, 下午1时13分, Qing <happys...@gmail.com> wrote:
> 我晕，虽然讨论前进了一步，但依然是困难重重。好像这个混合架构的核心变成cdw之争了，有没有第三个人站出来来说说cdw？
>
> 昨天还有朋友问我cdw是啥玩意儿，我不知道，确实不知道，为什么两位都认为在ttnn每个人都知道这些呢？关于这些概念的东西，也许个人认识有所差异，但如果-谈谈他的历史，比如谁提出的？为了解决什么问题提出的概念？
>
> 按照interstage的说法，cdw是ibm的一个保险行业的信息模型中提出的概念，这是不是就是innovate参与的那个项目呢？至于说ibm整出cd-w是因为要弥补edw跟staging
> area的不足，是弥补哪方面的不足呢？另外，为什么说，列式存储就解决了cdw的问题了呢？如果说是解决时间和空间的矛盾（通俗点就是要速度还是要容量吧），-难道cdw就是为了缓解这个矛盾的吗？----也就是说，cdw的存在是为了访问数据更快一点吗？也就是说cdw是一种比较贴近分析查询的汇总层吗？
>
> > CDW也是必须的，BI分析不能没有维度模型，但多个主题的分析，要解决业务数据一致性、统一性，必须统一建模。它也需要有一定历史数据，来支撑分析，但是更大-的特点是，周期性特强，日、周、月、季、年，分别可有自己的周期汇总数据。
>
> > 数据集市(DM)主要是为BI提供数据，由于BI分析的多样性，所以一般来说，数据集市的模型会比统一维度的还要详细许多，扩展许多，个性化分析需求的字段也需-要根据情况扩展。各种展现效率、安全管理、业务变化，都得有充分的设计。
>
> 从这个归纳看，edw跟cdw的区别，是前者超级稳定，能够容忍业务变化，一般不让查询。而后者，是面向分析主题的，是汇总的。一般查询都从这里出。但他们是否-有严格的区分界限呢？
>
>
>
> > 。。。 所以对于CDW,。。。CDW is an environment for storage and retrieval of
>
> - 显示引用的文字 -
设采用了CDW组件,而在中国很少有DW项目用CDW组件的,所以他提出新架构的资本了.
2,CDW组件的出现是晚于2大架构的,但奇怪的是,CDW组件到现在也存在了10年,居然2大架构没有融合它进来(期间DW2.0还修正过),所以这
也是我一直想知道的原因,难道是CDW组件的出现只是技巧性的,不存在对架构中各组件逻辑功能的再补充.
3,CDW目前的真正作用,我个人感觉是将CIF架构中EDW组件的部分功能和MD架构中Staging Area组件的全部功能合并.所以,你看
innovate的新架构中没有Staging Area组件了,而且看上去是混合2个架构.
4,CDW有一个认识陷阱,就是以为CDW比EDW小,但实际上是相反的,在数据膨胀的角度考虑,CDW一定是超过EDW的.
5,你说到一个经典的技术思路方向,就是分布式(不管是网格还是云计算)的继续推进,未来在逻辑和物理上都不可能有CDW的位置存在.但EDW和
Staging Area在逻辑上还是可以分解,可能在物理上是一个.
这就是本次架构之争的焦点,不管是从架构定义描述上,设计方向上,技术发展上,我真的一点都没感觉架构创新的影子. 可能唯一剩下的是CDW组件实现的
方法论和数据模型设计的经验呀.但这个很早前,有公司已经总结出来,叫什么产品包,去买钱了.
On 5月14日, 下午1时13分, Qing <happys...@gmail.com> wrote:
> 我晕，虽然讨论前进了一步，但依然是困难重重。好像这个混合架构的核心变成cdw之争了，有没有第三个人站出来来说说cdw？
>
>
> 按照interstage的说法，cdw是ibm的一个保险行业的信息模型中提出的概念，这是不是就是innovate参与的那个项目呢？至于说ibm整出cd-w是因为要弥补edw跟staging
> area的不足，是弥补哪方面的不足呢？另外，为什么说，列式存储就解决了cdw的问题了呢？如果说是解决时间和空间的矛盾（通俗点就是要速度还是要容量吧），-难道cdw就是为了缓解这个矛盾的吗？----也就是说，cdw的存在是为了访问数据更快一点吗？也就是说cdw是一种比较贴近分析查询的汇总层吗？
>
> 于是我产生一个疑问，如果是为了解决时间与空间的矛盾，那么现在的分布式数据库也能查询，是不是也相当于解决cdw的问题了呢？
>
> 关于这个问题，我想还是得翻开以往的帖子，来看看innovate怎么对这四层理解的，今年三月份时候的一次讨论提到的比较归纳：
>
>
>
> > 逻辑架构规划，首先看看未来趋势，是否采用哪种架构。我个人觉得最好的方式是有ODS，有范式模型的EDW，也有客户化维度型数据仓库（CDW，由范式到多维，-采用统一维度建模思想），然后是数据集市。其中
> 于是我产生一个疑问，如果是为了解决时间与空间的矛盾，那么现在的分布式数据库也能查询，是不是也相当于解决cdw的问题了呢？
>
> 关于这个问题，我想还是得翻开以往的帖子，来看看innovate怎么对这四层理解的，今年三月份时候的一次讨论提到的比较归纳：
>
>
>
>
> > ODS需要有如下功能：数据清洗/准备、业务数据集成过渡（供业务系统数据集成过渡使用）、即时BI数据源；
>
> > EDW主要功能还是在数据整合集成方面，但不直接给BI使用，中长远看，EDW是必须的，他不但可以最好地管理数据，管理历史数据，而且能保持最细的数据，没有-业务转换的数据，意味着哪怕维度模型有天翻地覆的变化，EDW也能做最好的支撑。有的项目EDW也支持最细节的复杂查询，我觉得这个要看情况去理解具体需求了。
> > ODS需要有如下功能：数据清洗/准备、业务数据集成过渡（供业务系统数据集成过渡使用）、即时BI数据源；
>
>
> > CDW也是必须的，BI分析不能没有维度模型，但多个主题的分析，要解决业务数据一致性、统一性，必须统一建模。它也需要有一定历史数据，来支撑分析，但是更大-的特点是，周期性特强，日、周、月、季、年，分别可有自己的周期汇总数据。
>
> > 数据集市(DM)主要是为BI提供数据，由于BI分析的多样性，所以一般来说，数据集市的模型会比统一维度的还要详细许多，扩展许多，个性化分析需求的字段也需-要根据情况扩展。各种展现效率、安全管理、业务变化，都得有充分的设计。
>
> 从这个归纳看，edw跟cdw的区别，是前者超级稳定，能够容忍业务变化，一般不让查询。而后者，是面向分析主题的，是汇总的。一般查询都从这里出。但他们是否-有严格的区分界限呢？
>
> 以上的一些疑问，有些是向interstage求证，有些是向innovate请教的，再汇总一下：
> 1、cdw最初提出的理由是什么？大概是哪一年？
> 2、cdw的真正作用是什么？为了解决什么问题而存在（具体点）
> 3、edw跟cdw的严格区别在何处？所谓严格，就是他们各自能干什么，不能干什么，最好不要功能重叠。
> 4、分布式数据库是否能解决性能问题，从而可以直接访问edw而舍弃cdw？（这个问题可能本身提法就有问题，得根据前面的答案来。）
>
> 2008/5/14 interstage buer0...@gmail.com:
> 以上的一些疑问，有些是向interstage求证，有些是向innovate请教的，再汇总一下：
> 1、cdw最初提出的理由是什么？大概是哪一年？
> 2、cdw的真正作用是什么？为了解决什么问题而存在（具体点）
> 3、edw跟cdw的严格区别在何处？所谓严格，就是他们各自能干什么，不能干什么，最好不要功能重叠。
> 4、分布式数据库是否能解决性能问题，从而可以直接访问edw而舍弃cdw？（这个问题可能本身提法就有问题，得根据前面的答案来。）
>
>
>
>
> > 。。。 所以对于CDW,。。。CDW is an environment for storage and retrieval of
> > corporate systems data, both current and historical. The goal of the CDW is
> > to provide easy access to integrated, accurate, and timely information
> > through interfaces that facilitate querying and reporting by end
> > users(CDW的原始功能是什么,清楚了吧).。。。- 隐藏被引用文字 -
> > to provide easy access to integrated, accurate, and timely information
> > through interfaces that facilitate querying and reporting by end
>
> - 显示引用的文字 -
interstage
May 14, 2008, 2:19:15 AM5/14/08
to ttnn BI 观点
难道TTNN中除了我们2人,都没谈过CDW吗,奇怪,难道innovate加入TTNN后,没详细解释过CDW吗,没把CDW深入浅出的说明白吗.
哎,网上有人曾经总结出DW建设中6大实用性架构,我转贴一下:
1．独立的数据集市架构（Independent data mart architecture）
独立的数据集市架构有时也称为独立的数据仓库架构，应该是出现最早的架构方式，也是很常见的方式。特别是对于中小企业、中小开发公司，出于成本和见效快
的考虑都会采用这种架构方式。大家对这种架构方式一定也很熟。
这种架构方式的缺点也很明显，不是企业内一致的数据，产生信息孤岛。当然如果企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方
式也没什么。先期小投资，让企业看看效果，以后发展大了再考虑重新建立数据仓库。
2．联邦式数据仓库架构（Federated data warehouse architecture）
它的出现是由于，企业发展的初期建立了几个独立的数据集市架构，后来发现这样不行，数据没整合，要解决信息孤岛得想办法。推倒重建当然好，不过投入太
大，以前的数据集市还想用，怎么办。于是，想出另一种办法，在各个独立的数据集市间建立一些对照表，在不推倒它们的基础上能进行一下数据交换。后来，慢
慢发现，早想好整合策略，直接这样建数据仓库也可以，于是，地域联邦、功能联邦的概念也就都提出来了。
联邦架构的缺点也很明显，除非建立之初就采用类似总线架构的方法实现数据一致，否则很容易出现数据不一致，导致整合的不彻底。如果之初就考虑好的话，和
总线架构的差别就不大了。当然，对于临时解决企业原有独立数据集市的数据交换问题，联邦架构还是有一定作用的。
3．集中式架构（Centralized architecture）
集中式架构方式的出现，标识着数据仓库架构已经进入比较成熟的时期。他的架构方式是建立物理的EDW，即中心数据仓库，数据都集中的EDW中，应用和分
析程序都在EDW中进行访问，数据是全企业内一致的。随着ROLAP的发展，在这种集中式架构中建立ROLAP开始比较流行，常见的
MicroStrategy公司的解决方案就是在EDW中建立ROLAP。ROLAP单独建表保存元数据，只保存维度模型的关系，不保存维度模型的数
据，由MicroStrategy的应用去解析，加上应用服务器作为缓存，速度还可以。
这种方式也有一些缺点，如扩展能力差，对EDW所在的RDBMS要求太高，随着数据量和分析的逐步增长，就不得不再把数据进行分离。如果在EDW的基础
上进行数据分离，为不同的应用单独建立数据集市或者挖掘仓库，集中式结构也就演变成Hub and Spoke架构方式。
4．集线器和车轮辐条架构（Hub and spoke architecture或Corporate information factory）
architecture），集线器和车轮辐条架构听起来比较别扭，叫起来也不响亮。而企业信息工厂应该是这种架构方式的最出色的代表。从名称我们也能
大概猜个差不多，中心数据仓库 EDW从各个源系统收集数据，将数据提供给各个数据集市和挖掘仓库，功能和集线器很相似，所以称为Hub。如果大家把图
画出来，可能会更形象一些，EDW 和各个源数据库及数据集市、挖掘仓库之间都连一条线，看起来就向一个车轮，这些连线就像车轮辐条，所以称为
Spoke。而这种采用中心数据仓库EDW集成数据，再分散到各个数据集市使用数据的方式就形象的称为Hub and spoke
architecture。
这种架构方式当然也有缺点，虽然是在集成的中心数据仓库EDW上建立数据集市，但是这些数据集市之间还是不能进行数据交换的，大家建立的方法和ETL程
序都会不同，各个数据集市之间的数据不见得的是一致的。而且这种架构方式开始变得复杂。
5．总线架构（Bus architecture）
总线架构和Hub and spoke architecture 的最大区别，应该是维度建模的原子层和一致性维度的建立。正因为预先建立的总线架构
和一致性维度，所以这种架构可以保证在逐步建立数据集市的过程中还能保证企业数据的一致性。总线架构是数据仓库架构方式从复杂走向简单的一步，将维度建
模的数据仓库原子层和数据集市合而为一，一层就把数据仓库建立好的，还能支持各种数据集市分析应用。
当然总线架构也有缺点，中心数据仓库以维度模型保存，对于特殊的非维度型分析应用会有局限性，支持的不好。
6．复合式架构（Composite architecture）
这种架构方式是综合考虑Huband spoke architecture和Bus architecture两种架构方式，或者说综合两种方式得出
的一种架构方式，CDW架构应该就是这种架构方式的代表。复合式架构的缺点也是很明显，架构过于复杂，（比CIF还要复杂），企业内数据量大的话，每一
次搬动都会非常麻烦。
所以基于CDW组件的复合式架构（Composite architecture）最大的问题在于企业内数据量大的话，每一次搬动都会非常麻烦.
innovate因为只碰到了几T数据,所以没有发现用CDW组件的复合式架构带来数据膨胀问题.
以上6个架构的英文名字都叫architecture,其实是项目建设的架构说法.而理论性2个架构的英文名字是"architectural
framework ",是可以总结出framework的理论性东西了.
我不知道这个说法,TTNN是否明白清晰了吗.欢迎继续交流DW的架构,架构的说法一定要清晰.
哎,网上有人曾经总结出DW建设中6大实用性架构,我转贴一下:
1．独立的数据集市架构（Independent data mart architecture）
独立的数据集市架构有时也称为独立的数据仓库架构，应该是出现最早的架构方式，也是很常见的方式。特别是对于中小企业、中小开发公司，出于成本和见效快
的考虑都会采用这种架构方式。大家对这种架构方式一定也很熟。
这种架构方式的缺点也很明显，不是企业内一致的数据，产生信息孤岛。当然如果企业就是很小，就一个系统，不用整合，一个数据集市足以的情况下采用这种方
式也没什么。先期小投资，让企业看看效果，以后发展大了再考虑重新建立数据仓库。
2．联邦式数据仓库架构（Federated data warehouse architecture）
它的出现是由于，企业发展的初期建立了几个独立的数据集市架构，后来发现这样不行，数据没整合，要解决信息孤岛得想办法。推倒重建当然好，不过投入太
大，以前的数据集市还想用，怎么办。于是，想出另一种办法，在各个独立的数据集市间建立一些对照表，在不推倒它们的基础上能进行一下数据交换。后来，慢
慢发现，早想好整合策略，直接这样建数据仓库也可以，于是，地域联邦、功能联邦的概念也就都提出来了。
联邦架构的缺点也很明显，除非建立之初就采用类似总线架构的方法实现数据一致，否则很容易出现数据不一致，导致整合的不彻底。如果之初就考虑好的话，和
总线架构的差别就不大了。当然，对于临时解决企业原有独立数据集市的数据交换问题，联邦架构还是有一定作用的。
3．集中式架构（Centralized architecture）
集中式架构方式的出现，标识着数据仓库架构已经进入比较成熟的时期。他的架构方式是建立物理的EDW，即中心数据仓库，数据都集中的EDW中，应用和分
析程序都在EDW中进行访问，数据是全企业内一致的。随着ROLAP的发展，在这种集中式架构中建立ROLAP开始比较流行，常见的
MicroStrategy公司的解决方案就是在EDW中建立ROLAP。ROLAP单独建表保存元数据，只保存维度模型的关系，不保存维度模型的数
据，由MicroStrategy的应用去解析，加上应用服务器作为缓存，速度还可以。
这种方式也有一些缺点，如扩展能力差，对EDW所在的RDBMS要求太高，随着数据量和分析的逐步增长，就不得不再把数据进行分离。如果在EDW的基础
上进行数据分离，为不同的应用单独建立数据集市或者挖掘仓库，集中式结构也就演变成Hub and Spoke架构方式。
4．集线器和车轮辐条架构（Hub and spoke architecture或Corporate information factory）
architecture），集线器和车轮辐条架构听起来比较别扭，叫起来也不响亮。而企业信息工厂应该是这种架构方式的最出色的代表。从名称我们也能
大概猜个差不多，中心数据仓库 EDW从各个源系统收集数据，将数据提供给各个数据集市和挖掘仓库，功能和集线器很相似，所以称为Hub。如果大家把图
画出来，可能会更形象一些，EDW 和各个源数据库及数据集市、挖掘仓库之间都连一条线，看起来就向一个车轮，这些连线就像车轮辐条，所以称为
Spoke。而这种采用中心数据仓库EDW集成数据，再分散到各个数据集市使用数据的方式就形象的称为Hub and spoke
architecture。
这种架构方式当然也有缺点，虽然是在集成的中心数据仓库EDW上建立数据集市，但是这些数据集市之间还是不能进行数据交换的，大家建立的方法和ETL程
序都会不同，各个数据集市之间的数据不见得的是一致的。而且这种架构方式开始变得复杂。
5．总线架构（Bus architecture）
总线架构和Hub and spoke architecture 的最大区别，应该是维度建模的原子层和一致性维度的建立。正因为预先建立的总线架构
和一致性维度，所以这种架构可以保证在逐步建立数据集市的过程中还能保证企业数据的一致性。总线架构是数据仓库架构方式从复杂走向简单的一步，将维度建
模的数据仓库原子层和数据集市合而为一，一层就把数据仓库建立好的，还能支持各种数据集市分析应用。
当然总线架构也有缺点，中心数据仓库以维度模型保存，对于特殊的非维度型分析应用会有局限性，支持的不好。
6．复合式架构（Composite architecture）
这种架构方式是综合考虑Huband spoke architecture和Bus architecture两种架构方式，或者说综合两种方式得出
的一种架构方式，CDW架构应该就是这种架构方式的代表。复合式架构的缺点也是很明显，架构过于复杂，（比CIF还要复杂），企业内数据量大的话，每一
次搬动都会非常麻烦。
所以基于CDW组件的复合式架构（Composite architecture）最大的问题在于企业内数据量大的话，每一次搬动都会非常麻烦.
innovate因为只碰到了几T数据,所以没有发现用CDW组件的复合式架构带来数据膨胀问题.
以上6个架构的英文名字都叫architecture,其实是项目建设的架构说法.而理论性2个架构的英文名字是"architectural
framework ",是可以总结出framework的理论性东西了.
我不知道这个说法,TTNN是否明白清晰了吗.欢迎继续交流DW的架构,架构的说法一定要清晰.
interstage
May 14, 2008, 3:04:57 AM5/14/08
to ttnn BI 观点
Ralph Kimball 和 Bill Inmon 一直是DW领域或者说BI领域中的革新者，提出了自己特色的新的技术和体系结构。
Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”；他通过“面向主题”表
示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要
容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。 Inmon 的
方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源
和工作。
Ralph Kimball 说“数据仓库仅仅是构成它的数据集市的联合”，他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。每个数据
集市将联合多个数据源来满足特定的业务需求。通过使用“一致的”维，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。
Kimball 的方法将提供集成的数据来回答组织迫切的业务问题并且要快于 Inmon 的方法。Inmon 的方法是只有在构建几个单主题区域之
后，集中式的数据仓库才创建数据集市。而 Kimball 认为该方法缺乏灵活性并且在现在的商业环境中所花时间太长。
这就是双方辩论核心思想,2大架构的不同点其实就是辩论先建数据仓库还是先建数据集市的问题?
在TTNN的这次架构质疑,尽管说是架构,其实也是这个内容的延伸. interstage为什么很想知道那个所谓混合架构究竟是如何展开的,就是希望
找到一条平息先建DM还是先建DW的争论的路.从innovate对混合架构的描述来看,是这个混合架构既可以先建DM(如果项目投资小)也可以先建
DW(如果项目投资大).仅仅是这样的回答,其实很不够. 而混合架构的核心CDW组件,也不是解决这个问题的关键点. 而innovate越来越激
动,无法继续展开,建议架构质疑到此为至.等innovate平静后继续.
而目前BIER比较认可设计方向的选择取决于项目的主要商业驱动。
1,如果该组织正忍受糟糕的数据管理和不一致的数据，或者希望为今后打下良好的基础，那么 Inmon 的方法就更好一些。
2,如果该组织迫切需要给用户提供信息，那么 Kimball 的方法将满足该需求。
3,而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。数据仓库将使数据集市与遗留系统和 OLTP 系统隔离，并
且支持更快地创建将来的数据集市。
由于数据仓库在整个发展中一直承担了重任，所以它将支持极力关注数据集市。实际上基于商业驱动的需要，采用上面三种设计方案中的最后一种方法：自顶向下
和自底向上综合的方案会很好的适应数据仓库建立过程中的不同需求。
Bill Inmon 将数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”；他通过“面向主题”表
示应该围绕主题来组织数据仓库中的数据，例如客户、销售、产品等等。每个主题区域仅仅包含该主题相关的信息。数据仓库应该一次增加一个主题，并且当需要
容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。 Inmon 的
方法包含了更多上述工作而减少了对于信息的初始访问。但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源
和工作。
Ralph Kimball 说“数据仓库仅仅是构成它的数据集市的联合”，他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。每个数据
集市将联合多个数据源来满足特定的业务需求。通过使用“一致的”维，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。
Kimball 的方法将提供集成的数据来回答组织迫切的业务问题并且要快于 Inmon 的方法。Inmon 的方法是只有在构建几个单主题区域之
后，集中式的数据仓库才创建数据集市。而 Kimball 认为该方法缺乏灵活性并且在现在的商业环境中所花时间太长。
这就是双方辩论核心思想,2大架构的不同点其实就是辩论先建数据仓库还是先建数据集市的问题?
在TTNN的这次架构质疑,尽管说是架构,其实也是这个内容的延伸. interstage为什么很想知道那个所谓混合架构究竟是如何展开的,就是希望
找到一条平息先建DM还是先建DW的争论的路.从innovate对混合架构的描述来看,是这个混合架构既可以先建DM(如果项目投资小)也可以先建
DW(如果项目投资大).仅仅是这样的回答,其实很不够. 而混合架构的核心CDW组件,也不是解决这个问题的关键点. 而innovate越来越激
动,无法继续展开,建议架构质疑到此为至.等innovate平静后继续.
而目前BIER比较认可设计方向的选择取决于项目的主要商业驱动。
1,如果该组织正忍受糟糕的数据管理和不一致的数据，或者希望为今后打下良好的基础，那么 Inmon 的方法就更好一些。
2,如果该组织迫切需要给用户提供信息，那么 Kimball 的方法将满足该需求。
3,而一旦满足了迫切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。数据仓库将使数据集市与遗留系统和 OLTP 系统隔离，并
且支持更快地创建将来的数据集市。
由于数据仓库在整个发展中一直承担了重任，所以它将支持极力关注数据集市。实际上基于商业驱动的需要，采用上面三种设计方案中的最后一种方法：自顶向下
和自底向上综合的方案会很好的适应数据仓库建立过程中的不同需求。
wu
May 14, 2008, 5:03:01 AM5/14/08
to ttnn BI 观点
个人觉得,我们不应拘泥于是架构还是不是架构.而应把概念谈得更具体详细一点.
Goldenfish3
May 14, 2008, 7:22:11 AM5/14/08
to tt...@googlegroups.com
架构就那么几种模式，不如结合具体问题谈。
背景：某港口企业，应用系统众多，系统结构条状分布，导致信息共享程度低。准备对现有的生产调度系统、货运管理信息系统、集装箱管理系统、集装箱客户服务系统、集装箱生产数据统计系统、出口集装箱水陆联运调度系统、铁矿石管理系统、煤炭焦炭管理系统、货源管理系统、收费管理系统、综合物流信息服务系统、人力资源管理信息系统、干部稽查系统、安监管理信息系统、危品申报系统、能源管理信息系统、引航站管理信息系统、办公自动化系统、机关办公耗材管理系统等进行资源整合，建立统一的信息资源平台，对数据进行统一管理，提高信息共享程度，并实现管理决策支持。
问：该如何设计该企业的信息资源平台解决方案？
发件人： wu
发送时间： 2008-05-14 17:03:12
收件人： ttnn BI 观点
抄送：
主题： Re: 体验混合架构的来源
背景：某港口企业，应用系统众多，系统结构条状分布，导致信息共享程度低。准备对现有的生产调度系统、货运管理信息系统、集装箱管理系统、集装箱客户服务系统、集装箱生产数据统计系统、出口集装箱水陆联运调度系统、铁矿石管理系统、煤炭焦炭管理系统、货源管理系统、收费管理系统、综合物流信息服务系统、人力资源管理信息系统、干部稽查系统、安监管理信息系统、危品申报系统、能源管理信息系统、引航站管理信息系统、办公自动化系统、机关办公耗材管理系统等进行资源整合，建立统一的信息资源平台，对数据进行统一管理，提高信息共享程度，并实现管理决策支持。
问：该如何设计该企业的信息资源平台解决方案？
发件人： wu
发送时间： 2008-05-14 17:03:12
收件人： ttnn BI 观点
抄送：
主题： Re: 体验混合架构的来源
tosimple
May 14, 2008, 8:03:17 AM5/14/08
to ttnn BI 观点
你这个也太粗了吧。 你至少得把每个系统有些什么信息大致讲下吧。
如果不知道你有什么东西，那么，也得讲讲你想要什么东西？
如果两样都没有，呵呵。。
如果不知道你有什么东西，那么，也得讲讲你想要什么东西？
如果两样都没有，呵呵。。
Goldenfish3
May 14, 2008, 7:23:52 PM5/14/08
to tt...@googlegroups.com
这个case的存在至少说明
1.架构设计要有对行业业务价值链的基本理解。客户的需求描述就是这么简单，真实的情况就是需要根据这么有限的信息去提供解决方案。
2.客户不会站在设计师的角度提需求，他们只站在他们的立场。他们与架构师可能并没有共通的术语，甚至将某些业务系统的建设和作为数据整合的CDW，EDW，ODS之类混杂在一起。
与其空谈Kingball模式还是Inmon模式，不如结合具体问题分析。这些信息不够的话，还要哪些信息才够－由此可以找出，架构的决策究竟取决于哪些因素？
2008-05-15
Goldenfish3
发件人： tosimple
发送时间： 2008-05-14 20:03:38
interstage
May 16, 2008, 12:05:04 AM5/16/08
to ttnn BI 观点
对,这就是客户对CASE的要求.所以你的1,2两点做法,基本上的实施思路为:
1,以行业咨询角度入手,告诉客户针对该行业应该如何考虑决策分析,再描述清楚该行业决策分析的几个方向后，再描述如何根据在要建的平台(主要是分析报
表和图的展现方式和人机交互的界面)进行决策分析,接着再平台IT设计架构和实施思路.
2,客户只站在他们的立场的话,也有一种方式,就是不引入行业咨询方向,直接去理解客户对自己企业的决策分析的立场,然后再按照1方式实施
这种情况是目前DWBI项目最常见的模式(客户不关心架构模式,但在最后交流中需要你提供几种架构的选择,让客户选),可能占90%以上.
目前谈的架构之争,不是谈实施项目的方式方法,谈的是DW架构理论性的东西(这也是牛人一直在说的创新的"第3种架构"),但真理是越辩越清晰,已经通
过各种交流方式,还原了所谓创新"第3种架构"的本质,所以近阶段不需要再谈这个架构了.
至于这个CASE需要DWBI项目实施经验交流,可以另开主题谈. 我感觉TTNN的交流都是浅尝辄止,没有细节展开的勇气,怕说话得罪人,你在论坛上
都怕这个,那你在现实BI项目交流,能说清楚观点,让客户解释吗. 我曾经做一个BI项目,和客户就DW实现细节争论到拍桌子,最后还是签了合同.在做
DWBI项目的时候,我们BIER一定要有这样的信念,我们一起来这个系统是来帮你客户解决问题的,不是来求人给口饭吃的,把这个信念传导到你们的销售
和你们的领导,让他们也以这个思维去销售.
On 5月15日, 上午7时23分, "Goldenfish3" <goldenfi...@163.com> wrote:
> 这个case的存在至少说明
>
> 1.架构设计要有对行业业务价值链的基本理解。客户的需求描述就是这么简单，真实的情况就是需要根据这么有限的信息去提供解决方案。
>
> 2.客户不会站在设计师的角度提需求，他们只站在他们的立场。他们与架构师可能并没有共通的术语，甚至将某些业务系统的建设和作为数据整合的CDW，EDW，O-DS之类混杂在一起。
> > > 和自底向上综合的方案会很好的适应数据仓库建立过程中的不同需求。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
1,以行业咨询角度入手,告诉客户针对该行业应该如何考虑决策分析,再描述清楚该行业决策分析的几个方向后，再描述如何根据在要建的平台(主要是分析报
表和图的展现方式和人机交互的界面)进行决策分析,接着再平台IT设计架构和实施思路.
2,客户只站在他们的立场的话,也有一种方式,就是不引入行业咨询方向,直接去理解客户对自己企业的决策分析的立场,然后再按照1方式实施
这种情况是目前DWBI项目最常见的模式(客户不关心架构模式,但在最后交流中需要你提供几种架构的选择,让客户选),可能占90%以上.
目前谈的架构之争,不是谈实施项目的方式方法,谈的是DW架构理论性的东西(这也是牛人一直在说的创新的"第3种架构"),但真理是越辩越清晰,已经通
过各种交流方式,还原了所谓创新"第3种架构"的本质,所以近阶段不需要再谈这个架构了.
至于这个CASE需要DWBI项目实施经验交流,可以另开主题谈. 我感觉TTNN的交流都是浅尝辄止,没有细节展开的勇气,怕说话得罪人,你在论坛上
都怕这个,那你在现实BI项目交流,能说清楚观点,让客户解释吗. 我曾经做一个BI项目,和客户就DW实现细节争论到拍桌子,最后还是签了合同.在做
DWBI项目的时候,我们BIER一定要有这样的信念,我们一起来这个系统是来帮你客户解决问题的,不是来求人给口饭吃的,把这个信念传导到你们的销售
和你们的领导,让他们也以这个思维去销售.
On 5月15日, 上午7时23分, "Goldenfish3" <goldenfi...@163.com> wrote:
> 这个case的存在至少说明
>
> 1.架构设计要有对行业业务价值链的基本理解。客户的需求描述就是这么简单，真实的情况就是需要根据这么有限的信息去提供解决方案。
>
>
> 与其空谈Kingball模式还是Inmon模式，不如结合具体问题分析。这些信息不够的话，还要哪些信息才够－由此可以找出，架构的决策究竟取决于哪些因素？
>
> 2008-05-15
>
> Goldenfish3
> 与其空谈Kingball模式还是Inmon模式，不如结合具体问题分析。这些信息不够的话，还要哪些信息才够－由此可以找出，架构的决策究竟取决于哪些因素？
>
> 2008-05-15
>
>
> 发件人： tosimple
> 发送时间： 2008-05-14 20:03:38
> 收件人： ttnn BI 观点
> 抄送：
> 主题： Re: 体验混合架构的来源
> 你这个也太粗了吧。 你至少得把每个系统有些什么信息大致讲下吧。
>
> 如果不知道你有什么东西，那么，也得讲讲你想要什么东西？
>
> 如果两样都没有，呵呵。。
>
> On 5月14日, 下午7时22分, "Goldenfish3" <goldenfi...@163.com > wrote:
>
>
>
> > 架构就那么几种模式，不如结合具体问题谈。
>
> > 背景：某港口企业，应用系统众多，系统结构条状分布，导致信息共享程度低。准备对现有的生产调度系统、货运管理信息系统、集装箱管理系统、集装箱客户服务系统、-集装箱生产数据统计系统、出口集装箱水陆联运调度系统、铁矿石管理系统、煤炭焦炭管理系统、货源管理系统、收费管理系统、综合物流信息服务系统、人力资源管理信-息系统、干部稽查系统、安监管理信息系统、危品申报系统、能源管理信息系统、引航站管理信息系统、办公自动化系统、机关办公耗材管理系统等进行资源整合，建立统-一的信息资源平台，对数据进行统一管理，提高信息共享程度，并实现管理决策支持。
> 发件人： tosimple
> 发送时间： 2008-05-14 20:03:38
> 收件人： ttnn BI 观点
> 抄送：
> 主题： Re: 体验混合架构的来源
> 你这个也太粗了吧。 你至少得把每个系统有些什么信息大致讲下吧。
>
> 如果不知道你有什么东西，那么，也得讲讲你想要什么东西？
>
> 如果两样都没有，呵呵。。
>
> On 5月14日, 下午7时22分, "Goldenfish3" <goldenfi...@163.com > wrote:
>
>
>
> > 架构就那么几种模式，不如结合具体问题谈。
>
>
> - 显示引用的文字 -
Reply all
Reply to author
Forward
0 new messages