IBM Business Analytics 最佳实践: Dynamic Cubes - 近实时和跨数据库的查询

简介

本文档的目的

IBM Cognos Dynamic Cubes 在静止数据的处理上具有很大的性能优势。在如今瞬息万变的业务环境中，还需要减少数据的过时程度或数据的刷新频率。该需求的一些示例可能包括：在财务流程快结束时进行了一项调整，而且立刻将结果显现出来，以确保获得正确的数据；或者在销售环境中同时需要最新的数据和历史数据来帮助发现趋势和改善业务成果。

本文要求读者掌握一定的 IBM Cognos Dynamic Cubes 和 IBM Cognos Cube Designer 知识，还要求读者拥有深入的多维数据集建模知识。有关多维数据集建模的更多信息，请参阅 IBM Cognos Dynamic Cubes 红皮书 和 Dynamic Cubes 用户指南 。本文将描述两个主要的概念：

• 将对缓存的和感知聚合的历史数据结构的高性能查询与应用了新数据和增量修改的近实时数据结构结合使用的能力。
• 在两个支持的关系数据库管理系统 (RDBMS) 上完成此工作的能力。

请注意，引入第二个 RDBMS 通常是因为需要执行跨功能的分析，例如，账单仓库在 DB2 中，而收益仓库在 SQL Server 中。在这种情况下，IBM Cognos Dynamic Cubes 可在一个虚拟多维数据集中包含多个基础多维数据集，后者具有存在部分不同的结构（粒度和维度数据），以显示哪些客户发票已收回了所有款项。本文假设这些数据结构都是相同的，而且将通过涵盖不同的数据库平台来实现近实时性。

这种近实时分析技术在同一个 RDBMS（比如 DB2）中得到应用的可能性更大一些。本文决定使用两种不同的 RDBMS 引擎来演示更复杂的环境。

回页首

实现近实时 Dynamic Cubes 的方法

该方法源于 IBM Cognos Dynamic Cubes 红皮书 中简短描述的 时间分区 方法（请参见本文末尾处的参考资料部分），但将增量多维数据集设置为近实时的。这种场景相对简单，适合绝大部分数据都是历史数据而且不会更改的情形。

新数据（插入新行、增量修改或删除行）可能仅适用于当前时段。类似地，对于绝大部分数据，可以提供最需要缓存的数据，对历史时段执行聚合和其他优化，而不是让当前时段占用更小的比例。数据量越大，重新填充缓存、计算数据库中的聚合和加载内存中的聚合所花的时间就越长，因此在当天重新填充优化并不总是行得通。通过基于周期性来拆分数据，可以减少频繁重载这些优化的需求。

解决方案是基于易变性来拆分数据，将不变的数据放在一个（或多个）多维数据集中，将实时数据放在另一个多维数据集中。这意味着不需要频繁地加载和计算最佳选择（比如摘要表），而且实时数据很少，足以执行动态聚合。尽管按照易变性和静态数据集来拆分数据也有这样的好处，但对于本文，我们将按照历史和当前时段来拆分数据。该日期并不是指数据集中的日期，而是输入更改的数据的日期 - 在当前时段执行增量修改，但可以将它应用到过去的交易记录上。

根据所涉及的数据量，我们可以按照历史、当月和当天来划分不同的动态多维数据集，其中只有当天的动态多维数据集没有利用聚合缓存。然后，我们可以将物理多维数据集进行组合，以便创建一组虚拟多维数据集，这样就可以将所有数据组合到一个虚拟多维数据集来进行报告。

出于简单性考虑，本文只有一个包含不变数据的 历史多维数据集 和一个实时的 当前时段多维数据集 ，后者是根据当前时段更改的数据而构建的多维数据集，没有聚合或数据/结果集缓存。图 1 显示，这些历史和当前时段多维数据集可合并到一个虚拟多维数据集中，供用户用于创建报告。

图 1 - 实时 Dynamic Cube，其中的历史和当前时段多维数据集被合并到一个虚拟多维数据集中

请注意，IBM Cognos BI 10.2 中的一个虚拟多维数据集目前仅组合了两个多维数据集。但是，一个可能是虚拟多维数据集，因此支持将多个历史数据多维数据集链接在一起。

回页首

环境

此练习的环境是一个简单的虚拟机，它运行着所有需要的组件。图 2 显示了此环境的各个部分，包括

• IBM Cognos Dynamic Query Analyzer
• IBM Cognos BI 10.2 单服务器安装
• Firefox 10.0.11 和 Internet Explorer 8 Web 浏览器
• Microsoft IIS 7.5 Web Server
• IBM DB2 10.1，运行 IBM Cognos BI Content Store 并包含 1 亿行遗留数据
• Microsoft SQL Server 2008，包含实时数据集

图 2 - 为本文使用的环境的结构图

这个虚拟机还用于处理其他工作负载，因此所需的内存比这里使用的数据量所需的内存还要大。例如，在测试期间，该系统实际上只使用了不到 8 GB 的 RAM。

回页首

数据集描述

