主要BI功能特性分析

拆解BI套件—主要BI功能特性分析

近几年来的BI市场虽然已经上演了很多的大鱼吃小虾事件，但仍然有不少的供应商，产品套件也是琳琅满目，SAS Enterprise BI Server、Cognos BI Series、Business Objects Enterprise、Hyperion、MicroStrategy、Microsoft Reporting Services……

但是，严峻的现实是，在通往BI产品选择和标准化的路上依然布满荆棘，很少有人能够理解这些产品中有哪些差别，这些差别又会怎样影响到可用性、可管理性、成本以及最终的成功。当人们购买轿车的时候，他们知道污染、汽油价格等的影响，但是在BI工具的选择和标准化时，诸如“带状报表（banded report）”或“multipass SQL”这样的特性对不同的人就是不同的意思，取决于他是用户、BI专家还是BI厂家。

查询

首先来看查询（Query）功能，也就是怎样把数据从数据的大仓库或运作的系统中取出来。在决定哪一个标准重要之前，企业组织首先必须回答几个策略性问题：

谁来制作大多数的报表，是业务强大用户还是IT开发者？答案也许是“两者”，但是对每组用户的重要功能是截然不同的，这就迫使你或者选择多种工具（尽管可能是来自一家厂商），或者要求一部分使用者牺牲功能。

Web是制作报表的环境还是仅仅为一个发布机制？很多最初为桌面构建的BI产品仍然与Web类产品有功能差异（虽然这个差距在缩小）。

需要指出的是，由于很多现实原因，使用者需要同时查询多种数据资源，有时可能需要把两种数据显示为两种不同目标形式，如，一个消费者收入的表格和一个消费者满意度图形同时显示。另外的情形是，数据可能存储在两个不同地方，但使用者需要合并两套数据并在一个表格中进行分析。理论上说，所有的数据都已经被清洗并存储在数据仓库之中，但实际上，在多数据库的情况下可能存在不同的版本，包括个人电子数据表或部门的数据库。所以收入可能出自数据仓库，但消费者分组及产业分割可能是在Microsoft Access数据库中。

实际产品的功能表现也不尽相同。虽然Business Objects universe只允许访问单一数据库，但个别的文件允许使用者同时访问多种数据库、存储的程序以及个人电子数据表，这给查询者制作报表提供了相当灵活性，也是Web Intelligence不具备的功能之一。Cognos ReportNet产品包通过ODBC为多数据资源服务。然而，一个报告只能查询一个包，这给了管理者控制权但限制了使用者的灵活性。同样，Query Studio也只能显示一个表格或图表结果，但Report Studio具有更大的灵活性。Informatica的PowerAnalyzer在管理者定义数据资源之后，允许一个报告访问多种数据资源，结果只能显示一个图表。通过MicroStrategy 7.5的新Document Editor (桌面)，你可以在一个项目中包含多种查询，但项目只能访问一种关系型数据库中的数据，因为这种访问只是在格式化的文件中进行，OLAP分析或钻取(drill-down)对这种文件是不可用的。Microsoft的Reporting Services允许一个文件访问多种数据资源，显示结果可以是两个或一个。

报表

坦白地讲，报表的声誉并不好。出自大型主机打印机的大量不鼓舞人的文件报表创造了那么多的原始数据，但很少对决策有用。把注意力放在文件报表上几乎很难付诸行动。相反，分析却很容易付诸行动，这也就是许多报告消费者努力的方向。

令人振奋的消息是报表正在改变，如同轿车从单纯的使用机器走向奢华、炫耀的工程之作一样，今天的报表已经能够服务于更敏捷的、更具有竞争性的行动。

首先，随着用户期待指数的提升，对报表工具支持复杂文件、原始数据查询以及在一页或一个报表中以多种方法展现等的需求也随之而来。例如，你可能需要在看到延期交货订单的详细表列数据的同时，在其旁边看到一个能显示未决定、延期、准时出货百分比分布的饼状图。

是否要使用带状报表（banded report）去控制报表设计，也是厂商们最近争论比较多的地方，他们的争执点是关于“怎样”，而不是“什么”的问题。从一个用户的立场，应该关注的是你是否能够拥有分组、小计以及详情等。不过，不同产品实现这些目标的方法也不同。

