看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

[interstage]

今天微软最终收购了数据库设备供应商DATAllegro，而Teradata和Netezza是DATAllegro的主要对手，在加上传统的列式存
储的数据库Sybase IQ. 看来列式存储的数据库和数据仓库应用设备支撑数据集市或者CDW的时代已经来到．随之而来的，将是对传统ＤＷ模型和结
构的重新反思和定义．不知道新的ＤＷ模型出现能否支撑企业ＤＷ１０年以上．
而这种数据仓库新的应用到来，使我们在设计ＢＩ和ＤＷ变的相对简单了，就象＂山寨机＂一样，和传统数据库导入数据一样，原来模式下的一个查询需要２天现
在只需要２分钟了，我们对优化模型来提高速度的技能看来不是太需要了，那些天天叫嚣利用ＤＷ的模型设计来优化查询速度的牛人将越来越没有市场了．

[hunter]

好快啊！

是说interstage这么快就关注到了行业消息。。

我的消息一般都是论坛上看来的，好像比google快讯要及时

[interstage]

就象我在1年前看到三大独立BI厂商被收购后,就预测"列式存储的数据库"一定会成为DW建设的主流. 接下来我认为数据仓库应用设备将以硬件支持列式
存储数据库的并行技术,然后结合"云计算"的理念,使DW模型和BI展现对用户实施而言,变的越来越简单了. 看来这几年在数据仓库行业的洗牌越来越清
晰了.

[hunter]

是啊，以后用户按个绿色小按钮，成本下降5%（的可行报告立即出来），能到这个程度，BI也就大功告成了

呵呵，本回复有点灌水。

在web上的newgroup怎么都给我bbs的感觉。。

[syfins]

好象不大对头吧

Sybase IQ是在现有基于列存储的优秀压缩算法的基础上才进一步提出列存储的概念的


如果列存储真的那么神，应该各大厂商早就推广应用了

[innovate511]

神经病才会天天叫嚣拿数据模型去优化查询．对于查询方面的需求，是个做ＢＩ的都知道首先是数据库本身的能力，其次才是物理模型和查询手段的设计（如ＳＱ
Ｌ语句）．

至于优秀的ＤＷ／ＤＭ模型的本质作用，稍微深有体会的人，应该知道主要是两点，也是ＤＷ／ＤＭ模型设计的核心价值：
1.　业务整合与个性化分析的整合＼分离的科学结合，以便适应企业数据整合与针对性分析多方面需求的需要．数据整合是为了避免数据孤岛，而针对性分析需
要根据行业特点、公司实际情况、部门发展阶段的特点去设计，好的模型能兼顾多种需求，同时不过多使用存储空间，有效控制存储成本又能保证企业数据、信息
不丢失，历史变化基本都能捕捉到。
2.　面向变化，由于ＤＷ／ＤＭ模型依赖于行业特点与业务系统特点双重约束（有的业务系统是通用产品，有的业务系统是自己开发），意味着多种变数和不稳
定性．如果模型设计粗犷，意味着将来模型需要不断改变，模型改变意味着ＥＴＬ需要随着改变，数据质量不能长期保证不说，维护成本将成倍增加．已经有人开
始注意到维度模型中多种辅助模型设计方案的重要性了。

就不知道物理技术的改进和逻辑设计技术的发展和改进有何矛盾，难道物理技术改进了，逻辑设计技术就可以忽略不计了？优化查询这样的事情始终是ＤＢＡ这样
的纯技术性的工作，而ＤＷ的模型设计师要能熟悉怎样的物理设计算合理，这只是很小的一部分考虑问题，他们重点应该是以数据＋业务为中心，围绕两个核心本
质特点去考虑，逻辑严密且能应变尽可能多的变数，减少企业开发和维护成本，并保证更好的数据（信息）质量。

“利用ＤＷ的模型设计来优化查询速度的牛人”，难道是指专职ＤＷ方面的ＤＢＡ？

[interstage]

呵呵,太搞笑了,天天在吹嘘"数据模型"的牛人,居然提出"ＤＷ的模型设计师该是以数据＋业务为中心，围绕两个核心本质特点去考虑", 看来你真的
是"通才",数据你也牛,业务你也牛,你这2方面都牛了,那还谈了屁. 我们从头到尾还争了啥,争来争去,不就是你天天在吹嘘你的"数据模型"支撑企业
业务10年!! 在我眼里,你这个吹嘘"数据模型"的人,不就是指专职ＤＷ方面的ＤＢＡ,你还当你是谁呀,别以为公司给你一个名片,上面TITLE不
写"DBA",你就是一个业务牛人,一个专门通过"数据"来诠释业务管理理论的牛人.太牛比无极限了吧!!

[interstage]

呵呵，天天在吹嘘＂数据模型支撑企业业务发展１０年＂的人，居然说＂ＤＷ的模型设计师重点应该是以数据＋业务为中心，围绕两个核心本质特点去考虑＂，太
神奇了！！数据你也牛，业务你也牛，那我们还争什么，话都让你说，争来争去，不就是你所谓那个支撑企业业务发展１０年的＂数据模型＂．你真把你当成数据
和业务的双重牛人了．在我眼里不就是＂专职ＤＷ方面的ＤＢＡ＂！！！　别以为名片上的title不这么写，就自以为是了．你对着天空放箭，那肯定能命中
目标，还谈了啥．

On 7月27日, 下午11时27分, innovate511 <innovate...@gmail.com> wrote:

[Qing]

innovate这话说得有什么问题呢？围绕数据和业务为中心不是挺对的么，只要别抠字眼，就不会显得太神奇了。

 

这个逻辑是"一个人以什么什么为中心"，那么这个"什么什"么，就是这个人牛逼的地方。很奇怪的逻辑不是？

2008/7/29 interstage <buer...@gmail.com>

呵呵，天天在吹嘘＂数据模型支撑企业业务发展１０年＂的人，居然说＂ＤＷ的模型设计师重点应该是以数据＋业务为中心，围绕两个核心本质特点去考虑＂，太神奇了！！数据你也牛，业务你也牛，那我们还争什么...

[interstage]

列式存储的数据库是以软件的方式存在，而Sybase这样的小公司也不可能把列式存储的数据库发扬光大．而且数据仓库应用设备是以硬件的方式存在，所以
这２者结合就具备了很强的生命力，本次微软收购的DATAllegro，其主要对手是Teradata和Netezza，而不是Sybase IQ,看
来在列式存储的数据库和数据仓库应用设备领域，Sybase IQ也将被边缘化,就象和它的ASE一样．Sybase这样短视的公司只能这个宿命了．所
以在这个列式存储的数据库＋数据仓库应用设备领域，我相信象ＨＰ，ＩＢＭ，ＯＲＡＣＬＥ，微软这样的公司将会越来越关注和跟进．ＢＩ／ＤＷ领域未来会非
常清晰，ＤＢＡ＋业务人员的分工模式，就可以支撑操作性或实时性ＢＩ的应用，当分工变的清晰，变的简单的时候，应用的价值才会无穷，让那些既是＂数据＂
牛人，也是＂业务＂牛人的通才去哭吧，去幻想支撑１０年业务的＂数据模型＂吧．

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

[interstage]

围绕数据和业务为中心这话当然对呀，但这不是对着天空射箭，一定能命中目标．而且和他一直吹嘘的＂数据模型＂支撑企业业务１０年不是自相矛盾吗．而且数
据和业务本身是相辅相成的，说这种通话，没什么价值．和他坚持的牛比混合＂数据模型＂不符合．反正在我眼里，他就是一个ＤＷ的ＤＢＡ．别谈什么业务了．
好好谈点数据层面，把数据层面的逻辑搞搞透，每次出来说话，都是自相矛盾，一会＂数据驱动业务＂，一会＂混合数据模型支撑企业业务１０难＂，一会＂数据
和业务双中心＂，不象我，就一句＂业务驱动数据＂，仅此而已．

On 7月29日, 上午10时28分, Qing <happys...@gmail.com> wrote:
> innovate这话说得有什么问题呢？围绕数据和业务为中心不是挺对的么，只要别抠字眼，就不会显得太神奇了。
>
> 这个逻辑是"一个人以什么什么为中心"，那么这个"什么什"么，就是这个人牛逼的地方。很奇怪的逻辑不是？
>

> 2008/7/29 interstage <buer0...@gmail.com>
>
>
>
>
>
> > 呵呵，天天在吹嘘＂数据模型支撑企业业务发展１０年＂的人，居然说＂ＤＷ的模型设计师重点应该是以数据＋业务为中心，围绕两个核心本质特点去考虑＂，太神奇了！-！数据你也牛，业务你也牛，那我们还争什么...- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[Steven]

引申一下

暂且认同“看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来”你这种观点与断言，

那么在这种形势下，DBA应该要如何去做规划和设计呢，或者说DBA做规划和设计时的注意事项是什么？

 

太技术性了，可以展开讨论，但不一定强求，呵呵！

 

但可以设想一下新的分析思路，手段，方法，或者说DBA+业务人员的合作模式？

 

 

2008-07-29

---

Steven

---

发件人： interstage

发送时间： 2008-07-29  10:39:16

收件人： ttnn BI 观点

抄送：

主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

列式存储的数据库是以软件的方式存在，而Sybase这样的小公司也不可能把列式存储的数据库发扬光大．而且数据仓库应用设备是以硬件的方式存在，所以

这２者结合就具备了很强的生命力，本次微软收购的DATAllegro，其主要对手是Teradata和Netezza，而不是Sybase IQ,看

来在列式存储的数据库和数据仓库应用设备领域，Sybase IQ也将被边缘化,就象和它的ASE一样．Sybase这样短视的公司只能这个宿命了．所

以在这个列式存储的数据库＋数据仓库应用设备领域，我相信象ＨＰ，ＩＢＭ，ＯＲＡＣＬＥ，微软这样的公司将会越来越关注和跟进．ＢＩ／ＤＷ领域未来会非

常清晰，ＤＢＡ＋业务人员的分工模式，就可以支撑操作性或实时性ＢＩ的应用，当分工变的清晰，变的简单的时候，应用的价值才会无穷，让那些既是＂数据＂

牛人，也是＂业务＂牛人的通才去哭吧，去幻想支撑１０年业务的＂数据模型＂吧．

On 7月27日, 下午10时58分, syfins <syf...@gmail.com> wrote:

> > 晰了.- 隐藏被引用文字 -

>

> - 显示引用的文字 -

[raullew]

dba主要做与硬件设备和系统维护关系比较紧的设计和规划
比如存储\内存\备份等

On 7月29日, 上午10时56分, "Steven" <tanhm1...@gmail.com> wrote:
> 引申一下
> 暂且认同"看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来"你这种观点与断言，
> 那么在这种形势下，DBA应该要如何去做规划和设计呢，或者说DBA做规划和设计时的注意事项是什么？
>
> 太技术性了，可以展开讨论，但不一定强求，呵呵！
>
> 但可以设想一下新的分析思路，手段，方法，或者说DBA+业务人员的合作模式？
>
> 2008-07-29
>

> Steven

>
> 发件人： interstage
> 发送时间： 2008-07-29 10:39:16
> 收件人： ttnn BI 观点
> 抄送：
> 主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来
>
> 列式存储的数据库是以软件的方式存在，而Sybase这样的小公司也不可能把列式存储的数据库发扬光大．而且数据仓库应用设备是以硬件的方式存在，所以
> 这２者结合就具备了很强的生命力，本次微软收购的DATAllegro，其主要对手是Teradata和Netezza，而不是Sybase IQ,看
> 来在列式存储的数据库和数据仓库应用设备领域，Sybase IQ也将被边缘化,就象和它的ASE一样．Sybase这样短视的公司只能这个宿命了．所
> 以在这个列式存储的数据库＋数据仓库应用设备领域，我相信象ＨＰ，ＩＢＭ，ＯＲＡＣＬＥ，微软这样的公司将会越来越关注和跟进．ＢＩ／ＤＷ领域未来会非
> 常清晰，ＤＢＡ＋业务人员的分工模式，就可以支撑操作性或实时性ＢＩ的应用，当分工变的清晰，变的简单的时候，应用的价值才会无穷，让那些既是＂数据＂
> 牛人，也是＂业务＂牛人的通才去哭吧，去幻想支撑１０年业务的＂数据模型＂吧．
> On 7月27日, 下午10时58分, syfins <syf...@gmail.com> wrote:
>
>
>
> > 好象不大对头吧
>
> > Sybase IQ是在现有基于列存储的优秀压缩算法的基础上才进一步提出列存储的概念的
>
> > 如果列存储真的那么神，应该各大厂商早就推广应用了
>
> > On 7月26日, 下午8时56分, interstage <buer0...@gmail.com> wrote:
>
> > > 就象我在1年前看到三大独立BI厂商被收购后,就预测"列式存储的数据库"一定会成为DW建设的主流. 接下来我认为数据仓库应用设备将以硬件支持列式
> > > 存储数据库的并行技术,然后结合"云计算"的理念,使DW模型和BI展现对用户实施而言,变的越来越简单了. 看来这几年在数据仓库行业的洗牌越来越清
> > > 晰了.- 隐藏被引用文字 -
>

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

[interstage]

这个问题提的好，我喜欢．　这也是我一直在思考的，我个人觉得现代企业的＂扁平式＂组织管理方式能解决这个问题，因为ＩＴ技术的发展使这个组织管理方式
成为可能．而在单个业务实施和运营中我觉得＂持续改善＂的运营模式值得提倡．其实也不是什么新的分析思路，手段，方法，我个人认为就是一个决策和执行力
的结合问题，业务分析主要来自业务人员，执行来自双方的协同，通过ＰＤＣＡ环，我个人还是觉得可以理顺的．我一直认为ＢＩ其实没那么复杂，ＤＷ也没那么
复杂，我们把它搞复杂了，新的技术会让它变的简单的．

[Qing]

矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

 

说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？

 

"业务驱动数据"，几乎大家是认可的，但这是理想的。现实中，事情并不总是按照理想原则进行。有的地方搞数据的人很厉害，有的地方搞业务的人厉害，前者的做法，看起来几乎是从数据出发的，因为从业务是弱势。但如果这个搞数据很厉害的人就会完全忽略业务么？肯定不会，他也会说从业务出发，然而，具体的行动必然还是偏重数据的。

 

我觉得innovate站在自己架构师的角度评论数据跟业务，是应该的事情。让他不要谈业务，就跟让interstage不要谈数据，不要评价架构一样的道理。在以往的混合型dw架构论战当中，interstage已经指出这种架构的背景，这能够让人增长知识。不过，由此而否定innovate的思考，将重点放在他言辞的漏洞上面，未免有些不厚道吧。

 

2008/7/29 interstage <buer...@gmail.com>

..反正在我眼里，他就是一个ＤＷ的ＤＢＡ．别谈什么业务了．
好好谈点数据层面，把数据层面的逻辑搞搞透，每次出来说话，都是自相矛盾，一会＂数据驱动业务＂，一会＂混合数据模型支撑企业业务１０难＂，一会＂数据和业务双中心＂，不象我，就一句＂业务驱动数据＂，仅此而已．...

[Qing]

对于"列式存储..时代"的判断，可以注意一下现在数据仓库市场里面几家主要竞争对手的技术方案。

 

在这个领域，Teradata，netezza是领头的，其他几家，Vertica、IQ、Datallegro还有另外几家等都强调自己是列式存储。目前，后面几家还没有前两者的实力，而他们是不是列式存储呢？不是，至少从宣传上来看，不是。因此，他们是否会考虑将列式存储这种技术当作他们的未来？这可不是个小决定。

 

对于bi/dw的分工将变成dba+业务人员，这个说法很奇怪。或者可以给这两个老概念赋以新概念，dba是干什么的，传统的dba职责可能主要在数据库的维护方面，保证其稳定、快速使用。那么，数据库的逻辑设计、整体技术架构、分析建模这些事情都由谁来干呢？是dba吗？还是业务人员？都不是，那么就必然缺少某种角色来承担这些职责，dba+业务人员的模式显然太简单的。

如果是按照扁平化的组织趋势，设立中间环节当然是多了一层。不过我觉得这是两码事，职责和组织岗位还有点区别，扁平化并不是合并专业分工。

 

持续改善、pdca都是好的思想，可总是提这些概念也太空泛。比如改善，你凭什么改善，pdca，你凭什么计划，凭什么检查？如果回答是，根据数据反映出来的性能指标进行改善和计划，那么数据从哪里来？如何保证数据源的可靠性？如何保证数据源很容易获取到？那么就需要对数据有好的管理。如果这些事情是很专业的事情，就得又专业的人来干。这些事情复杂么？可以说复杂，也可以说不复杂。说不复杂，不就是一堆数据而已吗。说复杂，其中一个小小的环节就够折腾人的，为什么最后的报表数据对不上呢？哪儿出了问题了？

 

管理思想和技术架构是两个领域的事情，说我这个对，你那个不对（或者没有必要），说不通。

 

2008/7/29 Steven <tanh...@gmail.com>

引申一下

暂且认同"看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来"你这种观点与断言，

那么在这种形势下，DBA应该要如何去做规划和设计呢，或者说DBA做规划和设计时的注意事项是什么？...

[interstage]

变化是永恒的,所以某种意义上坚持"不放弃,不抛弃"的人很少见,一般的人都是在变化中快速调整自己的观念. 而真正让我佩服的人,都是坚持观念并不断
调整自己实现方式使观念实践成功的人.如果今天你提出观念,明天就变了,那这样的人不值我去尊重,这是"忽悠". 当然你可以说,从"数据驱动业务",
发展到"牛比数据模型可以支撑业务10年以上",再到"数据和业务是双中心",这是表达方式的变化,不是观念的变化.那我无语.
究竟是言语中表述的漏洞,还是观念的改变, 你可以自己去判断. 我的特点是,就观念的交流一直要谈深刻,不要怕得罪人.网络上交流,你也怕的话,那你
还能在实践中坚持什么观念,还不是人云亦云. 从"数据驱动业务"深刻点在哪里,是"500强企业的DW数据牛比,先有DW再有BI业务",但我交流中
没有发现任何这样的先例;"牛比数据模型可以支撑业务10年以上"深刻点在哪里,是所谓包含CDW的混合模型,但在交流我也没看到10年以上的支
撑;"数据和业务是双中心",深刻点在哪里,是不是他的混合模型又包含的业务逻辑了,那请他展开.
至于说牛人对企业运营过程业务水平如何,我真的没看出来,但我相信他在做DW项目实施中,项目实施的业务能力还是可以的,但这个DW项目实施的业务能力
和DW项目所内涵的企业运营业务能力其实相差很大,我现在也在努力学习中,不敢说很精通,但至少现代企业运营业务的表现方式很多情况下是靠数据表达出
来,所以依附在业务内涵中的数据是非常重要,但这个数据对DW的技术人员眼里能代表什么,可能什么都代表不了,不就是在一个字段或者一个计算汇总吗,你
能说这个技术人员是业务高手吗,显然不是,就象你不能说铸剑高手是使剑高手吧,分工不同,但如果没有使剑高手在使剑,铸剑高手都失业了,去改铸犁了.
我不是不让牛人谈业务,我是让牛人把那个所谓支撑企业10年以上业务发展的"混合数据模型"谈深刻,如果他说这个"混合数据模型"目前已经包含"业务模
型",当然可以让他谈业务,为什么不谈,我更喜欢谈.

On 7月29日, 下午1时22分, Qing <happys...@gmail.com> wrote:
> 矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而-对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

>
> 说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？
>

> "业务驱动数据"，几乎大家是认可的，但这是理想的。现实中，事情并不总是按照理想原则进行。有的地方搞数据的人很厉害，有的地方搞业务的人厉害，前者的做法，-看起来几乎是从数据出发的，因为从业务是弱势。但如果这个搞数据很厉害的人就会完全忽略业务么？肯定不会，他也会说从业务出发，然而，具体的行动必然还是偏重数-据的。
>
> 我觉得innovate站在自己架构师的角度评论数据跟业务，是应该的事情。让他不要谈业务，就跟让interstage不要谈数据，不要评价架构一样的道理。-在以往的混合型dw架构论战当中，interstage已经指出这种架构的背景，这能够让人增长知识。不过，由此而否定innovate的思考，将重点放在他言-辞的漏洞上面，未免有些不厚道吧。
>
> 2008/7/29 interstage <buer0...@gmail.com>
>
>
>
> > ..反正在我眼里，他就是一个ＤＷ的ＤＢＡ．别谈什么业务了．
>
> > 好好谈点数据层面，把数据层面的逻辑搞搞透，每次出来说话，都是自相矛盾，一会＂数据驱动业务＂，一会＂混合数据模型支撑企业业务１０难＂，一会＂数据和业务双-中心＂，不象我，就一句＂业务驱动数据＂，仅此而已．...- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[interstage]

对于"列式存储..时代",我认为是趋势,至少在最近主数据仓库不动的前提下,数据集市和CDW会采用这种方式.
关于"dba+业务人员"支撑BI/DW模式,目前来看,的确是简单了,但我相信未来这个DW项目的DBA的岗位职责和目前RDB的DBA的岗位职责会
有所不同,而业务人员掌握报表分析的能力,目前已经超过我们技术人员了,未来就是一个业务上岗的技能了.所以,这个模式也未必不可.可以探讨和展开.
至少,这种模式不会造成"忽悠".

On 7月29日, 下午1时52分, Qing <happys...@gmail.com> wrote:
> 对于"列式存储..时代"的判断，可以注意一下现在数据仓库市场里面几家主要竞争对手的技术方案。
>

> 在这个领域，Teradata，netezza是领头的，其他几家，Vertica、IQ、Datallegro还有另外几家等都强调自己是列式存储。目前，后-面几家还没有前两者的实力，而他们是不是列式存储呢？不是，至少从宣传上来看，不是。因此，他们是否会考虑将列式存储这种技术当作他们的未来？这可不是个小决定-。
>
> 对于bi/dw的分工将变成dba+业务人员，这个说法很奇怪。或者可以给这两个老概念赋以新概念，dba是干什么的，传统的dba职责可能主要在数据库的维护-方面，保证其稳定、快速使用。那么，数据库的逻辑设计、整体技术架构、分析建模这些事情都由谁来干呢？是dba吗？还是业务人员？都不是，那么就必然缺少某种角-色来承担这些职责，dba+业务人员的模式显然太简单的。

>
> 如果是按照扁平化的组织趋势，设立中间环节当然是多了一层。不过我觉得这是两码事，职责和组织岗位还有点区别，扁平化并不是合并专业分工。
>

> 持续改善、pdca都是好的思想，可总是提这些概念也太空泛。比如改善，你凭什么改善，pdca，你凭什么计划，凭什么检查？如果回答是，根据数据反映出来的性-能指标进行改善和计划，那么数据从哪里来？如何保证数据源的可靠性？如何保证数据源很容易获取到？那么就需要对数据有好的管理。如果这些事情是很专业的事情，就-得又专业的人来干。这些事情复杂么？可以说复杂，也可以说不复杂。说不复杂，不就是一堆数据而已吗。说复杂，其中一个小小的环节就够折腾人的，为什么最后的报表-数据对不上呢？哪儿出了问题了？

>
> 管理思想和技术架构是两个领域的事情，说我这个对，你那个不对（或者没有必要），说不通。
>

> 2008/7/29 Steven <tanhm1...@gmail.com>
>
>
>
> > 引申一下
> > 暂且认同"看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来"你这种观点与断言，
> > 那么在这种形势下，DBA应该要如何去做规划和设计呢，或者说DBA做规划和设计时的注意事项是什么？...- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[innovate511]

做人厚不厚道，Qing兄也不是第一次见识，我早就说过，不会在TTNN做任何争论，因为和不厚道的人争论，那需要脸皮厚才行，我办不到。

TTNN google群刚才打开一看，有人说
"(17:53:16) 说:
哇 TTNN上面又掐起来了
(17:59:52) 说:
两个人越吵越没档次了
(18:00:01) 说:
冷饭热炒
"
一看我就知道某些人又要说不厚道的话了，而且还有兄弟帮我说话，不然看着不会这么说，于是上TTNN来看看，果真如此。

顺便说一句，我赞同raullew 的观点，dba主要做与硬件设备和系统维护关系比较紧的设计和规划，比如存储\内存\备份等。如果搞BI的后台，是
DBA+业务人员，那么谁去结合数据库去为业务服务，业务人员能区分清楚各范式和多维模型的技术特点么？模型多了，业务人员能了解怎么整合能保证数据质
量如一且节省人力？然后谁开发ETL呢？（ETL开发是专业开发，有区别于其他企业数据库系统的独特流程和开发模式，绝大多数DBA做不好的） 。


真怀疑说"DBA+业务人员"的人是否认真做过整个数据仓库项目的各个细节，还是只是做项目管理，或者只去研究业务，再到处看点新技术了解点厂商的技术
皮毛，然后实际数据仓库项目的流程规范什么的都道听途说？

说实话，如果我再这么为这么业余的言论回帖，就太浪费时间了。各位有空继续讨论，只是希望TTNN不要由高端讨论落到BI&DW业务讨论去了。而且如果
不是某人在发帖的时候还不忘指桑骂槐的话，我才难得上来发帖。从上面几位兄弟的回帖来看，某些人的言论实在太业余了，实在不忍再看下去了，闪人，各位慢
慢聊。如果要说具体技术或分析感受，我会去其他地方开贴。

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

> 矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而-对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

>
> 说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？
>

[dwbier]

看两位老大发言虽然尖锐，但各有道理：）， 让小弟来说两句。

BIDW是需要half dba+half MBA的人，技术和业务都要有的，这样才能做到成功。
关注HP 的Neoview 中，准备干掉Teradata，从软硬件角度支持并行查询。为DW的建设提供了一个platform

支撑10年的业务模型也不是不可能，但前提是该企业的信息化建设和业务流程都比较成熟，否则再好的模型也扛不住业务的频繁变更和业务系统的变迁的。

今天的人只能猜测明天的人会分析些什么，但决不能知道明天的人真的会分析什么，当维度不断添加的时候，FACT也就不能承受如此之重了。

一套好的建模方法能够支撑10年的业务，但一套模型挺难的。

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

[life2008life]

呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;

 

鼓吹自己的观点没有问题,我也经常向一帮同事鼓吹我的一套理论;但是如果单从自己的那个角度去否定别人的观点,我就得从人格成熟度的角度去看你这个人了!

 

不太同意QING的所言,我们就是在找一种'平衡';数据和业务之间的平衡;我们在项目中也经常会见到一种情形:我们的业务专家想出一个想法,很美,然后DBA跑过来将它否决,然后我们就需要一起坐下来找一种平衡,是牺牲这个功能呢,还是另找方法去实现?不同的项目,不同的处理方法;这点一点问题也没有;

 

innovate兄,我很佩服你的架构能力,你总是在尝试着给出一个整体的解决方案,也看得出你丰富的项目经验;但是你又何必非要去用自己的经验去打破别人的想法呢,的确会有这样的人:技术和业务兼牛,其实他也在找一种平衡,只是这种平衡缺少了争吵,因为在他这里,他已经做出了相对'平衡'的一个选择;不要去否认这种可能.

 

interstage兄,我不想骂你,是因为我自己和你挺象,呵呵,顺便抬高一下自己;但是我肯定吵不过你;我想说的是,别把自己看得太重,别把我们的系统太重,如果你觉得想靠我们的系统去改进客户的管理结构,恭喜你,你的项目怕是已经要失败一半了;客户选择我们的系统通常是为了两个目的:其一,最基本的一个功能,简单化流程,方便自己的工作;其二,很多客户面临着自己的业务问题,无法解决,他们需要我们的咨询能力,我们的业务帮助;但是只是业务!如果你要涉及管理的话,那是管理咨询的事情;

 

送二位一句话:我们都是尝试着去解决问题的人,不要让自己成为别人的问题;

 

 

 

2008-07-29

---

发件人： innovate511

发送时间： 2008-07-29 22:01:57

收件人： ttnn BI 观点

抄送：

主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

 

[raullew]

偷偷问一句,什么是管理咨询?干些啥?

On 7月29日, 下午11时32分, "life2008life" <life2008l...@126.com> wrote:
> 呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;
>
> 鼓吹自己的观点没有问题,我也经常向一帮同事鼓吹我的一套理论;但是如果单从自己的那个角度去否定别人的观点,我就得从人格成熟度的角度去看你这个人了!
>

> 不太同意QING的所言,我们就是在找一种'平衡';数据和业务之间的平衡;我们在项目中也经常会见到一种情形:我们的业务专家想出一个想法,很美,然后DBA-跑过来将它否决,然后我们就需要一起坐下来找一种平衡,是牺牲这个功能呢,还是另找方法去实现?不同的项目,不同的处理方法;这点一点问题也没有;
>
> innovate兄,我很佩服你的架构能力,你总是在尝试着给出一个整体的解决方案,也看得出你丰富的项目经验;但是你又何必非要去用自己的经验去打破别人的想-法呢,的确会有这样的人:技术和业务兼牛,其实他也在找一种平衡,只是这种平衡缺少了争吵,因为在他这里,他已经做出了相对'平衡'的一个选择;不要去否认这种-可能.
>
> interstage兄,我不想骂你,是因为我自己和你挺象,呵呵,顺便抬高一下自己;但是我肯定吵不过你;我想说的是,别把自己看得太重,别把我们的系统太重-,如果你觉得想靠我们的系统去改进客户的管理结构,恭喜你,你的项目怕是已经要失败一半了;客户选择我们的系统通常是为了两个目的:其一,最基本的一个功能,简-单化流程,方便自己的工作;其二,很多客户面临着自己的业务问题,无法解决,他们需要我们的咨询能力,我们的业务帮助;但是只是业务!如果你要涉及管理的话,那-是管理咨询的事情;
>
> 送二位一句话:我们都是尝试着去解决问题的人,不要让自己成为别人的问题;
>
> 2008-07-29

>
> 发件人： innovate511
> 发送时间： 2008-07-29 22:01:57
> 收件人： ttnn BI 观点
> 抄送：
> 主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来
>
> 做人厚不厚道，Qing兄也不是第一次见识，我早就说过，不会在TTNN做任何争论，因为和不厚道的人争论，那需要脸皮厚才行，我办不到。
> TTNN google群刚才打开一看，有人说
> "(17:53:16) 说:
> 哇 TTNN上面又掐起来了
> (17:59:52) 说:
> 两个人越吵越没档次了
> (18:00:01) 说:
> 冷饭热炒
> "
> 一看我就知道某些人又要说不厚道的话了，而且还有兄弟帮我说话，不然看着不会这么说，于是上TTNN来看看，果真如此。
> 顺便说一句，我赞同raullew 的观点，dba主要做与硬件设备和系统维护关系比较紧的设计和规划，比如存储\内存\备份等。如果搞BI的后台，是
> DBA+业务人员，那么谁去结合数据库去为业务服务，业务人员能区分清楚各范式和多维模型的技术特点么？模型多了，业务人员能了解怎么整合能保证数据质
> 量如一且节省人力？然后谁开发ETL呢？（ETL开发是专业开发，有区别于其他企业数据库系统的独特流程和开发模式，绝大多数DBA做不好的） 。
> 真怀疑说"DBA+业务人员"的人是否认真做过整个数据仓库项目的各个细节，还是只是做项目管理，或者只去研究业务，再到处看点新技术了解点厂商的技术
> 皮毛，然后实际数据仓库项目的流程规范什么的都道听途说？
> 说实话，如果我再这么为这么业余的言论回帖，就太浪费时间了。各位有空继续讨论，只是希望TTNN不要由高端讨论落到BI&DW业务讨论去了。而且如果
> 不是某人在发帖的时候还不忘指桑骂槐的话，我才难得上来发帖。从上面几位兄弟的回帖来看，某些人的言论实在太业余了，实在不忍再看下去了，闪人，各位慢
> 慢聊。如果要说具体技术或分析感受，我会去其他地方开贴。
> On 7月29日, 下午1时22分, Qing <happys...@gmail.com> wrote:
>
>
>

> > 矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而--对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

>
> > 说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？
>

> > "业务驱动数据"，几乎大家是认可的，但这是理想的。现实中，事情并不总是按照理想原则进行。有的地方搞数据的人很厉害，有的地方搞业务的人厉害，前者的做法，--看起来几乎是从数据出发的，因为从业务是弱势。但如果这个搞数据很厉害的人就会完全忽略业务么？肯定不会，他也会说从业务出发，然而，具体的行动必然还是偏重-数-据的。
>
> > 我觉得innovate站在自己架构师的角度评论数据跟业务，是应该的事情。让他不要谈业务，就跟让interstage不要谈数据，不要评价架构一样的道理。--在以往的混合型dw架构论战当中，interstage已经指出这种架构的背景，这能够让人增长知识。不过，由此而否定innovate的思考，将重点放在他-言-辞的漏洞上面，未免有些不厚道吧。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[life2008life]

偷偷得回答一句,其实我也不知道

 

---

life2008life

2008-07-30

---

发件人： raullew

发送时间： 2008-07-30 09:18:47

[Qing]

这次讨论不是出来一个dba+业务人员的分工模式观点么？不知道这点是interstage随口提出来的，还是经过一番考虑。

而关于架构的问题，其实质内容确实没有讨论清楚。但按照现在这种气氛，不知道能不能讨论的下去，走着瞧吧。

 

以前一次跟interstage聊，他批评ttnn一个不好的地方，就是有些观点不敢深入探讨，可能是怕伤了感情，总是隔了一层什么东西不能捅破。这个批评挺好的，我们通常的讨论确实缺少穷追猛打。也可能这是中国人的传统美德，非常含蓄、谦逊（虽然这是面子上的谦逊，而骨子里面都是互相瞧不起），但一旦撕开脸了，这些面子都可以抛弃，对方任何方面的东西，包括观点本身，包括人格，包括职业，都成了靶子。

 

对于interstage的言辞，其实我基本持欣赏态度，对于他的咄咄逼人，我认为这是风格问题。所以，只是我担心他继续用这样的论调来讨论，会将真实的观点吓跑，因为很多讨论并非围绕主题进行的。但也许，这种担心是多余的，我不知道。

 

life提到，不同意我的所言，我不知道你是不同意我哪部分的所言。

 

关于"平衡"的说法，我说这是废话。废话虽然一般是正确的，但总是说就没有必要。寄希望能有进一步"如何平衡"的讨论。

 

2008/7/29 life2008life <life20...@126.com>

呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;

...

[interstage]