本文中使用的数据集，是标准 IBM Cognos GO Sales 示例的一个修改版本，表示为一种星形模式。出于本文的用途，我们将重点介绍建模和交付技术，而不是实际数据。由于需要聚合合理的数据量，可能存在一些重复的数据。有两个数据集：一个包含在 IBM DB2 数据库中，另一个包含在 Microsoft SQL Server 数据库中。

DB2 数据集

表 1-8 详细描述了来自 DB2 数据源的每个维度的结构。一个维度中每个级别的成员数量有助于提供数据稀疏水平的背景信息。

表 1 - Products 维度

表 2 - Order Method 维度

表 3 - Periods 维度

表 4 - Slice 维度

表 5 - Retailer 维度中的类型

表 6 - Retailer 维度中的位置

表 7 - Staff 维度

表 8 - MainFact 事实表

MainFact 事实表中的总行数为 100,825,767。

SQL Server 数据集

表 9-16 详细描述了来自 SQL Server 数据源的每个维度的结构。一个维度中每个级别的成员数量有助于提供数据稀疏水平的背景信息。

表 9 - Products 维度

表 10 - Order Method 维度

表 11 - Periods 维度

表 12 - Slice 维度

表 13 - Retailer 维度中的类型

表 14 - Retailer 维度中的位置

表 15 - Staff 维度

表 16 - MainFactRT 事实表

回页首

多维数据集设计

两个多维数据集的设计是相同的，除了为 Millennium 和 Quarter 级别使用的计算方法之外，其中的结果值是相同的，但使用了特定于 RDBMS 的函数。作为调优练习的一部分，DB2 历史数据集还添加了一些优化。这些优化包括数据库聚合（摘要表）和内存中聚合（in-memory aggregate），并启用了数据和结果集缓存。

本文首先在没有历史多维数据集优化的情况下测试，以便执行相关的时间对比。

具有单个雪花维度的星形模式如图 3 所示，添加了分层结构和级别。该图显示了雪花维度中部的 MainFact 表，该维度中还连接了 Large_Periods 、 Staff_Dimension 、 Order_Method_Dimension 、 Slice 、 Retailer_Dimension 和 Product_Dimension 表。Product_Dimension 表还连接了 Product_Type ，后者进而连接到 Product_Line ，以完善 Products_Dimension 需要的关系。

图 3 - 历史数据的星形模式图

回页首

测试报告

本测试中使用的报告是针对两个用途而设计的：模拟简单的临时导航和模拟可在未来保存为报告输出的更复杂的分析。表 17 列出了本文后面将引用的报告名称。IBM Cognos Insight 应用程序中创建的报告和数据可用于简化结果分析。

表 17 - 测试报告名称

图 4 是一个简单的报告，显示了对所有数据的初始临时查询，显示了每种产品线的不同订购方法的总行数。请注意突出显示的圆圈，它显示返回的总行数为 100,825,767。

图 4 – Basic Crosstab Products by Order Method 报告

图 5 显示了一个简单的交叉表报告，它模拟了在最大的产品线 (Mortgages) 上的下钻分析，显示抵押产品类型中不同订购方法的行数。

图 5 – Drill Down by Products 报告

图 6 演示了用户上钻到每个产品线中不同订购方法的总行数的原始视图。

图 6 – Drill Up 报告

图 7 显示了一个交叉表报告，它更改了报告结构，以便模拟不同时间的用户调查情况 - 每个产品线中不同时间的总行数。在本例中，1000s 和 2000s 列指该日期所属的世纪。例如，1996 属于 1000s 列。

图 7 – Replace Columns 报告

在图 8 中，用户可下钻以调查当前世纪。

图 8 - Drill Down to Years 报告

在图 9 中，用户列出了两个年份、两个季度和 3 个月份中所有产品类型的总行数。

图 9 - Multi Level Set 报告

图 10 显示的报告与图 9 相同，但这一次通过计算显示了 2012 年 6 月对 2012 年全年的贡献比例，然后显示了贡献最大的 5 个产品类型。

图 10 – Multi Level Calculate and Top 报告

图 11 显示了用于计算前 5 大产品类型的方法。通过使用属性 Set Definition ，将 Top or Bottom 属性设置为 Top Type 并将 Number of items 设置为 5 来完成计算。

图 11 - 图 10 中使用的前 5 大产品类型的计算方法

图 12 是一个简单的报告输出，列出了不同切片的总行数，其中只有实时切片有所不同。

图 12 - Real-time Test 报告

回页首

计时方法

计时全部采直接在 Dynamic Query Analyser (DQA) 界面中运行报告时，DQA 中显示的总查询时间。

图 13 - Dynamic Query Analyzer 中显示的查询处理时间总计报告

两个底层 RDBMS 未在不同测试之间重新启动，可能该层的任何数据或查询计划缓存会让结果稍微有点失真。因此，报告执行了 3 次，然后采用了它们的平均值。

因为该环境是虚拟的，所以其他工作负载也有可能导致结果变化。在适当的情况下，Dynamic Cubes 会在每次运行后重新启动，惟一的例外是合并的虚拟多维数据集，重新启动它会影响历史多维数据集层上的一些缓存的优势。