像MicroStrategy的Report Services使用了带状报表，需要你把小计放到报头或尾部，在主体部分是详情，图表也必须出现在报头或尾部。像Business Objects Enterprise、Cognos ReportNet、Microsoft Reporting Services等其他BI产品，使用页面设计概念，这样你可以在任何你需要的地方放总计及详情，它们只是独立的对象，其位置你可以自由控制。概要图表也可以出现在页面上任何你需要的地方。两种方法的结果很类似，但设计方法却截然不同，带状报表结构可能对传统大型主机报表开发者更熟悉，页面设计概念则对Excel、PowerPoint或HTML开发人员更熟悉。

下面说说图表。图表的表现价值胜过千言万语。但不幸的是，很多报表开发者仍然使用传统表列数据，其实图表是最方便于分析的工具。

所有厂商都提供同样的基本图表类型：柱状、线形和饼状图，但只有少数提供map、bubble等独特的图表类型。在图表类型中，使用者需要具备控制不同图表属性的能力，如min/max刻度、标志布置、3D效果、个别线条或条棒的颜色等。

双Y轴的能力是绘制多度量器时的必备条件。例如，如果你分析随着时间推移价格对销售量的影响，你就必须要有两个Y轴。Business Objects在其桌面工具中提供这个功能，但在其Web Intelligence中并没有提供。Cognos ReportNet也有类似的局限性。

再看报表协作性。报表消费者（典型的商业业务使用者）能够与报表相结合的程度也是一个重要的衡量标准。不能提供协作性的报表只不过是使分发“哑巴”纸质报表的过程自动化而已。发现一个趋势图中的异常只是商业洞察力的第一步；能够研究这种异常才是关键性的第二步。

即使BI工具提供了一定程度的协作性，一些使用也会限制它。聪明的使用者会自动输出数据到Excel，创造多种版本的真相，这是目前一种更加危险的状况。

协作性有两方面：单独的报表协作性，跨越多种报表导航。在两种情况下，报表和OLAP钻取之间的分界线正变得越来越模糊不清。

Business Objects Web Intelligence提供了很好的单独报表协作性；Microsoft Reporting Services提供了模拟钻取(出)的一个独特大纲视图，但它缺少过滤和分组。Cognos ReportNet在

单独报告协作性方面较弱，只提供了一个静态页面，但是ReportNet提供了很好的全面导航功能，允许在报告之间钻取(出)以及报告与其他应用之间的钻取（出），包括Cognos PowerPlay和Visualizer。

Informatica Power Analyzer 的导航功能非常独特。胜过从一个报告到另一个报告的钻取，Power Analyzer使用了“工作流（workflow）”的概念，使用者看到一个可选择报告的列表，而不是只能在一个静态的子报告中挑选，一个主报告可以有多种工作流，灵活地提供了更多导航。

需要指出的是，文件复杂性、图表、协作性等只是各BI厂家提供的一些主要差异性报表特性，诸如有条件格式化、相对定位以及格式纸等另外的一些特性也会影响报表设计。

信息发布

查询和报表使你把原始数据转变成能促进决策行动的强大的文件，然而，除非你已经把那些文件放到决策制定者手中，否则数据间的链条仍然是断开的。接下来就要依赖于信息发布（information delivery）功能了。

两种技术对企业信息发布有重大影响：Web和email。

过去，信息递送过程包括走向打印机、拿到打印输出，或者传达室把报告递到你手上。在20世纪90年代后期，很多公司有了企业内部网络，开始把标准报表输出到内部网上，这些报表可能是电子数据表文件或以HTML保存的静态BI报表。

今天，BI报表按照BI工具赋予的文件格式存储，拥有更多协作和更新数据的能力，Web和email 也扩展了报表传递的范围，尽管当初上百用户执行BI就被认为是很大规模，今天所谓大规模已经是好几万的概念。这样，可扩展性就成为衡量信息发布功能的一个主要因素：一个报表必须到达多少使用者以及怎么样到达。

评估各厂家BI工具的可扩展性并不容易，因为不同产品扩展方式不同，仔细查看公开的基准测试结果、查看消费者指南手册、理解其架构是评估一个产品是否能按照你的期望扩展的必要步骤。

