Skip to Content
原文地址(英文):http://scn.sap.com/docs/DOC-58532
作者:Merlijn Ekkel,现就职于SAP

目标

这个文档的目的是给WebI报表的设计人员提供一些建议和最佳实践。多年来,Web Intelligence已经发展成为一个有很多功能的成熟产品,因此这也就给开发文档带来了一些挑战。
好的执行文档是能让用户采用产品的关键因素,因为用户期待快速的响应,如果在一定的时间内没有得到他们所期望的结果,他们将会放弃正在进行的任务转而寻找替代品。
WebI文档的设计应该和WebI的引擎功效相匹配,以确保展示出让用户满意的文档,以下是影响Web Intelligence性能的因素:
  1. 系统配置
  2. 文档设计
  3. 语义层配置和查询设计
  4. 工作流程
我们希望通过此文档在上述这些方面为您提供建议和最佳实践,从而帮助您构建良好的可执行的Web Intelligence文档,最终让您的用户满意。注:所提供的建议和最佳实践不指定特定的版本,因此本文档提到的某些功能可能没有包含在您所用的版本中。
提高web intelligence性能的最佳实践和技巧的文档,是一个持续进行的项目。如果您希望收到更新的通知,请选择文档右上方的“Follow”选项。
如果您希望某些功能的最佳实践或建议被添加进来,请在底部通过评论部分告知我们,我们将评估是否可以包含在内。
这些建议来自SAP各方,包括:开发,技术支持,服务和产品专家。非常感谢所有人对这个文档的付出。
我们也创建了相同内容的幻灯片版面。如果您想把这个话题演示给您的用户,您可以在这里找到演示幻灯片:Slidedeck – Best Practices for Web Intelligence Report Design
注:一旦有其他信息添加,将会首先更新在此SCN文档。幻灯片版面将在此之后定期进行更新。
注:此文档和Tips for Optimizing the Performance of Web Intelligence Documents文档包含相同的内容,尽管有些内容是重复的,但两个文档都包含一些技巧和最佳实践,可以帮助您优化WebI报表。这个文档是最佳实践的概述,上述文件将提供有关如何优化Web Intelligence文档性能的更详细内容。

SAP社区网络的其他参考资料

除了这个最佳实践文档,以下这几个附加文件对提高WebI报表的性能可能会有帮助:

提高Web Intelligence性能的几点提示

快速运行的applet

每个人都讨厌等待应用程序加载。最近几个月发布的一些Java更新会严重影响Web IntelligenceAppletRich Internet Application)的加载时间。该方面经常出现以下三个问题:
  1. 在线证书撤销检查造成延误
  2. 新的JRE的安全变化引发问题和延误
  3. 包含超过60 JAR文件的Applet引发许多安全检查

在线证书撤销检查

新的JRE版本(1.7.0_25及之后的版本)自动在线检查撤销的证书。对一个applet中的每个JAR文件,它将运行此撤销检查。在BI4.0的初始版本中,这些applet包含的JAR文件超过60个。
此外,网络连接速度也是影响加载时间的主要因素。在网络连接慢的时候还要检查60多个JAR文件的证书撤销,加载时间会增加几分钟。
提高在线证书撤销检查的性能的提示:
默认情况下, Java运行环境通过两种方式验证证书撤销,即“证书撤销列表(CRL’s)”和“在线证书状态协议(OCSP)”。为了减少在互联网连接缓慢时的加载时间,建议更改Java控制面板的默认设置,只使用证书撤销列表(CRL’s),或者选择“不检查”选项,如果这是公司安全准则所允许的话。
Java Control Panel.png
更多详细信息请参考WIKIKBA1904873

JRE安全性改变

Orable已经花费了大量的精力来加强applet的安全要求。下一步,相比较SAP BusinessObjects的修补周期,新的JRE版本的发布将会更加频繁。
一些常见问题和解决方法可以在这里查找:Web Intelligence and Oracle JRE Known Issues

Applet大小