本来这个帖子的主题是:微软最终收购了数据库设备供应商DATAllegro,看来软件大企业认可了列式存储和数据仓库应用设备的方式,在未来DW的建
设中,列式存储和数据仓库应用设备将会被大规模应用,至少在主数据仓库不动的前提下,数据集市和CDW可以采用这种方式.这样大大减低了DW的实施门
槛,就象"山寨机"的兴起一样,由于门槛降低使很多企业DW的项目实施不需要太高深的DW模型,也不太过分需要所谓的牛人了.某种意义上DBA+业务人
员模式也能实施DW/BI项目了.
没想到,微软的这个收购所未来的趋势又刺激某些人的"牛比混合数据模型",其实,以前在技术上讨论这么久,这个"牛比混合数据模型"根本就是一个名称,
连架构拓扑图,各组件的定义都没看到.现在又借题发挥,显得很无辜的样子,把"牛比混合数据模型"加入了业务模型,你既然这个牛,到是展开这个模型,别
老是讲这个模型给企业能带来什么好处或者讲它有什么功能?只要你按照传统架构拓扑图,各组件的定义,组件间的"松耦合"接口定义,组件内的"紧耦合"接
口定义,这些描述清楚,我们自然会理解它能给企业带来的好处和应有的功能.
至于Qing说我的风格可能会把那些"真实的观点"吓跑,这点不用担心,只要你有真才实学,把自己的观念讲透,针对别人的质疑描述清楚,自然我会认可
的.在DW上,很多人提出的观念我都接触过,都深刻探讨过,有的观念最后说服了我,当然也有观念事实证明是项目经验,肯定不是所谓通用模型,

On 7月30日, 上午9时43分, Qing <happys...@gmail.com> wrote:
> 这次讨论不是出来一个dba+业务人员的分工模式观点么？不知道这点是interstage随口提出来的，还是经过一番考虑。
> 而关于架构的问题，其实质内容确实没有讨论清楚。但按照现在这种气氛，不知道能不能讨论的下去，走着瞧吧。
>

> 以前一次跟interstage聊，他批评ttnn一个不好的地方，就是有些观点不敢深入探讨，可能是怕伤了感情，总是隔了一层什么东西不能捅破。这个批评挺好-的，我们通常的讨论确实缺少穷追猛打。也可能这是中国人的传统美德，非常含蓄、谦逊（虽然这是面子上的谦逊，而骨子里面都是互相瞧不起），但一旦撕开脸了，这些-面子都可以抛弃，对方任何方面的东西，包括观点本身，包括人格，包括职业，都成了靶子。
>
> 对于interstage的言辞，其实我基本持欣赏态度，对于他的咄咄逼人，我认为这是风格问题。所以，只是我担心他继续用这样的论调来讨论，会将真实的观点吓-跑，因为很多讨论并非围绕主题进行的。但也许，这种担心是多余的，我不知道。

>
> life提到，不同意我的所言，我不知道你是不同意我哪部分的所言。
>
> 关于"平衡"的说法，我说这是废话。废话虽然一般是正确的，但总是说就没有必要。寄希望能有进一步"如何平衡"的讨论。
>

> 2008/7/29 life2008life <life2008l...@126.com>
>
>
>
> > 呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;

[interstage]

这位兄弟你说"支撑10年的业务模型也不是不可能，但前提是该企业的信息化建设和业务流程都比较成熟，否则再好的模型也扛不住业务的频繁变更和业务系统
的变迁的。",这句话,我很认同. 但我要问的是,在中国,你觉得存在这个的企业吗.在中国数据库大规模使用才多少年. 这样的企业存在,一定是"企业
文化"做支撑,才有企业管理,最后才成熟的业务流程,有了成熟的业务流程才进入成熟的信息化模型层面. 你认为仅仅凭参与实施过国外一个DW的项目的
人,能深刻理解这些,并创造性的搞出支撑中国企业10年发展的模型吗,实在太空中楼阁吧,因为中国的企业文化很没到达到这个境界,你作为末端的IT人居
然达到这个境界,太神奇了吧. 而且就象互联网发展一样,现在在中国成功的都是c2c(copy to china),国外生存并发展起来的模式如
google,ebay,yahoo等模式个个在中国失败,为什么,就是中国文化和别人不一样,那怕你真的修炼到把国外的成功DW模型精华到极限,也不
太可能符合中国企业特点,更何况,仅仅参与实施了国外的这个一个DW项目,太把自己当神了.

[interstage]

呵呵,这个兄弟太抬举我了,我没有什么牛比模型,也没什么牛比系统,更不指望我有什么系统去改进客户管理结构. 真是因为我发现目前的BI/DW项目无
法满足企业的实际情况,才认为应该从引入企业业务管理模型角度入手去改造我们传统的BI/DW实施模式.这几年下来,我学习了很多企业业务管理模型,认
为戴明的品质管理和今明正井的"持续改善"在现代企业越来越有生命力,使现代企业正在走向"扁平化组织架构".因此把这个业务模式引入到我们DW/BI
的实施方法上.仅此而已,所以,我从来没提出过什么牛比模型,所以也不存在太看重自己的系统,有人也许会说我一直在推广"持续改善",这个不是我的创
造,是大师,只是,我想把它引入到BI实施而已.

On 7月29日, 下午11时32分, "life2008life" <life2008l...@126.com> wrote:

> 呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;
>
> 鼓吹自己的观点没有问题,我也经常向一帮同事鼓吹我的一套理论;但是如果单从自己的那个角度去否定别人的观点,我就得从人格成熟度的角度去看你这个人了!
>

> 不太同意QING的所言,我们就是在找一种'平衡';数据和业务之间的平衡;我们在项目中也经常会见到一种情形:我们的业务专家想出一个想法,很美,然后DBA-跑过来将它否决,然后我们就需要一起坐下来找一种平衡,是牺牲这个功能呢,还是另找方法去实现?不同的项目,不同的处理方法;这点一点问题也没有;
>
> innovate兄,我很佩服你的架构能力,你总是在尝试着给出一个整体的解决方案,也看得出你丰富的项目经验;但是你又何必非要去用自己的经验去打破别人的想-法呢,的确会有这样的人:技术和业务兼牛,其实他也在找一种平衡,只是这种平衡缺少了争吵,因为在他这里,他已经做出了相对'平衡'的一个选择;不要去否认这种-可能.
>
> interstage兄,我不想骂你,是因为我自己和你挺象,呵呵,顺便抬高一下自己;但是我肯定吵不过你;我想说的是,别把自己看得太重,别把我们的系统太重-,如果你觉得想靠我们的系统去改进客户的管理结构,恭喜你,你的项目怕是已经要失败一半了;客户选择我们的系统通常是为了两个目的:其一,最基本的一个功能,简-单化流程,方便自己的工作;其二,很多客户面临着自己的业务问题,无法解决,他们需要我们的咨询能力,我们的业务帮助;但是只是业务!如果你要涉及管理的话,那-是管理咨询的事情;
>
> 送二位一句话:我们都是尝试着去解决问题的人,不要让自己成为别人的问题;
>
> 2008-07-29
>

> 发件人： innovate511
> 发送时间： 2008-07-29 22:01:57
> 收件人： ttnn BI 观点
> 抄送：
> 主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来
>
> 做人厚不厚道，Qing兄也不是第一次见识，我早就说过，不会在TTNN做任何争论，因为和不厚道的人争论，那需要脸皮厚才行，我办不到。
> TTNN google群刚才打开一看，有人说
> "(17:53:16) 说:
> 哇 TTNN上面又掐起来了
> (17:59:52) 说:
> 两个人越吵越没档次了
> (18:00:01) 说:
> 冷饭热炒
> "
> 一看我就知道某些人又要说不厚道的话了，而且还有兄弟帮我说话，不然看着不会这么说，于是上TTNN来看看，果真如此。
> 顺便说一句，我赞同raullew 的观点，dba主要做与硬件设备和系统维护关系比较紧的设计和规划，比如存储\内存\备份等。如果搞BI的后台，是
> DBA+业务人员，那么谁去结合数据库去为业务服务，业务人员能区分清楚各范式和多维模型的技术特点么？模型多了，业务人员能了解怎么整合能保证数据质
> 量如一且节省人力？然后谁开发ETL呢？（ETL开发是专业开发，有区别于其他企业数据库系统的独特流程和开发模式，绝大多数DBA做不好的） 。
> 真怀疑说"DBA+业务人员"的人是否认真做过整个数据仓库项目的各个细节，还是只是做项目管理，或者只去研究业务，再到处看点新技术了解点厂商的技术
> 皮毛，然后实际数据仓库项目的流程规范什么的都道听途说？
> 说实话，如果我再这么为这么业余的言论回帖，就太浪费时间了。各位有空继续讨论，只是希望TTNN不要由高端讨论落到BI&DW业务讨论去了。而且如果
> 不是某人在发帖的时候还不忘指桑骂槐的话，我才难得上来发帖。从上面几位兄弟的回帖来看，某些人的言论实在太业余了，实在不忍再看下去了，闪人，各位慢
> 慢聊。如果要说具体技术或分析感受，我会去其他地方开贴。
> On 7月29日, 下午1时22分, Qing <happys...@gmail.com> wrote:
>
>
>

> > 矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而--对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

>
> > 说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？
>

> > "业务驱动数据"，几乎大家是认可的，但这是理想的。现实中，事情并不总是按照理想原则进行。有的地方搞数据的人很厉害，有的地方搞业务的人厉害，前者的做法，--看起来几乎是从数据出发的，因为从业务是弱势。但如果这个搞数据很厉害的人就会完全忽略业务么？肯定不会，他也会说从业务出发，然而，具体的行动必然还是偏重-数-据的。
>
> > 我觉得innovate站在自己架构师的角度评论数据跟业务，是应该的事情。让他不要谈业务，就跟让interstage不要谈数据，不要评价架构一样的道理。--在以往的混合型dw架构论战当中，interstage已经指出这种架构的背景，这能够让人增长知识。不过，由此而否定innovate的思考，将重点放在他-言-辞的漏洞上面，未免有些不厚道吧。- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[innovate511]