按照信息发布来评估可扩展性要求，你还必须考虑使用者怎样与报表相互作用。一种所谓的push（相对于pull）方法是，BI工具按照计划产生报表，然后通过email或无线设备等门户把这些结果推向最终使用者。乍看，push方法好像是管理可扩展性的理想方法，因为IT能够预先决定什么时候处理大量BI作业。但是，就像一个执行主管反映的，他经常被报表email所淹没，现在他通常是删除，因为他认为如果真的有问题的话，肯定会有人打电话给他。很显然，并不在于说你推出去多少个报告，而要看多少人在做决策的时候真正使用了这些报告。

而且，还必须考虑你强行推给用户的是一种静态PDF附件还是一个到BI报告的URL，如果是PDF，扩展性需求并不是很严重，因为PDF是预先制作好的，使用者在浏览报表的时候不会对BI应用服务器造成压力；但URL情形则需要更多的扩展性，因为使用者要访问BI应用服务器。

push方法还包含“bursting”问题，也就是拿到一个大型报告，并分解，以便不同使用者只能得到允许的或需要看到的数据，如，每一个人事主管只能看到其职工的薪酬。这种个性化无论从安全方面还是从管理信息超载方面都非常重要。

在大多情况下，bursting能减轻RDBMS（关系型数据库管理系统）的一些负荷，因为许多的人事主管并不需要运行许多的单独查询，而是，运行一个大型查询，其结果被分为多个部分。

然而，bursting的实现方法也不同，也不总是能提供这种优势。比如，在Business Objects提供的两种bursting方法中，一种就是通过Broadcast Agent Scheduler为每一组接受者运行查询，这种技术允许公司使用独立数据库登录，并具有安全性，但它会给RDBMS造成不必要的负荷。Cognos Impromptu 也使用这种方法。

图1 Business Objects 的InfoView Portal允许使用者创建

可作为dashboard使用的My InfoView,内容包括报、Web URL等.

不过，大多数的产品，包括Business Objects Broadcast Agent Publisher及Cognos ReportNet，都是使用运行一个查询、然后分裂为多个单独报表的方法，这样减少了查询对RDBMS的访问。

久经考验的pull方法是广大最终使用者喜欢的方法，然而它对IT部门和厂商提出了更多挑战。这种方法是使用者登录到BI的工具，有选择地寻找他们需要的报告。

schedule-and-pull取代schedule-and-push方法的过程将是很缓慢的。有重现信息需求的使用者可能会把查询更新的时间安排在非高峰时间，或者说，IT可能会将高使用率的报表安排为整晚更新，以便其结果能够预先缓存给使用者。schedule-and-pull的方法减少了BI应用服务器的负荷，从而让它能支持并发的查询更新以及复杂文件的产生等。

专门的BI门户能够让使用者访问标准的报表或个人报表。对于一些已经实现企业范围门户解决方案的公司来说，与Plumtree、IBM WebSphere或Microsoft Sharepoint等门户产品集成是非常重要的。根据你不同的策略，你也许：把特定的BI功能嵌入企业门户中；从企业门户内部访问专门的BI门户；通过Web URL访问专门的门户。

好的BI门户允许使用者将门户定制到诸如My Yahoo 这样的仪表盘中，显示多种报表、Web站点、提示以及报表列表等。标准的报表通常以各种主题分组。完美的BI门户允许一个报表以多种方式分组，而不会造成同一报表的多复制本。而且越来越多的厂商允许电子数据表、PDF文件等非BI文件存储在BI仓库中，并在门户中展现。随着BI内容的增加，使用者也需要简单的方法来通过作者、关键字或其他方法来查询报表。

Excel集成

在评估BI工具套件功能的时候，人们往往很容易沉浸在逐个功能的对比中，而忽略了执行BI所要达到的商业目标。前文曾经把选择BI工具与购买轿车相比拟，在购买轿车的时候，我们很少考虑将怎么使用它或有关正确的驾驶方法等，在为“它是如此酷、敞亮、时尚”激动之中，一些最好的实践和使用往往被丢到脑后。在选择BI工具的时候，有一个特别的功能是用户非常需要的，我们这里也将直接深入研究，那就是Excel集成。