随着SAP BusinessObjects BI4.0的引入web intelligence Applet有了一个完整的新架构。在早先的版本中,web intelligence applet存在于一个jar文件中(ThinCadenza.jar)。随着BI4.0新架构的引进,这个已经被很多个独立的jar文件(60+)所取代,使得开发和升级更加简单。但由于Java安全更新,在加载Applet的时候导致性能下降。 SAP已决定从BI4.1 SP03开始恢复到单个文件webiapplet.jarwebiapplet_<language>.jar作为伴随资源文件)。这使得JRE仅有1个安全检查和1个缓存检查。
为了从改进的高性能的web intelligence applet中获益,建议升级BI产品到BI4.1 SP03或更高版本。
注:webiappletjar是一个44MJAR文件。第一次加载的时候需要一些时间,这取决于网络性能。在升了新的服务版本或补丁的时候首次加载也会慢。

附加的JRE Tweaks

在前面提到JAVA设置中,附件的重要tweaks可用于进一步提高Web Intelligence Java Applet的性能(Rich Internet Application)
  1. 确保JRE缓存是启用的
  2. 确保JAVA下一代产品插件被使用

避免“巨型”文档

太大的文档会浪费很多时间。如果一个大文档只有10-20%有用,89-90%都是浪费的。这种情况下是强烈建议避免使用大文档的。
  1. 避免在一个独立的文档中建很多个报表(tabs
            1.一个文档里包含10个报表是合理的
       2.一个文档里不要超过20个报表
   2.  不要尝试考虑到所有场景,而是着眼于特定场景
            1.一个文档包含50000行数据是合理的
            2.不要超过500000行数据
   3. 如果不是文档需要,不要添加额外的数据提供者
            1. 5个数据提供者是合理的
            2.一个文档不要超过15个数据提供者
为了提高运行和分析速度,针对特定的业务需求创建更小的文档。从具体业务需求开始,并根据这种需求建立文档。通过创建更小的可重用的文档,你将会:
  • 减少查看器加载文档所用的时间
  • 减少文档刷新所用时间
  • 减少客户端和服务器端系统所需资源
  • 修改文档时性能提升
  • 用户分析文档时性能提升

使用报表链接

考虑使用小文档并把它们链接起来,而不是用很大的文档。用openDocument的特性,可以把很多个文档链接起来并且从一个文档跳转到另一个文档。从报表中选择的值和结果可以作为提示或过滤输入到目标文件,让逻辑文档的整个链条变的精简。
为了使OpenDocument使用更简单,超链接向导在Web Intelligence HTML设计模式下是可用的。使用该超链接向导,OpenDocumen URL的逻辑可以很容易地通过用户界面(而不是编码)定义。
利用报表链接(OpenDocument),在某些情况下会导致更长的设计时间,但终端用户会对它良好的性能满意。

报表设计最佳实践

限制数据提供者的数量

最佳实践是每个文档不超过15个数据提供者
  • 数据提供者连续运行,所以运行时间增加
  • 刷新时间和维度合并会导致在处理服务器端的延时
利用数据仓库整合资源和ETL工具产生更好的报表源是一个好的做法。

取回聚合的数据而不是在文档中做聚合

从数据源取得尽可能多的预先聚合数据直接给用户使用是最佳做法,在需要聚合时取回详细数据,被认为是不好的做法。尽管web intelligence对数据聚合有很强的处理能力,但数据源在处理数据聚合方面更高效。
如果所需的聚合不能做预先计算,在查询定义里使用聚合命令(参见语义层最佳实践)。这将要求源数据库在发送给Web Intelligence处理引擎之前聚合数据。

不要禁用Web Intelligence的缓存机制

Web intelligence对已经查看过的文档有很强的缓存机制,利用缓存可以加快文档的加载时间,然而有一些web intelligence的函数会阻止使用缓存。这些函数是:
  • CurrentTime()
  • CurrentDate()
  • UserName()
使用这些函数将会在每次请求时都重新生成文档,这样就利用不到缓存的好处。

避免自动调整

尽管对单元格,表,交叉表和图来说,自动调整是个很好的选项,可以自动调整大小以适应内容。但是它也会在导航时强制使文档计算。这将会使浏览报表时变慢,最大的影响是在一个大报表里从最后一页跳到第一页时变的很慢。

避免高维图

BI4.x开始,添加了一个新的图表引擎,通用可视化对象模型(CVOM)。这个引擎是包含在自适应处理服务器(APS)里的,称作可视化服务。
CVOM可以让您在Web Intelligence文档中做出很好看的图,不过,应该创建很多个小图,而不是创建一个包含很多数据的大图。使用更小,更详细的图将是更有效的。

避免嵌套节

使用嵌套节会导致性能下降。在使用条件如“在以下各项为空时隐藏节”时是尤为突出的。
WebI BestPractices - Nested Sections.png

向下钻取报表时使用查询钻取

在文档属性里,有一个“使用查询钻取”的选项。查询钻取功能会利用底层数据库的性能。如果没有勾选查询钻取,查询会加载越来越多的数据到文档中。一旦启用这个功能,钻取请求就会修改查询语句并且从数据库取得新的数据。通过这种处理方式,存储在本地的供钻取用的数据量有利于提升文档性能。
WebI Best Practices - Query Drill.png

“分析范围“的使用限制

分析范围可以使用在有简单钻取会话的文档里。然而,一旦分析范围被启用和定义,额外的数据将从数据库中被检索并存储在文档的cube里。加载数据越多,对性能影响越大。
WebI BestPractices - Scope of Analysis.png
除了使用分析范围/钻取,报表链接可以在获取详细数据时作为一种替代。报表链接的好处是,详细的报表只取所需的数据(相对于整体使用钻取)
提示:在BI启动板Web Intelligence的首选项里,您可以选择在钻取需要更多数据时是否提示。

公式的最佳实践

Web Intelligence公式引擎具有强大的功能,但取决于公式的逻辑。公式中的一些语句总是会计算整个数据集,然而,把计算分解为多个步骤(因式分解)将会使计算引擎工作地更快。以下记录的是关于计算引擎的已知示例
  • 语句”ForEach””ForAll”只在非常必要的时候用,建议用”In”语句来代替
  • Where运算符也会花费很长时间去处理文档,用”If..Then..Else”可能会更好。
  • 因式分解可以减少计算引擎的消耗。例如:
        v_Sales = [MeasureA] + [MeasureB]
        v_SalesEst = [v_Sales] + [MeasureC]
    对比于:
        v_SalesEst = [MeasureA] + [MeasureB] + [MeasureC]
    通过分解步骤,计算引擎在处理结果的速度上会更快。

语义层最佳实践

创建可执行的WebI文档依赖于底层universe。一些语义层的默认设置在实际使用时并不是最佳的,建议对其进行更改。

构建精益的查询

创建一个新的文档时,很多度量和维度都在初始查询中被取回。在随后的构建中,越来越多的对象被添加进来,导致非常多的查询。这与语义层的基本准则是相违背的,因为它的目的是要简化数据查询。
查询中包含很多对象去获取大量信息,对开发人员来说可能有用,但对最终用户来说是不方便的。
按下面步骤逐步创建文档:
  1. 从文档的需求着手并为这种特定的需求创建查询。
        –不要添加不需要的维度,细节或度量
        –如果不能明确知道哪些对象是需要的,做一个简单报表而不是以后再移除对象。
   2.  移除查询中不用的对象。
     报表完成的时候,验证是否所有在查询中需要的对象都被真正用到了文档中。如果不是,移除没被用到的对象。
   3.  移除没用到的局部变量
     移完不用的对象后,要移除任何在文档中没有被用到的变量。即使变量没被用到,计算引擎也会计算它。
总结:创建查询时只包含在文档中用到的对象。

优化数组提取大小

语义层的一个默认设定是数组提取大小(在连接里定义)。数组提取大小设定每次从数据库取得的最大行数。调整到一个合适的大小可以明显的提高性能。
内部测试证明增加数组提取大小(之前默认值=10IDT设置成“优化模式”)会提高基于这个universe创建的报表的整体性能。
在内部测试时,我们从数据库取得1228000条记录到报表中并记录了从数据库得到这些行需要的时间。
WebI BestPractices - Array Fetch Size.png
在我们的事例中,增加数组提取大小到1000(每一次提取的行数),数据从数据库加载到报表引擎用了18秒。
不建议盲目采用我们内部测试的结果,因为有很多因素影响您的具体的情形(比如网络)。推荐的做法是做很多次测试并且用多种不同的设置,从而定义您的最优数组提取大小。
随着BI4.x的引进,每个新创建的连接里数组提取大小都默认设置成“最佳”。这不总是最好的设定,因为它是基于有限测试的结果。你可以用“DISABLE_ARRAY_FETCH_SIZE_OPTIMIZATION”参数来禁用这个设置。为了重写最佳值,你必须在Universe Design Tool UDT)或Information Design ToolIDT)里把参数设置成”Yes”.
更多关于参数的详细信息请参考Information Design Tool Guide