Qing兄，我觉得目前TTNN还没法深入讨论，国内其他论坛或者圈子也不行。原因有如下几点：
1. 目前业界环境还不够成熟。上次我忘了在itpub还是某个地方提到过，目前国内BI整体是追求大而全，而非精而专。就拿诸位来说，有多少人是数年
来一直专注于一个方向，比如数据挖掘，数据仓库（只关注DW和ETL）或是某一个行业业务精深分析？我想我们都做过BIDW各个方向，在企业需要的情况
下，需要做啥就做啥，或者觉得数据挖掘牛，我就转做挖掘，说行业业务分析或项目管理才能长久，就抛弃以前的细节转做另外的角色。

试想如果不从一个角色沉寂下来深挖其更多价值，如何能在当今社会分工如此严密的情况下，做出符合国庆的创新和深入挖掘价值呢？有人问数据仓库后台没直接
价值，挖掘啥深入价值？其实你的模型相对稳固，可扩展和操作性强和方便，ETL严密减少数据质量问题和流程可控性，以此降低企业风险以及开发、维护成
本，那就是最大的价值，当然这也得得到企业高层认可和支持才行，需要点时间。

试想几乎每个人都只做1、2年ETL，1、2年报表开发，1、2年数据建模，再1、2年数据挖掘，顺便1、2年业务分析，也许还有1、2年纯项目管理，
这样的"完人"在具体的业务点结合技术点时，能做出什么深入的判断和理解，又是经验的简单重复和一些想象中的深入？如果把这种经验拆分来看，都是很常见
的经验和总结，深入下去又能有什么结论？

个人觉得方向应该相对固定地发展才合理，比如数据仓库为后台一族，包括数据建模和ETL，辅以小半个DBA和小半个业务分析师的额外知识和经验，方可精
深下去。同理，以业务分析为主，以行业业务分析+数据挖掘，结合BI工具，辅以数据模型知识和经验，方可深入下去。

虽说本人以前也做过展现和分析，而现在的工作中，业务方面工作也占到了一定比例，但是我认准了方向仍然以后台为主，而且还有很多东西可以深入下去。

2. 讨论的时候，常以自己的非专业的角度看待专业问题，实在没法讨论下去，各位现在可能还有耐心，估计要不了多久兴趣也会减弱。如果说DBA+业务人
员的模式在操作BI项目的话，那么这个DBA应该不仅熟悉数据库和操作系统，还熟悉行业模型、ETL开发、测试等，而这个业务人员应该熟悉一些统计知识
和方法，熟悉各种展现工具，同时要熟悉数据模型才行。不过实在想不到会有哪家公司或者哪个专家这么定义过DBA的职能定义应该这样，而我们的业务人员职
能应该那样。这样脱离实际的想象，反正我是没法讨论下去的。

如果说我的观点比较悲观，那么我们试目以待，3年之内，国内的专业论坛和圈子都难以建立深入讨论的氛围和环境，也许市场成熟，人员发展机制成熟些后，情
况会有所好转。

On 7月30日, 上午9时43分, Qing <happys...@gmail.com> wrote:

> 这次讨论不是出来一个dba+业务人员的分工模式观点么？不知道这点是interstage随口提出来的，还是经过一番考虑。
> 而关于架构的问题，其实质内容确实没有讨论清楚。但按照现在这种气氛，不知道能不能讨论的下去，走着瞧吧。
>

> 以前一次跟interstage聊，他批评ttnn一个不好的地方，就是有些观点不敢深入探讨，可能是怕伤了感情，总是隔了一层什么东西不能捅破。这个批评挺好-的，我们通常的讨论确实缺少穷追猛打。也可能这是中国人的传统美德，非常含蓄、谦逊（虽然这是面子上的谦逊，而骨子里面都是互相瞧不起），但一旦撕开脸了，这些-面子都可以抛弃，对方任何方面的东西，包括观点本身，包括人格，包括职业，都成了靶子。
>
> 对于interstage的言辞，其实我基本持欣赏态度，对于他的咄咄逼人，我认为这是风格问题。所以，只是我担心他继续用这样的论调来讨论，会将真实的观点吓-跑，因为很多讨论并非围绕主题进行的。但也许，这种担心是多余的，我不知道。

>
> life提到，不同意我的所言，我不知道你是不同意我哪部分的所言。
>
> 关于"平衡"的说法，我说这是废话。废话虽然一般是正确的，但总是说就没有必要。寄希望能有进一步"如何平衡"的讨论。
>

> 2008/7/29 life2008life <life2008l...@126.com>
>
>
>
> > 呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;

[Steven]

借题发挥一下

传统的BI/DW实施模式是什么？

引入“扁平化组织架构”这种业务模式到DW/BI实施上后BI/DW的实施模式又是什么样的？

 

能否就这两种模式进行阐述，比较！

 

 

2008-07-31

---

Steven

---

发件人： interstage

发送时间： 2008-07-30  21:42:06

收件人： ttnn BI 观点

抄送：

主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

呵呵,这个兄弟太抬举我了,我没有什么牛比模型,也没什么牛比系统,更不指望我有什么系统去改进客户管理结构. 真是因为我发现目前的BI/DW项目无

法满足企业的实际情况,才认为应该从引入企业业务管理模型角度入手去改造我们传统的BI/DW实施模式.这几年下来,我学习了很多企业业务管理模型,认

为戴明的品质管理和今明正井的"持续改善"在现代企业越来越有生命力,使现代企业正在走向"扁平化组织架构".因此把这个业务模式引入到我们DW/BI

的实施方法上.仅此而已,所以,我从来没提出过什么牛比模型,所以也不存在太看重自己的系统,有人也许会说我一直在推广"持续改善",这个不是我的创

造,是大师,只是,我想把它引入到BI实施而已.

On 7月29日, 下午11时32分, "life2008life" <life2008l...@126.com> wrote:

> 呵呵,是我说两个人越吵越没档次的,我出来主动认错!吵,不是坏事;很多新鲜的观点都是吵出来的,但是吵成人生攻击就没有意思了;

>

> 鼓吹自己的观点没有问题,我也经常向一帮同事鼓吹我的一套理论;但是如果单从自己的那个角度去否定别人的观点,我就得从人格成熟度的角度去看你这个人了!

>

> 不太同意QING的所言,我们就是在找一种'平衡';数据和业务之间的平衡;我们在项目中也经常会见到一种情形:我们的业务专家想出一个想法,很美,然后DBA-跑过来将它否决,然后我们就需要一起坐下来找一种平衡,是牺牲这个功能呢,还是另找方法去实现?不同的项目,不同的处理方法;这点一点问题也没有;

>

> innovate兄,我很佩服你的架构能力,你总是在尝试着给出一个整体的解决方案,也看得出你丰富的项目经验;但是你又何必非要去用自己的经验去打破别人的想-法呢,的确会有这样的人:技术和业务兼牛,其实他也在找一种平衡,只是这种平衡缺少了争吵,因为在他这里,他已经做出了相对'平衡'的一个选择;不要去否认这种-可能.

>

> interstage兄,我不想骂你,是因为我自己和你挺象,呵呵,顺便抬高一下自己;但是我肯定吵不过你;我想说的是,别把自己看得太重,别把我们的系统太重-,如果你觉得想靠我们的系统去改进客户的管理结构,恭喜你,你的项目怕是已经要失败一半了;客户选择我们的系统通常是为了两个目的:其一,最基本的一个功能,简-单化流程,方便自己的工作;其二,很多客户面临着自己的业务问题,无法解决,他们需要我们的咨询能力,我们的业务帮助;但是只是业务!如果你要涉及管理的话,那-是管理咨询的事情;

>

> 送二位一句话:我们都是尝试着去解决问题的人,不要让自己成为别人的问题;

>

> 2008-07-29

>

> 发件人： innovate511

> 发送时间： 2008-07-29 22:01:57

> 收件人： ttnn BI 观点

> 抄送：

> 主题： Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

>

> 做人厚不厚道，Qing兄也不是第一次见识，我早就说过，不会在TTNN做任何争论，因为和不厚道的人争论，那需要脸皮厚才行，我办不到。

> TTNN google群刚才打开一看，有人说

> "(17:53:16) 说:

>   哇 TTNN上面又掐起来了

>   (17:59:52) 说:

>   两个人越吵越没档次了

>   (18:00:01) 说:

>   冷饭热炒

> "

> 一看我就知道某些人又要说不厚道的话了，而且还有兄弟帮我说话，不然看着不会这么说，于是上TTNN来看看，果真如此。

> 顺便说一句，我赞同raullew 的观点，dba主要做与硬件设备和系统维护关系比较紧的设计和规划，比如存储\内存\备份等。如果搞BI的后台，是

> DBA+业务人员，那么谁去结合数据库去为业务服务，业务人员能区分清楚各范式和多维模型的技术特点么？模型多了，业务人员能了解怎么整合能保证数据质

> 量如一且节省人力？然后谁开发ETL呢？（ETL开发是专业开发，有区别于其他企业数据库系统的独特流程和开发模式，绝大多数DBA做不好的） 。

> 真怀疑说"DBA+业务人员"的人是否认真做过整个数据仓库项目的各个细节，还是只是做项目管理，或者只去研究业务，再到处看点新技术了解点厂商的技术

> 皮毛，然后实际数据仓库项目的流程规范什么的都道听途说？

> 说实话，如果我再这么为这么业余的言论回帖，就太浪费时间了。各位有空继续讨论，只是希望TTNN不要由高端讨论落到BI&DW业务讨论去了。而且如果

> 不是某人在发帖的时候还不忘指桑骂槐的话，我才难得上来发帖。从上面几位兄弟的回帖来看，某些人的言论实在太业余了，实在不忍再看下去了，闪人，各位慢

> 慢聊。如果要说具体技术或分析感受，我会去其他地方开贴。

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

>

>

>

> > 矛盾不是人的天性么？反倒是刻意保持言语一致性令人怀疑，一个人的想法随时都会变，表达方式也随时在变。说一句"业务驱动数据"，也同样可以看作是一种废话。而--对于"数据和业务双中心"的说法，也可以是另一种理解，即在数据和业务之间平衡。

>

> > 说到"平衡"这个词，就跟说辩证法一样，很废话。任何事情都有对的一面，也有不对的一面。平衡呢，就是在一个端点和另一个端点之间找到一个点，这个点在哪儿？

>

> > "业务驱动数据"，几乎大家是认可的，但这是理想的。现实中，事情并不总是按照理想原则进行。有的地方搞数据的人很厉害，有的地方搞业务的人厉害，前者的做法，--看起来几乎是从数据出发的，因为从业务是弱势。但如果这个搞数据很厉害的人就会完全忽略业务么？肯定不会，他也会说从业务出发，然而，具体的行动必然还是偏重-数-据的。

>

> > 我觉得innovate站在自己架构师的角度评论数据跟业务，是应该的事情。让他不要谈业务，就跟让interstage不要谈数据，不要评价架构一样的道理。--在以往的混合型dw架构论战当中，interstage已经指出这种架构的背景，这能够让人增长知识。不过，由此而否定innovate的思考，将重点放在他-言-辞的漏洞上面，未免有些不厚道吧。- 隐藏被引用文字 -

>

> - 显示引用的文字 -

[jun.sky]

看了你的陈述，有如下问题：
1、列式存储的数据库是以软件的方式存在 这句话怎么理解？我的理解是，
比如sybase iq这种产品，已经将数据分布固化到segment 上了，而segment的实质就是
硬盘上的很多block，这应该算是一种硬件的存在吧？为什么会是软件的存在呢？
2、数据仓库应用设备有什么样的特点？比如teradata和sybase iq比起来在硬
件实现上又有什么优势之处？
请解读一下，谢谢
-----邮件原件-----
发件人: tt...@googlegroups.com [mailto:tt...@googlegroups.com] 代表 interstage
发送时间: 2008年7月29日 10:39
收件人: ttnn BI 观点
主题: Re: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到来

列式存储的数据库是以软件的方式存在，而Sybase这样的小公司也不可能把列式存储的
数据库发扬光大．而且数据仓库应用设备是以硬件的方式存在，所以
这２者结合就具备了很强的生命力，本次微软收购的DATAllegro，其主要对手是
Teradata和Netezza，而不是Sybase IQ,看
来在列式存储的数据库和数据仓库应用设备领域，Sybase IQ也将被边缘化,就象和它的

[interstage]

不好意思,这段时间一直在做上线运营工作,到TTNN时间越来越晚,越来越少,突然发现有BIer很多问题问我,我要一个一个解释以下:
列式存储的数据库类似sybase iq,teradata(自从独立于NCR,可以支持NT和UNIX),这种产品,是软件方式,我们在采购中,不但
要采购这类软件,还要采用一些磁盘阵列,主机等硬件.
这里讲的硬件方式,主要是讲数据仓库应用设备(data warehouse appliances)。数据仓库应用设备就是能够进行大型数据仓
库相关大规模并行处理操作的软硬捆绑套件。这些产品的设计就是想利用连接到网格的大量硬件节点的超强处理能力，最大限度的提升相关数据管理系统的功能，
以便创造出超高效率的工作负荷和搜索功能。简而言之，就是能够在相对较短的时间完成TB级的数据的装载和搜索任务。这个概念要解释起来也很简单：其中一
个节点充当分配器或管理器节点，当从调用程序里发布一条SQL语句时，分配器就会把它分割成若干的物理子查询(数量的多少由系统的节点数和数据在节点间
的物理分布决定)，并在所有的节点间分配这些子查询。这些节点并行处理这个查询需求，并把执行结果返回到分配器节点。然后由分配器节点整理结果，如果需
要还要进行终极筛分，最后把结果返回到请求程序。而大规模并行处理系统已经盛行了相当长一段时间了，而且运作非常成功。不过，大多数情况下，大规模并行
处理系统的实施成本太高，而且必须配备专门的技术人员才有可能最大限度优化其效率。所以数据仓库应用设备(软硬捆绑套件,所以我们称为硬件方式,来区别
单独选型列式存储的数据库软件)就应用而生了,主要的好处在于:

　　1,较低的拥有总成本(TCO)：与前一代的大规模并行处理系统相比，数据仓库应用设备价格要便宜多了，只是传统大规模并行处理系统成本的一个零
头。

　　2,较高的可扩展性：对于企业的钱袋来说，这是数据仓库应用设备系统最重要的一个分化指标。企业可能一开始会构建一个五到十个节点的小规模数据仓库
(类似网格方式,或者刀片方式)，然后根据需求和预算的提高再增加新节点和额外的存储设备。

　　3,黑盒子：就像绝大部分的大规模并行处理系统一样，数据仓库应用设备系统不需要IT部门分开购买硬件和数据管理系统，不需要他们去安装数据库管理
系统(比如sybase iq,teradata)，不需要再动用一个资深数据库管理员的时间去优化系统所有节点的性能。数据仓库应用设备之所以称之为
应用设备就是因为它是一个完整的设备包。除了数据库的物理设计和实现所有指定节点的效率最优化等问题外，IT人员不必担心其他任何问题。其实某种意义上
来将我们不应该把数据仓库应用设备当作一个硬件解决方案，它是真正的混合应用设备。

　　4,处理海量数据：数据仓库应用设备系统就是为了更容易处理超TB级数据而设计的。因此，如果你手头上要处理的数据量非常大，而又没那么多资金的
话，数据仓库应用设备可能是你最佳的选择。

　　5,高度灵活性：你想构建一个企业级数据仓库吗?没问题。你已经有了一个企业级数据仓库，又想构建一个小型的数据集市?没问题。你还没有构建数据仓
库解决方案的经验，但又想尝试构建一些新的数据仓库?都没问题。不管是哪种要求，你都不用付出太多。

　　6,实时数据仓库的实现：数据仓库应用设备支持目前流行的实时和近实时数据仓库的构建。

　　虽然以上的这些优点显而易见，不过凡事都得看两面。主要的缺点当然就是企业用来存储和支持节点的数据中心物理容量和能源容量的问题了。有一些企业其
数据中心没有足够的空间和/或能量来维持庞大的系统，要知道为四十、六十甚至更多的节点提供足够的空间、能源和冷却设备会是个大问题。

　　我们应该仔细的分析企业的短期和长期需求，再决定用哪套合适的工具(是采用列式存储的数据库管理系统的软件方式为主,还是采用数据仓库应用设备系统
的硬软件混合体为主)来达到一举两得的效果。不管采用什么工具,目前大型软件公司如HP,IBM,Oracel,微软都在他们原来主数据仓库管理系统
(就是EDW组件,一般会采用传统的RDB系统来做支撑)不变的情况下,实施CDW组件和DM组件的开始选择列式存储的数据库管理系统或者数据仓库应用
设备系统这类产品,因此这次微软的收购就是说明了这个趋势.这种组件产品选择的变化,深刻影响了原来体制下传统的DW架构理论和模型机制,导致这个变革
的加速.所以这些DW模型需要重新兼容这些产品的特性了.而其实反过来也可以讲,这些产品是在研究了DW架构和模型基础上归纳成产品了.这就是我所说的
未来DW的门槛越来越底,就象联发科一样使一个草根手机时代的到来,一个草根DW时代也将来到.

[raullew]

多节点的问题在于宕机几率比性能增长还要快
我昨天补数据从3点补到24点，今天又出问题，周六又跟补数据干上了，真他妈干！

[郭军]

