BW算是数据仓库吗

BW算是数据仓库吗

【翻译】原文地址：http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/15708

一直以来，SAP BW和传统的企业级数据仓库似乎就是两个不同的世界，之间隔着一道墙。如果你到LinkedIn的TDWI论坛上发文，说你自己是一位BW工作者，你立刻会被众人鄙视，诸如“BW是一个古老、笨重、怪异的技术”，“我至今遇到的SAP用户都在第N次企图让BW能够正常高效的运转”，“BW实施需要大量投入，包括软件、硬件、咨询等，极长的周期，让业务用户绝望”，等等言论不绝于耳。 

同样的，当我和那些传统数据仓库的同事讨论时，他们只想从我这听到BW的弱点是什么，或者为什么BW的性能如此糟糕，又或者我们要怎样才能用ERWin/Informatica/Netizza/Microstragegy等等其他技术来替换BW。

每每我和别人在论坛上或者当面讨论这些问题的时候，我总是站在BW的那一边，来证明BW是一个功能丰富，强大，开放，并且灵活的数据仓库平台。但是今天，我在SDN上想和我的BW同仁们坦诚的讨论一下：你的BW是真正意义上的数据仓库吗？从我的经验来看，这个答案往往是否定的。以下是我的一些想法：

1. 根本原因是，从历史上看，BW一开始就是作为SAP R/3的报表扩展模块。BW 3.0B在发布的时候，它目的是这样来描述的：“BW让你能够分析SAP系统中的数据，以及其他系统中的数据，包括数据库，在线服务和互联网数据”。没错，BW有一个强大的OLAP引擎，但是当时没有人谈到数据仓库。数据仓库是后来加上的，可是它的真正含义并没有被意识到。

2. 在我看来，许多BW开发者缺乏必要的数据仓库背景知识。像Kimbal和Inman这样的鼎鼎大名，很多BW开发人员都没有听说过。我希望Arun Varadarajan可以再发起一次这方面讨论。大多数的BW开发人员都抱着“BW顾问在市场上很抢手”的想法，从ABAP开发或是其他SAP功能模块转过来的。也有一部分BW开发人员是直接从应届生过来的。当编程语言（ABAP）和业务源系统表结构（例如财务，客户关系管理，分销等）比数据仓库知识更加重要的时候，自然而然的，许多BW从业者缺乏数据仓库架构，建模，以及数据质量方面的知识。

3. 除了之前一点，还有一个问题就是过于依赖所谓的“最佳实践”。我常常被问到关于某些BW领域的最佳实践，而我的回答始终是，“你的需求是什么”。然而，他们总是期待听到一个放之四海皆准的标准答案，能够在一夜之间把他们的BW变为强大的数据仓库。我太经常听到有BW顾问说把所有的转换都写成专家例程是一个最佳实践，然后这个说法被奉为金科玉律。。

4. 不幸的是，SAP本身也没有以身作则，提供良好的数据仓库结构。SAP的预定义内容就没有遵守数据仓库的基本原则：没有为性能考虑，没有按照多层架构来设计，没有设计为可整合多数据源。甚至连SAP自己大力推广的多层次可扩展结构（Layered Scalable Architecture，我本人也是它的粉丝）也没有在预定义的BW内容对象中体现。

5. 另外一个问题就是BW实施没有SAP的方法论。ASAP并不是一个正确的BW实施方法，按此思路来实施BW，好比削足适履。我曾经期望在收购了Business Objects以后，SAP能够继续把BO的“BI 方案加速器”发展提升至下一阶段，并作为SAP自己的数据仓库实施方法论。但至今我没有看到。

6. 作为紧密相关的工作团队，我从未在其他地方见过如此的割裂：应用程序开发人员（BW开发人员），和系统管理员（SAP系统管理员）。更糟糕的是，一些SAP用户将BW和系统管理分别外包给两个不同的公司。要想让BW获得更好的性能，两个团队必须从一开始就紧密合作。我最喜欢举的一个例子就是BW顾问在RSRCACHE里把OLAP缓存调至200M，同时Basis顾问在RZ11里还保留默认的导入导出内存值为4M。BW的性能问题就这样困扰着人们，一直到某天两个团队的成员开始交谈。

总之，现在开始，我们要一方面改变SAP世界之外的传统数据仓库从业者对BW的固有印象，另一方面，加入企业级数据仓库业界的讨论并发挥影响。