数据仓库架构本质的个人理解（原创）

[innovate511]

上次提到技术应该是面向需求的（包括未来的需求），那么架构正是技术的高级表现形式。（这里核心讲数据架构）

ＢＩＤＷ在项目的表现形式是由数据库（数据模型）、ＥＴＬ、ＯＬＡＰ、前端几部分组成，他们各部分分别由各大产商提供了相应的产品或工具，那么我们所抽
象出来的架构是否是空旷的架构，是否按照厂商提供的产品开发方案顺着开发就行了，架构的本质到底是什么呢？

总结到一句话，个人理解架构的本质就是能更好地对系统进行管理、维护和扩展数据仓库系统。

从业界讨论最激烈的两种架构，至顶向下和至底向上，到现在越来越多使用的混合架构（两者特点都有），他们的观点都表达了对数据仓库设计、管理、扩展、维
护的理解，只是出发点不同。到现在多年发展后，两个观点的创始人逐步也充分了解到对方观点的优点，以更好地发挥本阵营的优势。

那么，对于多数企业的现状是资金不能一次性投入太多，但又希望能循序渐进投入，不断产生回报，减少弯路，我想，混合架构将是最受欢迎的。

首先我简单介绍下我对混合架构精髓的理解，那就是整体松耦合，各层结构以接口形式集成，而结构内部紧耦合，该层结构的功能定义需要规划好，管理的数据对
象需要定义好，ＥＴＬ策略需要定义好，这样既可以发挥厂商的产品优势（包括行业模型产品），整合有效资源，又能在整体上弱化个别产品的作用，增加架构的
健壮性。而以接口形式集成整体，意味着有的层次结构在初期不必建设，而在后来可以根据规划增加进整体架构来，既在初期以教小成本建好ＢＩ，体现出成果，
又能在后期找到深化、扩展、管理的目标。

目前混合架构的标准大的结构层次分别有ODS-EDW-CDW-DM四大部分，其中ODS-EDW结构采用了Inmon派的策略，而CDW-DM采用了
Kimball派的策略。EDW是近３范式模型，CDW属于多维数据仓库，有统一维度建模策略。如上面所描述，只要我们清晰现在必须做什么，现有资源和
人力能做成什么样，这样就能制定当前架构采取哪些部分，然后制定相关接口规范，以后扩展，才不会脱节。当然这样做，对项目管理要求很高，必须文档齐备，
内容规范，否则松耦合的弱点就体现出来了。

从此看出，架构并不是空虚的，它是实实在在的技术策略，但是它的好坏并不是一定是谁的好，谁的坏，而是是否满足企业现在和未来的ＢＩ战略需求，架构就是
帮助我们更好地使用好BIDW软件产品和工具、管理好、维护好我们的数据，而对于未来的新数据源和业务分析需求以及接口需求，都有个说法。

[innovate511]

感觉最近冒出来的云计算概念，属于一种通用管理、维护模式，总觉得其先进技术会用到传统BIDW架构上，而不会完全代替传统BIDW，因为传统BIDW
管理模式非常严谨、安全、个性化足，当然缺点就是投资相对较大。


On 5月1日, 下午12时05分, innovate511 <innovate...@gmail.com> wrote:

[interstage]

呵呵,终于明白牛人的混合架构逻辑了,居然Inmon的ODS-EDW和而Kimball的CDW-DM以所谓的整体松耦合和内部紧耦合结合在一起.所
有话都让你说了,看来你真的牛到家了,这样的混合架构,真的是太搞笑了.看来你真的没理解为什么在Inmon提出ODS-EDW架构后Kimball还
会提出CDW-DM架构,就是在现实中成本大太,而ODS-EDW架构中有些成本Kimball认为可以省略或者简化的,所以最后争论的结果使
Inmon从CIF转向GIF,而就是GIF也是借美国911机会才做了一部分,现在经济不好就更难做了,使inmon的GIF成为一个大而全的圣经,
这个圣经并不是说ODS-EDW架构本身有多伟大,是由于这样的成本环境下变成可遇不可求的项目.而Kimball的MD模式更容易被企业接受也是这个
道理,你居然提出要把这2派整合,显然没考虑到成本问题,我服了你.
我想把长城贴满瓷砖,技术上绝对可行,真的人会这样干吗. 欧洲产品的元素是高贵,美国产品的元素是创新,日本产品的元素是品质,看来我们国人产品的元
素只能是忽悠了,忽悠的越牛越好,前段时间居然某个科学院权威在忽悠10进制的网络,DWBI看来在中国也是忽悠,

On 5月1日, 下午12时05分, innovate511 <innovate...@gmail.com> wrote:

[Qing]

完全代替不至于，云计算也恐怕也不会代替所有的计算，至少那些大型的企业，他们总会有自己的一套。在BI领域，云计算跟其他还有些不同，数据的大集中现在就做不到。但现在有On-Demand BI，这算是应用方面的云计算，而一旦越来越多的事务系统，比如CRM、网站点击都被云化了，数据仓库云化的日子也不远了。

 

但如果说传统BIDW管理模式非常严谨、安全、个性化足，我想你是在说笑话。

2008/5/6 innovate511 <innov...@gmail.com>:

[raullew]

云计算落实到DW，就是grid么，换了个名词继续炒？