看了interstage的回复，不得不感叹其架构知识的资深！但我仍然有一些疑问：
列式存储和行式存储之间的主要区别，主要体现在存储设备上数据的分布形式
上；而数据分布其实是一个逻辑的概念，体现在物理上就是正负电位的分布；而正负电
位如何分布又是由软件来驱动的；
不管是sybase iq数据仓库服务器还是oracle数据仓库服务器，其均是一个软
硬件的捆绑体，所不同的只是oracle是将数据按一行接一行的顺序往bock上写，同一条
记录尽可能分布在一个block上，而同一个对象表尽可能在同一个segment上；而sybase
iq数据仓库服务器是将数据按列分布，一列数据存储在一个segment上，一条记录如果
不只一个列的话肯定是分布在不同的segment上，而这样的数据分布是由oracle或
sybase iq按照其各自写数据的机制来决定的。
在此你也提及你所讲的数据仓库应用设备是一个软硬捆绑套件，而经过我前面
的分析知道sybase iq数据仓库服务器也是一个软硬件捆绑体，所不同的是前者是套件
（纯种），后者不是套件（杂交），就象现在的品牌机和组装机之间的区别一样，但这
个不应该成为是软件方式还是硬件方式的判断标准，对不？
另外，对于数据仓库应用设备和传统型的大规模并行处理系统的本质区别希望
你能够讲的更清楚，更实质化一点。我暂时列一些问题如下：
相对于传统型的大规模并行处理系统如ORACLE RAC来说，它是如何保证较高的
可扩展性的？按照我的理解，随着子节点的增加，分配器或管理器节点的负载会越来越
来，用于通信的代价会越来越高，如何解决这个问题的？
你所说的数据仓库应用设备又是如何更好地支持目前流行的实时和近实时数据
仓库的？
期盼你的回复，谢谢！

-----邮件原件-----
发件人: tt...@googlegroups.com [mailto:tt...@googlegroups.com] 代表 interstage

发送时间: 2008年8月2日 2:09
收件人: ttnn BI 观点
主题: Re: 答复: 看来列式存储的数据库和数据仓库应用设备支撑数据仓库时代已经到
来

不好意思,这段时间一直在做上线运营工作,到TTNN时间越来越晚,越来越少,突然发现有
BIer很多问题问我,我要一个一个解释以下:
列式存储的数据库类似sybase iq,teradata(自从独立于NCR,可以支持NT和UNIX),这种
产品,是软件方式,我们在采购中,不但
要采购这类软件,还要采用一些磁盘阵列,主机等硬件.
这里讲的硬件方式,主要是讲数据仓库应用设备(data warehouse appliances)。数
据仓库应用设备就是能够进行大型数据仓
库相关大规模并行处理操作的软硬捆绑套件。这些产品的设计就是想利用连接到网格的
大量硬件节点的超强处理能力，最大限度的提升相关数据管理系统的功能，
以便创造出超高效率的工作负荷和搜索功能。简而言之，就是能够在相对较短的时间完
成TB级的数据的装载和搜索任务。这个概念要解释起来也很简单：其中一
个节点充当分配器或管理器节点，当从调用程序里发布一条SQL语句时，分配器就会把
它分割成若干的物理子查询(数量的多少由系统的节点数和数据在节点间
的物理分布决定)，并在所有的节点间分配这些子查询。这些节点并行处理这个查询需

[raullew]

oracle没有解决节点通信问题
列存储也只能搞定简单业务
所以，几十T以后搞MapReduce吧

[interstage]

你通过这种展开，其实也未不可，但如果展开硬件的存储和主机层面，这不是我的专长了，毕竟我是搞数据库软件出身的，我的回答如下，仅供参考：
１，本贴主题中的＂列式存储的数据库＂这个是纯软件的角度来谈，当然在实施ＤＷ项目中，你肯定需要采用主机和存储设备来支撑，所以在谈＂列式存储的数据
库＂，它的比较对象是与传统的ＲＤＢ软件，就是以行存储的数据库，所以谈的是在ＤＷ项目中的选择数据库管理软件作为ＤＷ组件（主要是ＥＤＷ组件，ＣＤＷ
组件，ＤＭ组件），从这次收购的引出的未来趋势上来看，我认为是ＣＤＷ组件，ＤＭ组件在今后选择＂列式存储的数据库＂作为数据库将越来越清晰，而传统的
ＥＤＷ组件在很长一段时间内还将是行存储的数据库的选择．当然这些以＂列式存储＂为特点的数据库产品，在支持多点查询（主要是查询，更新能力比较差）各
自有自己的风格．
２，至于数据仓库应用设备(data warehouse appliances)，其实关键字是＂appliances＂，我们把它翻译成＂设备＂其
实基于ＤＷ的端到端解决方案，而本次收购的主角DATAllegro其实是该数据仓库应用设备代表，很多数据仓库应用设备，不管其建立基础是行式还是列
式数据库，都具有一个共同点，那就是它们有一个大规模并行处理(massively parallel processing)的无共享架构。大规模并
行处理，意味着查询负载被分布到了许多处理器或节点上，这些处理器和节点通常都位于运行Linux系统的标准硬件上。无共享则意味着每个节点都是独立
的，都拥有属于自己的存储器。如此一来，我们既获得了极高的性能，同时又不必花钱去买那些在传统数据仓库中常用到的大功率对称多处理器。应用设备逐渐盛
行的另一原因，在于它们比传统数据仓库更容易部署和维护，后者需要进行繁琐的调试和优化。利用这一诱人的优势，包括ParAccel公司、Sybase
公司以及Vertica公司在内的列式数据库厂商都推出了基于第三方硬件的软硬件捆绑产品。而传统我们见到的ＯＲＡＣＬＥ　ＲＡＣ是share
disk的方式，所以，我们一些技术人员很自然会以ＲＡＣ节点技术方式来质问数据仓库应用设备所支撑的节点技术，这个也是业界目前数据库领域最大的争
论，就是
share disk(oracle 为代表)和share nothing（IBM为代表）之争，所以这个争论，我相信不是我们技术人员在ＴＴＮＮ上
能争论清楚的．
３，关于企业在评估数据仓库应用设备或列式数据库时，应该先考虑一下自己的实际需求：到底是想更换整个企业数据仓库呢，还是仅仅想卸载复杂的数据密集型
分析查询，以达到提高性能，推迟企业数据仓库升级的目的。如果是因为前者，其实列式存储产品不适合涉及到太多数据特征的行式密集型查询（以ＥＤＷ组件为
代表模式）。
４，对于专题DM和用于支持复杂查询及超大数据容量的CDW组件而言，应用设备和列式数据库无疑是非常优秀。以NYSE 为例。用了3台
Netezza Performance Server来取代3个基于Oracle数据库的100TB数据仓库。在传统DW中耗时长达26小时的复杂查
询任务，如今只需要2.5分钟；而以往耗时7分钟的简单查询现在只用5秒钟就可完成。
５，关于应用设备和列式数据库支持实时数据仓库的说法，是从实时数据仓库定义展开的，实时数据仓库是两种事物的组合：实时行为和数据仓库。实时行为是一
种即时发生的行为。行为可以是任何事情，如超市中小商品的销售行为。一旦行为完成，就有关于它的数据。数据仓库捕获有关商业行为的数据，而实时数据仓库
在商业行为发生时就捕获数据。当商业行为完成时，相关数据就已经进入到数据仓库并且能立即使用。换句话说，实时数据仓库是这样一个系统，只要行为发生、
数据变得可用时，就能从中获得信息。而传统的ＤＷ架构由于ＥＴＬ，ＯＤＳ，ＥＤＷ，ＣＤＷ，ＤＭ等组件的存在，从原生态数据到ＢＩ展开的数据，很难作到
实时行为和数据仓库的结合．所以应用设备和列式数据库出现在分析数据集市层面的快速查询和计算能力，使这个实时数据仓库成为可能．
以上回答是否回答了你的问题，请继续讨论．

On 8月2日, 下午6时22分, 郭军 <flysky0...@gmail.com> wrote:

[interstage]

还有，你千万别说＂不得不感叹其架构知识的资深！＂，在ＴＴＮＮ上，我已经被牛人定义为＂只会谈谈业务的非专业ＤＷ人士＂，你把我这样的＂非专业ＤＷ人
士＂说成＂其ＤＷ架构知识的资深！＂，那那个牛人的ＤＷ架构知识不是用＂资深＂２字来说明他的架构能力，我估计只能用１个字＂神＂来诠释他的架构能力．
象我这样的＂非专业ＤＷ人士＂谈ＤＷ架构知识，他一般是不屑于评价的．当然你可以继续通过提问让他展开他所谓支撑企业业务发展１０年的那个牛比的＂混合
数据架构＂，反正我这样＂非专业ＤＷ人士＂向他提问关于他的这个架构问题，他已经明确表态是不会也不屑于回答了．

On 8月2日, 下午6时22分, 郭军 <flysky0...@gmail.com> wrote: