fbpx

用}StatsByRule提高规则性能--第一部分

有了TM1,你将有更多的时间进行分析和其他有价值的活动,而不必放弃Excel。 Cubewise将告诉你如何做。

最近,Cubewise Code部门写了一篇很棒的文章"写更快的IBM TM1和规划分析规则的7个技巧"。他们展示了不同的技术,告诉你如何编写规则以提高其性能。我在今年巴黎的欧洲Cubewise会议上也介绍了同样的主题,我认为值得介绍一下它的背景和一些实际案例。在这篇文章中,我想重点介绍一下"为什么"、"如何"和"何时"你可以衡量规则的性能。

功能性数据库

IBM Planning Analytics powered by TM1是一个实现功能数据库的例子--多维内存OLAP数据库和类似电子表格的单元格导向计算引擎之间的结合。多维性允许设计一个反映公司业务复杂性的模型,并允许以数据透视表的方式进行快速和高效的分析。TM1使用独特的稀疏数据合并算法,允许创建具有大量维度和字面上难以想象的潜在单元格数量的巨大立方体.每个单元格,就像在Excel中一样,可以是一个简单的输入值,也可以是一个从不同单元格计算出来的函数,而这些单元格又可以是简单的值或函数。这些计算被称为"规则",是TM1建模的核心,因为它们允许你对业务所需的所有复杂性进行建模。 

"为什么"你应该监控规则性能

TM1 \ PA具有极高的可扩展性,可以处理庞大的数据集。规则提供了实时计算的功能,从不同的模块中收集信息,并给出一个关于模型计算结果的可靠答案。它们的开发相对简单、快速,可以随着业务的发展而变化,以反映不断变化的需求。但是,就像有人说的那样--权力越大,责任越大。当你编写规则时,同样的结果可以通过不同的方式获得。每次你计划设计规则的时候,你应该在脑海里有一些东西。

  1. 模型的可维护性
    • 有时候,硬编码的规则更容易,也更节省时间。但驱动因素的设置可能会改变。你可以预见到这一点!创建参数立方体来存储驱动程序,增加了灵活性,减少了未来的维护。
    • 你不可能预见一切。因此,规则应该易于理解,并在未来由你或你的同事进行调整。
  2. 可追溯性--用户可以使用追溯功能来了解数值是如何计算的。特别是在比较复杂的计算中,可以显示出什么是数据流。
  3. 性能--规则必须足够快,以便在可接受的时间范围内计算出结果。

有些目标是矛盾的,不一定能全部实现,所以必须做出妥协。在规划分析2.0之前,测量不同计算方法的性能是很复杂的,因为没有工具。开发人员在编写规则时,通常相信自己的经验、直觉和神话。有时他们使用秒表来检查规则计算的速度。

"如何"监测规则

在规划分析2.0版本中,当}StatsByRule立方体被添加到TM1的性能监控器中时,情况就变好了。现在您可以监控每个规则被调用的次数以及计算每个规则行所需的时间。

启用和启动规则性能监控非常容易。你只需要将一个立方体的"RULE_STATS"属性设置为"YES",然后启动性能监控。

现在,每次用户或进程查询立方体中的规则计算值时,Performance Monitor都会跟踪统计数据,并将结果写入}StatsByRule立方体。对于该机制的工作原理,你需要注意一些事情。

  • 性能监控(TM1的子进程)监控统计数据,并以60秒的时间间隔将结果写入}StatsByRule cube。因此,有时你需要等待一分钟才能看到完整的测量结果。
  • 您可以在性能监控器运行时更改您要监控的立方体的配置,但同样需要一分钟的时间来接收更改。
  • 您可以通过两种方式触发统计捕获:刷新包含由规则驱动的单元格的视图(来自任何用户界面),或通过CellGetN运行将使用相同单元格的TI。
  • 性能监控器存储递增的统计数据。每次执行视图或运行TI时,它都会将最新结果添加到总体结果中。
  • 监控规则计算有一个性能开销。这个功能一般应该在开发中使用,而不是在生产中使用。
  • 清除立方体中的统计数据不会重置它们。性能监测器将在每个时间间隔后恢复累计结果。
  • 重置统计可以通过以下方式实现: 1:
    • 关于立方体的保存规则
    • 重新启动性能监控器
    • 重新启动TM1实例