最后，在执行所有调优后，每次运行都有两次迭代：一次初始运行和一次重新运行，以便凸显数据和结果集缓存的优势。

为了方便在调优的历史数据与近实时的合并数据之间进行比较，来自最后一个调优阶段的结果被复制到了 Final times (1st run) 和 Final times rerun 中。前面已经提到过，所有计时都记录在一个 IBM Cognos Insight 应用程序中，以方便进行结果分析。

回页首

Historic 多维数据集

描述

这个星形模式仅包含 1 亿行静态数据，建模方式与所有正常的 Dynamic Cube 都相同。然后，该多维数据集有一个优化周期，应用工作负载来提高性能。

尽管 1 亿行较少，但它为我们提供了一个基准，在调优之前，报告的查询运行总时间平均值为 585.54 秒（接近 10 分钟），我们要查看调优的影响，并在以后与近实时的多维数据集进行对比，这个时间已经足够长了。

配置多维数据集

我们根据这种星形模式构建并部署了一个 Dynamic Cube 模型，然后使用该部署进行初始计时。使用 Aggregate Advisor 生成两个数据库的摘要。内存中聚合以及一些手动创建的摘要（并非建议结果的一部分）是从上一个练习中添加的。IBM Cognos BI 为聚合缓存使用的最大量的内存从默认的 0 MG 更改成了 1024 MB（图 14），以便提供足够的内存来保存该多维数据集所需的内存中聚合。

图 14 - 聚合缓存内存设置

对于这一数据量，Aggregate Advisor 推荐的内存中聚合总计需要 190MB 的 RAM。有关此过程和 Dynamic Cubes 的更多信息，请参阅 IBM Cognos Dynamic Cubes 用户指南 中的 Cognos Dynamic Cubes 管理 章节或 IBM Cognos Dynamic Cubes 红皮书 。

报告计时

图 15 给出了显示报告计时的 IBM Cognos Insight 报告，演示了任何摘要聚合的影响都很大。简单地添加内存中聚合和使用 IBM Cognos Dynamic Cubes 内置的聚合感知功能，将报告总运行时间从 585.54 秒缩短到了 0.92 秒。该图还显示，Drill Up 报告（报告 3）和 Multi Level Calculation and Top 报告（报告 7）花费的时间从未超过 0.01 秒。

图 15 – 调优结果（以秒为单位）

如果将该视图更改为毫秒，可以看到 Drill Up 和 Multi Level Calculation and Top 报告在所有调优级别上都具有一致的性能，最慢的查询在 6 到 7 毫秒之间（图 16）。

图 16 - 调优结果（以毫秒为单位）

所有调优级别上具有类似性能的原因对于每个报告是各不相同的。Drill Up 报告（报告 3）实际上能够重用来自 Basic Crosstab Products by Order Method 报告（报告 1） 的结果集，因此不需要查询数据库，而且在上钻到上一个视图或以不同格式输出结果时，数据缓存和结果集缓存会对临时查询有所帮助。对于 Multi Level Calculation on Top 报告（报告 7），查询时间也是一致的。这是因为来自 Multi Level Set 报告（报告 6）的数据缓存是可重用的，但数据缓存上执行的计算和 topcount 函数需要额外花费 5 毫秒的时间。这不仅证明了混合查询引擎的价值，还显示了用户在执行计算和其他操作时，分析可以为用户带来的好处。

如图 17 所示，重新运行 Drill Up 报告（报告 3）最终的平均时间，几乎比仅使用数据库中聚合多 1 毫秒的时间，而且内存中结果也稍微慢一些。报告 1 和 3 基本上是相同的查询，出现此差异，部分原因是环境中的波动，这也显现出了在用户执行计算和其他操作时分析能够为用户带来的好处。

图 17 - 报告 1 和报告 3 的报告执行结果

添加内存中聚合后，计算性能很快，抵消了创建一个结果集缓存及从数据缓存中重新计算和检索数据的需求，因为查询时间从 340 毫秒缩短到了 73.99 毫秒。 Minimum query execution time before a result set is considered for caching (milliseconds) 设置确定了导致需要创建结果集缓存的性能特征。此设置可以在 Query Service using IBM Cognos Administration 的 Tuning 属性中找到，默认值为 50 毫秒（图 18）。

图 18 - 针对需要缓存的最短查询执行时间的 Dynamic Cube 高级设置

使用结果集缓存会减少成本，但对于不足 50 毫秒的查询（从数据缓存检索为 0.88 毫秒，初始内存中聚合计算为 73.99 毫秒），是不值得维护的。

如果忽略标记为 1 No Aggregates run 的列，那么在所有报告上使用结果集缓存的影响就会清晰地显现出来，由于需要直接查询超过 1 亿行，这会让此时间失真。图 19 显示了一些结果。当没有任何形式的预先创建的聚合的情况下运行时，Basic Crosstab Products by Order Method 报告（报告 1）的初始运行显示，初始运行时间是 122,268.60 毫秒。与此相比，利用了数据库聚合的第二次执行的报告执行时间下降为 340.94 毫秒，使用了内存中聚合的第三次执行的报告执行时间下降为 73.99 毫秒。在 Replace Columns 报告（报告 4）上也会看到类似结果，其中初始运行时间是 242,232.15 毫秒，第二次运行是 205.37 毫秒，第三次运行是 12.05 毫秒。