尽管Excel可能是无可争辩的最主要的BI工具，但它也是导致多种版本真相的主要原因。两个使用者同时查询一个中央数据仓库，并把数据导入Excel，一个使用者在Excel中使用一组特殊的标准过滤数据，并用一些个人的公式来计算；另一个使用者过滤数据的方法稍有不同，或许在公式中犯一个小错误。谁的电子数据表是正确的呢？结果大量的时间花费在协调多种版本之上而不是考察业务发展。在每次查询更新及产生结果报表以后都必须重复同样的流程。

尽管电子数据表存在正确性问题，但是还是有很多因素使得在BI工具选择中不能忽略Excel集成：工具熟悉。使用者很少有时间获得数据然后去分析，通常最简单的方法就是使用他们已经熟悉的工具。

“按摩（massage）”数据的能力。“按摩”数据包括重新分类、过滤、创建公式，以及在某些情况下修理坏数据等。理论上说，所有这些都应该在BI流程的早期完成。在报表部分我们提到，能够让使用者重新分类、过滤或在本地BI工具中隐藏个人专栏的BI工具协作能力，当这种功能失效或不存在时，使用者除了把数据导入Excel外几乎没有多少选择。在Excel电子数据表中校正坏数据的巨大任务对于数据一致性来说显然是一场噩梦。然而，如果流程不能适当地从根源上修理坏数据或修改ETL错误，使用者无论如何也难以创建一个有用的报表。

较好的图表。Excel图表以及所有对比例、坐标轴、标注的控制已经成为一种事实上的基准。如果BI工具不能提供强大的图表功能，显然使用者需要把数据输出到Excel来使用其图表功能。

摘要文件（Briefing books）。Excel可以将多个工作表存储在一个工作手册（workbook）文件中。使用者可以离线访问所有数据，这些数据可能是通过多种数据源或查询组合成的一个文件。很少有BI厂家能够很好地复制这个功能。尽管仪表盘功能提供了类似的替换选择，但通常需要网络连接。

减少许可证成本。企业已经花费了Excel的许可证费用，如果他们能够通过更好地利用Excel减少BI使用者的数量，那他们就可以节省BI许可证成本。不过，BI厂家也在逐渐加宽“使用者”的定义，一个BI使用者已经不再是某一个登录BI工具的个人，而是所有能够接到BI工具输出（包括电子数据表）的人。

既然限制Excel是不可能的，关键就是找到既提供Excel集成又能保证单一版本真相的方法。各个厂家实现这个目标的方法也不同。最差的，所谓“零支持”就是一次性输出到Excel，既没有对该输出的查账索引，也没有连接到中央的查询。所谓“良好的支持”是指，BI工具跟踪Excel电子数据表的所有权及所做变化，然后把数据表存储在BI仓库中。

Excel电子数据表可以随着新数据更新，特别是能保持与原始查询文件的连接。需要指出的是，没有任何单一特性能够保证单一版本真相，它的实现部分依赖于厂商提供的功能特性，部分依赖于你必须执行的流程。

例如，MicroStrategy的Office产品就是一个Excel插件，可以使用户查询及更新一个存在于电子数据表环境或PowerPoint和Word中的报表。当原始报表的定义或基础数据变化时，电子数据表也随之变化。同样的报表浏览可以通过Web、桌面或电子数据表来完成，这样使用者可以通过他们喜欢的界面来访问，从而也保证了单一版本真相。

把数据一次性输出到Excel是企业保持单一版本真相的最大挑战，但好像也是最普遍存在的一种现象。如果你浏览的报表并不是按照你的需求过滤或分类，你只是简单地存储数据到Excel并在那里做分析，BI团队必需事先有准备：如果很多使用者都这样工作，BI团队就必须在本地BI工具中提供更好的协作性，或修改标准报表定义。不过，如果是个别需求，那另当别论。

最后还要指出一点，在关注Excel集成时，应该注意需要哪个版本的Excel，以及跨越版本是否有功能上的差异。

OLAP

有些分析家认为OLAP（Online Analytical Processing，在线分析处理）只对小部分用户适用。但现在大家普遍认为，从断断续续的信息消费者到强大用户（power user）都能从OLAP功能的不同方面获益。不幸的是，OLAP体系结构和成本经常会阻止其广泛采用。

OLAP vs.报表