On 5月7日, 下午1时14分, Qing <happys...@gmail.com> wrote:
> 完全代替不至于，云计算也恐怕也不会代替所有的计算，至少那些大型的企业，他们总会有自己的一套。在BI领域，云计算跟其他还有些不同，数据的大集中现在就做不-到。但现在有On-Demand

> BI，这算是应用方面的云计算，而一旦越来越多的事务系统，比如CRM、网站点击都被云化了，数据仓库云化的日子也不远了。
>
> 但如果说传统BIDW管理模式非常严谨、安全、个性化足，我想你是在说笑话。

> 2008/5/6 innovate511 <innovate...@gmail.com>:
>
>
>
>
>
> > 感觉最近冒出来的云计算概念，属于一种通用管理、维护模式，总觉得其先进技术会用到传统BIDW架构上，而不会完全代替传统BIDW，因为传统BIDW管理模式-非常严谨、安全、个性化足，当然缺点就是投资相对较大。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[interstage]

对于最近炒的很热的"云计算",我只能说还属于概念导入,尽管IBM号称"蓝云"产品可以销售,但google已经说了暂无计划出售"云计算"技术.其
实本人认为不管叫"云计算"也好,网格2.0也好,这个技术出现的原因是什么,目前只能解释为"扁平化组织"在企业管理中的兴起,传统企业组织的特点，
表现为层级结构。一个企业的高层、中层、基层管理者组成一个金字塔式的形状。当企业规模扩大时，原来的有效办法是增加管理层次，而现在的有效办法是增加
管理幅度。当管理层次减少而管理者幅度增加时，金字塔状的组织形式就被"压缩 "成扁平状的组织形式。
扁平化得以在世界范围内大行其道，究其原因：
一是分权管理成为一种普遍趋势，金字塔状的组织结构是与集权管理体制相适应的，而在分权的管理体制之下，各层级之间的联系相对减少，各基层组织之间相对
独立，扁平化的组织形式能够有效运作。
二是企业快速适应市场变化的需要，传统的组织形式难以适应快速变化的市场，为了不被淘汰，就必须实行扁平化。
三是现代信息技术的发展，特别是计算机管理信息系统的出现，使传统的管理幅度理论在某种程度上不再有效。虽然管理幅度增加后指数化增长的信息量和复杂的
人际关系大大的增加了管理的难度，但这些问题在计算机强大的信息处理能力面前往往都能迎刃而解。

目前的中国还没有一家伟大的企业出现,传统上还处于亲"亲"的组织架构,科层式的组织架构才在兴起,"团队学习"和"持续改善"的组织管理模式还没有成
熟,一下子提基于"扁平状"组织的"云计算",呵呵,不是太傻去扔钱,就是太聪明去骗钱.

On 5月7日, 下午1时14分, Qing <happys...@gmail.com> wrote:

> 完全代替不至于，云计算也恐怕也不会代替所有的计算，至少那些大型的企业，他们总会有自己的一套。在BI领域，云计算跟其他还有些不同，数据的大集中现在就做不-到。但现在有On-Demand

> BI，这算是应用方面的云计算，而一旦越来越多的事务系统，比如CRM、网站点击都被云化了，数据仓库云化的日子也不远了。
>
> 但如果说传统BIDW管理模式非常严谨、安全、个性化足，我想你是在说笑话。

[Goldenfish3]

云计算是1.基于Grid的存储和/或计算力，2.并体现为支持远端使用的服务能力。即便DW（特别是share nothing）集群具备grid的一些特征，对远端大量用户的直接服务能力仍欠缺，不像搜索引擎或邮件系统。支持大量远端用户实时查询的ODS（例如邮政快递的状态跟踪）倒是更像云计算一些。

 

 

2008-05-07

---

Goldenfish3

---

发件人： raullew

发送时间： 2008-05-07  13:36:57

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库架构本质的个人理解（原创）

[innovate511]

某些人没经历过，或者说没有见过实际操作的，永远理解不到精髓，只会在哪里动动嘴皮子而已。

混合架构的两个精髓，一是架构本身在很多国际客户使用后被广泛认可的原因，就是其功能全，既稳固，而且适应各种应用。二是架构本身可以虚拟化，各部分以
接口形式存在，在前面已经讲过了，就不多说了，这个特点注定了可以让企业以较小的成本先使用多维分析，然后通过虚拟架构的管理，逐渐完善架构，而不失整
体性。

正因为成本问题，所以对于普通企业来说，刚开始建设可以省略ODS-EDW，而直接建设多维模型，而ODS-EDW在架构中也实际存在，只是虚拟的，在
适当的时候再做起来，长期来看均化了投资成本，因为在架构中，接口定义很重要，在后期才能建立起来而不需要重新构建整体架构，只是添加不用重复劳动的组
件。

至于为啥有的人很喜欢这个架构，而有的人不削，甚至挖苦讽刺。我想有两个原因，首先国内甲方多数都不成熟，没有感觉架构规划的必要，一上来就是直接上
BI应用，于是乙方人员也就以实现BI功能为目标，架构可以简化，毕竟甲方考察的只是BI展现。其次国内几乎没有成功的类似架构应用案例，不是象电信运
营商那种纯Inmon派的（人家有钱耗），就是直接Kimball派的（当然很多是断章取义，并没有Kimball派的精华），于是乎就会说，这个综合
架构是忽悠，创造概念而已，增加了客户成本云云，完全没见识过这种应用。要知道经历过90年代混合架构的失败后，目前已经走到现在成熟的架构方案，国际
上已经有大量的成功案例。我只是这里大胆预测，当企业在未来2、3年不断碰壁后，自然会想到如果循序渐进建立稳固的架构，而刚开始又不用投资过多。