图 19 - 显示了初始运行结果与利用了缓存的结果的报告计时

有趣的是，对于 Drill Down to Years 报告（报告 5），内存中聚合的添加将总运行时间从 74.01 毫秒增加到了 102.407 毫秒。这是由于在更细粒度上创建了数据库中摘要。与内存中聚合相比，这与该报告更匹配，而且会被首先选中。实际上，这并不是一种好的模式，因为它需要维护一个没有多少价值的数据库中摘要。对于临时查询，更大的数据库中聚合可带来更好的结果。出于本文的用途，我们将忽略这一点，因为平均查询时间上的差异小于 50 毫秒，而且重新运行实际上会使用缓存，这会抵消一部分优势。

最终，查询性能得益于聚合的使用。缓存和混合查询在所有报告中都很重要，它们可以将总运行时间从几分钟降低到几毫秒。

回页首

近实时的多维数据集

描述

近实时的多维数据集在结构上等同于历史数据集。基础表中仅填充了 150 万行，以模拟一天中的负载，使用一个存储过程，以平均每秒 362 行的速度添加数据。

除了 Dynamic Cubes 需要的成员缓存之外，所有缓存都已禁用，而且没有使用聚合。

配置实时多维数据集

在发布并运行多维数据集后，我们需要禁用缓存。在 IBM Cognos Administration 中，请选择 Status 选项卡并选择 System 。单击要下钻到的服务器，然后单击 Dispatcher 并选择 QueryService 。从这里，您可以管理任何已发布到该 Dispatcher 的 Dynamic Cube。右键单击 QueryService ，从菜单中选择 Set properties （图 20），然后选择 Settings 选项卡（图 21）。

图 20 - 在 IBM Cognos Administration 中设置 QueryService 的属性

图 21 – Query Service 的 Settings 选项卡

在 Settings 选项卡下，单击 Dynamic cube configurations 条目的 Edit... 链接（图 22），然后单击实时多维数据集的 Edit configuration 图标，该多维数据集在本例中名为 MainFactRT （图 23）。

图 22 - QueryService Settings 选项卡

图 23 - Dynamic Cube 配置

确保 Disable result set cache 复选框已启用， Data cache size limit (MB) 被设置为 0，并且 Disable external aggregates 复选框已启用（图 24）。设置之后，单击 OK 3 次返回到主屏幕，保存更改。

图 24 - Dynamic Cube 属性

我们需要等待将更改写入 Content Store，然后再返回到 Dynamic Cube 服务器，等待 30 秒的时间看足够了。然后可以重新启动这个多维数据集，在重新启动该数据集之后，可以从报告输出中看到，这个多维数据集现在已经能够近实时的工作了。在 IBM Cognos Administration 中，选择 Status 选项卡并选择 System 。单击要下钻到的服务器，然后单击 Dispatcher 并选择 QueryService 。右键单击该 Dynamic Cube，在本例中为 MainFactRT ，然后选择 Restart （图 25）。

图 25 - 实时多维数据集的 ueryService 菜单显示了重新启动选项

在实时数据库中载入数据后，可以看到相应产品和订购方法的行数在缓慢增加，我们现在有一个类似将实时数据载入生产数据库中的真实场景的系统。

报告计时

由于没有进行数据库中或内存中优化，所以结果中排除了它们。在第二运行时，重新运行的性能会得到改善，不过这是因为 Dynamic Cube 资源已加载并准备好，而且数据层上具有改进的 RDBMS 查询运行和计划缓存。图 26 显示了第一次运行与接下来 6 次报告执行的平均值之间的报告执行时间差异。查询性能平均增长了 45%。

图 26 - 实时报告计时

这在 Dynamic Query Analyzer 中可以得到一定程度的证明。对于一次示例报告运行，对数据库执行查询的数据检索时间为 361 毫秒，而总处理时间不到 379 毫秒。第二次运行为 60 毫秒，总处理时间为 93 毫秒。在两种情况下，数据查询外的处理花费的时间约为 30 毫秒。这些结果可在图 27 中看到。

图 27 - Dynamic Query Analyzer 结果显示了不同报告运行的数据检索时间

XCubeRetrieval进程表示一个对底层 RDBMS 的查询。分析发出的查询后，我们发现每次运行的查询都是相同的。使用的一个查询示例：

SELECT   "Order_Method_Dimension"."Order_Method_Key" AS "Order_Method_Dimension_Order_Method_Key" ,  "Product_Type"."Product_Type_Code" AS "Product_Dimension_Product_Type_Code" ,  SUM("MainFactRT"."Total Rows")AS "Total_Rows"  FROM   "DQMSampleDataRT"."dbo"."Order_Method_Dimension" "Order_Method_Dimension"   INNER JOIN "DQMSampleDataRT"."dbo"."MainFactRT" "MainFactRT"  ON "Order_Method_Dimension"."Order_Method_Key" = "MainFactRT"."Order_Method_Key"  INNER JOIN "DQMSampleDataRT"."dbo"."Product_Dimension" "Product_Dimension"   ON "Product_Dimension"."Product_Key" = "MainFactRT"."Product_Key"   INNER JOIN "DQMSampleDataRT"."dbo"."Product_Type" "Product_Type"   ON "Product_Dimension"."Product_Type_Code" = "Product_Type"."Product_Type_Code"   INNER JOIN "DQMSampleDataRT"."dbo"."Product_Line" "Product_Line"   ON "Product_Type"."Product_Line_Code" = "Product_Line"."Product_Line_Code"  WHERE   "Product_Line"."Product_Line_Code" IN (1 ) GROUP BY   "Order_Method_Dimension"."Order_Method_Key",  "Product_Type"."Product_Type_Code"

在 RDBMS 工具内发出相同查询时，我们可以证明该数据库事实上能够更快地完成同一个客户端的请求。图 28 直接摘自 RDBMS 查询工具统计数据，不包含任何 IBM Cognos 组件。该图显示，此次查询第一次运行花费的时间为 855 毫秒，后续运行花费的时间为 149 到 158 毫秒，即使数据已发生更改。如果不进行进一步的分析，那么可以得出这样的结论，RDBMS 在缓存中保存了一些数据页，新数据仍在缓存中，而且几次查询是连续运行的，因此可以提高性能。

图 28 - 在 RDBMS 工具中执行的查询的执行计时

运行其他查询时，这一优势就会消失，所以在下一次迭代中，我们看到了相同的效果。只有在 Dynamic Cube 第三次重新启动并运行时，第一次和第二次运行的结果才一致。

通过对 RDBMS 执行进一步跟踪分析，可能会发现存在的差异，但是，由于结果仅存在一两秒的差异，而且本文关注的是 Dynamic Cubes 而不是底层的 RDBMS，所以我们将忽略这一异常。

随着数据的不断添加，基础查询花费的时间变得更长，预计实时多维数据集上的后续查询可能变得变慢。对于我们的虚拟化环境中的结果，对 150 到 300 万行增量数据运行的所有查询花费的时间在 87 毫秒到 1.7 秒之间，这一性能对我们的基础架构而言是可接受的。

回页首

虚拟多维数据集

虚拟多维数据集在系统中发挥着重要作用，因为在这里，通过将历史和近实时多维数据集合并到一个多维数据集中，我们添加了调优的静态数据和不断改变的数据。对于我们的测试，历史多维数据集已全部缓存来模拟真实场景，而报告连续运行两次，每次运行都会重复该过程 3 次。

如何创建和配置虚拟多维数据集

使用 Cube Designer ，转到 Project Explorer 窗格，右键单击 Model ，选择 New ，然后选择 Virtual Cube （图 29）。

图 29 – 在 Cube Designer 中创建一个新的虚拟多维数据集

在 Select Base Cubes 对话框中，选择历史多维数据集 Large Sales Dynamic Cube 和实时多维数据集 MainFactRT （图 30）。

图 30 - Select Base Cubes 对话框，其中已选定 Large Sales Dynamic Cube 和 MainFactRT 多维数据集

如果所有数据都在同一个数据库中，那么各个维度可能相同并自动匹配。在某些情况下，比如本例中，它们具有不同的名称，因为它们来自不同的来源。我们需要定义虚拟维度将如何合并底层的多维数据集维度和度量 - 引用维度应该在键上进行合并。这在创建的虚拟多维数据集的属性中完成（图 31）。

图 31 - 虚拟多维数据集维度映射

我们需要删除所有与历史维度不匹配的实时维度，方法是从编辑器窗格中删除它们。接下来，我们需要确保在两个物理多维数据集之间正确地映射了类似的多维数据集。图 32 显示了用于在 Large Sales Dynamic Cube 和 MainFactRT 多维数据集之间映射类似的维度的映射对话框。两个多维数据集都包含一个产品维度，但 Large Sales Dynamic Cube 包含一个名为 Products 的维度， MainFactRT 多维数据集产品维度名为 Product_Dimension 。要映射该维度，可以选择多维数据集中与您希望合并的维度相对应的省略号，然后在单选对话框中，从该多维数据集中选择您希望合并的维度。

图 32 - 虚拟多维数据集维度映射选择来源对话框

下一步是确保虚拟维度中的分层结构也建立了映射。双击每个虚拟维度，确保为正确的分层结构建立了映射。如果分层结构具有相同的名称，那么系统会为您自动完成此操作，否则您需要选择基础多维数据集中的每个维度下的省略号，并选择正确的分层结构，确保选择了正确的分层结构。在图 33 中，可以看到虚拟多维数据集中的 Order Methods 维度将来自一个多维数据集的 Order Methods 分层结构映射到来自另一个多维数据集的 Order_Method_Dimension 。

图 33 - 虚拟多维数据集维度属性

最后，双击每个虚拟分层结构，检查每个多维数据集中的各个级别，确保它们已经对齐。图 34 显示了 Periods 和 Large_Periods 分层结构中使用的各个级别已合并到虚拟多维数据集中的 Periods 分层结构中。可以看到，在本例中，所有级别名称都已匹配，但是，如果它们在您的多维数据集中并没有匹配，那么您需要选择与多维数据集中要建立映射的目标级别相对应的恰当的级别名称。