当你打开}StatsByRule立方体时,你会发现它有三个维度。带立方体列表的}Cubes,带监控规则起始行的}LineNumber和带统计措施的}RuleStats。

  • 规则文本--监控规则的前99个字符。忽略换行字符,文本只显示在一行中。
  • 总运行次数--规则被执行的次数。
  • 最小时间(ms)--最快的规则执行时间,单位为毫秒。由于有很多情况下,单条规则的计算时间低于一毫秒,所以这个时间往往可以为零。
  • 最大时间(毫秒)--规则执行的最长时间。如果这个值看起来不合理地高,可以用来跟踪有问题的情况。
  • 平均时间(毫秒)--基于其他两个测量值的计算结果。总时间(毫秒)/总运行次数。一般来说,这是一个比最小或最大更好的统计数字,因为这些统计数字可能是异常值。
  • 总时间(毫秒)--计算规则行所需的总时间(总运行次数x平均时间)。

当你开始分析时,首先要检查的是总时间(ms)的测量。你应该关注执行时间最长的规则。使用Code文章中的技术,你可以尝试不同的方法,使规则更快。

有时您可能会发现,被确定为慢的规则可能不是导致问题的原因。当对规则执行情况进行测量时,总的时间会作为结果显示出来,包括其他被调用的规则的前期依赖性计算。例如,我们假设在立方体A中发现该规则的执行时间为1011毫秒。经过对数据流的分析,似乎有一个计算链来提供一个结果。从C到B,从B到C的数据传输执行正常。出现问题的核心原因是C立方体C执行分配缓慢。

馈线也可以使用}StatsByRule Cube进行分析。馈线显示的时间还包括被测量的那个馈线执行的所有其他馈线的时间。运行计数显示的是某一馈线被发射的次数,而不是馈线单元的数量。如果喂料机的总运行次数较低,但执行时间较长,则很有可能在喂料机链中存在过度喂料。

虽然测量的结果是非常精确的,可以指出有问题的地方,但你需要记住,结果是针对环境的,即使在相似的模型上,也会给出不同的结果。影响规则性能的一些因素是:

  • 立方体的稀疏性
  • 在立方体中的尺寸顺序
  • 维度元素的数量
  • 规则使用的字符串长度
  • 服务器上的资源(如CPU核数、CPU速度)。
  • 实例配置
  • 服务器硬件

"何时"衡量规则执行时间

分析规则性能是一项耗时的任务,特别是当你尝试不同的技术来加快它们的速度时。你不应该在生产服务器上运行它,因为在做分析时可能会出现实例稳定性的问题。如果你试图纠正规则性能,并经常改变规则,这是开发的正常事实,你可以期待调节差异,锁和其他通常的嫌疑人。

我认为主要有三种情况下值得花力气检查规则性能。

  • 排除系统性能故障--你注意到了性能的下降。在大多数情况下,规则是在比生产环境中使用的数据集更小的数据上测试的。有时,数据量随着时间的推移而增加,直到达到有问题的大小。
  • 在开发过程中优化规则--我通常会在可能是重度的立方体上检查规则。要么会存储大量的数据,要么会进行重计算和分配。
  • 学习--虽然有些能提高性能的技术只在特殊情况下使用(如维度阴影),但其他的技术(如短记号而不是长记号)应该成为你的习惯。

在下面的文章中,我将展示我如何对客户数据库进行分析,并将展示所使用的不同技术的比较。如果你觉得这部分很有趣,我强烈建议你阅读第二部分,因为其中的一些发现相当吸引人,有时甚至是反直觉的。