使用查询过滤器而不是报表过滤器

通常,报表过滤器能给报表使用者灵活快速地呈现一组特定的数据。然而使用报表过滤器可能会导致数据增加到一定程度后使性能下降。如果你要获取大量数据以使用报表过滤器进行过滤,建议调整报表查询并且使用查询过滤器。
使用查询过滤器将会减少报表整体运行时间,因为很显然它会检索较少的数据。

启用查询剥离

查询剥离是BI4.x的一个新功能,可以帮助您从查询中移除不用的对象。使用查询剥离,查询引擎在刷新前会验证是否所有查询中的对象在文档中都被使用。如果对象没被使用,它们将会从发送到数据库的查询中移除(注意,在查询面板中不会被移除)
BI4.1 SP3起,查询剥离对关系型数据库也可用。在这之前,查询剥离只对基于BICS连接(BW)创建的文档可用。
对于使用BICS连接的文档,查询剥离默认是启用的,然而其他的连接类型是要手动设置的。
对于基于关系型数据库创建的文档,以下参数是必须要设置的:
  1. 允许业务层的查询剥离(IDT universe
  2. webi文档的查询属性里启用查询剥离
  3. webi文档的文档属性里启用查询剥离
注意:USE_ENHANCED_QUERY_STRIPPING参数只优化SELECTGROUP BY子句,不修改表链接或SQL语句的其他子句。

只在需要时合并维度

默认情况下,如果两个数据提供者包含相同的对象,BI4.x web intelligence将会创建一个合并维度.然而,如果最终报表不需要展现合并数据,建议不要合并维度。
合并维会影响性能,因为它的逻辑必须应用于计算引擎内以创建合并数据集。拆分不需要的维度可以提高性能。
WebI Best Practices - Unmerge.png

解架构差异

SAP BusinessObjects BI4.x和以前的版本相比是不同的。尽管从技术上看起来是相同的平台,但是在后台有很大的改变。
主要的变化是,BI4.x是一个完全的64位服务器体系结构。以前的版本(XI3.x及更早版本)是32位架构,因此会有很多局限性。使用64位体系结构的主要优点是,单个进程可以请求大于2GB的内存。
除此之外,BI平台的后台服务的“工作”方式也改变了。在XI3x平台,Web Intelligence处理服务器将处理所有请求:从生成SQL语句到呈现报表和图表…… BI4.x上,这些任务已经被分给各个“通用与共享“服务去处理。
web Intelligence,以下这些BI平台的服务可能被用到(取决于具体情境)
  1. web intelligence处理服务器
  2. 可视化服务(APS->生成图
  3. DSL-桥服务(APS->新建语义层和BICS连接
  4. 数据联合服务(APS->多源universe
  5. 连接服务器(64位)->3 层连接模式
  6. 连接服务器(32位)->2 层连接模式
  7. 安全标记服务(APS->SSO会话
  8. WebI监控服务(APS->客户端监控
  9. Web应用程序服务器->页面呈现
  10. 中央管理服务->认证
  11. 文件存储服务->文件检索/实例存储
  12. 发布服务(APS
  13. …..
强烈建议去理解BI4.x Architecture的技术图解和Web IntelligenceBI4x Process Flows。以下处理流程是至少要理解的:
注意:这些流程目前正在修订以包含最近的更新。请继续关注更新的版本!

使用计划功能

为什么使用计划
  • 配置正确的话,使用计划可以减少用户等待时间
  • 允许你在非高峰期处理任务
  • 可以帮助分配荷载
  • 高峰期减少对数据库的影响
最佳实践是,任何刷新超过5分钟的报表都应该用计划功能。使用BI平台的计划功能,您可以利用Web Intelligence处理服务器的缓存机制,以加快报表的处理。在计划设置里,当计划为 Web Intelligence 格式时,可以选择在计划时用于预加载高速缓存的格式 (包括XLSPDF格式)。
建议让用户使用计划功能而不是让技术人员处理所有计划。

对服务器做分割以达到最佳性能

任何刚安装的BI4.x是没有为生产使用做分割和配置的。随着BI4.x堆栈的变化和它的64位架构,web intelligence服务可以处理更多任务(如果适当分割并配置)。由于64位在为Web Intelligence处理服务器的内存分配上没有了限制。因此同一台机器上的其他Web Intelligence处理服务器不再需要(平衡内存需要)。
对于BI4x,建议每台机器只有一个Web Intelligence处理服务器。只有当达到极限/或希望进一步平衡负载,建议添加其他Web
Intelligence处理服务器。但是,不建议一台机器上添加多于2 Web Intelligence处理服务器。因为在新的架构下,WebI能抢占更多的内存,如果多个Web
Intelligence处理服务器都在一台机器上有可能危及系统的稳定性。
在更改的架构上,Web Intelligence处理服务器也把各项工作分发给其他服务:
  • 基于BICS连接创建的报表使用DSL桥服务(APS
  • Unx关系型universe使用DSL桥服务(APS
  • 包含图的报表使用可视化服务(APS
  • 多源universe使用数据联合服务(APS
除了正确对Web Intelligence处理服务器做分割外,你还应该对其依赖的服务做分割和配置。如需进一步了解Web Intelligence或自适应处理服务器(APS)的分割,详细信息请参考BI Sizing页面www.sap.com/bisizing

位置会导致很大差异

理想情况下,应该让你的(Web Intelligence)处理层靠近你的数据库。处理层是从数据库请求数据并通过网络层取得数据。如果处理层和数据库之间存在一个很长的距离,可能会出现很多性能问题。即使你的处理层靠近数据库,强烈推荐使用快速网络(1 Gbps+)。处理层和数据库之间加入的任何网络层,都会增加额外的步骤并且因此产生延时。想要知道处理层和数据库所需的时间,建议定期检查网络的性能和任何潜在的瓶颈。

使用本地存储

Web Intelligence处理服务器可以使用大量的缓存,都存储在磁盘上。Web
Intelligence处理服务器缓存在本地磁盘上(最好是很快的,如SSD10+ K SCSI)将会提高性能,因为本地存储在输入/输出方面相比较网络存储明显是快的。如果高速缓存目录是在网络共享/ NAS / SAN,建议定期检查网络性能和任何潜在的瓶颈。

CPU很重要

虽然BI4x的分割工作是在APS server执行有一个事实是,CPU加速DOESWeb Intelligence的整体性能很有关系。这在旧的硬件上更相关。即使你有1281200MHzCPU,也会导致报表变慢。 Web Intelligence需要进行大量的计算,CPU越快,引擎越快。
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply