北京年会和关于数据仓库板块的思考

原创于2008年01月12日，2009年10月18日迁移至此。

说实话我认为是一个喜欢研究技术的人，虽然我的Oracle、Sybase、SQLServer等数据库水平实在很菜，甚至Powerbuilder,VB,Java水平也不过尔耳；在火车上是和hanson、yxyup、yeahy三位Oracle高手一起入住的；在08年会上新认识的warehouse、zhouwf0726、赵宇；包括ningoo、blue_prince、xzh2000、piner在内的淘宝的一系列的DBA；yangtingkun、D.C.B.A、rollingpig这样的牛人；其他DBA像老朱、diablo2虽然是DB2或者已经不做数据库了；还有棉花糖这个好学生；ora-600这个职业讲师兼自由人；已经当了官的QQ小鸟；HP的yanggq、fusnow、skyjiang；当然还有eygle和biti这两位超级牛人，虽然他们不一定认识我；Oracle板块的斑竹我应该认识一半有余了；总的来说给我的感觉他们的数据库功底非常的深厚，Oracle的DBA队伍越来越庞大，人才济济；这一点看看数据库的分会场就知道了，这一块也是itpub安身立命的基础，也是打败各个其他论坛的基石，衷心希望itpub能够坚持下去，DBA能够一代一代的传承下去；环顾过去数据仓库只有我和flywolf2000两个人参会，未免太形单影只了，当然数据仓库并不是我们两个可以代表的。

 

当然除了itpub之外还有一些其他活跃的论坛和群组，像TTNN、dwway、ChinaBI、BI立方体－商业智能社区、CSDN的子板块。

 

http://www.dwway.com/好像那里需要发表原创文档才能成为正式会员，反正我发了一篇之后就没去过了，要求门槛太高，变成阳春白雪了，对于普及和发展阶段的BI/DW并非什么好事。

http://www.ChinaBI.com/网站口气很大，不过似乎并不活跃，那里的文章转载居多（当然也包括我的，曾向我约稿过，后来就没怎么谈了），所有的博客访问量比我多一些，以介绍案例为主

http://www.bicubes.com是个刚成立的网站，最近折腾的比较厉害，刚开始在itpub上做广告，还因为转载文章的缘故，在数据仓库板块PK了一阵子，着是热闹了一阵子，没理会他，最近联合TTNN组织过两次BIER的聚会。曾经想注册看看虚实，无奈新浪邮箱注册不了也就算了，不过更新很慢。

http://groups.google.com/group/ttnn算是个比较火的BI/DW讨论群组了，每个月定期会出一本电子杂志，创办人独立支撑了两年(确实很不容易)，务虚和耍嘴皮子的太多而真正做架构的很少，很多东西流于概念，谈不到一起，后来我也就是定期去下载杂志，不怎么发言了。道不同不相为谋，没准别人认为我层次太低呢。

http://www.csdn.net 上面的数据仓库板块可以忽略不谈了

 

itpub的数据仓库板块现状又如何呢？

只能说数据仓库板块依托于itpub数据库板块和社区功能情况还不至于太糟糕；搞数据库的往往自以为数据库和性能优化可以解决一切数据仓库问题，自然不屑于这些有些理想化和过于理论化的东西，像盛大好像就是如此花了很多时间请外面的人讲解数据仓库基本知识；ebay倒是有一批专职数据仓库人员的，可相当部分是HP过去的，因为ebay的数据仓库就是HP的人在维护和实施的；呵呵，不知道淘宝的数据仓库如何；itpub上讨论具体工具使用的太多，还处于初级阶段，当然这和数据仓库自身的特点很有关系，BI/DW包括了数据库、OLAP、报表展现工具、ETL工具等等，每种又包括若干主流工具，数据仓库解决方案可能由几十种组合方式，大家疲于奔命只好学习工具而不能自拔了；稍微有些数据仓库工作经验的就开始务虚了，讨论这个概念那个概念的，以为概念能解决任何问题；有些人过分拘泥于数据仓库的概念，对数据仓库、数据库、OLAP、BI本身的概念纠缠不休，殊不知数据仓库本身就在不断的发展过程中；有些人还对业务驱动还是技术驱动的第一驱动力产生了兴趣，曾经在数据仓库板块发动了一场轰轰烈烈的辩论；新概念只能是为了吸引新的用户群体发展客户群来用的，不管怎么数据仓库的本质没有改变。

 

说了这么多，那数据仓库究竟是什么呢？

数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”。

也就是说数据仓库是个数据集合，它的载体依然是数据库，不过和大多数联机在线系统（OLTP）在目标用途特性上已经有了本质的区别。

联机事务处理系统(OLTP)，也称为面向交易的处理系统，其基本特征是顾客的原始数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果。衡量联机事务处理系统的一个重要性能指标是系统性能，具体体现为实时响应时间。OLTP系统的主要特点就是事务处理、面向应用、反映当前情况。

数据仓库的目的则是为了解决在信息技术(IT)发展中存在的拥有大量数据、然而有用信息贫乏(Data rich-Information poor)的问题。如何把数据转换成信息，进一步把信息转换成知识的过程。数据仓库的特点则是面向主题、集成性—企业数据框架、历史性、稳定性。

说到底数据仓库不是一门纯粹的技术，不是数据库不是OLAP不是ETL甚至不是BI工具，从数据库角度来看，良好的物理设计和性能优化只是其手段而不是目的，数据仓库允许数据的冗余允许长时间的运行；它应该是一种体系结构，它的核心是在于对于数据的整合，通过抽丝剥茧把企业原始数据进行集成、归类、分析，从而提供了企业决策分析需要的KPI；同样它也是一个过程ETL对数据进行集成、整合、清洗、转换和加载，并在实践和与用户确认中不断的校验，其最终目标是为了达到整合企业信息信息，提供决策支持。

 

因此数据仓库本身应该包括两个问题：逻辑结构和物理结构

物理的就是数据仓库架构问题，一套好的解决方案应该是有弹性的，ODS区、明细数据数据区、汇总数据区（也叫事实表）；以及数据库、OLAP、报表工具、ETL处理一个都不能少；数据库作为数据仓库的载体，而且是超大数据集合的存储，其性能和分层设计自然是重中之重；OLAP关系到多维立方体和数据的展现效率和效果；报表工具是用户的门户，良好的用户体验也是系统的关键；ETL呢是数据仓库最为关键的地方。ETL既可以是纯粹的数据库脚本也可以是ETL工具本身的可视化界面，ETL工具本身提供了屏蔽各个异构系统之间的复杂接口，提供了集成转化抽取装载的一致化接口，甚至提供了性能优化的途径，也相应的也减化和弱化了DBA的工作。当然ETL工具的优化无论如何也比不上DBA的优化结果。某种程度上仍然需要数据仓库DBA的参与。

逻辑的主要是指业务问题，如果只是数据迁移和数据的集中，达不到决策支持的目标，便失去了数据仓库的意义，因此业务问题才是数据仓库项目成败最重要的关键环节，所以必须有商务领域知识专家、IT专家的角色(就是通常所说的咨询顾问)和甲方的积极参与，这些人往往具备比较资深的行业背景，具备丰富的独立实施该行业信息系统建设的经验，了解该行业最先进和通用的标准和规范，同时在结合现有企业信息系统的基础上，以及融合企业发展战略的基础上，提出当前企业的业务模型，来帮助企业提高决策支持分析能力。这一点我不是行业专家，不敢谈及太多。

 

年会的时候，Sybase公司的卢总找flywolf2000和我谈起邀请Ralph Kimball来华授教的问题，想通过itpub了解和调查一下用户可接受的前景，毕竟邀请大师来也是一笔不小的费用。如果能和it168联合举办也不失为宣传it168和itpub的一种策略，至于其他的论坛还没有足够的财力来支撑这笔联办费用。Infosys曾经邀请过数据仓库的鼻祖Bill Inmon到印度培训了两周，留下了很多的宝贵资料。在我看来他们没有什么本质的区别，只是细节和实施方法上有些差别而以，大概是因为我读的书确实不够多的缘故。

 

尽管数据库和数据仓库本质上和要求是不同的，而令我感到惭愧的是我工作了很多年，Oracle从使用到现在也经历了8个春秋了，却还不如那些论坛里面学了2年Oracle的人厉害，也许Oracle数据库管理确实不是我的专长，但是学好数据库无论如何对数据仓库的物理架构设计还是有着至关重要的影响的，有一技之长总是好的，像我总是飘忽在博而不精、杂而不专的陷阱之中；我希望能够像各位Oracle牛人学习，并在此再向那些深耕于Oracle的DBA表示深深的敬意！