这个综合架构，我参加过整个生命周期的建设，而现在所在企业的架构是我主规划和设计，无论内行人员还是外行中高层管理者，无不对这个从虚拟架构，慢慢落
实物理化的策略折服，因为我从技术架构到技术细节讲解后，其流程非常清晰，落实过程也易理解。架构这玩意，没实战经验不能乱吹，也不能乱说，纸上谈兵的
我看多了。

如果要完全否定ODS-EDW的作用，那问问电信、金融、以及国外的500强企业，谁敢撤消掉ODS-EDW直接用多维？

对于纯业务派来说，我也没必要也没义务让这些业务牛人都能理解技术架构，这些东西只给能理解的人参考。继续说些外行话，只是些笑柄而已。

On 5月7日, 下午6时44分, "Goldenfish3" <goldenfi...@163.com> wrote:
>

[innovate511]

所以我觉得新的技术对某些需求还是有帮助的，不能一概否定，从概念、实验、实践到推广，还需要一段过程。

对于我这里提到的架构，如果针对的情况是部门级的应用，当然不合适，对于发展停滞类型的企业，也不见得就一定能到ODS-EDW都完成的必要，也许只需
要部分ODS功能，甚至都不要，当需要的时候，根据接口和核心模型建设就是了，成熟之后再架构移植。所以从适合群体来看，适合各种高速发展的企业，既想
马上能较低成本建设BIDW，但又想在未来企业发展到一定程度的时候享受稳健的架构。而这类企业在中国目前属于比较主流的。

On 5月7日, 下午6时44分, "Goldenfish3" <goldenfi...@163.com> wrote:

> 云计算是1.基于Grid的存储和/或计算力，2.并体现为支持远端使用的服务能力。即便DW（特别是share nothing）集群具备grid的一些特征，对远端大量用户的直接服务能力仍欠缺，不像搜索引擎或邮件系统。支持大量远端用户实时查询的ODS（例如邮政快递-的状态跟踪）倒是更像云计算一些。
>

[interstage]

没吃过猪，还没见过猪跑吗，而且你怎么知道我没经历过，请问电信有钱还是移动有钱？我现在负责运营一个全网移动业务，这个业务打通了３１个省移动的ＢＯ
ＳＳ系统，每天和３１个省移动的市场部进行交流，这个业务运营了近８个月，通过这个全网业务，已经发现很多省移动ＢＯＳＳ系统的数据质量是多么的差，所
谓的架构是多么的无聊，接口是多么混乱，ＢＯＳＳ报文数据传递还经常冗余，连中移动的ＢＯＳＳ系统也没法实现你所谓的ODS-EDW－CDW-DM架
构,你天天在讲你的电信上的架构是多么成功，多么先进，而你举的这些数据量（仅仅几Ｔ），我并不认为很大很海量．难道我象你那样动不动谈架构，每旬给移
动集团的汇报上提建设架构，就是移动集团真的按照你所谓的架构重新改进各省ＢＯＳＳ和ＣＢＯＳＳ系统，业务问题就不会出了吗？
别在这个动不动以架构牛人自称，以海量数据实践经验自据，每个项目都不容易，原则上我做人的风格是不评价别人做过的项目的，但你天天以项目牛人自称，动
不动谈实施过５００强企业的ＤＷＢＩ自据，实在太井底之蛙了．所谓移动ＢＯＳＳ系统的ＤＷＢＩ方式，难道作为项目实施方的你们，还能比全网业务运营方的
我更明白数据分析的重要性，天天看报表，改报表，查ＢＯＳＳ数据质量问题，难道你建项目的人有我用项目的人理解很深刻，而且你也不可能把３１个省的ＢＯ
ＳＳ系统全实施了，亚信在中国移动也就做了７个省的ＢＯＳＳ系统．外行话就别说了，看看谁笑话谁．

[syfins]

哇
场面越来越火爆了
比QING那个太监贴强的不是一点半点
抓紧时间保存
防止斑竹删贴

[Goldenfish3]

“一是分权管理成为一种普遍趋势，金字塔状的组织结构是与集权管理体制相适应的，而在分权的管理体制之下，各层级之间的联系相对减少，各基层组织之间相对

独立，扁平化的组织形式能够有效运作。”

 

我认为组织扁平化是权力集中的一种手段，分权才会造成金字塔。例如省直管县，取消中间市一层，就是将管理权限集中到省，实现省集权，提高效率。

 

2008-05-08

---

Goldenfish3

---

发件人： interstage

发送时间： 2008-05-07  16:08:59

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库架构本质的个人理解（原创）

[Steven]

从两位吵架的过程中，越来越发现有趣的事实，那就是越来越达到一个共识，有可能引发两位之间的合作关系，innovate511谈架构，说实话，现在不谈架构谈什么呢？interstage 主张不谈架构，可有没除谈架构之外更好的办法？一个从技术，一个从业务，如果技术和业务调整姿态，开创一个双赢的局面岂不甚好，这是一个比较理想的想法。从interstage 的眼里，可能太多的问题阻碍架构的想法和实施，但在innovate511 眼里，这个架构的东西又不得不去做，即使问题重重，否则后面堆积的问题会越来越多（随着应用增多，用户增多，数据增多），也要去做，但如何去做，其实两位可能都已经认识到了，但愿不愿意做，这个在实际过程中遇到太多的实际情况，不好处理；最好的是技术上统一架构，统一平台，再加上“云计算”，引用一下新概念，呵呵，业务上做些流程再造，流程改进，是不是太理想化了？

 

 

