关于"实践性混合架构"继续讨论

[interstage]

对以前的争论做了阶段性总结,现在另起一个主题,innovate是否愿意就 "实践性混合架构"细节进行展开,从以下几点开始:
1,是否给出一个拓扑图,把各组件的关系清晰,各组件在"实践性混合架构"中是如何定义的,是否与CIF和MD中定义一样?
2,各组件的松耦合是如何定义,如何接口,是否可以通过流程定义随机变化,是否可以提升为"服务",符合SOA精神?
3,组件内的紧耦合是如何定义,如何管理的?
4,行业模型是属于单个组件,还是跨不同组件内的?

[innovate511]

1. 拓扑图早就有了, 在公司规划讨论会上经过多次修改已经取得了一致的意见,不过详细的图是公司财富, 不能外漏. 粗略的图可能讲不太清楚, 因
为考虑到不能和公司的版本有明显重复, 有机会讨论的时候再讲,而且我还不知道这个群怎么发图. CIF、MD当然使用成熟思想了，自己研究出路的话，
等于本来可以站在别人肩膀人看更远的，结果你想自己跳起来看更远，当然不够好，也不够现实了。

混合架构其实没有象Inmon,Kimball那样的明显定义, 只是现实项目中潜移默化地使用这个架构越来越多, 只是没有足够总结和归纳. 从一开
始来看,他们要么选择Inmon方案, 要么是Kimball方案, 但当需求满足不了后, 自然会想到一些补充方案来补充原来的不足, 比如
Inmon派的项目在几年之后可能潜移默化地将MD数据仓库化,同时企业统一维度模型化, 就用了Kimball派的思想. 反之, 当Kimball
派项目早期MD模型不够完善, 后来几年客户不但需要企业级细节数据查询需求,而且MD模型后期无法承受, 就会考虑EDW建设起来, 并支持MD的架
构重组. IBM公司是一直坚持混合架构的派系(和我说的这个不同,他们建议架构组件都同时上,而我的想法是架构升级到虚拟化,逐步实现,毕竟多数公司
现实情况不允许这样), 只是还未形成那么明显的理论.

2. 松偶合是指组件之间的相对独立性，他们的功能不同、不重复、各自完成自己分工。很多BIer喜欢灵活性架构，想怎么建就怎么建，到最后架构会怎
样？因为架构是管理方案，后来当然是没法管理了。ODS根据其模型特点：业务系统模型一致，那么可以充分做各种和业务系统相关的事情，并做一定的清洗并
为DW服务，也能EDI工作。EDW功能属于较长期的考虑，模型方面虽然设计方法接近ODS，当并不等于ODS，EDW需要行业标准化，也就是说你的模
型不符合行业标准，那么这个EDW就失去了基础架构的作用，迟早要做大修改，基础就跨掉了。CDW需要考虑企业统一维度，标准度量，但要考虑到数据集市
那边部门级个性化需求，于是辅助架构成为必然，有稳定的多维架构体系，才能更好为DM服务。DM属于面向最终使用的需求，于是模型会更多样性、维需求、
度量可能在不同部门之间有很多不同、退化维的产生、星型模型标准、为了满足效率，还需要汇总、建宽表等动作。是不是符合SOA精神，在建设更合理后，自
己就能体会到。如果很多朋友说我的各个组件的模型设计方案可以根据需求而随意变化，比如他想在CDW不统一维度建模，或者没有辅助架构体系，或者在
CDW就有大量汇总模型，那么当过多模型重复、功能不明确，1、2年就会陷入自己不标准的麻烦。至于其中很多细节，当然得自己去思考了。

3。紧偶合的定义很简单，内部模型之间功能标准化，不能随便变，上面提到过了。其次有的组件内部也需要分层或分域才方便管理，比如CDW的辅助模型最好
独立分一个域管理，这样既方便管理也方便以模型技术去思考。但辅助模型在统一维度模型里有关键作用，它是决定多维模型适应变化能力且是否坚固的关键因素
之一，他们和主题模型，维表、事实表紧密关联，当维定义和维组织层次变化时，是辅助模型去管理，而不是靠维表象变化维那样自己管理。总之，这里的辅助模
型不能和主题模型独立开来，因为一分开两者在整体看来，就什么都不是了，所以我说属于紧偶合，而四大组件之间可以独立分开地建设。

4. 如果说架构是立体的管理方案，那么行业模型属于平面的，以描述业务为主题的模型。无论是Teradata为代表的EDW模型，还是
Oracle,Sybase为代表的多维模型，他们都是面向主题的，这样才符合数据仓库定义嘛。至于他们是否跨不同组件，要看你的架构怎么设计。比如多
维的行业模型，如果你直接拿来用，你可以把行业模型直接拿来做CDW，甚至一个主题的话，数据集市也集成在这里。但当你有需求建统一的维度模型，有更多
主题需要建设，那么你的行业模型肯定不是万能的，需要扩展，于是行业模型需要经过一段时间认识到其业务本质后，分别分散到CDW和DM，根据多年总结出
来的CDW、DM的功能划分，将他们不同模型块按照他们的功能，分别放到CDW和DM，但别忘了模型的扩展哦，特别是我看了他们的辅助架构，明显不能满
足企业高速发展多变的需求，之后重新ETL并形成新的技术元数据（所以ETL工具还是很有优势，长远来看，手工编写ETL会遇到架构重组、模型变化等多
种元数据管理问题，较难管理）。

[life2008life]

有没有专门关于架构方面的论坛或者网站推荐一下?

 

---

life2008life

2008-05-09

---

发件人： interstage

发送时间： 2008-05-09 19:45:03

收件人： ttnn BI 观点

抄送：

主题： 关于"实践性混合架构"继续讨论

[life2008life]

有没有专门关于架构方面的论坛或者网站推荐一下?

 

---

life2008life

2008-05-09

---

发件人： interstage

发送时间： 2008-05-09 19:45:03

收件人： ttnn BI 观点

抄送：

主题： 关于"实践性混合架构"继续讨论

 

[interstage]

你看看他写的这个回答,这么空虚,动不动一个虚拟架构,这样的架构有一点原创性吗,太搞笑了. 以这样的答案,我估计TTNN上的70%的人都可以写出
来,大家都是原创专家.

On 5月12日, 上午8时31分, "life2008life" <life2008l...@126.com> wrote:
> 有没有专门关于架构方面的论坛或者网站推荐一下?
>
> life2008life
> 2008-05-09

[interstage]

1,拓扑图不愿意给,说是公司财富,说明连拓扑图也不是理论层面的东西,只有特定到某公司的,所以,不但连所谓的"架构"也没到理论层面的解释,连拓扑
图也不是理论层面,,我问的在它所谓"架构"中的各组件定义和与其他2大架构组件的区别,他说没定义明确(或者没总结),然后就说CIF和MD组件的问
题,真不知道他会不会正确的回答人家提出的问题,人家又不是再想听你对"架构"的评价,是让你展开一下,没让你评论,真是答非所问.OK,这个所谓
的"架构"目前是这样的现状,1,架构本身无理论定义,2,拓扑图本身无理论定义,3,架构中目前组件无理论定义. 那这个架构还剩下什么,哦,估计是
项目实施方法论和管理理论,他又对管理理论如此不屑,只剩下项目实施方法论,这样的东西能叫"架构",简直是对"架构"的侮辱
2,对松耦合的回答,他开始讲CIF和MD架构中组件(ODS-EDW-CDW-DM)的独立性和各自功能,奇怪的很呀,问题明明问他,组件间交互的接
口定义规则,和组件间交互的流程管理方式,他连这个问题都不知道如此回答.
3,对组件内紧偶合的回答,其实他2,3的回答稍微可以符合我3的问题,但我后面还有一句"组件的紧偶合是如何管理",就是问他各组件内部接口是不是有
统一管理方式还是不统一的,因为组件间松耦合需要统一的管理方式,组件内不一定,没回答,一直在需要组件内的功能和作用,难道ODS-EDW-CDW-
DM这些组件有什么功能,我们不知道,还需要你来讲
4,问题是"行业模型是属于单个组件,还是跨不同组件内的" 他回答说"架构是立体的管理方案，那么行业模型属于平面的",那就是说行业模型是跨组件
的,那回答第2个问题,跨组件的接口究竟是如何,符合SOA的精神的原理,是各个组件可以作为"服务"出现,那也就是说在跨组件内含行业模型的不同属
性,每个属性也可以单独以"服务"方式出现.

通过以上4个问题回答,对他的关于技术理解能力和交流能力,深表怀疑,这样的能力能单独原创"架构",实在无语.最好的方式是公开所谓成果,让TTNN
的人群策群力,完成这个架构.

> > 4,行业模型是属于单个组件,还是跨不同组件内的?- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[innovate511]

目前国内没有专门的讨论网站，国外的知名网站可以参考TDWI.org 或者dmreview.com， 里面出了主流架构介绍和讨论外，还有很多第三
种声音去比较和综合讨论，也有业界成功案例的简单介绍和评选。

[interstage]

总结一点,其实DW的经典矛盾就是"纬度"和"粒度"的矛盾,这个矛盾的存在导致架构需要找到适当的平衡点,所以就导致了包含"纬度"和"粒度"的组件
间的交互规则和管理方式,以及组件内的定义描述和规范化的描述, 然后再对这个管理和规则等进行组件定义等,这就是"架构"的本质, 在这个本质中已经
以技术方式包含了管理思路. 根据这个架构你在实施项目中,适当按照实际需要找到适合该公司的实施方法论,这样的项目是可能能够接近成功的.所以,我们
现在是讨论"架构"的本质,就是需要找到可以规范化被定义的东西.

他反复讲他架构中"ODS-EDW-CDW-DM"组件的好处,然后描述的功能和定义都不知所云,好象和2大架构中组件没本质区别,那我们希望的是组件
不变的前提下,是否在组件间的交互上有创新,然后看到了什么,我甚至怀疑什么样的技术是"松偶合"和什么样的技术是"紧藕荷",他也未必很精通,为什
么"松偶合"和"紧藕荷"的出现能产生"SOA"计算,也未必很深入.

让TTNN的人说说,那他的架构还剩下什么,方法论?经验之谈? 哎,真的无语了.我们对DW的治学如此不严谨.

> > - 显示引用的文字 -- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[interstage]

再次总结对应用性技术创新的要求,DW技术不是基础性创新,基础性就是数学,物理,化学这样基础性的东西,所以你可以不关注人的行为,企业的管理方式,
人机交互的层面,甚至这个研究者很"变态"也没关系,他只关注自然本质的东西,不会考虑社会性学科的东西.但应用性技术的创新,一定需要结合社会性学科
的东西搞出来,不是凭空出现的,所以和大家多交流,接受大家的质疑和盘问,都很正常,研究者的心态一定要平和,不能太敏感. 不能因为别人对你的应用
性创新提出质疑,就歇斯底里说"TTNN的所有人"都支持你,就我不支持,都反对我,说这话真是太搞笑了.