从生命周期的角度来考虑架构问题
5 views
Skip to first unread message
innovate511
May 8, 2008, 12:14:06 PM5/8/08
to ttnn BI 观点
业界建设DW有20多年了，国内从开始商业尝试也有10来年了，多种实施方案讨论不绝，但是很少有从生命周期的角度来讨论的，要知道生命周期决定了一方
法论的使用周期和范围、投资回报比、适用行业和客户情况等等，这也是为什么当初多家争鸣（主要是两家）没有个结论的主要原因。
从技术上来说（不考虑客户需求和投资的纯技术角度的话），近3NF的EDW最稳固，其次是Kimball的统一维度模型存储的DW，再次是大家公认的
DM。
那么从生命周期来看呢？我们来看一个业界典型的混合架构的成功案例。该项目目前整体生命周期为9年，几乎每2-3年DM需要重组一次，以满足企业BI效
率、分析个性化等变化需求。统一维度数据仓库使用7年后渐显疲惫，于是在第8年开始开展大规模的维度模型的数据仓库架构重组，原因很简单，虽然这个理论
到目前来说是能满足企业信息一致、维度模型管理、维护的最佳设计方案，但由于维度模型的缺陷在于信息抽象后，随着数年的经历，变化太多，业务繁复，管理
越来越难。不过至今唯一没变的是EDW。
从生命周期来看，维度模型数据仓库结合数据集市容易建设，但生命周期相对教短，在考虑数据集市生命周期一般2年左右的情况下，维度模型数据仓库必须2年
内建设成熟，最好1年内建设成熟，成为成熟架构体系，否则你还未开始企业级多维架构的时候，数据集市已经又需要重建了，那时工作量可大了。
那么EDW呢？如果维度数据仓库建模水平不高，那还是尽快建设吧，刚才我举的例是顶级项目了，一般项目维度模型数据仓库达到5年都难，所以我建议维度数
据仓库使用2年后就有必要开始着手建设EDW，哪怕你觉得EDW用处不是很大，要知道当一个庞大的企业级多维仓库直接在业务系统或者ODS之上进行重
组，不仅仅耗费巨大，而且不容易成功。
有朋友说多维数据仓库不行了本来就要重建，有没有EDW有什么关系呢？首先有的行业本身就需要细节数据，EDW是一个很好的存储细节数据的平台，而且是
企业级集成的平台。其次，在有个架构支撑的情况下重建，和没有架构支持重建，那是完全两回事。比如刚才我说的DM重组，在有维度数据仓库在架构上对DM
的支持下，庞大的DM重组只用了少量的人力，3、4个月的时间就完成，如果没有前面统一维度数据仓库架构来支撑DM重组，后果不堪设想。
这里架构的作用，就是我上次提到的接口作用，你更上层应用的架构重组，但我底层架构的接口并没变，大大方便了应用层架构的重组的实现。
法论的使用周期和范围、投资回报比、适用行业和客户情况等等，这也是为什么当初多家争鸣（主要是两家）没有个结论的主要原因。
从技术上来说（不考虑客户需求和投资的纯技术角度的话），近3NF的EDW最稳固，其次是Kimball的统一维度模型存储的DW，再次是大家公认的
DM。
那么从生命周期来看呢？我们来看一个业界典型的混合架构的成功案例。该项目目前整体生命周期为9年，几乎每2-3年DM需要重组一次，以满足企业BI效
率、分析个性化等变化需求。统一维度数据仓库使用7年后渐显疲惫，于是在第8年开始开展大规模的维度模型的数据仓库架构重组，原因很简单，虽然这个理论
到目前来说是能满足企业信息一致、维度模型管理、维护的最佳设计方案，但由于维度模型的缺陷在于信息抽象后，随着数年的经历，变化太多，业务繁复，管理
越来越难。不过至今唯一没变的是EDW。
从生命周期来看，维度模型数据仓库结合数据集市容易建设，但生命周期相对教短，在考虑数据集市生命周期一般2年左右的情况下，维度模型数据仓库必须2年
内建设成熟，最好1年内建设成熟，成为成熟架构体系，否则你还未开始企业级多维架构的时候，数据集市已经又需要重建了，那时工作量可大了。
那么EDW呢？如果维度数据仓库建模水平不高，那还是尽快建设吧，刚才我举的例是顶级项目了，一般项目维度模型数据仓库达到5年都难，所以我建议维度数
据仓库使用2年后就有必要开始着手建设EDW，哪怕你觉得EDW用处不是很大，要知道当一个庞大的企业级多维仓库直接在业务系统或者ODS之上进行重
组，不仅仅耗费巨大，而且不容易成功。
有朋友说多维数据仓库不行了本来就要重建，有没有EDW有什么关系呢？首先有的行业本身就需要细节数据，EDW是一个很好的存储细节数据的平台，而且是
企业级集成的平台。其次，在有个架构支撑的情况下重建，和没有架构支持重建，那是完全两回事。比如刚才我说的DM重组，在有维度数据仓库在架构上对DM
的支持下，庞大的DM重组只用了少量的人力，3、4个月的时间就完成，如果没有前面统一维度数据仓库架构来支撑DM重组，后果不堪设想。
这里架构的作用，就是我上次提到的接口作用，你更上层应用的架构重组，但我底层架构的接口并没变，大大方便了应用层架构的重组的实现。
interstage
May 8, 2008, 10:36:22 PM5/8/08
to ttnn BI 观点
OK,对于你这个主题,直到"有朋友说多维数据仓库不行了本来就要重建，有没有EDW有什么关系呢？首先有的行业本身就需要细节数据，EDW是一个很好
的存储细节数据的平台，而且是企业级集成的平台。"到这句话,我完全认可. 关键是这句话以后"其次，在有个架构支撑的情况下重建，和没有架构支持重
建,那是完全两回事". 如果从企业层面对DM建设到EDW建设有未来3-5年目标,并同时有一整套的管理机制和实现方式,让业务部门,IT部门,运营
部门,财务部门基于这个统一的工作方式,实现了你所谓的从DM建设到EDW建设的过程.那么我刚才说的方式是不是你所谓的架构.反过来如果架构只是IT
部门提出来,其他部门没这个精神,那么你的数据来源格式是基本不变和时刻调整,只是数据量的增加而已,那你永远就形成不了闭坏BI,这样的技术架构可能
真的能实现DM建设到EDW建设的过程,但对企业有什么价值,基本没有.所以还是回到原点,需要你解释以下3个问题:
1,对你所说的架构需要明确定义,只是技术层面的,还是有实施方法层面,从来延伸到管理层面,你这个架构只是IT部门在用,还是其他部门在用(哪怕用这
个架构的精神,如果用它的精神,如何用体制保证)
2,你的架构起点在哪里,不管是自上而下,还是自下而上,还是我现在在"持续改善"中主张的"中间驱动",这个起点需要明确.
3,你所说架构本身也具有生命周期,你不能因为DM和EDW存在生命周期,而提出一个自己本身无生命周期的架构,所以这个也需要明确.
OK,你别以为我盯着你的"架构"不放,是对你个人有意见或者看不起你的DW经验,其实不是,因为我现在走的BI之路,是从业务管理思路变革来影响技术
层次的创新(但我目前只能做到技术实施方法论的创新,我认为我是达不到架构创新的),我很想了解你走的BI路,是不是真的能以技术层次创新来影响业务管
理思路的创新.而这条道路在中国是否真的能走通? 这是我一直在追求的答案.
请尽快回答我的3点问题,谢谢!!
的存储细节数据的平台，而且是企业级集成的平台。"到这句话,我完全认可. 关键是这句话以后"其次，在有个架构支撑的情况下重建，和没有架构支持重
建,那是完全两回事". 如果从企业层面对DM建设到EDW建设有未来3-5年目标,并同时有一整套的管理机制和实现方式,让业务部门,IT部门,运营
部门,财务部门基于这个统一的工作方式,实现了你所谓的从DM建设到EDW建设的过程.那么我刚才说的方式是不是你所谓的架构.反过来如果架构只是IT
部门提出来,其他部门没这个精神,那么你的数据来源格式是基本不变和时刻调整,只是数据量的增加而已,那你永远就形成不了闭坏BI,这样的技术架构可能
真的能实现DM建设到EDW建设的过程,但对企业有什么价值,基本没有.所以还是回到原点,需要你解释以下3个问题:
1,对你所说的架构需要明确定义,只是技术层面的,还是有实施方法层面,从来延伸到管理层面,你这个架构只是IT部门在用,还是其他部门在用(哪怕用这
个架构的精神,如果用它的精神,如何用体制保证)
2,你的架构起点在哪里,不管是自上而下,还是自下而上,还是我现在在"持续改善"中主张的"中间驱动",这个起点需要明确.
3,你所说架构本身也具有生命周期,你不能因为DM和EDW存在生命周期,而提出一个自己本身无生命周期的架构,所以这个也需要明确.
OK,你别以为我盯着你的"架构"不放,是对你个人有意见或者看不起你的DW经验,其实不是,因为我现在走的BI之路,是从业务管理思路变革来影响技术
层次的创新(但我目前只能做到技术实施方法论的创新,我认为我是达不到架构创新的),我很想了解你走的BI路,是不是真的能以技术层次创新来影响业务管
理思路的创新.而这条道路在中国是否真的能走通? 这是我一直在追求的答案.
请尽快回答我的3点问题,谢谢!!
interstage
May 8, 2008, 10:43:50 PM5/8/08
to ttnn BI 观点
还有这句话"从技术上来说（不考虑客户需求和投资的纯技术角度的话），近3NF的EDW最稳固，其次是Kimball的统一维度模型存储的DW，再次是
大家公认的
DM" 我现在有异议,但我已经开始疏远技术细节.所以有点模糊,需要各位BIer明确一下,当然innovate,你能解释是最好的
3NF我印象中是设计RDB的一个关键因素,而Inmon提出DW的时候,最关键的一句话就是"反RDB设计的3NF,尽量实现冗余",这也是85年
DW出现并区别于RDB的关键一点,是否在DW2.0以后Inmon修正了他的观点,把这点放弃了? 不然EDW和RDB的区别解释不清晰了.
请各位BIer在技术上明确一下,谢谢!!
大家公认的
DM" 我现在有异议,但我已经开始疏远技术细节.所以有点模糊,需要各位BIer明确一下,当然innovate,你能解释是最好的
3NF我印象中是设计RDB的一个关键因素,而Inmon提出DW的时候,最关键的一句话就是"反RDB设计的3NF,尽量实现冗余",这也是85年
DW出现并区别于RDB的关键一点,是否在DW2.0以后Inmon修正了他的观点,把这点放弃了? 不然EDW和RDB的区别解释不清晰了.
请各位BIer在技术上明确一下,谢谢!!
innovate511
May 8, 2008, 10:54:19 PM5/8/08
to ttnn BI 观点
这里说的是从宏观数据仓库架构上谈生命周期，我想下次聊下不同实际项目在不同建模架构、ETL架构所导致的不同生命周期的原因，以及提高各层结构生命周
期的重点。
比如同样的EDW，不同项目的理解是不同的，同样的多维数据仓库，实施思路，达到的目的也可能有很大不同，数据集市也是，他们虽然分别可以比较独立，但
不同结构之间的模型、存储数据之间的关系都可以有千变万化，这会最终导致他们的生命周期的长短。
大师们的书籍中总是完整的项目架构体系，所以对于投资、人力有限制的情况从起步开始建，或者接手人家的现有架构去再建项目，难有根据实际情况的整体性指
导，但我们可以从他们的细节描述中得到一些启发，实现我们想要的东西，细节的才是真正有效的，就像一个个分子。
更好的方法论是前人用实践和教训总结出来的，他们都有自己的大量客户群体和成功案例，也有其必然的技术原因。我想，从更多项目经验抽象总结出来后，无论
你的整体架构怎么搭建，你在细节上的思考会严密得多，生命周期长了，不仅仅是对客户带来附加值，更是对BIDW整体的推动，需要业界集体的力量。当然交
流肯定都是比较抽象的，太细节的东西毕竟是核心竞争力，只要能理解其意会即可。
我想业界广泛使用的混合架构，并非一次性到位的理想架构，而是我多次提到的虚拟架构，然后一步一步去做实，最后成为一个整体。它的落实也不是额守成规
的，只是剪切了优秀成功架构的一些精髓，你可以DIY成为自己最合适的架构，你可以把EDW虚拟化，该不该落实，什么时候去落实，你可以看企业客户的
IT战略、IT投入战略、分析需求决定，当实在需要的时候，你可以建议客户，现在该落实了，否则XXXX。
像统一维度建模，这个做得好，生命周期可以很多年，10来年都可能，但你刚开始也可以虚拟化，先完成BI应用再说，在合适的时候，马上去落实，然后将原
先比较随意的多维仓库移植到新的架构，移植其实不难，找好接口就行，也不影响BI应用。当然客户比较牛，能一次性投入大量资金采购设备、软件和雇佣
2、3十人的团队建设，那当然可以一开始就建设各个组件。只是这样做的风险比较大，特别是集成商如果EDW建设和统一维度仓库建设都没足够经验的话，客
户很可能需要重复花钱，所谓桥墩都不稳，桥怎么能稳呢？
期的重点。
比如同样的EDW，不同项目的理解是不同的，同样的多维数据仓库，实施思路，达到的目的也可能有很大不同，数据集市也是，他们虽然分别可以比较独立，但
不同结构之间的模型、存储数据之间的关系都可以有千变万化，这会最终导致他们的生命周期的长短。
大师们的书籍中总是完整的项目架构体系，所以对于投资、人力有限制的情况从起步开始建，或者接手人家的现有架构去再建项目，难有根据实际情况的整体性指
导，但我们可以从他们的细节描述中得到一些启发，实现我们想要的东西，细节的才是真正有效的，就像一个个分子。
更好的方法论是前人用实践和教训总结出来的，他们都有自己的大量客户群体和成功案例，也有其必然的技术原因。我想，从更多项目经验抽象总结出来后，无论
你的整体架构怎么搭建，你在细节上的思考会严密得多，生命周期长了，不仅仅是对客户带来附加值，更是对BIDW整体的推动，需要业界集体的力量。当然交
流肯定都是比较抽象的，太细节的东西毕竟是核心竞争力，只要能理解其意会即可。
我想业界广泛使用的混合架构，并非一次性到位的理想架构，而是我多次提到的虚拟架构，然后一步一步去做实，最后成为一个整体。它的落实也不是额守成规
的，只是剪切了优秀成功架构的一些精髓，你可以DIY成为自己最合适的架构，你可以把EDW虚拟化，该不该落实，什么时候去落实，你可以看企业客户的
IT战略、IT投入战略、分析需求决定，当实在需要的时候，你可以建议客户，现在该落实了，否则XXXX。
像统一维度建模，这个做得好，生命周期可以很多年，10来年都可能，但你刚开始也可以虚拟化，先完成BI应用再说，在合适的时候，马上去落实，然后将原
先比较随意的多维仓库移植到新的架构，移植其实不难，找好接口就行，也不影响BI应用。当然客户比较牛，能一次性投入大量资金采购设备、软件和雇佣
2、3十人的团队建设，那当然可以一开始就建设各个组件。只是这样做的风险比较大，特别是集成商如果EDW建设和统一维度仓库建设都没足够经验的话，客
户很可能需要重复花钱，所谓桥墩都不稳，桥怎么能稳呢？
interstage
May 8, 2008, 11:13:34 PM5/8/08
to ttnn BI 观点
你这个描述,实在太虚,都是非常空洞的话,而你提出的"业界广泛使用的混合架构",这个所谓"业界广泛使用的混合架构",目前我通过google和
baidu查国内还是国外的资料,都好象不是你所说的那个东西,再次请给出"混合架构"权威描述版本(英文也行)
还有,我上面的几个问题,是否针对性回答一下,你这个描述,我个人感觉没回答,或者我水平不够,看不出你描述中已经针对回答了,谢谢!!
innovate511
May 8, 2008, 11:33:18 PM5/8/08
to ttnn BI 观点
从各种资料来看，Inmon倡导的EDW都是近3范式的，这个细节我想就没必要多讨论了，四处google一下，都这么描述的。至于冗余，那肯定会有一
些，毕竟是近3NF，又不是完全按照3NF建模。
我们的整体架构只解决企业IT/BI战略问题，和具体部门需求没关系，解决各部门需求的只是各组件内的模型去解决。如果老是拿着部门甚至企业级的需求来
谈建数据仓库，永远也别想建设出想象的架构来。
现在BI数据仓库系统中对企业各部门的分析、分析变化的支持不够，很大原因是层次结构内部的模型架构设计不当造成，和我这里说的整体架构没半点关系。就
像有的讨论谈到的，EDW应该是近3NF的按照行业标准建设的模型（比如可以考虑采购行业模型），多维数据仓库应该有统一维度建设技术的多维存储，它是
面向企业级，统一管理和存储维和事实表，DM应该是面向部门、数据层级多样、信息抽象多样、安全管理灵活的模型存储。当你大方向思路清晰后，再考虑该一
起建设还是分阶段、时段建设，然后如何让它适应更多需求，因为部门的需求是不固定的、可变的、多样性的，那么多维数据仓库肯定不能只有维、事实表能支撑
这些需求，而它和DM的存储信息的管理应该分工明确。
上次我已经提到过现在已有的BI闭环数据流，主要体现在ODS层针对业务系统的闭环，以及基于多维的计划、预测系统的闭环。什么闭环流程，不是钉死的，
是根据实际情况去应用。
现在老生常谈避开谈架构的XDJM，好好看看已经运行的项目，是否能撑过3年？如果你老是盯着BI应用，那可以不谈架构，因为无论我架构怎么变，还是升
级，BI应用不应停止。上一个帖子我已经提到过，全部重新建设，和基于底层架构重新建设的效率、可靠性、投资成本，都不在一个层次。
就像我们国家的建筑，很多生命周期只有3、5十年，甚至更短，国外的很多城市建筑是上百年甚至更远。OK，你可以建设短周期的建筑，多少年后你可以重新
建，但是从能源的角度，从开支、建设的角度，这是不可同日而语的。无休止地重复建设，只盯着最终应用，是发展初级考虑的问题，而长远考虑，还是得考虑架
构、降低风险和成本。
至于采用至顶向下，还是至底向上方案，我觉得非要下一个结论，有点过于迂腐。就像一个哥们说的，我们做技术的是追求真理，不是搞崇拜，如果非要说谁的
好，除非它的理论能完美到彻底压倒其他观点，但既然各有千秋，各有成功案例，为啥你非要做出一个决断，不去自己判断呢？“至顶向下，还是至底向上”只是
一个概念和思路，不是我们追求的技术真理，我们追求的应该是其本质的东西，那就是架构本身只是方便管理、维护我们的数据和系统，并非万能不变的具体技
术。
些，毕竟是近3NF，又不是完全按照3NF建模。
我们的整体架构只解决企业IT/BI战略问题，和具体部门需求没关系，解决各部门需求的只是各组件内的模型去解决。如果老是拿着部门甚至企业级的需求来
谈建数据仓库，永远也别想建设出想象的架构来。
现在BI数据仓库系统中对企业各部门的分析、分析变化的支持不够，很大原因是层次结构内部的模型架构设计不当造成，和我这里说的整体架构没半点关系。就
像有的讨论谈到的，EDW应该是近3NF的按照行业标准建设的模型（比如可以考虑采购行业模型），多维数据仓库应该有统一维度建设技术的多维存储，它是
面向企业级，统一管理和存储维和事实表，DM应该是面向部门、数据层级多样、信息抽象多样、安全管理灵活的模型存储。当你大方向思路清晰后，再考虑该一
起建设还是分阶段、时段建设，然后如何让它适应更多需求，因为部门的需求是不固定的、可变的、多样性的，那么多维数据仓库肯定不能只有维、事实表能支撑
这些需求，而它和DM的存储信息的管理应该分工明确。
上次我已经提到过现在已有的BI闭环数据流，主要体现在ODS层针对业务系统的闭环，以及基于多维的计划、预测系统的闭环。什么闭环流程，不是钉死的，
是根据实际情况去应用。
现在老生常谈避开谈架构的XDJM，好好看看已经运行的项目，是否能撑过3年？如果你老是盯着BI应用，那可以不谈架构，因为无论我架构怎么变，还是升
级，BI应用不应停止。上一个帖子我已经提到过，全部重新建设，和基于底层架构重新建设的效率、可靠性、投资成本，都不在一个层次。
就像我们国家的建筑，很多生命周期只有3、5十年，甚至更短，国外的很多城市建筑是上百年甚至更远。OK，你可以建设短周期的建筑，多少年后你可以重新
建，但是从能源的角度，从开支、建设的角度，这是不可同日而语的。无休止地重复建设，只盯着最终应用，是发展初级考虑的问题，而长远考虑，还是得考虑架
构、降低风险和成本。
至于采用至顶向下，还是至底向上方案，我觉得非要下一个结论，有点过于迂腐。就像一个哥们说的，我们做技术的是追求真理，不是搞崇拜，如果非要说谁的
好，除非它的理论能完美到彻底压倒其他观点，但既然各有千秋，各有成功案例，为啥你非要做出一个决断，不去自己判断呢？“至顶向下，还是至底向上”只是
一个概念和思路，不是我们追求的技术真理，我们追求的应该是其本质的东西，那就是架构本身只是方便管理、维护我们的数据和系统，并非万能不变的具体技
术。
innovate511
May 9, 2008, 12:04:14 AM5/9/08
to ttnn BI 观点
至于网上参考，只有一些具体做实际项目的人写了类似的文章，至于权威否，至少没有两个大师权威。不知道ttnn是否有人做过国际500强总部的项目没
有，如果有的话，我玩过其中两个这种项目，当然只是参与，不过对我后面的独立设计项目有很大的启发和帮助。应该知道他们的架构无论最先采用至顶向下，还
是至底向上，最终发展到现在，基本都是混合式架构，这就是他们走过来的历程。但两个大师没提混合架构，所以也谈不上有权威的文章。
我很久没上英文网站了，这里随便找了点链接。
http://www.dmreview.com/issues/20050301/1021501-1.html
http://www.dmreview.com/news/1057601-1.html
这些文章很多，谈不上权威，但都是在客观分析和比较两者的利弊，而实际项目升级的时候，他们很多都在采用各自架构的优点。
有，如果有的话，我玩过其中两个这种项目，当然只是参与，不过对我后面的独立设计项目有很大的启发和帮助。应该知道他们的架构无论最先采用至顶向下，还
是至底向上，最终发展到现在，基本都是混合式架构，这就是他们走过来的历程。但两个大师没提混合架构，所以也谈不上有权威的文章。
我很久没上英文网站了，这里随便找了点链接。
http://www.dmreview.com/issues/20050301/1021501-1.html
http://www.dmreview.com/news/1057601-1.html
这些文章很多，谈不上权威，但都是在客观分析和比较两者的利弊，而实际项目升级的时候，他们很多都在采用各自架构的优点。
interstage
May 9, 2008, 12:17:26 AM5/9/08
to ttnn BI 观点
关于中国建筑行业,你根本不了解,请不要再举例了(你好象以前举过例),中国的建筑为什么周期短,不是结构设计的问题,负责建筑签字的结构师都是终身负
责制,建筑出结构性设计问题导致倒了出人命了,不管他那时候是30岁还是100岁,只要活着,他就进监狱.中国建筑的周期短,是由于当官在任期间为了政
绩或者私利,就搞建了又拆, 拆了又建的事情,根本原因是监督机制没建立,人大没有责问,自从三峡工程建设人大表决艰难通过过后,你看看以后什么大工程
有进入人大表决了,都是政府想建就建,想拆就拆.这个话题不展开了,和你的架构没任何关系.
OK,我们现在开始展开你的话题,我查了http://inmoncif.com网站,对EDW的概念,enterprise data
warehouse - a data warehouse holding the most atomic data the
corporation has. Two or more enterprise data warehouses may be
combined in order to create a distributed data warehouse
所以,EDW只是海量原子级数据的集合而已,并没有说必须以3NF或者反3NF存储. 如果是这样,那只能描述你所说的混合体系(我目前没法感觉出它是
架构,只能称为体系或者模型)中的EDW是3NF的,而且昨天你也承认这个混合体系不是你自创的(经过几个月交流,昨天我才知道这个体系不是你自创的,
以前给我感觉就是你自创的,不知道TTNN的其他Bier是不是也是这样感觉),那么就是你比我们早接触了国外这个混合体系,并实施后觉得不错,想把它
推广,所以TTNN的Bier非常感谢你的这个想法和行动,表示感谢.那请你继续从我刚才的3个问题描述一下你学习并实践的这个混合体系,如果这3个问
题你能针对性一一解释,说明你对这个混合体系理解很不错,我需要向你继续请教这个混合体系的实施方式.如果,你回答不了这3个问题,也没关系,人不可能
都领悟到这个体系的精华,所以希望你给出这个混合体系的详细文档(英文也行),让我直接从文档中学习,我可以把学习心得和你继续交流,让你也成为更对这
个混合体系进行深化.
第3次请求请你针对性我的3个问题来解释你的混合体系,谢谢!!
责制,建筑出结构性设计问题导致倒了出人命了,不管他那时候是30岁还是100岁,只要活着,他就进监狱.中国建筑的周期短,是由于当官在任期间为了政
绩或者私利,就搞建了又拆, 拆了又建的事情,根本原因是监督机制没建立,人大没有责问,自从三峡工程建设人大表决艰难通过过后,你看看以后什么大工程
有进入人大表决了,都是政府想建就建,想拆就拆.这个话题不展开了,和你的架构没任何关系.
OK,我们现在开始展开你的话题,我查了http://inmoncif.com网站,对EDW的概念,enterprise data
warehouse - a data warehouse holding the most atomic data the
corporation has. Two or more enterprise data warehouses may be
combined in order to create a distributed data warehouse
所以,EDW只是海量原子级数据的集合而已,并没有说必须以3NF或者反3NF存储. 如果是这样,那只能描述你所说的混合体系(我目前没法感觉出它是
架构,只能称为体系或者模型)中的EDW是3NF的,而且昨天你也承认这个混合体系不是你自创的(经过几个月交流,昨天我才知道这个体系不是你自创的,
以前给我感觉就是你自创的,不知道TTNN的其他Bier是不是也是这样感觉),那么就是你比我们早接触了国外这个混合体系,并实施后觉得不错,想把它
推广,所以TTNN的Bier非常感谢你的这个想法和行动,表示感谢.那请你继续从我刚才的3个问题描述一下你学习并实践的这个混合体系,如果这3个问
题你能针对性一一解释,说明你对这个混合体系理解很不错,我需要向你继续请教这个混合体系的实施方式.如果,你回答不了这3个问题,也没关系,人不可能
都领悟到这个体系的精华,所以希望你给出这个混合体系的详细文档(英文也行),让我直接从文档中学习,我可以把学习心得和你继续交流,让你也成为更对这
个混合体系进行深化.
第3次请求请你针对性我的3个问题来解释你的混合体系,谢谢!!
Goldenfish3
May 9, 2008, 1:11:24 AM5/9/08
to tt...@googlegroups.com
1.参考架构是实践经验总结出来的东西，更多的人是“知其然，不知其所以然”。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实际情况灵活调整。
2.架构是具有成长性的，要动态调整的，但最终会往一个方向发展，你要控制它一开始就往这个方向发展，还是等它自然演变，中间可能有重构？这就要权衡。
2008-05-09
Goldenfish3
发件人： interstage
发送时间： 2008-05-09 10:37:05
收件人： ttnn BI 观点
抄送：
主题： Re: 从生命周期的角度来考虑架构问题
Steven
May 9, 2008, 1:27:41 AM5/9/08
to tt...@googlegroups.com
混合体系在很多行业都有那么些应用，而且其实施方式各不尽相同，体现在实施步骤、实施周期、实施管理等各方面上；混合体系也是一种架构，但要用一个标准来描述这个混合体系架构是一个什么样的架构，可能不是那么好描述，毕竟这是一个针对不同行业不同环境做出的混合几种架构外带一些外卖（辅助程序等）而形成的具有行业特色，企业特色的独特架构，这种架构就好像“中国特色”一样那么不可复制，innovate511 能从这么多各具特色的混合体系中抽象出公共，通用的混合架构体系，我是相当佩服的，这个体系能形成，在很大程度上指导后来者建立自己特色的混合架构体系，国外可能有提混合架构体系是一个怎么样的概念和想法，但要落实到某一行业，某一具体案例上混合架构体系是什么样的，为什么要采用这样的一个架构体系，需要大家一起总结归纳
2008-05-09
Steven
发件人： interstage
发送时间： 2008-05-09 12:18:06
收件人： ttnn BI 观点
抄送：
主题： Re: 从生命周期的角度来考虑架构问题
interstage
May 9, 2008, 1:29:45 AM5/9/08
to ttnn BI 观点
你这个回答，是解释ＤＷ项目实施中采用Inmon的ＣＩＦ架构还是kimball的架构，或者根据实际情况灵活调整，这个方法我们在实施ＤＷ项目都是这
样做的．但现在的主题是innovate提出了区别去inmon和kimball的第３个架构－－－混合架构（不管是自创还是推广），所以就不是ＤＷ项
目实施的问题，已经上升为理论了，需要学习研究．
理论一定要有明确的定义和界定，你看看inmon的ＣＩＦ架构中的定义，中间组件的定义，都很清晰，让人容易理解和接受．在项目实践中，你可以选择不
同理论指导，来完成，放几个理论共存的架构来实施一个项目都很正常，所以，这就是我们一直讨论的焦点．
On 5月9日, 下午1时11分, "Goldenfish3" <goldenfi...@163.com> wrote:
> 1.参考架构是实践经验总结出来的东西，更多的人是"知其然，不知其所以然"。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing-、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实际-情况灵活调整。
> > 这里架构的作用，就是我上次提到的接口作用，你更上层应用的架构重组，但我底层架构的接口并没变，大大方便了应用层架构的重组的实现。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
样做的．但现在的主题是innovate提出了区别去inmon和kimball的第３个架构－－－混合架构（不管是自创还是推广），所以就不是ＤＷ项
目实施的问题，已经上升为理论了，需要学习研究．
理论一定要有明确的定义和界定，你看看inmon的ＣＩＦ架构中的定义，中间组件的定义，都很清晰，让人容易理解和接受．在项目实践中，你可以选择不
同理论指导，来完成，放几个理论共存的架构来实施一个项目都很正常，所以，这就是我们一直讨论的焦点．
On 5月9日, 下午1时11分, "Goldenfish3" <goldenfi...@163.com> wrote:
> 1.参考架构是实践经验总结出来的东西，更多的人是"知其然，不知其所以然"。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing-、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实际-情况灵活调整。
>
> 2.架构是具有成长性的，要动态调整的，但最终会往一个方向发展，你要控制它一开始就往这个方向发展，还是等它自然演变，中间可能有重构？这就要权衡。
>
> 2008-05-09
>
> Goldenfish3
> 2.架构是具有成长性的，要动态调整的，但最终会往一个方向发展，你要控制它一开始就往这个方向发展，还是等它自然演变，中间可能有重构？这就要权衡。
>
> 2008-05-09
>
>
> - 显示引用的文字 -
interstage
May 9, 2008, 1:42:47 AM5/9/08
to ttnn BI 观点
还是定义不清晰，把体系定义为架构．体系可以模糊，根据实际情况随时选择架构或者调整架构中的组件．架构一定要清晰，要界定，要成为理论，让人一学就
懂．你看看他提供＂Hub-and-Spoke Architecture ＂的第一句话A data warehousing architect
at a large insurance company told Forrester＂，也就是说，作者在实施一个insurance 公司的
DW项目中,提出了一个叫＂Hub-and-Spoke Architecture ＂,这种描述方式,一般都是讲方法论形成的体系,而不象Inmon
谈架构的时候,不说什么项目,直接定义什么叫CIF,CIF包括EDW,ODS等等组件,那什么又是ODS组件,什么叫EDW组件,一目了然.所以，我
们的治学一定要严谨．
所以,目前讨论基本可以得出2个阶段性答案:
1,＂Hub-and-Spoke Architecture ＂不是innovate原创的,是推广的,可能加了它的经验
2,＂Hub-and-Spoke Architecture ＂目前还到不了CIF和MD2大架构的理论性描述层面,目前还处于经验和方法归纳阶
段.
不是大家是否认可.
On 5月9日, 下午1时27分, "Steven" <tanhm1...@gmail.com> wrote:
> 混合体系在很多行业都有那么些应用，而且其实施方式各不尽相同，体现在实施步骤、实施周期、实施管理等各方面上；混合体系也是一种架构，但要用一个标准来描述这-个混合体系架构是一个什么样的架构，可能不是那么好描述，毕竟这是一个针对不同行业不同环境做出的混合几种架构外带一些外卖（辅助程序等）而形成的具有行业特色-，企业特色的独特架构，这种架构就好像"中国特色"一样那么不可复制，innovate511 能从这么多各具特色的混合体系中抽象出公共，通用的混合架构体系，我是相当佩服的，这个体系能形成，在很大程度上指导后来者建立自己特色的混合架构体系，国外可-能有提混合架构体系是一个怎么样的概念和想法，但要落实到某一行业，某一具体案例上混合架构体系是什么样的，为什么要采用这样的一个架构体系，需要大家一起总结-归纳
>
> 2008-05-09
>
> Steven
> > 术。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
懂．你看看他提供＂Hub-and-Spoke Architecture ＂的第一句话A data warehousing architect
at a large insurance company told Forrester＂，也就是说，作者在实施一个insurance 公司的
DW项目中,提出了一个叫＂Hub-and-Spoke Architecture ＂,这种描述方式,一般都是讲方法论形成的体系,而不象Inmon
谈架构的时候,不说什么项目,直接定义什么叫CIF,CIF包括EDW,ODS等等组件,那什么又是ODS组件,什么叫EDW组件,一目了然.所以，我
们的治学一定要严谨．
所以,目前讨论基本可以得出2个阶段性答案:
1,＂Hub-and-Spoke Architecture ＂不是innovate原创的,是推广的,可能加了它的经验
2,＂Hub-and-Spoke Architecture ＂目前还到不了CIF和MD2大架构的理论性描述层面,目前还处于经验和方法归纳阶
段.
不是大家是否认可.
On 5月9日, 下午1时27分, "Steven" <tanhm1...@gmail.com> wrote:
> 混合体系在很多行业都有那么些应用，而且其实施方式各不尽相同，体现在实施步骤、实施周期、实施管理等各方面上；混合体系也是一种架构，但要用一个标准来描述这-个混合体系架构是一个什么样的架构，可能不是那么好描述，毕竟这是一个针对不同行业不同环境做出的混合几种架构外带一些外卖（辅助程序等）而形成的具有行业特色-，企业特色的独特架构，这种架构就好像"中国特色"一样那么不可复制，innovate511 能从这么多各具特色的混合体系中抽象出公共，通用的混合架构体系，我是相当佩服的，这个体系能形成，在很大程度上指导后来者建立自己特色的混合架构体系，国外可-能有提混合架构体系是一个怎么样的概念和想法，但要落实到某一行业，某一具体案例上混合架构体系是什么样的，为什么要采用这样的一个架构体系，需要大家一起总结-归纳
>
> 2008-05-09
>
> Steven
>
> - 显示引用的文字 -
Goldenfish3
May 9, 2008, 2:39:32 AM5/9/08
to tt...@googlegroups.com
如果作一件事有A和B两种方法，通常可以调和出一个半A半B（或者A+B)的折衷方案，往往在现实中妥协出来的－除非A和B不相容。这只能降格为“观点”，不能严格成为“理论”－如果像CIF这种才能成为理论的话。
2008-05-09
Goldenfish3
发件人： interstage
发送时间： 2008-05-09 13:30:11
innovate511
May 9, 2008, 2:46:41 AM5/9/08
to ttnn BI 观点
参考架构确实在技术书中还没抽象成理论，因为都是在10多年实践经验中，各个大厂商自己总结的，来支撑自己的主体模型架构，目的就是延长多维数据仓库的
生命，不至于因为太多变化就早早夭折。
我看过两大厂商的参考架构，作为产品卖的时候，参考架构和行业模型混在一起，没有实践经验的话，实在难发挥去作用，而且产品化的东西功能实在有限。而在
实际的项目中，参考模型无论你是哪种方案，无非围绕这样的问题去解决实际问题：1. 维的定义变化和层次结构变化 2. 维、度量如何在企业级多维数据
仓库中统一管理，但却又要满足不同部门的不同定义需求。如果从这样的问题解决方案出发，就不难理解他们的参考架构，同时我们还可以继承他们10多年的经
验继续深化发展了。
重构在漫长的岁月中是避免不了的，如果从长远发展来看，我们不但要实现企业级+部门个性化BI需求，还必须考虑降低未来重构的风险和成本，这才是混合架
构的最终目的。不过虚拟化混合架构，循序建设逐步建设（包括在老EDW架构上也可以建设多维数据仓库，或者多维数据仓库建设好后再建EDW，松耦合的优
势），这是本人提出来的，确实在业界没看见有人提出，包括英文文章，不知道是否我有漏掉相关查询。
为什么我拿生命周期来说，因为我们在考虑风险、成本的时候，可以根据客户自身情况决定什么时候最合适建什么组件，相当于我把四大组件产品概念化，你可以
选择，前提是你很清楚他们的接口和关键细节么（比如多维数据仓库的统一维度生成过程、参考架构的核心思想，多维数据仓库和数据集市的存储关系和数据流关
系）？
> 1.参考架构是实践经验总结出来的东西，更多的人是"知其然，不知其所以然"。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing-、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实际-情况灵活调整。
生命，不至于因为太多变化就早早夭折。
我看过两大厂商的参考架构，作为产品卖的时候，参考架构和行业模型混在一起，没有实践经验的话，实在难发挥去作用，而且产品化的东西功能实在有限。而在
实际的项目中，参考模型无论你是哪种方案，无非围绕这样的问题去解决实际问题：1. 维的定义变化和层次结构变化 2. 维、度量如何在企业级多维数据
仓库中统一管理，但却又要满足不同部门的不同定义需求。如果从这样的问题解决方案出发，就不难理解他们的参考架构，同时我们还可以继承他们10多年的经
验继续深化发展了。
重构在漫长的岁月中是避免不了的，如果从长远发展来看，我们不但要实现企业级+部门个性化BI需求，还必须考虑降低未来重构的风险和成本，这才是混合架
构的最终目的。不过虚拟化混合架构，循序建设逐步建设（包括在老EDW架构上也可以建设多维数据仓库，或者多维数据仓库建设好后再建EDW，松耦合的优
势），这是本人提出来的，确实在业界没看见有人提出，包括英文文章，不知道是否我有漏掉相关查询。
为什么我拿生命周期来说，因为我们在考虑风险、成本的时候，可以根据客户自身情况决定什么时候最合适建什么组件，相当于我把四大组件产品概念化，你可以
选择，前提是你很清楚他们的接口和关键细节么（比如多维数据仓库的统一维度生成过程、参考架构的核心思想，多维数据仓库和数据集市的存储关系和数据流关
系）？
> 1.参考架构是实践经验总结出来的东西，更多的人是"知其然，不知其所以然"。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing-、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实际-情况灵活调整。
innovate511
May 9, 2008, 3:00:13 AM5/9/08
to ttnn BI 观点
广泛应用是肯定的，只是在各专业网站总结文章中，都没有明显形成体系，更别说真正的理论了，只是大家在实践中觉得这样最好用，左右逢园，能满足各种需
求，风险降低且成本不高，那多好啊。
去前年我提到过有个哥们要和我合作写书，他是主架构师，而且有申请美国专利的可能，他公司还准备支持他，但他太忙了，公司安排了他参与2大500强
TOP50的总部的主架构师之一的工作，我也没时间自己组织架构体系，然后组织成理论，经验当然也没那哥们那么牛，毕竟能被邀请多个国际巨头总部数据仓
库项目主架构师的人还不多，所以我也就是偶尔上网跟大家聊聊。
其实Steven说的中国特色架构，其实也是普遍存在，只是有的组件部分四不像，比如多维数据仓库就是根据各个主题组合来的，没有统一建模体系，更没参
考架构体系，想到哪做到哪，数据仓库里又含有大量汇总表，我建议他们大多数汇总表还是放数据集市，因为汇总意味着信息的浓缩，不符合数据仓库的主题思
想。还有EDW，也有朋友尝试自己建，但是主体是企业的业务模型的再次汇总，这样没有行业标准自己摸索的建设EDW，我觉得风险很大，要知道企业的很多
系统并非行业通用系统，如果换了业务系统，你又将如何？
求，风险降低且成本不高，那多好啊。
去前年我提到过有个哥们要和我合作写书，他是主架构师，而且有申请美国专利的可能，他公司还准备支持他，但他太忙了，公司安排了他参与2大500强
TOP50的总部的主架构师之一的工作，我也没时间自己组织架构体系，然后组织成理论，经验当然也没那哥们那么牛，毕竟能被邀请多个国际巨头总部数据仓
库项目主架构师的人还不多，所以我也就是偶尔上网跟大家聊聊。
其实Steven说的中国特色架构，其实也是普遍存在，只是有的组件部分四不像，比如多维数据仓库就是根据各个主题组合来的，没有统一建模体系，更没参
考架构体系，想到哪做到哪，数据仓库里又含有大量汇总表，我建议他们大多数汇总表还是放数据集市，因为汇总意味着信息的浓缩，不符合数据仓库的主题思
想。还有EDW，也有朋友尝试自己建，但是主体是企业的业务模型的再次汇总，这样没有行业标准自己摸索的建设EDW，我觉得风险很大，要知道企业的很多
系统并非行业通用系统，如果换了业务系统，你又将如何？
interstage
May 9, 2008, 6:46:50 AM5/9/08
to ttnn BI 观点
你总结的还是不够精华，关于和数据相关项目在实施中的矛盾，ＲＤＢ项目实施的问题永远是时间和空间的矛盾，ＤＷ项目实施的问题永远是纬度和粒度的矛盾，
这就是经典矛盾总结了．不用这么复杂写１，２出来．
On 5月9日, 下午2时46分, innovate511 <innovate...@gmail.com> wrote:
> 参考架构确实在技术书中还没抽象成理论，因为都是在10多年实践经验中，各个大厂商自己总结的，来支撑自己的主体模型架构，目的就是延长多维数据仓库的
> 生命，不至于因为太多变化就早早夭折。
>
> 我看过两大厂商的参考架构，作为产品卖的时候，参考架构和行业模型混在一起，没有实践经验的话，实在难发挥去作用，而且产品化的东西功能实在有限。而在
> 实际的项目中，参考模型无论你是哪种方案，无非围绕这样的问题去解决实际问题：1. 维的定义变化和层次结构变化 2. 维、度量如何在企业级多维数据
> 仓库中统一管理，但却又要满足不同部门的不同定义需求。如果从这样的问题解决方案出发，就不难理解他们的参考架构，同时我们还可以继承他们10多年的经
> 验继续深化发展了。
>
> 重构在漫长的岁月中是避免不了的，如果从长远发展来看，我们不但要实现企业级+部门个性化BI需求，还必须考虑降低未来重构的风险和成本，这才是混合架
> 构的最终目的。不过虚拟化混合架构，循序建设逐步建设（包括在老EDW架构上也可以建设多维数据仓库，或者多维数据仓库建设好后再建EDW，松耦合的优
> 势），这是本人提出来的，确实在业界没看见有人提出，包括英文文章，不知道是否我有漏掉相关查询。
>
> 为什么我拿生命周期来说，因为我们在考虑风险、成本的时候，可以根据客户自身情况决定什么时候最合适建什么组件，相当于我把四大组件产品概念化，你可以
> 选择，前提是你很清楚他们的接口和关键细节么（比如多维数据仓库的统一维度生成过程、参考架构的核心思想，多维数据仓库和数据集市的存储关系和数据流关
> 系）？
>
> On 5月9日, 下午1时11分, "Goldenfish3" <goldenfi...@163.com> wrote:
>
>
>
> > 1.参考架构是实践经验总结出来的东西，更多的人是"知其然，不知其所以然"。DW的架构是分层的。为什么要分ODS/DW/DM？DW又分出Stageing--、SystemRecord、Sum？DM难道就不需要明细数据了？每个层次都涉及数据存储，又占用空间又占用时间。讲不出所以然没问题，但至少要知道根据实-际-情况灵活调整。
>
> > 2.架构是具有成长性的，要动态调整的，但最终会往一个方向发展，你要控制它一开始就往这个方向发展，还是等它自然演变，中间可能有重构？这就要权衡。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
这就是经典矛盾总结了．不用这么复杂写１，２出来．
On 5月9日, 下午2时46分, innovate511 <innovate...@gmail.com> wrote:
> 参考架构确实在技术书中还没抽象成理论，因为都是在10多年实践经验中，各个大厂商自己总结的，来支撑自己的主体模型架构，目的就是延长多维数据仓库的
> 生命，不至于因为太多变化就早早夭折。
>
> 我看过两大厂商的参考架构，作为产品卖的时候，参考架构和行业模型混在一起，没有实践经验的话，实在难发挥去作用，而且产品化的东西功能实在有限。而在
> 实际的项目中，参考模型无论你是哪种方案，无非围绕这样的问题去解决实际问题：1. 维的定义变化和层次结构变化 2. 维、度量如何在企业级多维数据
> 仓库中统一管理，但却又要满足不同部门的不同定义需求。如果从这样的问题解决方案出发，就不难理解他们的参考架构，同时我们还可以继承他们10多年的经
> 验继续深化发展了。
>
> 重构在漫长的岁月中是避免不了的，如果从长远发展来看，我们不但要实现企业级+部门个性化BI需求，还必须考虑降低未来重构的风险和成本，这才是混合架
> 构的最终目的。不过虚拟化混合架构，循序建设逐步建设（包括在老EDW架构上也可以建设多维数据仓库，或者多维数据仓库建设好后再建EDW，松耦合的优
> 势），这是本人提出来的，确实在业界没看见有人提出，包括英文文章，不知道是否我有漏掉相关查询。
>
> 为什么我拿生命周期来说，因为我们在考虑风险、成本的时候，可以根据客户自身情况决定什么时候最合适建什么组件，相当于我把四大组件产品概念化，你可以
> 选择，前提是你很清楚他们的接口和关键细节么（比如多维数据仓库的统一维度生成过程、参考架构的核心思想，多维数据仓库和数据集市的存储关系和数据流关
> 系）？
>
> On 5月9日, 下午1时11分, "Goldenfish3" <goldenfi...@163.com> wrote:
>
>
>
>
> > 2.架构是具有成长性的，要动态调整的，但最终会往一个方向发展，你要控制它一开始就往这个方向发展，还是等它自然演变，中间可能有重构？这就要权衡。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
May 9, 2008, 7:16:12 AM5/9/08
to ttnn BI 观点
OK,从innovate这段话描述来看，已经验证了我刚才2个阶段性结论:
1,＂Hub-and-Spoke Architecture ＂不是innovate原创的,是国外引进推广的,但innovate在实践中已经有他
自己的新思路了（比如利用松仅耦合的四大组件）
2,＂Hub-and-Spoke Architecture ＂目前还到不了CIF和MD2大架构的理论性描述层面,目前还处于经验和方法归纳阶段描
述层面.
这2个结论已经可以确定了，也就结束了从我发表＂OLAP工具毁了BI＂后与 innovate就他的架构论而展开的＂业务驱动技术＂，＂甲方工作＂，
＂数据架构本质＂等等经历8个多月的争论(呵呵,就这个问题上看热闹的,估计要失望了)．
现在需要对 innovate的架构做一个名词定义，为了继续交流的需要．为了区别CIF和MD是理论性架构,那把innovate基于＂Hub-
and-Spoke Architecture ＂发展出了的架构需要定义出交流几方都接受的名字.我建议把它定义为 "实践性混合架构", 这样我觉
得双方都能接受了,支持innovate论点的Bier看到"混合架构"这4个字还存在,支持interstage论点的Bier看到了"实践性"3个
字,就知道还没升级为理论性架构,目前还不能独立成于CIF和MD 2大理论性架构的第3股力量.
好,下面的问题是,innovate是否愿意就他的 "实践性混合架构"细节进行展开,从以下几点开始:
1,是否给出一个拓扑图,把各组件的关系清晰,各组件在"实践性混合架构"中是如何定义的,是否与CIF和MD中定义一样?
2,各组件的松耦合是如何定义,如何接口,是否可以通过流程定义随机变化,是否可以提升为"服务",符合SOA精神?
3,组件内的紧耦合是如何定义,如何管理的?
4,行业模型是属于单个组件,还是跨不同组件内的?
我们就这几点先行开始讨论,可以吗?
On 5月9日, 下午3时00分, innovate511 <innovate...@gmail.com> wrote:
> 广泛应用是肯定的，只是在各专业网站总结文章中，都没有明显形成体系，更别说真正的理论了，只是大家在实践中觉得这样最好用，左右逢园，能满足各种需
> 求，风险降低且成本不高，那多好啊。
>
> 去前年我提到过有个哥们要和我合作写书，他是主架构师，而且有申请美国专利的可能，他公司还准备支持他，但他太忙了，公司安排了他参与2大500强
> TOP50的总部的主架构师之一的工作，我也没时间自己组织架构体系，然后组织成理论，经验当然也没那哥们那么牛，毕竟能被邀请多个国际巨头总部数据仓
> 库项目主架构师的人还不多，所以我也就是偶尔上网跟大家聊聊。
>
> 其实Steven说的中国特色架构，其实也是普遍存在，只是有的组件部分四不像，比如多维数据仓库就是根据各个主题组合来的，没有统一建模体系，更没参
> 考架构体系，想到哪做到哪，数据仓库里又含有大量汇总表，我建议他们大多数汇总表还是放数据集市，因为汇总意味着信息的浓缩，不符合数据仓库的主题思
> 想。还有EDW，也有朋友尝试自己建，但是主体是企业的业务模型的再次汇总，这样没有行业标准自己摸索的建设EDW，我觉得风险很大，要知道企业的很多
> 系统并非行业通用系统，如果换了业务系统，你又将如何？
>
> On 5月9日, 下午1时27分, "Steven" <tanhm1...@gmail.com> wrote:
>
>
>
> > 混合体系在很多行业都有那么些应用，而且其实施方式各不尽相同，体现在实施步骤、实施周期、实施管理等各方面上；混合体系也是一种架构，但要用一个标准来描述这--个混合体系架构是一个什么样的架构，可能不是那么好描述，毕竟这是一个针对不同行业不同环境做出的混合几种架构外带一些外卖（辅助程序等）而形成的具有行业特-色-，企业特色的独特架构，这种架构就好像"中国特色"一样那么不可复制，innovate511 能从这么多各具特色的混合体系中抽象出公共，通用的混合架构体系，我是相当佩服的，这个体系能形成，在很大程度上指导后来者建立自己特色的混合架构体系，国外可--能有提混合架构体系是一个怎么样的概念和想法，但要落实到某一行业，某一具体案例上混合架构体系是什么样的，为什么要采用这样的一个架构体系，需要大家一起总-结-归纳- 隐藏被引用文字 -
>
> - 显示引用的文字 -
1,＂Hub-and-Spoke Architecture ＂不是innovate原创的,是国外引进推广的,但innovate在实践中已经有他
自己的新思路了（比如利用松仅耦合的四大组件）
2,＂Hub-and-Spoke Architecture ＂目前还到不了CIF和MD2大架构的理论性描述层面,目前还处于经验和方法归纳阶段描
述层面.
这2个结论已经可以确定了，也就结束了从我发表＂OLAP工具毁了BI＂后与 innovate就他的架构论而展开的＂业务驱动技术＂，＂甲方工作＂，
＂数据架构本质＂等等经历8个多月的争论(呵呵,就这个问题上看热闹的,估计要失望了)．
现在需要对 innovate的架构做一个名词定义，为了继续交流的需要．为了区别CIF和MD是理论性架构,那把innovate基于＂Hub-
and-Spoke Architecture ＂发展出了的架构需要定义出交流几方都接受的名字.我建议把它定义为 "实践性混合架构", 这样我觉
得双方都能接受了,支持innovate论点的Bier看到"混合架构"这4个字还存在,支持interstage论点的Bier看到了"实践性"3个
字,就知道还没升级为理论性架构,目前还不能独立成于CIF和MD 2大理论性架构的第3股力量.
好,下面的问题是,innovate是否愿意就他的 "实践性混合架构"细节进行展开,从以下几点开始:
1,是否给出一个拓扑图,把各组件的关系清晰,各组件在"实践性混合架构"中是如何定义的,是否与CIF和MD中定义一样?
2,各组件的松耦合是如何定义,如何接口,是否可以通过流程定义随机变化,是否可以提升为"服务",符合SOA精神?
3,组件内的紧耦合是如何定义,如何管理的?
4,行业模型是属于单个组件,还是跨不同组件内的?
我们就这几点先行开始讨论,可以吗?
On 5月9日, 下午3时00分, innovate511 <innovate...@gmail.com> wrote:
> 广泛应用是肯定的，只是在各专业网站总结文章中，都没有明显形成体系，更别说真正的理论了，只是大家在实践中觉得这样最好用，左右逢园，能满足各种需
> 求，风险降低且成本不高，那多好啊。
>
> 去前年我提到过有个哥们要和我合作写书，他是主架构师，而且有申请美国专利的可能，他公司还准备支持他，但他太忙了，公司安排了他参与2大500强
> TOP50的总部的主架构师之一的工作，我也没时间自己组织架构体系，然后组织成理论，经验当然也没那哥们那么牛，毕竟能被邀请多个国际巨头总部数据仓
> 库项目主架构师的人还不多，所以我也就是偶尔上网跟大家聊聊。
>
> 其实Steven说的中国特色架构，其实也是普遍存在，只是有的组件部分四不像，比如多维数据仓库就是根据各个主题组合来的，没有统一建模体系，更没参
> 考架构体系，想到哪做到哪，数据仓库里又含有大量汇总表，我建议他们大多数汇总表还是放数据集市，因为汇总意味着信息的浓缩，不符合数据仓库的主题思
> 想。还有EDW，也有朋友尝试自己建，但是主体是企业的业务模型的再次汇总，这样没有行业标准自己摸索的建设EDW，我觉得风险很大，要知道企业的很多
> 系统并非行业通用系统，如果换了业务系统，你又将如何？
>
> On 5月9日, 下午1时27分, "Steven" <tanhm1...@gmail.com> wrote:
>
>
>
>
> - 显示引用的文字 -
Reply all
Reply to author
Forward
0 new messages