2008-05-08

---

Steven

---

发件人： interstage

发送时间： 2008-05-07  21:27:51

收件人： ttnn BI 观点

抄送：

主题： Re: 数据仓库架构本质的个人理解（原创）

[innovate511]

一个资深的人，如果抱着自己的观点不放，死守已有的经验，是无法改变的，也没必要改变，各人的环境和长处不同。所以我上一个帖子就说了，是给DW人员作
为交流，并非和DW外行或者假内行交流。

架构是什么？是一种方法论结合各种事情情况的总结，第一个帖子提到过了，是一种管理手段，方便未来的管理、维护和扩展，并有效提高效率、降低成本，如果
增大了成本、不方便管理和维护，那还要架构干嘛？

电信行业早在近10年前就在摸索BI了，现在做出了点成绩，那是多年积累，是必然，就是瞎子摸象也能做出点东西来了。问题也很多，具体问题现在我也不清
楚，4年多没接触过电信行业了。他们有钱和时间去慢慢折腾，不过新兴行业可不敢随便冒风险折腾，不然就吓怕了。

电信和金融无论是国内还是国外，都是最先实现很多企业信息化的行业，而实际应用的行业很多，并非只有电信金融行业。我这里讨论的是一个比较有通用性的，
适合各种新兴行业和企业的建设。电信金融的情况很特殊，他们信息化早，有资金，可以一次性定义架构，也可以部门级自己实现部分BI，而且要数据质量，他
们的数据质量相对新兴行业，那要好很多。

我已经在2个非电信行业实践过架构理论，并取得良好的评价，现在做的是从0开始的架构规划直到未来3、5年完全实现，得到了公司IT从高层到普通人员的
一致肯定，技术有效解决了大多数实际问题，并对业务系统有一定技术反馈和帮助。如果想否定我的观点，除非他仅仅局限在电信银行行业去死缠烂打，不敢扩大
到广大其他行业，毕竟最近几年我没做这些垄断行业了，我不敢妄自下结论，因为我要下结论的话，必须是实践过、总结过的，而非猜测和推理。所谓没吃过猪肉
见过猪跑，纯粹是猜测，实际很多问题根本没反思过。但如果想全盘否定，那简直是荒谬，别说我实践成功过，即使整个业界也有很多成功案例。


On 5月8日, 上午10时23分, "Steven" <tanhm1...@gmail.com> wrote:
> 从两位吵架的过程中，越来越发现有趣的事实，那就是越来越达到一个共识，有可能引发两位之间的合作关系，innovate511谈架构，说实话，现在不谈架构谈-什么呢？interstage 主张不谈架构，可有没除谈架构之外更好的办法？一个从技术，一个从业务，如果技术和业务调整姿态，开创一个双赢的局面岂不甚好，这是一个比较理想的想法。从in-terstage 的眼里，可能太多的问题阻碍架构的想法和实施，但在innovate511 眼里，这个架构的东西又不得不去做，即使问题重重，否则后面堆积的问题会越来越多（随着应用增多，用户增多，数据增多），也要去做，但如何去做，其实两位可能都-已经认识到了，但愿不愿意做，这个在实际过程中遇到太多的实际情况，不好处理；最好的是技术上统一架构，统一平台，再加上"云计算"，引用一下新概念，呵呵，业-务上做些流程再造，流程改进，是不是太理想化了？
>
>

[Qing]

呵呵，看来前段时间让很多人失望了，真是太对不住。不过这位兄弟说防止斑竹删贴，实在是对ttnn最大的侮辱。

 

早上刚上班，就有一位朋友msn上告诉我说，"那俩人又干起来了。"我们之前曾经讨论过他们的争论，所以这里用"又"。我"呵呵"了一下，有热闹看当然好，我很喜欢看人打架，而且认为那种拉架的人是世界上最虚伪的人，因为他们阻止了别人的情感，不能为了和谐就牺牲人的情感。有人说，看热闹是中国人的劣根性，我看这是自卖自夸，这恐怕是人类的劣根性，当然还有个前提，如果这是劣根的话。中午有点热，这话有点跑题了。

 

那位朋友接着又问，"你怎么看？"我说，"innovate在探索架构，不认同interstage的态度，但认为他说的很有道理。"这话说的，真漂亮，自我感觉挺良好的。那位朋友还想继续深入，我赶紧看看后面还有什么争论的，原来比昨天增加了不少。于是说还没来得及看完。看完再发表高见。

 

不过中午看了看，发现上面那个回答还是成立的，新的争论没有任何新意，都是老调重弹，无非一个说，我很牛，另一个说，其实你一点都不牛。

 

我还等着innovate继续说架构呢。在这个讨论的一开始，提出想混合两种架构，没有细说。虽然我也有些疑惑，但以为是自己的风格问题。

 

我认为整合自上而下和自下而上的两种架构不可行，因为他们本身就是矛盾的，如果说混合以后就对立统一了，那时理论层面的。在人们的实践过程中，要不就是自上而下，要不就是自下而上。设计师完成架构，交给实施的人，说，咱们就按照这个来，先ods，再dw，ods 3nf建模，dw维度建模，咱们说定了，可就这么办了。ods自上而下，整出一个完美模型，dw，咱们自下而上，应用需要什么数据我们整什么数据。可从逻辑上分析，这是为什么呀？

 

为什么要混合啊？似乎是为了弥补两种不同架构的缺点似的。

但他们缺点到底在哪儿？自上而下的方法是不是忽略了应用的需求？自下而上的方法是不是不能满足灵活的扩展？

这些缺点是不是真实存在着？他们各自是否有相应的补救方法？

 

对于这两种路线，我一直有一种感觉，自上而下的方法很完美，但是从来没有完美的人来设计他，乱。自下而上的方法很实际，但人们在执行的时候，经常缺乏原则指导，乱。从我个人的喜好来说，我喜欢自下而上，喜欢演进的方法而不是一开始规划好的方法，这是我对自下而上的理解，但相信很多人有其他理解。

 

说了这么多，有个问题，这都是在这种架构是否合理的理论层面探讨，我已经多年没有实践，所以大家可以说这是在扯淡。innovate的架构是否适用，得通过实践去证明。也请innovate继续将这个架构说的更细一点，这样也有东西可以探讨。

 

至于interstage的批评，我认为他基于成本的考虑很实际，很赞同。不过显然，这个说法已经被他其他的观点淹没，比如你牛什么之类，从来没见过你这种架构之类的说法。我之前回答说，不认同他的态度，就是指他的语含讽刺的态度。不过后来我又想，也许，这未必不可能是个合适的态度，也许innovate由此而更加坚定自己的架构探索之路。

 

所以，大家还是爱咋咋地吧。

2008/5/7 syfins <syf...@gmail.com>:

哇
场面越来越火爆了
比QING那个太监贴强的不是一点半点
抓紧时间保存
防止斑竹删贴

[interstage]

哈哈,反过来了,当我08年之前不接触电信行业,做了10年零售行业的DWBI项目的时候,牛人说他是500强企业电信行业成功经验,说ODS-
EDW-CDW-DM架构在大行业可行,不能因为小行业没上ODS-EDW-CDW-DM架构,只用MD架构,就否定他的架构.现在我深刻接触了电信行
业的全网项目,而他又去小行业了,又以小行业的经验专家自居了,真是不知所云.而你认为我不是DW人员,是DW外行或者假内行,我已经写了我的10年内
在DWBI项目引起的职业变化的经历,让大家看看是不是DW人员.可能在技术细节(其实我也不可能知道你的技术细节实施能力,说不定还真不如我)实施
上，我开始疏远了,但对DW技术的发展和把握能力上,我自信有和你这个牛人交流DW架构的水平.
我不否认架构的创新,但我认为目前的中国没有条件有能力让你达到创新的水平,所以与其架构的创新不如实在点说实施方法上的创新,

On 5月8日, 上午11时30分, innovate511 <innovate...@gmail.com> wrote:
> 一个资深的人，如果抱着自己的观点不放，死守已有的经验，是无法改变的，也没必要改变，各人的环境和长处不同。所以我上一个帖子就说了，是给DW人员作
> 为交流，并非和DW外行或者假内行交流。
>
> 架构是什么？是一种方法论结合各种事情情况的总结，第一个帖子提到过了，是一种管理手段，方便未来的管理、维护和扩展，并有效提高效率、降低成本，如果
> 增大了成本、不方便管理和维护，那还要架构干嘛？
>
> 电信行业早在近10年前就在摸索BI了，现在做出了点成绩，那是多年积累，是必然，就是瞎子摸象也能做出点东西来了。问题也很多，具体问题现在我也不清
> 楚，4年多没接触过电信行业了。他们有钱和时间去慢慢折腾，不过新兴行业可不敢随便冒风险折腾，不然就吓怕了。
>
> 电信和金融无论是国内还是国外，都是最先实现很多企业信息化的行业，而实际应用的行业很多，并非只有电信金融行业。我这里讨论的是一个比较有通用性的，
> 适合各种新兴行业和企业的建设。电信金融的情况很特殊，他们信息化早，有资金，可以一次性定义架构，也可以部门级自己实现部分BI，而且要数据质量，他
> 们的数据质量相对新兴行业，那要好很多。
>
> 我已经在2个非电信行业实践过架构理论，并取得良好的评价，现在做的是从0开始的架构规划直到未来3、5年完全实现，得到了公司IT从高层到普通人员的
> 一致肯定，技术有效解决了大多数实际问题，并对业务系统有一定技术反馈和帮助。如果想否定我的观点，除非他仅仅局限在电信银行行业去死缠烂打，不敢扩大
> 到广大其他行业，毕竟最近几年我没做这些垄断行业了，我不敢妄自下结论，因为我要下结论的话，必须是实践过、总结过的，而非猜测和推理。所谓没吃过猪肉
> 见过猪跑，纯粹是猜测，实际很多问题根本没反思过。但如果想全盘否定，那简直是荒谬，别说我实践成功过，即使整个业界也有很多成功案例。
>
> On 5月8日, 上午10时23分, "Steven" <tanhm1...@gmail.com> wrote:
>
>
>

