说实话我认为是一个喜欢研究技术的人，虽然我的 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.bicubes.com 是个刚成立的网站，最近折腾的比较厉害，刚开始在 itpub 上做广告，还因为转载文章的缘故，在数据仓库板块 PK 了一阵子，着是热闹了一阵子，没理会他，最近联合 TTNN 组织过两次 BIER 的聚会。曾经想注册看看虚实，无奈新浪邮箱注册不了也就算了，不过更新很慢。
http://groups.google.com/group/ttnn 算是个比较火的 BI/DW 讨论群组了，每个月定期会出一本电子杂志，创办人独立支撑了两年 ( 确实很不容易 ) ，务虚和耍嘴皮子的太多而真正做架构的很少，很多东西流于概念 ，谈不到一起，后来我也就是定期去下载杂志，不怎么发言了。道不同不相为谋，没准别人认为我层次太低呢。上面的数据仓库板块可以忽略不谈了
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 表示深深的敬意！
本文转自baoqiangwang51CTO博客，原文链接：http://blog.51cto.com/baoqiangwang/309747
，如需转载请自行联系原作者