图 34 - 虚拟多维数据集时段分层结构级别映射对话框

对于这个近实时的示例，级别名称都应该是匹配的，但是，如果我们合并了来自同一个数据库或不同数据库的不同主题区域，那么它们可能不匹配，分层结构中可能有额外的维度和级别。我们需要确保度量值已使用求和运算符进行正确合并。在图 35 中，我们选择了虚拟度量值 Quantity ，并将属性 Merge Operator 更改为了 Sum 。这将确保在使用 Quantity 时，结果是从两个底层多维数据集拉取的值的求和预算结果。

图 35 - 虚拟多维数据集度量值映射对话框

计算的度量值（比如 Total Cost）也可用在许多区域。可以使用一个计算方法来计算 Quantity 和 Unit Cost 的乘积，而不是将度量值存储在 RDBMS，并导致检索总和的开销以及聚合和摘要的计算开销。对于多主题区域，比如销量和收益，可以使用一个已计算的度量值来表示订单总额与收益的差。

另一个不错的性能例子是求平均值，比如 Average Sales Total。无需让数据库计算平均值并潜在地避免摘要的使用（需要根据基本的事实来计算平均值），一种不错的做法是在摘要表和基础表中包含一个总行数度量值。然后，我们可以对 Average 使用已经计算出来的度量值，将想要的度量值除以总行数。然后就可以高效地使用已存在的摘要和缓存。有关摘要和缓存的使用的更多信息，请参阅文末参考资料部分中的 IBM Cognos Dynamic Cubes 红皮书 。

最后，需要在虚拟多维数据集上禁用结果集缓存和数据缓存。有关这些设置的更多信息，请参阅 配置实时多维数据集 一节中的步骤来编辑虚拟多维数据集定义。图 36 显示了实时多维数据集的属性。 Disable result set cache 复选框已启用， Data cache size limit (MB) 设置为 0，这将禁用结果集缓存和数据缓存。

图 36 - 禁用结果集缓存和数据缓存的虚拟多维数据集设置

在有多个历史多维数据集的系统中（例如包含名为 History All Years、History Month 和 Real-Time 的多维数据集），可以证明将两个历史多维数据集放在一个启用数据缓存和结果集缓存的虚拟多维数据集中会更好。实时多维数据集可将对完整历史聚合数据的每天重新构建工作延迟到月末，这样，您只需重新构建当前的每月优化，无需每天都重新构建。这样做可以节省内存和处理，因为历史和每月多维数据集都禁用了缓存，而且从优化的多维数据集重新计算数据缓存的开销可能很小。然后，我们采用本文中描述的相同方式，将使用第二个虚拟多维数据集来合并历史虚拟多维数据集和实时多维数据集。

虚拟多维数据集的报告计时

从图 37 中所示的结果中可以看到，一个报告的总查询时间最多 1.31 秒，证明可高效地针对由历史和实时数据组成的虚拟多维数据集运行相同的报告。在包含更改数据的 1 亿多行的结果集中，在这个基础架构上，这样的结果被认为是可接受的。

图 37 - 第一次运行与再次运行的虚拟多维数据集报告计时对比

如果对比第一次运行与第 2、3 次运行，可以看到一致性上存在细微的差别（图 38）。一些报告上的第一次查询运行似乎比后续的再次运行慢 1 秒左右。在此测试中，多维数据集并未重新启动，所以历史缓存的好处是完全可以实现的，在 Dynamic Cube 服务器资源和 RDBMS 页面缓存开始发挥作用后，第 2 和 3 次运行更一致。可能会看到毫秒级的细微差异，这可能是因为虚拟化的环境在争用资源。

图 38 - 虚拟多维数据集的第 1、2 和 3 次运行计时

回页首

总报告计时

计算所有场景的结果时，不包含变化的数据或优化的 1 亿多行的数据集的报告运行总时间平均值接近 10 分钟（586 秒）。添加变化的数据且系统优化后，报告运行总时间平均值下降到 4 分钟以下（3870.17 毫秒）。

如果我们仅查看优化的历史数据的报告运行总时间平均值，就会发现结果低于 15.85 毫秒，所以可以推断，仅实时数据和虚拟多维数据集的添加，就向查询的处理增加了 3854.32 毫秒。实际单独对近实时多维数据集测试的总运行时间平均值大于 4096.02 毫秒。在各个报告上可以看到此结果，有时会看到一些奇怪的异常（图 39）。

图 39 - 所有报告的历史、实时和虚拟多维数据集计时

下面的结果显示，在虚拟多维数据集中添加近实时的数据的影响微乎其微。图 40 显示，除了 3 个报告（Multi Level Set、Multi Level Calculation 和 Top and Basic Crosstab Products by Order Method）之外，实时数据和多维数据集优化的添加实际上会导致报告执行时间下降 28 - 151 毫秒。甚至在执行时间增加的报告中，也仅增加了 14 - 147 毫秒的时间。这些结果对实际用户没有切实影响。

图 40 - 虚拟多维数据集和实时多维数据集之间的时间差异

在此示例中，与基础实时运行相比，大多数平均查询时间实际上都减少了。这部分归因于并行处理虚拟多维数据集的能力（也可在 Dynamic Cubes 中实现），而在每次运行后不重新启动多维数据集，这也意味着底层 RDBMS 在相同连接上的执行性能比新连接上更好。此效果可在图 41 中看到，其中第一次运行显示针对虚拟多维数据集的报告的总执行时间为 4337 毫秒，而针对实时多维数据集的执行时间为 3437 毫秒。图 42 显示了第二次运行的性能改进，其中虚拟多维数据集上的报告总执行时间为 3581 毫秒，对实时多维数据集的报告执行时间为 4110 毫秒。

图 41 - 对虚拟多维数据集和实时多维数据集第一次运行报告所花的时间对比

图 42 - 对虚拟多维数据集和实时多维数据集第二次运行报告所花费的时间对比

总体来讲，这些结果表明一个与底层数据库建立了连接的正在运行的系统，可在超过 1 亿行的数据量上运行近实时的查询。事实上，您甚至可在更大的数据量上执行临时查询，只要实时数据集足够小，就能够在可接受的时间内返回结果。

回页首

近实时多维数据集配置

在整篇文章中，我们都使用了 近实时 的表述。部分原因在于数据不是实时传输的。我们需要在请求输出时查询数据，查询中的延迟可能意味着数据已发生细微变化。当然，这有点吹毛求疵，在大多数情况下，能够在请求结果后的 1 秒内看到一个视图就被视为是实时的。我们说这是近实时的主要原因是，多维框架（所有维度成员和它们的属性）是在多维数据集启动时加载的。在本文使用的示例中，这不是问题，因为没有创建新成员，所有实时数据都使用了已经存在的键（比如 Products）。甚至时间和日期都已全部填入。如果需要刷新成员缓存来容纳新成员，IBM Cognos BI 提供了功能来完成此任务。

刷新成员缓存时，会将新缓存从数据库中载入内存中，然后在准备好后与正在运行的缓存相交换。这具有一定的性能优势，在运行成员刷新查询时不会对用户请求排队，但是在托管 IBM Cognos BI Dispatcher 的服务器上需要更多 RAM，该服务器托管着该多维数据集才能在刷新时持有成员缓存的两个副本。

刷新成员缓存的最有效方法是创建一个可在随后调度或触发的 管理任务 。在 IBM Cognos Administration 中，选择 Configuration 选项卡，并在左侧窗格中选择 Content Administration 。单击 New Query service administration task 下拉菜单，然后从出现的菜单中选择 Dynamic cube... （图 43）。

图 43 - 用于刷新 Dynamic Cube 的 New Query Service administration task

为新任务提供一个名称，这里使用了 Reload Dimensions - 如果愿意，您还可以输入一段描述和屏幕提示。单击 Next 按钮（图 44）。

图 44 – 使用 New Query Service Administration Task wizard 对话框指定任务名称

从 Operation 下拉菜单中选择 Refresh member cache 选项，确保 Server Group 和 Dispatcher 已正确设置。仅为实时多维数据集创建此任务，因为此操作将强制刷新虚拟多维数据集的成员缓存。不要对历史多维数据集执行此操作，因为它会强制重新加载所有内存中聚合并让缓存失效，进而影响历史数据性能。为此，您需要确保仅在 Cubes 节中的列表中选择了 MainFactRT 多维数据集（图 45）。

图 45 - 完成的 Dynamic Cube 任务选项

单击 Next 按钮，在 Select an action 屏幕中将 Action 设置为 Save and schedule 并单击 Finish （图 46）。

图 46 – 保存并计划 Query Service 的新管理任务

图 47 中所示的报告在运行该管理任务之前运行，显示包含历史多维数据集中的 1,600,409 行数据的实时数据切片（不包括种子行），添加到实时数据库（由 RT Slice 表示）中的行数为 47,421。

图 47 - 该报告显示了任务执行之前的成员

执行管理任务，对于此模型，总刷新时间约为 2 秒。对于包含数百万个成员的更大的多维框架，此时间可能增加，所以应执行测试。管理任务运行后，我们现在可看到包含 1 行的新成员 RT New Member ，而 RT Slice 现在拥有 72,302 行数据（图 48）。

图 48 - 该报告显示了在任务执行后添加的 RT 新成员

值得强调的是，此管理任务可按计划运行，运行间隔可小至几分钟，或者您可以基于外部触发器来运行此管理任务。对于可检测到新成员插入的系统，可以使用触发器确保多维框架仅在需要时更新。例如，Event Studio 可以检测到成员数量的变化，然后执行一个管理作业来刷新成员缓存。对于较小的多维框架，使用 Event Studio 会对维度表运行查询带来开销，这可能抵消按计划的时间刷新成员缓存带来的好处。

回页首

数据的转存 (Roll-Over)

由于实时多维数据集的性能依赖于数据量和存储该多维数据集的 RDBMS，所以需要采用一种合适的机制来将提交的实时行转移到历史数据集中。由于转存也需要更新历史聚合和重载内存中聚合，所以转存的频率需要与实时数据量达到平衡。

尽管更为复杂，但这种方法使得使用多个历史多维数据集更具优势，而且可以减少中间的转存次数。转存数据的过程是一个简单的概念，可以使用 ETL 工具以及简单 SQL 脚本来执行以下任务。

1. 将数据从实时事实表转移到历史事实表。
2. 如果维度不同，那么可以向历史维度添加新成员。
3. 更新历史多维数据集的数据库中聚合。
4. 为所有多维数据集插入一个重新启动命令。

简单的刷新历史和实时多维数据集上的成员缓存，具有与重新启动这些多维数据集类似的效果，因为所有优化和缓存都将刷新，而且可以最大程度地减少宕机时间，但代价是需要额外的 RAM 来处理更改。

为了创建一个作业来重新启动所有多维数据集，可创建 3 个不同的查询服务管理任务，并将它们添加到单个作业中。创建管理任务的过程已在前一节中介绍，其中只有从 Operation 下拉列表中选择的任务是不同的。第一个任务应该使用 Stop immediately 或 Stop after active tasks complete 操作来停止虚拟多维数据集，第二个任务应该使用 Restart 操作来重新启动基础多维数据集并确保已选中它们，第三个任务应该使用 Start 操作来启动多虚拟多维数据集。

接下来，我们将创建一个 新作业 （图 49）来组合这 3 个任务，以便按照某种特定的顺序执行任务，然后在 Name 字段中键入 Restart Near Real-time （图 50）。要按顺序执行任务，可以按照您希望执行它们的顺序将它们添加到作业中，确保选择了 In Sequence 单选按钮（图 51）。

图 49 - 在 Cognos Administration 中创建新作业

图 50 - 键入新作业的名称和描述

图 51 - 包含按顺序执行的任务的新作业

此作业现在可用于手动重新启动整个多维数据集集合，采用交互方式或基于计划来运行该作业。在许多情况下，最有用的计划选项是使用触发器，因为该作业可由一个外部进程（比如 ETL 进程）调用。

您应该注意到，第一次停止虚拟多维数据集是由于 IBM Cognos BI 10.2 需要停止所有依赖的虚拟多维数据集，才能重新启动一个多维数据集。

包含多个多维数据集的系统的影响

通过本文您已经看到，一般而言，使用虚拟多维数据集可以最大限度减少查询时间开销。但是使用多个多维数据集以及像本例中一样使用一个虚拟多维数据集，具有相关的成本。此成本包括处理需求的增加，因为需要更多线程来处理并行执行。Dynamic Cubes 能够从多 CPU 计算能力中受益，而且这可能在改善单个复杂查询的性能方面发挥着重要作用。

您应该已经注意到，对于包含多个多维数据集的系统，需要足够的 RAM。在 IBM Cognos BI 10.2 中，每个多维数据集需要它自己的维度成员缓存。如果成员缓存在一个多维数据集运行时刷新了，那么还需要足够的 RAM 来存储该成员缓存的副本。这是为了最大程度减少对查询的影响，因为一旦加载了新成员缓存，它们就会替换掉当前的成员缓存。实际上，这意味着对于这种近实时的方法，最多需要的 RAM 是成员缓存的 6 倍。对于较小的系统，这可能具有极小的影响，但对于大型系统，对 RAM 需求的影响可能明显加大。

有关服务器调整的更多信息，请参阅本文 “参考资料” 部分中引用的文章 Dynamic Cubes 硬件调整建议 。

回页首

结束语

综上所述，IBM Cognos BI 10.2 中的 Dynamic Cube 功能不仅能够在大型数据集上带来显著的性能优势，方便历史查询的执行，而且还能向数据集中添加近实时的信息，以便在需要执行迭代式调整和多个报告周期的大数据量上执行报告。

尽管和预料的一样，实时数据的添加降低了系统的总体性能，但只要在合适的基础架构上正确地平衡历史数据和实时数据（而且该基础架构包含具有需要的查询性能的 RDBMS 和合适的数据管理制度），就能将它们用于需要近实时的数据和可接受的响应时间的场景。

此外，对不同的 RDBMS 平台的使用表明，只要维度表已复制，而其主要的事实数据可从单个表中检索，就可以使用一个经过过滤的操作系统（或镜像的事务数据库）和一个仓库实现此目的。

一定要注意的是，您可能需要度量对操作系统的影响，以便查找可使用镜像技术缓解的潜在问题，同时仍然提供近实时的报告。出于充分的理由，IBM Cognos BI 10.2 和 10.2.1 版仅支持星形和雪花模式，而且即使可以使用事务系统上的视图为实时元素创建星形结构，也不建议这么做，因为这些视图的性能可能会影响查询时间。

尽管可能不需要这样做，但两个 RDBMS 的使用已表明，虚拟多维数据集可合并来自两个不同的数据仓库的信息。在拥有多个数据仓库战略，或者一个应用程序（比如财务系统）和另一个应用程序（比如资产管理系统）都拥有自己的现成仓库的组织中，这可能有助于执行多主题区域分析。