> > 从两位吵架的过程中，越来越发现有趣的事实，那就是越来越达到一个共识，有可能引发两位之间的合作关系，innovate511谈架构，说实话，现在不谈架构谈--什么呢？interstage 主张不谈架构，可有没除谈架构之外更好的办法？一个从技术，一个从业务，如果技术和业务调整姿态，开创一个双赢的局面岂不甚好，这是一个比较理想的想法。从in--terstage 的眼里，可能太多的问题阻碍架构的想法和实施，但在innovate511 眼里，这个架构的东西又不得不去做，即使问题重重，否则后面堆积的问题会越来越多（随着应用增多，用户增多，数据增多），也要去做，但如何去做，其实两位可能都--已经认识到了，但愿不愿意做，这个在实际过程中遇到太多的实际情况，不好处理；最好的是技术上统一架构，统一平台，再加上"云计算"，引用一下新概念，呵呵，-业-务上做些流程再造，流程改进，是不是太理想化了？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[tosimple]

"不过显然，这个说法已经被他其他的观点淹没", qing, 佩服你看问题的思路。

看热闹是中国人的劣根性， 我对这句话的理解是看热闹的人也就是看看罢了，没有去思考这件事情的真象，它背后的东西。

看问题，得看本质，热闹，不知那么简单的！

On 5月8日, 下午1时12分, Qing <happys...@gmail.com> wrote:
> 呵呵，看来前段时间让很多人失望了，真是太对不住。不过这位兄弟说防止斑竹删贴，实在是对ttnn最大的侮辱。
>

> 早上刚上班，就有一位朋友msn上告诉我说，"那俩人又干起来了。"我们之前曾经讨论过他们的争论，所以这里用"又"。我"呵呵"了一下，有热闹看当然好，我很-喜欢看人打架，而且认为那种拉架的人是世界上最虚伪的人，因为他们阻止了别人的情感，不能为了和谐就牺牲人的情感。有人说，看热闹是中国人的劣根性，我看这是自-卖自夸，这恐怕是人类的劣根性，当然还有个前提，如果这是劣根的话。中午有点热，这话有点跑题了。
>
> 那位朋友接着又问，"你怎么看？"我说，"innovate在探索架构，不认同interstage的态度，但认为他说的很有道理。"这话说的，真漂亮，自我感-觉挺良好的。那位朋友还想继续深入，我赶紧看看后面还有什么争论的，原来比昨天增加了不少。于是说还没来得及看完。看完再发表高见。

>
> 不过中午看了看，发现上面那个回答还是成立的，新的争论没有任何新意，都是老调重弹，无非一个说，我很牛，另一个说，其实你一点都不牛。
>
> 我还等着innovate继续说架构呢。在这个讨论的一开始，提出想混合两种架构，没有细说。虽然我也有些疑惑，但以为是自己的风格问题。
>

> 我认为整合自上而下和自下而上的两种架构不可行，因为他们本身就是矛盾的，如果说混合以后就对立统一了，那时理论层面的。在人们的实践过程中，要不就是自上而下-，要不就是自下而上。设计师完成架构，交给实施的人，说，咱们就按照这个来，先ods，再dw，ods
> 3nf建模，dw维度建模，咱们说定了，可就这么办了。ods自上而下，整出一个完美模型，dw，咱们自下而上，应用需要什么数据我们整什么数据。可从逻辑上分-析，这是为什么呀？

>
> 为什么要混合啊？似乎是为了弥补两种不同架构的缺点似的。
> 但他们缺点到底在哪儿？自上而下的方法是不是忽略了应用的需求？自下而上的方法是不是不能满足灵活的扩展？
> 这些缺点是不是真实存在着？他们各自是否有相应的补救方法？
>

> 对于这两种路线，我一直有一种感觉，自上而下的方法很完美，但是从来没有完美的人来设计他，乱。自下而上的方法很实际，但人们在执行的时候，经常缺乏原则指导，-乱。从我个人的喜好来说，我喜欢自下而上，喜欢演进的方法而不是一开始规划好的方法，这是我对自下而上的理解，但相信很多人有其他理解。
>
> 说了这么多，有个问题，这都是在这种架构是否合理的理论层面探讨，我已经多年没有实践，所以大家可以说这是在扯淡。innovate的架构是否适用，得通过实践-去证明。也请innovate继续将这个架构说的更细一点，这样也有东西可以探讨。
>
> 至于interstage的批评，我认为他基于成本的考虑很实际，很赞同。不过显然，这个说法已经被他其他的观点淹没，比如你牛什么之类，从来没见过你这种架构-之类的说法。我之前回答说，不认同他的态度，就是指他的语含讽刺的态度。不过后来我又想，也许，这未必不可能是个合适的态度，也许innovate由此而更加坚-定自己的架构探索之路。

>
> 所以，大家还是爱咋咋地吧。
>
> 2008/5/7 syfins <syf...@gmail.com>:
>
>
>
> > 哇
> > 场面越来越火爆了
> > 比QING那个太监贴强的不是一点半点
> > 抓紧时间保存

> > 防止斑竹删贴- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[tosimple]

大家不要再纠缠在混合架构怎么怎么着，

不如innovate兄，你把你前面提到的架构讲详细点？ 或者提供一份文档，大家都来讨论下。

通过讨论，验证来促进dw的建设！ 这才是讨论的真正意义所在。

On 5月1日, 下午12时05分, innovate511 <innovate...@gmail.com> wrote:

[innovate511]

劣根性肯定存在的，就像当初Inmon和Kimabll互不承认各自的优点和缺点，到现在其实他们具体做项目中已经在潜移默化地在利用对方的优点改善自
己的缺点，而发扬自己的优点。