早在20世纪90年代，Essbase（当时为Arbor所拥有，现在是属于Hyperion）被看做是另类，所以Arbor雇佣关系数据库之父——E. F. Codd来澄清这一称为OLAP的新东西。Codd定义了12条准则，但以下4条最能清楚地把报表和OLAP区分开来：

1. 多维的：用户从多方位分析数值，如产品、时间、地理等。但一个报表一般都是基于单一尺度，如在某一个时间点上的产品价格列表。

2.快速：当使用者在一个维度中操纵不同的维度及等级时，OLAP意味着快速——思考的速度。如果一个使用者双击以从年度到季度钻取，为一个答案等待24分钟或24小时是不可接受的。当然，报表使用者也并不想要慢的报表，但实际中确实很多报表必须运行这么长时间。

3. 改变聚合的等级：为确保可预测的查询时间，OLAP供货商以不同方法重新聚合数据。相反，报表至少是需要细节：除了按照产品的销量外，对于特定顺序的数据，其中可能还有单独的排列项。

4. 跨纬度的计算：多维带来了复杂的计算。在OLAP中，你可能需要分析百分比贡献或市场份额，这些分析需要先做某一特定状态的销售小计，然后再计算对整个区域、国家或全球的百分比贡献。使用者可能通过许多其他维度来分析这个百分比市场份额，如实际vs.预算，今年vs.去年，或为特定的一组产品等。这些计算经常必须以特殊的顺序执行，并包含使用者从来没有见过的一些输入数字。但是，详细的报表经常依赖于简单的小计或报表本身显示的一些数值的计算。

不过记住一点，我们仅仅是对报表和OLAP加以区分，并不意味着使用者需要他们的分析工具和报表工具截然不同。OLAP使用者应该从多维数据中创建报表，相反，报表消费者也需要从前仅供OLAP 专用的高度形象的分析和红绿灯显示。怎么满足这些不同的需求，厂商们也已经奋斗了很多年。当你选择一种或多种BI工具时，你的工作是了解你最需要什么：OLAP，报表，还是两者。如果答案是两者都要，那么就需要仔细评估报表和OLAP的集成。

OLAP体系结构

在选择OLAP工具时，OLAP体系结构是需要理解的一个最重要的标准：它会影响很多其他单独特征以及你部署系统的能力。最近人们认为MOLAP-ROLAP-DOLAP（多维OLAP-关系型OLAP-桌面OLAP）争辩已经平息。我认为，只要厂商还提供这些不同的方法，争论就会存在。

MOLAP使用一种持久稳固的立方体结构，与关系型数据库是分离的。Hyperion Essbase、Microsoft Analysis Services、Cognos PowerPlay都是使用了这种方法。因为一个立方体包含一个预先计算好的数据子集，所以与DOLAP和ROLAP相比响应时间更快速且可以预测。MOLAP数据库传统上还具有更大程度的多维计算，比ROLAP中也更容易实现。例如，Hyperion Essbase使用一个

@DESCENDANTS功能，让你将一个特定级别中的成员指向同一层次（如，一月、二月、三月并列

是第一季度的下一级）。尽管一些关系数据库具有CASE功能，也可以使你在一个计算中指向这些行，但并不是所有都能做到，而且计算并不一定都是直截了当。

MOLAP的大幅下降是因为它是需要IT支持、管理、维护的另外一种数据存储。公司抱怨维护200个立方体需要很多努力，或公司拥有的是花费一个星期重新计算的设计不良的立方体，这都是很平常的。当一个维空间改变，如增加一个新的产品或改组业务单元，你可能就不得不重新计算整个MOLAP 立方体。

而关系型OLAP是使用关系型表格来提供多维分析，MicroStrategy和Informatica是主要的ROLAP厂商。MicroStrategy使用RDBMS中的分区和聚合表格来提供快速查询;为实现复杂的OLAP计算，它使用了一个multipass SQL和临时表格的结合体。

ROLAP工具没有单一立方体的限制，但却因低的响应时间而苦恼。如果你公司没有技术型DBA来熟练调整数据库，获取一个用户钻取的结果可能需要25分钟的查询。历史上，在MicroStrategy

中的一个钻取经常会触及最根本的关系表格。不过有了MicroStrategy的OLAP Services后，钻取会访问缓存，这也是对“ROLAP先天就比MOLAP慢”的有力还击。

很多MOLAP厂商使用ROLAP和MOLAP相结合的方法，这种方法被称为hybrid OLAP（HOLAP）。例如，Microsoft Analysis Services就能够使用ROLAP体系结构来对付大数据量；Hyperion Essbase也能在关系型表格中存储大量维空间。像其他ROLAP工具一样，其响应时间还是要比严格使用MOLAP慢，所以很多执行继续使用MOLAP存储来保证快速分析。

DOLAP代表桌面OLAP，是因为很多处理需要在使用者的桌面来完成。也有人把它叫做动态OLAP （dynamic OLAP），以突出微小的立方体是如何动态创建的，也许在桌面上，但大多是在中间层的应用服务器上。与MOLAP不同，这种情况IT部门不需要提前创建大型立方体，而是当使用者运行查询时动态创建立方体。相比MOLAP和ROLAP，其一个立方体中的数据量和维空间计算是有限的（尽管也可以达到GB级别）。这些立方体更适合看做是个人立方体。

DOLAP的最大好处是灵活性和维护：立方体不需要提前创建，当你公司增加一个新产品或重组部门时，这些变化也将在你更新查询的时候自动表现。不过，DOLAP工具同样也遭受与ROLAP一样的RDBMS性能的所有风险。

由于具有从多种数据源中抽取数据的能力，MOLAP工具经常被成功应用于小数据仓库的平台。这对于企业信息架构来说显然是不理想的。因此，来自多种数据源的数据最好能装入一个中央数据仓库中，然后才能用于组装MOLAP立方体。尽管，在实际中一些公司没有构建数据仓库的能力和资金，但具有数据仓库结构的MOLAP立方体确实能受益于快速的立方体创建。对Business Objects的microcube来说，一个立方体可以基于多种查询、存储的流程、XML文件及电子表格等来创建，Cognos PowerCubes和Hyperion Essbase cubes也能从多种数据源创建。

另外，对一个管理者来说，能够很轻松地设计、构建并调整OLAP平台是非常关键的。对于最终使用者来说，诸如属性分析、假定性分析、红绿灯显示、时间周期分析等也是非常重要的。

管理

管理方面的特性可能并不会引起商业使用者的兴趣，但却同样重要。好的部署应该既考虑到最终使用者的需求，也考虑到BI工具的管理问题。如果没有全面考虑二者，企业最终所有的无非两种结果：看似很好但需要相当的IT资源来维护的工具，或没有人使用的系统。

安全性

我承认，我憎恶BI安全。并不是说我没有看到需求，而是厌恶跟踪更多的用户ID和口令！没有什么比当一个BI使用者很高兴地访问仪表盘时却总被“不正确的口令”所折磨能更快地扼杀BI执行。一个教训是：你可能花费了大量时间来选择BI工具，但如果你没有花费足够时间计划安全性，工具早晚会被破坏及登录错误击垮。

安全可以分为两个阶段，首先是鉴定(authentication)——一用户名和口令的有效性；第二步是授权（authorization）——在鉴定以后允许其访问什么。LDAP (Lightweight Directory Access Protocol)服务承诺将多用户ID和密码问题减到最少。理论上，一个公司将拥有一台目录服务器来保存所有员工的用户名和密码。公司所有的系统，无论是网络、BI或ERP，都使用该目录服务器来鉴定。现在，还没有目录服务的清晰标准。Sun的iPlanet、Microsoft Active Directory、Novell

的eDirectory 是业界比较领先的产品。BI厂商会支持其中一些或全部。

由于历史的及实际的原因，大多BI工具继续使用它们自己的鉴定机制。如果你公司还没有实现目录服务器，你就需要这些机制；如果你已经有了目录服务器，你就需要BI工具来鉴别它。

授权比鉴定更杂乱。在授权中，你可能需要限制一些用户使用特定的业务浏览或元数据层、个别报表、软件功能以及数据等。理想状态，你需要定义角色（role）或用户组（groups of users），以便这些授权能够在组级实现，而不是直接针对上千的个人用户。这里有一个很大的挑战：即使你有一个LDAP服务器来做授权，你也不得不在BI工具中复制所有个人用户的ID来为授权服务！这种复制会带来风险——诸如用户ID或密码等一些东西有可能失去同步性。然而，如果你能够在目录服务器中定义组，并且BI工具能够读这些组，那还是有希望的。很明显，很多BI厂商在向这个方向靠拢。

元数据

元数据集成（Metadata integration）提供很多承诺。首先，它能减轻业务视图的管理；其次，它能给需要对每个metric的来源、转换以及计算有一致的、精确定义的业务使用者带来更大的透明。

不过，这些也仅仅是承诺。在实际中，BI基础架构中的每个组件都有自己的元数据，并为不同的目标而使用。一方面，这种情况存在是因为元数据已经被当做每个组件的“私有品”来对待，另一方面，也是因为每个组件都有自己的要素。使用BI工具的业务使用者需要业务术语，使用ETL工具的IT 部门则需要知道确切的来源系统、表格名称以及数据元素的起源地。是否要赋予数据元素一个商业术语对IT用户来说并不重要。

从BI套件来看，你应该考虑你需要共享什么元数据？在哪些组件之间共享？过去，BI厂商采取不同的方法来共享数据，经常是提供专有的API。随着来自Object Management Group的CWM (Common Warehouse Metamodel)被大家接受，厂商们很快就开始提供支持。后来，Business Objects和Cognos还使用了MITI (Meta Integration Technology Inc.)提供的一种遵循CWM 的元数据桥（metadata bridge）。SAS的Enterprise BI Server version 9也在元数据交换方面做了创新。这些都是为元数据交换而走出的很好一步。

影响分析

影响分析（Impact analysis），是指当你改变或删除一个数据元素的时候，能够知道哪些报表将受到影响的这样一种能力。影响分析在BI架构的不同点都有关。如果是源系统中发生改变，你怎么能够知道在业务视图以及最终的报表中什么将改变？如果是在业务视图中发生改变，这种变化是否能够自动传达到报表中？至少，管理员需要有能力识别BI套件中相互依赖的BI元素。

Business Objects的ETL工具Data Integrator，就同元数据层或universes有很好的影响分析。然而，其元数据设计工具Designer 内的影响分析却很少。MicroStrategy的影响分析工具更进一步：当你试图删除一个对象时，它立即会警告你哪些报表依赖于该对象。

使用监测

不能监测BI系统的使用，就如同在夜晚不开前灯和仪表盘驾驶汽车一样。最糟糕的情况就是你（或你的服务器）被撞坏，最好也不过你把汽油耗尽（或查询失败）。随着BI厂商越来越把目标锁定企业范围的部署，它们也开始注重提供使用监测功能。最初，厂商把BI行为记录在log文件中，很少在分析应用中使用。理想的情况应该是当数据在关系数据库中被捕捉到时，厂商提供预建报表；此外，管理员应该能决定哪些行文是要监测的，从大量的注册直到谁访问哪个目标等。

MicroStrategy通过其以服务器为中心的架构，在提供监测BI使用的工具方面一直是领导者。Business Objects也从2001年就推出了其Auditor产品，随后Cognos、Crystal、Informatica 等都推出此功能。

不过需要提醒的是，数据库监测和BI监测并不相同。在数据库层面，你可能会跟踪数据库领域ORDER.QTY被访问的频度；在BI应用中，却需要知道哪些计算出的metric用户最常访问，还包括哪些标准报表、哪些展示格式以及最大负荷时间等。

BI工具架构

最后，我们来关注结构方面的一些考虑因素，以便能够结合上下文帮助你找到适合自己企业的最好BI工具。BI架构的很多方面是从厂商的演示过程中得不到的，如：是client/server还是基于Web？使用了什么OLAP方法（MOLAP、ROLAP、DOLAP）？该BI工具是否能容易地定制或嵌入到其他应用中？该套件在查询、报表、OLAP、仪表盘以及分析应用等不同工具间使用的框架（元数据、安全以及基础架构）是否是通用的？该服务是否能跨越多个服务器和平台分布？很多BI套件架构方面的不同，也许只有当你安装、部署或定制产品的时候才能清晰体会到。

SOA

由于BI已经走向Web以及企业范围部署应用，今天的BI工具都具有服务导向的架构，即SOA （Service Oriented Architecture）。SOA允许不同的BI服务去执行特定的任务，必要的时候还可以分布到多个服务器上。

图2 BI工具的SOA7:BI应用服务器可以运行在一个Web服务器上，也可以运行在一个特定的应用服务器上。

我们以三个可能的BI服务举例来说：查询、展现以及时序安排。如图2所示，查询引擎负责查询数据源，可能是一个数据仓库或MOLAP立方体。当查询完成后，展示部件必须将查询结果转换成有意义的报表，也可能是图表和交叉表，而且还需要不同文件格式，如HTML或PDF。如果一个用户预定了某一个查询的时间，时序安排服务就会不断地监测是否到了已预定查询的执行时间，并在准确的时间把它传递给查询服务。查询、展示以及时序安排之间如何沟通，这就是诸如COM、CORBA、Web services协议等标准起作用的时候了。当然也有一些BI厂商会使用自己专有的方法来处理这些部件之间的通信。COM和CORBA是支持SOA的比较老的方法，Web services标准正处在高速发展期，其接受度和功能都在不断提升。

可扩展性架构

有趣的是，好像所有的BI工具都具有向上和向外扩展的能力：如果你添加更多强大的硬件（向上扩展），它就可以支持更多的用户；如果你添加更多服务器（向外扩展）并分布服务，它也能支持更多用户。然而，很多企业的目标是降低复杂性和成本。撇开对容错的考虑，如果所有的东西都高效地运行在一台服务器上，你就节省了硬件和管理的成本。

很不幸，目前针对BI工具还没有供对比产品用的基准测试。而且，使用和部署产品的方法也会影响其可扩展性。如，更新Business Objects全部客户机文件比更新其最新的瘦客户机文件就要更耗费资源。对MicroStrategy来说，数据仓库中聚合的表格越少以及一个报表模板中使用的过滤器越少，系统就越慢。

不管如何，你也可以根据一些特性来初步观察某一产品套件对资源的占用：OLAP体系结构、多线程的流程、查询管理器、高速缓存等。查询管理器可以使管理员防止饱和系统中的复杂及有害查询。好的BI工具都提供查询管理器，这样可以方便控制并发查询进程的数量、每一次查询返回的行的数量、以及一次查询运行的时间。理想状态，这些限制应该在每个服务器、用户组、不同任务或个别用户等不同级别中被定制。

另一种将这种服务器负荷风险减少到最小的方法是高速缓存。如果一个查询更新的请求能够通过高速缓存服务，那么并发查询进程就会减少。高速缓存还可以帮助BI架构中的其他服务，如授权和展示服务。当然缓存的重要性也是由特定工具的架构决定的。如MicroStrategy提供广泛的缓存，包括SQL、元数据甚至查询结果。管理员对指定什么获得缓存以及监测缓存是否使用都可以有良好控制。

总结

本文的目的是帮助大家了解什么BI功能是重要的以及原因。逐个功能比较是选择BI工具的一个方法，但并不是惟一方法。如同你购买轿车的时候，也许你购买福特的原因是你想购买美国品牌，而你选择通用可能是因为你的邻居就是其经销商，或许你购买Hummer是因为你喜欢其形象。同样的无形的及策略性的考虑也会出现在选择BI套件的情形。每一个BI厂商都有一套独特的BI策略。像Business Objects、Cognos、Hyperion这些主要竞争者都追求BPM（business performance management，业务性能管理），但方法却有截然不同。

每个厂商也都有各自独特的“最佳听音点（sweet spot）”、历史起源、以及对BI范围的观点。有一些厂商已经把BI范围扩展到包括数据库、ETL工具以及分析应用等。而有的厂商仍然坚持核心的查询、报表、OLAP三大功能。到底哪一种更好，这完全取决于你的出发点。如果你已经有了ETL工具，你是否还真正关心BI厂商是否提供一种不同版本？确实，还有一些协作性考虑，如元数据交换、安

全等，但在眼下的BI市场，协作性问题对于把目光锁定在同一供货厂的BI工具的公司以及从多家厂商购买工具的公司来说都有挑战。

坦白来说，在目前BI市场，可能没有任何一家厂商在所有功能领域都显著领先。而且，最好的BI 工具也并不是市场份额就能决定的，也并不在于谁先出现在这个市场上，而是看谁能够最有效地使用户实现他们的商业目标。