本文主要是介绍BWA 归结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
BWA 归结
转自: http://scnblogs.techweb.com.cn/amperson/
初识BWA
看到Vince在办小讲坛，感觉这个形式作为基本知识的介绍挺不错的。然后联想到和自己关系颇深的一个产品--SAP BWA--在国内还相当陌生，何不也用这种方式介绍一下呢？由于论坛帖子的一些限制所以无法很详细，这个小讲坛就当作一个入口吧。比较详细的内容我都会写在我在SCN新建的blog上(http://scnblogs.techweb.com.cn/amperson/)，欢迎大家光临！
比较正式的说法，SAP NetWeaver BW Accelerator 是一个高度可扩展的，基于内存的解决方案。它一方面大大提高了报表查询的效率（一般提高10倍以上的数据查询效率），另一方面也减少了建模开发和数据延迟的时间。同时由于其类“插件”的特性使得企业商务智能的应用可以更加丰富。
以上有两点我再稍说明一下，BWA用来提高（或者取代）的是DB时间，因此所谓“10倍以上”的概念是指DB Time来说的。换句话说，如果OLAP Time很高(比如用了exception aggregation)那当前BWA就无法有太大作用了。另一个是解释一下什么叫减少数据延迟时间。由于BW要通过Changerun/Rollup来更新数据因此报表总是会有延迟，而当Aggregates比较大比较多的时候changerun就非常慢。而BWA可以大大提高changerun的时间，一般来说也会有几倍到十几倍的提高，所以这就是减少数据延迟时间的意思。
然后让我们先来看看BWA是由哪些东西组成：一般的BWA系统在硬件上有n个刀片，一个中央存储磁盘以及相关的网络设备。软件上主要是SAP BWA软件（基于SAP TREX），SUSE Linux，以及不同硬件厂商提供的文件系统（OCFS，GPFS等）。因为BWA是作为一个类插件的产品来定位的，因此对客户来说就相当于是一个黑盒，不需要客户自己去设置什么参数。由于BWA和BW之间主要是通过RFC和ICM来连接的，因此用户只需设置好连接并确保这些连接是正常运行的就行了。因为BWA基本是属于即插即用性的，因此客户不需要对原有BW系统做什么改动，OLAP会判断query是否会读BWA，如果是读BWA的那OLAP Engine就会让其自动读向BWA，因此对于前端用户不需要做任何额外工作就可以感受大大提高的性能;)
那使用BWA和不是用BWA的query流程是什么呢？传统上，不用BWA的流程是这样的：预处理（Infomation broadcasting） -> OLAP Cache -> Aggregate -> InfoProvider，而现在用了BWA就是：预处理 -> OLAP Cache -> BWA。因为BWA有自己的存储系统，会把infocube的数据都拷贝到BWA系统里去，因此query基本不需要和数据库直接交互了（特殊情况下还是会的）。从这个流程也就能看出BWA对query来说的主要用途就是解决DB Read的问题。反之，如果query的时间主要是在前端或者OLAP时间上面那BWA就不能有很大提高了。当然，一般来说query的时间绝大多数都是花在db上面，这也是为何BWA的应用非常广泛的基本前提。事实上当今一些欧美大客户的部分报表已经到了不用BWA几乎无法工作的地步。
BWA即将到来的“将来”
今天聊一下SAP之后可能的BW/BI产品框架，虽说主要是说BWA部分但也会涉及到一些其他的产品。从中也可以看到今后BWA在其中的分量，以及一些想象空间。插一句的是，从最近产品的更名大家多少可以看的出来，SAP的传统部分在以后扮演的将是数据仓库的角色，而前台报表会大量采用或合并BOBJ的产品，这可能也是之前BI重新改名成BW的意思吧。
让我们从后台到前台分三层来说。
最基本的是数据存储及建模部分。传统的建模部分大家都很熟悉，我也就不多说了。比较有用的一个产品是Data Services。这个是用来从其他数据源来抽取数据到SAP BW里。由于这个产品的许多具体新功能现在许多还是远景或是规划，因此等有确实信息再说吧。
往上一层就是BWA，这是我着重要讲的。
1．BWA可以同时支持从传统SAP BW那里过来的query/index，同时也能够让其他前台工具来访问，比如现在已经实现的BusinessObjects Explorer。如果客户使用BusinessObjects Explorer，那可以配置BWA，使数据存储到BWA中，然后Explorer来读取数据。这样会是的Explorer的速度大大提高。其实在BOBJ和BWA产品整合中扮演一个关键角色的是Universe。通过Universe，BWA会通过Data Integrator来从其他各种数据源来抽取，因此这使得BWA作为一个独立的存储系统，而不仅仅只能存储SAP BW的数据成为可能。更为重要的是，通过Universe，BWA能够让各种前台报表工具，水晶报表，web intelligence, BusinessObjects Explorer，来使用这些数据。BWA内部对应的接口是基本开发完毕的TMX功能是内嵌在BWA本身的Python代码中。这个功能简单来说就是使得Trex能够解析类SQL语言。除了ABAP系统，也会提供Java的JDBC。从而是的TREX对于使用它的程序来说就相当于是一个普通的关系数据库。
2. 目前OLAP Engine的功能会整合进BWA。比如Top N的计算，Exception Aggregation，Multiprovider aggregation等。同时对Planning的直接支持也在其中（比如write-back）。
3. 更多的数据结构。目前BusinessObjects Explorer的引入就是的BWA中不仅仅只有原先的数据结构。之后DSO也会以另外一种形式加入，但这种形式目前看来不是当前使用的DSO。具体信息需要等确定后再和大家讨论。
综上所述，BWA在今后不仅只是一个加速器，而是一个比较独立的数据分析引擎产品。事实上，在不远的将来BWA将会完全更名，作为一个独立产品而推出了。
第三层是前台的报表工具，这里涉及大量SAP和BOBJ前台工具的整合，由于现在许多还没有定论，所以只就了解的一些信息和大家分享一下。（1）在Dashboard方面，Web App Designer基本会让位于Xcelsius了，（2）而在普通的报表工具中，会以水晶报表为主。（3）在网络报表和Ad-hoc的报表方面，Web Intelligence已经属于主推产品，目前在美国使用的客户倒也已经不少。（4）OLAP分析方面， BEx还会有一席之地，不过和BOBJ的相关产品整合是必然的，目前的产品项目是Voyager，正式推出可能叫Pioneer。但具体能做到什么程度，还需要看到具体实现再说。
今天就简单地和大家聊一下今后SAP BW可能的产品结构，其实说得也很简单。主要是因为目前仍在整合中，许多东西也不完全确定，因此与其聊小道消息，还不如踏实做好当前的事情。但无论如何，BWA在未来SAP BW中的地位将是重要且突出的。以后开始BWA技术将是我的主要话题了。
认识SAP NetWeaver BW Accelerator
SAP并购BOBJ对于商业智能领域无疑有着深远的影响，两者产品的取向及整合更是业内关注的焦点。而SAP BWA(SAP Business Warehouse Accelerator)可以说在当前乃至未来的产品架构中扮演着不可或缺乃至革命性的角色。鉴于国内对SAP BWA还很陌生，所以就不顾浅陋，将自己对SAP BWA理解和使用的经验和大家分享，作为BWA在国内的抛砖引玉吧。
当前由于IT应用的日益深入以及客户本身规模的扩大，商业应用对软件提出了更高的要求。让我们先来看一下当前商务智能报表的一些难点：
1.客户数据仓库中的数据量越来越大。面对动辄千万上亿数据量的数据立方 (InfoCubes) ，报表的性能如何保证？
2.使用商业报表的终端用户越来越多。在一个大型企业里信息工作者数量众多，类别也多种多样，这就决定了报表的种类和数量都是十分庞大的。那如何在尽可能减少维护管理工作的前提下保证绝大多数用户的使用性能？、
3.复杂的在线数据分析。商务智能的特点决定了客户需要对报表可以进行上钻，切片等多种高级操作，同时也存在大量的随机条件报表。但随着数据量和用户数的增加，这些高级应用的性能如何保证？
在传统的SAP场景中我们可以使用预处理技术（比如Information Broadcasting）OLAP Cache或Aggregates来提高性能，但其限制也是明显的。预处理技术不能处理随机的报表；OLAP Cache也不能处理随机报表，同时由于其容量的限制使得它无法真正应用于所有报表；Aggregates是过去通常的选择，相当于有针对性地建立了一个迷你数据立方，当由于是针对性设计的因此不可能穷尽各种条件，对于大数据量也会占用大量的磁盘空间，更重要的是随着Aggregates和characteristics的增多，数据更新(ChangeRun/Rollup)的时间会有极大的限制。这也是为何在较大的BW系统中维护Aggregates的成本是相当高的。
那SAP BWA是如何做的呢？
SAP NetWeaver BW Accelerator 是一个高度可扩展的，基于内存的解决方案。它一方面大大提高了报表查询的效率（一般提高10倍以上的数据查询效率），另一方面也减少了建模开发和数据延迟的时间。同时由于其类“插件”的特性使得企业商务智能的应用可以更加丰富。
首先，因为BWA有自己的存储系统，它会把数据立方里的数据连带几类重要的主数据都一起拷贝到自己的磁盘上去。这样当报表的场景就发生了变化。传统意义上，报表的执行顺序是：预处理 -> OLAP Cache -> Aggregate -> InfoProvider，而现在使用BWA后则是：预处理 -> OLAP Cache -> BWA。从这里可以看出一个使用BWA的报表其实是不需要和数据库交互的（特殊情况下会有较少的交互）。
然后是BWA高度的并发计算优势。我们知道一个BWA系统实际上由众多刀片组成的，因此BWA系统本身就像是一个大型分布式系统。BWA系统可以将从BW系统过来的报表查询请求分解成众多的子请求(subcall)，然后让这些请求在各个刀片上并发速算。以当前正常的BWA配置来说（8 CPU + 16G内存），每个CPU处理一个线程（子请求是以线程形式在BWA系统中进行计算的），因此一个刀片就可以同时计算8个分解后的子请求，再乘以客户的刀片数目，由此可以看出BWA系统并发的威力，同时也就可以理解为何BWA能如此高地提高性能了。
第三，BWA自身的数据结构特点。BWA使用的软件基础是SAP TREX。其数据结构不是二维关系表的结构，而是对数据Attribute的按列存储。当一个数据立方进入BWA系统中后它会被切成多个部分水平分到各个刀片上。这也是数据计算能够分布在各个刀片上而不是一个刀片上的前提。
以上简单介绍了一些SAP BWA的基本特点。正如软件开发没有“银弹”，世上也不会有十全十美的万能产品。因此尽管BWA的应用局限是比较小的，但也需要对BWA设立合适的期望。对于SAP BWA的具体使用和技术以后将陆续撰文介绍，欢迎对SAP BWA有兴趣的朋友一起讨论！更欢迎对SAP BWA有经验的朋友指正！
这篇关于BWA 归结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