架构的优势在于长久时间内才能看出其各自特点的优点和缺点，只有在历史过程中才能总结，单单看个别项目，一小段时间，能看出什么？就像一个哥们说，如果
客户对BI数据架构的需求就是使用1、2年，那需要复杂的架构么？答案是肯定的，他既然就是这么个定义，那么就做多大的事情，采用普通多维模型建设足
亦，反正1年之后人家就会重新规划。

那么对于整个业界健康发展，就需要"站在巨人的肩膀上"，吸取人家20年多年的建设经验和教训，没必要重复人家90年代走的过程，慢慢摸索，何不直接用
人家的经验教训，结合我们自身实际情况去循序渐进地建设架构呢？

架构的作用只有当时间越长，需求越多样和复杂才能体验其优势，前提是企业想向这个好的方向去发展，而不是做一个BI需求再重新来这种暴发户式的思维。当
需求多样和复杂后，新的主题分析和应用可以利用可用的教基础的数据，而不是全面重新开发，耗费大量的存储、人力、时间去建设，大大降低开发成本，提升开
发效率，同时又能满足企业的一致、个性化分析共存。

而且有的人观点很可笑，好像我在忽悠什么的，其实我们只是在走人家走过来的，成熟的路而已，技术架构上并无创新，而大量的成功案例已经可以作为参考。就
像一个哥们说的，我们偏技术方面的，只是在追求更好满足客户需求的技术真理，并非是做商业炒作之辈。

至于具体架构细节，不可能讲得太详细，就像我在ITPUB写的一个帖子"细节决定核心竞争力"，也就是说，企业和个人的核心竞争力其实在一个大方向之下
的具体细节，细节到具体模型、ETL方案，数据流/层、具体数据、安全管理方案等等细节。

我也没必要强迫别人跳进我的思维去考虑问题，晚上我有时间从历史经验上来讨论，长久来看，混合架构的优势。老美从90年代开始，失败了很多次混合架构，
到现在的成熟方案，那过了10年，混合架构的具体优势在哪里？每个构件在10年这个期限内，是否都发挥着其必须的、应用的架构功能，还是有的架构根本不
需要呢？

奉劝想向客户推荐只能使用1、2年，或者2、3年架构方案的不要看，因为那不符合你们以及客户的需求，没必要搞那么严密的逻辑。

同时，混合架构的另外一个特点，就是四大主件都以接口形势存在，在初级可以是虚拟架构，我这里再次强调，并不需要客户一次性投资到位，只要2、3年内逐
步到位即可，为什么是2、3年？之后，我会讲四大组件的生命周期在实际项目中的表现（10年的变化）

On 5月8日, 下午1时12分, Qing <happys...@gmail.com> wrote:

> 呵呵，看来前段时间让很多人失望了，真是太对不住。不过这位兄弟说防止斑竹删贴，实在是对ttnn最大的侮辱。
>

> 早上刚上班，就有一位朋友msn上告诉我说，"那俩人又干起来了。"我们之前曾经讨论过他们的争论，所以这里用"又"。我"呵呵"了一下，有热闹看当然好，我很-喜欢看人打架，而且认为那种拉架的人是世界上最虚伪的人，因为他们阻止了别人的情感，不能为了和谐就牺牲人的情感。有人说，看热闹是中国人的劣根性，我看这是自-卖自夸，这恐怕是人类的劣根性，当然还有个前提，如果这是劣根的话。中午有点热，这话有点跑题了。

[innovate511]

看了很多回帖，觉得误会很大：
1。这个混合架构是成熟架构，国际上很多成功案例，只是逻辑非常严密，对架构技术要求高（对投资并不比普通架构要求高）
2。不是我在一起追求架构、创新什么的，而是想推广一个人家已经成熟的架构，我自己已经在3个行业实践过，其中2个行业设计过。（制造、零售和信贷行
业）
3。我并不是想成为XX，到处宣扬自己，只是想打破很多人的思维局限，居然很多人没听说过，彻底晕了，混合架构最初在90年代就提出的EDW+CDW架
构，到现在很多企业在潜移默化地结合着使用，只是没有感觉到而已。
4。混合架构的两大特点，第一是有EDW，这是区别只有多维模型的DW。第二有企业级的统一维度建模技术和数据集市，这是区别只有EDW+DM，或者只
有中心数据仓库，这种没有统一维度建模技术的架构。这是混合架构最明显的特点。

不知道我说明白没有，希望大家不要再说上面我提到的4点，你可以看我之前的所有帖子，都是这么说的，但不知道为啥都看成了，好像我在创造什么新架构、好
像我在忽悠新概念。

汗，我还没这么牛，真这样的话，我可以直接和Inmon、Kimball两大前辈对话了，说不定还可以和他们探讨。但实际上人家走过的桥比我走过的路还
多，我只有努力追赶，学习人家走过的经验和教训，能赶上一部分就很不错，还说创新呢。要说创新，只有个性化创新的可能，用人家成熟的技术和理念，更好地
满足我们的客户，如果片面追求大范围创新，或者理论创新，没有足够的实践和总结，只有到处碰壁的。

[interstage]

赞同你的建议，让innovate给出架构详细文档，让大家讨论，这也是我想学习的东西．其实在观念碰撞中，innovate也在改变，已经不讲目前大
行业或者小行业适用他的混合架构了，开始讲时间性了，１－３年不适合，至少５年，四大组件后是１０年．ＯＫ，我先谈谈时间对一个企业的价值所在．传统的
企业生存周期一般是３年，１０年以上企业很少，１００年企业就更少了．所以我们的企业家都想做＂百年企业＂，做＂百年企业＂的要素是什么，就需要企业文
化的建设．所以＂百年企业＂一定是有自己企业文化才能够达到．为什么这么说？如果把宗教称为企业的话，那它们是千年企业，统一的文化让你形成统一的工作
和生活方式，这样企业持续时间很久，达到百年，或者千年．而期间文化也是在变化和调整中的，以中国＂儒学＂为例子，汉武帝独尊儒家后，儒学成为国教，那
么２０００年内，儒学发生了什么变化，从两汉的经学，到东西晋的玄学，这是儒学的第一次反思和调整，接着隋唐后中国佛学的兴起，就是儒学和佛学的结合
物，到了宋明心学和理学的争论，以理学取胜，经历了几百年，所以这是儒学第三次反思，期间清的＂新汉学＂，只是插曲，到五四后，西学的兴起，文革对儒学
的再次批判，目前中国还没有形成结合西学方式的新儒学．这就是文化的变革，而科学技术的变革自３００年内速度之快速，远远超过文化的变革速
度．innovate的混合架构是属于文化还是科学技术，我目前有点逻辑混乱了，我建议innovate别说１０年，要说百年，这样立志创造＂百年企业
＂的企业家对innovate会趋之若骛，对于新儒学的形成看来innovate是任重道远

> > 帮助我们更好地使用好BIDW软件产品和工具、管理好、维护好我们的数据，而对于未来的新数据源和业务分析需求以及接口需求，都有个说法。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[interstage]

ＯＫ，既然你说ＤＷ混合架构不是你创新的，在国外用的很多，逻辑非常严密，国外已经成熟的架构，一定可以查到，我建议以＂ＤＷ架构＂或者＂ＤＷ混合架构
＂为关键字在google和baidu中进行查询，看看有没有比较详细的资料和权威文档，区别于ＣＩＦ架构和ＭＤ架构的可以称为架构的第三种架构，名字
叫＂混合架构＂或者其他（可能英文原意不是混合两字），如果有的话，我们真的误解了,我们学习一下，不能让innovate这么优秀的BIER沉冤，如
果没有第三种架构的权威解释，那就不能叫架构，应该叫实施方法中对于架构选择经验之谈，请大家帮忙查一查．谢谢
呵呵,但就是真的有,你的架构能支持企业10年,还是需要继续讨论的.

[interstage]

我查了一下,Federated data warehouse architecture有点类似"混合架构"的意思,原文如下,
Federated data warehouse architecture is a system that works with
numerous data mart systems, analytical applications, and operational
data stores. A federated DW architecture is a system that is composed
of multiple architectures.
Many experts will tell you that there are a number of advantages
to using a centralized data warehouse system. A federated data
warehouse architecture will share information among a number of
different systems. Critical master files will be shared, and the other
system will be able to use this information. The federated data
warehouse architecture will work with an ETL tool. The ETL tool will
host a meta data repository.
When many people first hear about a federated DW architecture, they
will often wander if it is the same as a bottom-up dimenison approach.
Though the transfer of common data is the same, the federated DW
architecture will have unique components that will hold feeds for
numerous types of data. These feeds will not be shared by other
components. The federated DW architecture has a data sharing system
which is not as clean as the bottom-up approach. In a federated DW
architecture, the shared information may be taken from the mid-section
of the system instead of the source. This architecture was designed to
be an orthodoxed solution.

There are a number of ways that a federated DW architecture can be
built. The first thing you can do is document the data warehouse
system that you're already using with an enterprise data warehouse
architecture. At the zenith of this system is a diagram that will show
you the numerous systems and meta data that is exchanged between them.
After you have done this, you will next need to document your current
data warehouse system based on the data flow. The data flow will come
from multiple sources, and it may also come from transformations or
meta data repositories. Each element will need to be rated based on
the quality and accessibility.

但按照"The federated data warehouse architecture will work with an ETL
tool. The ETL tool will host a meta data repository"来看,好象又不是独立的架构体系,是搞了
一个好的ETL产品,来实现对很多数据库的共享方式.
是不是不是这个文章,请innovate告之,实际的英文叫什么,谢谢.

[holly]

大概为了平息‘口水门’事件罢，511大师才免为其难否决‘创新说’；
但相对于墨守陈规的人来说，打破众人的局限本身就是一种创新；
何况，如果真的将‘创新’否决了，岂不是否决了自己－－‘Innovate511’(‘我要创新’之意)。

[interstage]

这点我不同意,Innovate本身就是"创新"的意思,而"创新"是我们不断认识和提高的动力,现在的争论,并不否定Innovate的创新意识,相
反是肯定的,争论的焦点在于,Innovate提出的这次"创新"总结究竟已经可以称为"架构"创新.或者还只说"方法论"创新,甚至只是对国外新"创
新"知识的国内推广. 如果否认BI的创新精神,那我觉得TTNN就失去了最大的功能,成为教课书了.所以,我一再和Innovate争论,大家一开始
觉得很"热闹",好象我不喜欢创新的,其实我这个人是最喜欢创新的,但我更喜欢通过大家不断提不同意见让"创新"的东西更加成熟或者归于本质.我一再
说,我最尊重的是那些为自己目的不断坚持和持续修正的人.