简介这份PDF资料聚焦IBM Cognos TM1中FEEDERS机制的最佳实践面向已掌握Cube、维度、规则等基础概念的中高级TM1开发者帮助解决规则计算导致稀疏数据聚合算法失效、立方体性能下降的难题。内容围绕SKIPCHECK与FEEDERS的配合使用展开涵盖FEEDERS的定义与工作原理、条件feeder的写法、Underfeeding与Overfeeding的成因及规避策略并强调feeder只作用于叶级单元、合并元素在feeder语句中的特殊行为等易错原则。资源包共1个PDF文件约993KB篇幅精炼适合作为开发过程中的速查手册。目前已有596人学习。读者可从中获得一套可落地的feeder编写思路如何从规则逆向推导feeder、如何用条件feeder缓解Overfeed、何时该启用SKIPCHECK以及避免内存膨胀与查询变慢的排错方向对提升OLAP系统响应速度具有实际参考价值。1. TM1 Feeders 到底在解决什么问题从一次凌晨三点的规则重算说起如果你维护过 IBM Cognos TM1 的规则模型大概率经历过这种场景白天改了一条规则晚上跑数据加载原本十分钟能跑完的立方体重算硬是拖到两三个小时还没结束服务器 CPU 打满用户第二天早上打开报表发现数字还是旧的。翻日志、查规则、逐条注释最后发现罪魁祸首是一条没写 Feeders 的规则或者写了一条范围过大的 Feeders导致 TM1 在计算时把整个立方体都标记成了「需要重算」。TM1 Feeders 就是干这个的它告诉 TM1 引擎哪些单元格的计算结果会影响到其他单元格从而让引擎在重算时只处理真正需要更新的部分而不是全量扫描。没有 FeedersSKIPCHECK 打开后规则计算会漏数Feeders 写得太宽性能直接崩掉。这个标题讲的就是怎么把 Feeders 写对、写准、写快适合已经上手 TM1 规则、被性能问题折磨过的从业者也适合刚接触 SKIPCHECK 和 Feeders 配合机制、想少走弯路的开发者。2. SKIPCHECK 与 Feeders 的配合机制为什么开了 SKIPCHECK 就必须写 Feeders2.1 SKIPCHECK 到底跳过了什么TM1 的规则引擎默认会对立方体中每个单元格都执行一遍规则判断哪怕这个单元格没有数据、规则条件根本不成立。立方体维度一多、数据量一大这种全量遍历就是性能杀手。SKIPCHECK 的作用是在规则文件开头声明对于没有数据的单元格如果规则条件不满足引擎直接跳过不再逐条规则去试。但跳过之后会带来一个副作用如果某个单元格本身没有数据但它的值是通过规则从其他有数据的单元格推导出来的SKIPCHECK 会让引擎误以为这个单元格不需要计算结果就是报表上该出数的地方是空的。Feeders 就是用来补这个漏洞的——它显式地告诉引擎当某个源单元格有数据时请把对应的目标单元格标记为「需要计算」。# 规则文件开头声明 SKIPCHECK SKIPCHECK; # 一条典型的规则用销售额乘以汇率得到本币金额 [本币金额] N: [销售额] * DB(汇率立方体, !年份, !月份, USD, 本币); # 对应的 Feeders当销售额有数据时标记本币金额需要计算 FEEDERS; [销售额] [本币金额];这段代码里SKIPCHECK 放在规则最前面FEEDERS 块放在所有规则之后。逻辑说明规则部分定义了本币金额的计算方式Feeders 部分告诉引擎「销售额」这个源区域的数据变化会影响到「本币金额」这个目标区域。参数说明N:表示这条规则只对数值型单元格生效!年份和!月份是维度变量DB()函数用于跨立方体取数。如果没有最后那行 Feeders当销售额从外部导入时本币金额不会自动重算报表上就是空的。2.2 Feeders 的标记传播逻辑Feeders 不是直接计算公式它做的是一件事在内存中维护一张「依赖关系图」。当源单元格被写入数据时引擎沿着这张图找到所有被标记的目标单元格把它们加入重算队列。这个过程是单向的、批量化的所以 Feeders 的效率取决于两个因素标记的范围是否精确以及依赖链是否过长。常见做法是让 Feeders 的维度和规则保持一致的粒度。比如规则里用了DB()跨立方体取汇率Feeders 里就不需要再为汇率立方体写额外的标记因为汇率通常是静态数据不参与频繁重算。但如果规则里用了ATTRS()或者ELPAR()这类依赖维度属性的函数Feeders 就要考虑属性变化时是否需要触发重算。我一般会遵循一个原则Feeders 只标记那些会因外部数据加载或用户输入而变化的源单元格对于纯静态的维度属性、常量表不写 Feeders避免无谓的标记扩散。2.3 一个最小可复现的 Feeders 示例假设有一个销售立方体维度是年份、月份、产品、度量。度量维度包含销售额、成本、毛利。规则要求毛利 销售额 - 成本。下面是在 TM1 Architect 或 Performance Modeler 中可以直接粘贴的规则和 Feeders。SKIPCHECK; # 毛利计算规则 [毛利] N: [销售额] - [成本]; FEEDERS; # 当销售额或成本有数据时标记毛利需要计算 [销售额] [毛利]; [成本] [毛利];逻辑说明两条 Feeders 分别声明销售额和成本是毛利的源。参数说明N:依然表示数值型规则。操作步骤是打开立方体的规则编辑器粘贴上述内容保存后执行一次CubeProcessFeeders或者通过 TI 进程调用CubeProcessFeeders(销售立方体)让 Feeders 生效。验证方法是往销售额和成本里各输入一个数看毛利是否自动算出再把 SKIPCHECK 注释掉对比重算时间通常能看到明显差异。提示修改 Feeders 后必须重新处理 Feeders否则引擎用的还是旧的依赖图。在 Architect 里可以通过右键立方体选择「Process Feeders」来完成。3. Feeders 的常见写法与性能陷阱从全量标记到精准打击3.1 用 DB() 跨立方体取数时 Feeders 怎么写跨立方体取数是 TM1 规则里最常见的操作也是最容易把 Feeders 写崩的地方。假设销售立方体里有一条规则从汇率立方体取汇率来换算本币金额。SKIPCHECK; [本币金额] N: [销售额] * DB(汇率立方体, !年份, !月份, USD, 本币); FEEDERS; [销售额] [本币金额];这里 Feeders 只标记了销售额没有标记汇率立方体。原因在于汇率立方体通常是手工维护或定期导入的静态数据它的变化频率远低于销售额。如果给汇率也写 Feeders每次汇率更新都会触发所有销售记录的本币金额重算代价太大。常见做法是汇率更新后单独跑一个 TI 进程强制重算本币金额而不是依赖 Feeders 自动触发。参数说明DB()函数的第一个参数是立方体名后面依次是各维度的元素引用。!年份和!月份是当前立方体的维度变量直接传给汇率立方体使用。如果两个立方体的维度名不一致需要用DB()的维度映射语法比如DB(汇率立方体, !年份, !月份, USD, 本币)要求两个立方体的年份和月份维度同名。3.2 条件 Feeders 的写法与边界有时候规则里带了 IF 判断Feeders 也要相应地加条件否则会标记过多或过少。SKIPCHECK; [奖金] N: IF([销售额] 100000, [销售额] * 0.05, 0); FEEDERS; [销售额] [奖金];这条 Feeders 没有加条件意味着只要销售额有数据奖金就会被标记重算。即使销售额小于 100000奖金算出来是 0引擎也会走一遍计算。如果数据量很大这种无条件的 Feeders 会浪费大量计算资源。优化写法是给 Feeders 也加上条件FEEDERS; [销售额] DB(, !年份, !月份, !产品, 奖金);但 TM1 的 Feeders 语法不支持直接在左边写 IF 条件。变通做法是在规则里用一个辅助度量来标记或者接受这种粒度因为 Feeders 的标记本身是轻量级的真正的开销在于被标记后的规则计算。如果 IF 条件里的判断字段本身也是规则算出来的那就要小心循环依赖。我一般会评估如果条件过滤掉的数据比例超过 70%就值得用辅助列或者 TI 进程来替代 Feeders 自动触发如果过滤比例不高直接写无条件 Feeders 更简单维护成本更低。3.3 Feeders 范围过大的典型症状与排查Feeders 写得太宽最直接的表现就是数据加载后重算时间异常长。比如下面这条FEEDERS; [销售额] [毛利], [本币金额], [奖金], [税额], [净利];一条 Feeders 标记了五个目标如果这些目标之间还有依赖关系标记会继续传播。排查方法是打开 TM1 的}StatsByCube立方体看FeedersCount和FeedersTime两个指标。如果 FeedersCount 远大于实际有数据的单元格数说明标记范围过宽。另一个常见问题是 Feeders 里用了!维度变量但维度顺序写错。比如立方体维度顺序是年份、月份、产品、度量Feeders 里写成了[销售额] DB(, !产品, !年份, !月份, 毛利)维度错位会导致标记到错误的单元格表现为某些该算的没算不该算的算了。解决方法是保持 Feeders 里的维度顺序和立方体定义一致或者用DB()时显式写出所有维度。4. Feeders 避坑指南五条血泪经验4.1 现象数据加载后报表数字不更新手动重算才出数原因Feeders 漏写或者 Feeders 里的源区域没有覆盖到实际数据加载的维度组合。比如数据加载时写入了「销售额」的某个产品版本但 Feeders 只标记了另一个版本。解决检查 Feeders 的源区域是否和规则里引用的源单元格完全一致。可以用CubeProcessFeeders强制刷新然后往源单元格写一个测试值看目标单元格是否自动变化。如果不变化逐条注释 Feeders 定位漏网的那条。4.2 现象规则保存时报「Feeders 循环引用」错误原因Feeders 的依赖关系形成了环。比如 A 标记 BB 标记 CC 又标记 A。TM1 在保存规则时会检测这种循环并拒绝。解决画出依赖图找到环上的边把其中一条 Feeders 改成由 TI 进程手动触发。常见做法是打破跨立方体的循环让一个方向走 Feeders另一个方向走 TI。4.3 现象重算时间随数据量线性增长Feeders 数量爆炸原因Feeders 用了过于宽泛的维度引用比如[销售额] [毛利]没有限定任何维度导致所有年份、所有月份、所有产品的销售额都标记了对应的毛利。如果立方体有 10 年 × 12 月 × 1000 产品标记数量就是 12 万条。解决在 Feeders 里加上必要的维度限定比如只标记当前年份[销售额] [毛利]配合DB()限定年份。或者用 TI 进程在数据加载后只重算受影响的产品范围。4.4 现象SKIPCHECK 打开后某些通过 ATTRS() 取属性算出的值丢失原因Feeders 没有覆盖维度属性变化的情况。ATTRS() 取的是维度元素的属性属性变化不会触发 Feeders 标记因为 Feeders 只跟踪立方体单元格的数据变化。解决对于依赖属性的规则要么在属性更新后跑 TI 强制重算要么在 Feeders 里把属性也作为一个源来标记。但 TM1 的 Feeders 不支持直接标记属性所以通常用 TI 方案。4.5 现象Feeders 处理时间很长}StatsByCube里 FeedersTime 居高不下原因Feeders 的依赖链太长或者 Feeders 本身写在了规则文件里但每次数据加载都重新处理。Feeders 处理是批量操作如果立方体维度多、数据稠密处理时间会很长。解决把 Feeders 处理安排在数据加载之后、用户使用之前避免在高峰时段执行。如果 Feeders 处理时间超过可接受范围考虑用 TI 进程替代部分 Feeders只对受影响的数据区域做定向重算。注意修改 Feeders 后一定要重新处理 Feeders否则引擎用的还是旧的依赖图。在 TM1 Architect 里可以通过右键立方体选择「Process Feeders」来完成在 TI 里用CubeProcessFeeders(立方体名)。5. 用 TI 进程替代 Feeders 的进阶技巧定向重算与性能验证当 Feeders 的标记范围难以精确控制或者依赖链太复杂导致处理时间过长时用 TI 进程做定向重算是一个值得考虑的方案。核心思路是不用 Feeders 自动标记而是在数据加载完成后由 TI 进程根据业务逻辑计算出受影响的单元格范围直接对这些单元格执行重算。下面是一个 TI 进程的代码片段用于在销售额数据加载后只重算受影响产品的毛利和本币金额。# TI 进程定向重算受影响产品 # 参数pYear, pMonth, pProduct # 先关闭 Feeders 自动标记避免重复计算 CubeProcessFeeders(销售立方体); # 用 ViewZeroOut 清空受影响范围的旧值 ViewZeroOut(销售立方体, 受影响视图); # 用 CellPutN 触发规则重算 CellPutN( CellGetN(销售立方体, pYear, pMonth, pProduct, 销售额), 销售立方体, pYear, pMonth, pProduct, 毛利 ); # 重算完成后重新处理 Feeders CubeProcessFeeders(销售立方体);逻辑说明这段 TI 先调用CubeProcessFeeders刷新依赖图然后用ViewZeroOut清空受影响范围接着用CellPutN写入销售额的值触发规则引擎计算毛利。参数说明pYear、pMonth、pProduct是 TI 进程的运行时参数通常从数据加载的源文件或临时立方体中获取。ViewZeroOut需要一个预先定义好的视图视图里包含要清空的维度范围。验证方法是在 TI 执行前后分别记录}StatsByCube里的FeedersCount和CalculationTime对比定向重算和全量 Feeders 的差异。我一般会在测试环境跑三组数据小数据量、中等数据量、大数据量分别记录两种方案的处理时间。如果定向重算在大数据量下优势明显就值得在生产环境推广。另一个技巧是用CubeLockOverride在重算期间锁定立方体避免用户查询到中间状态的数据。但锁定时长要控制好超过几秒钟就会影响用户体验。我自己的习惯是新建立方体时先用 Feeders 快速跑通等数据量上来、性能瓶颈出现后再逐步把热点规则改成 TI 定向重算。Feeders 不是银弹它解决的是「标记哪些需要算」的问题而 TI 解决的是「什么时候算、算多少」的问题。两者配合才能让 TM1 模型在数据量增长后依然保持可用的响应速度。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF资料聚焦IBM Cognos TM1中FEEDERS机制的最佳实践面向已掌握Cube、维度、规则等基础概念的中高级TM1开发者帮助解决规则计算导致稀疏数据聚合算法失效、立方体性能下降的难题。内容围绕SKIPCHECK与FEEDERS的配合使用展开涵盖FEEDERS的定义与工作原理、条件feeder的写法、Underfeeding与Overfeeding的成因及规避策略并强调feeder只作用于叶级单元、合并元素在feeder语句中的特殊行为等易错原则。资源包共1个PDF文件约993KB篇幅精炼适合作为开发过程中的速查手册。目前已有596人学习。读者可从中获得一套可落地的feeder编写思路如何从规则逆向推导feeder、如何用条件feeder缓解Overfeed、何时该启用SKIPCHECK以及避免内存膨胀与查询变慢的排错方向对提升OLAP系统响应速度具有实际参考价值。1. TM1 Feeders 到底在解决什么问题从一次凌晨三点的规则重算说起如果你维护过 IBM Cognos TM1 的规则模型大概率经历过这种场景白天改了一条规则晚上跑数据加载原本十分钟能跑完的立方体重算硬是拖到两三个小时还没结束服务器 CPU 打满用户第二天早上打开报表发现数字还是旧的。翻日志、查规则、逐条注释最后发现罪魁祸首是一条没写 Feeders 的规则或者写了一条范围过大的 Feeders导致 TM1 在计算时把整个立方体都标记成了「需要重算」。TM1 Feeders 就是干这个的它告诉 TM1 引擎哪些单元格的计算结果会影响到其他单元格从而让引擎在重算时只处理真正需要更新的部分而不是全量扫描。没有 FeedersSKIPCHECK 打开后规则计算会漏数Feeders 写得太宽性能直接崩掉。这个标题讲的就是怎么把 Feeders 写对、写准、写快适合已经上手 TM1 规则、被性能问题折磨过的从业者也适合刚接触 SKIPCHECK 和 Feeders 配合机制、想少走弯路的开发者。2. SKIPCHECK 与 Feeders 的配合机制为什么开了 SKIPCHECK 就必须写 Feeders2.1 SKIPCHECK 到底跳过了什么TM1 的规则引擎默认会对立方体中每个单元格都执行一遍规则判断哪怕这个单元格没有数据、规则条件根本不成立。立方体维度一多、数据量一大这种全量遍历就是性能杀手。SKIPCHECK 的作用是在规则文件开头声明对于没有数据的单元格如果规则条件不满足引擎直接跳过不再逐条规则去试。但跳过之后会带来一个副作用如果某个单元格本身没有数据但它的值是通过规则从其他有数据的单元格推导出来的SKIPCHECK 会让引擎误以为这个单元格不需要计算结果就是报表上该出数的地方是空的。Feeders 就是用来补这个漏洞的——它显式地告诉引擎当某个源单元格有数据时请把对应的目标单元格标记为「需要计算」。# 规则文件开头声明 SKIPCHECK SKIPCHECK; # 一条典型的规则用销售额乘以汇率得到本币金额 [本币金额] N: [销售额] * DB(汇率立方体, !年份, !月份, USD, 本币); # 对应的 Feeders当销售额有数据时标记本币金额需要计算 FEEDERS; [销售额] [本币金额];这段代码里SKIPCHECK 放在规则最前面FEEDERS 块放在所有规则之后。逻辑说明规则部分定义了本币金额的计算方式Feeders 部分告诉引擎「销售额」这个源区域的数据变化会影响到「本币金额」这个目标区域。参数说明N:表示这条规则只对数值型单元格生效!年份和!月份是维度变量DB()函数用于跨立方体取数。如果没有最后那行 Feeders当销售额从外部导入时本币金额不会自动重算报表上就是空的。2.2 Feeders 的标记传播逻辑Feeders 不是直接计算公式它做的是一件事在内存中维护一张「依赖关系图」。当源单元格被写入数据时引擎沿着这张图找到所有被标记的目标单元格把它们加入重算队列。这个过程是单向的、批量化的所以 Feeders 的效率取决于两个因素标记的范围是否精确以及依赖链是否过长。常见做法是让 Feeders 的维度和规则保持一致的粒度。比如规则里用了DB()跨立方体取汇率Feeders 里就不需要再为汇率立方体写额外的标记因为汇率通常是静态数据不参与频繁重算。但如果规则里用了ATTRS()或者ELPAR()这类依赖维度属性的函数Feeders 就要考虑属性变化时是否需要触发重算。我一般会遵循一个原则Feeders 只标记那些会因外部数据加载或用户输入而变化的源单元格对于纯静态的维度属性、常量表不写 Feeders避免无谓的标记扩散。2.3 一个最小可复现的 Feeders 示例假设有一个销售立方体维度是年份、月份、产品、度量。度量维度包含销售额、成本、毛利。规则要求毛利 销售额 - 成本。下面是在 TM1 Architect 或 Performance Modeler 中可以直接粘贴的规则和 Feeders。SKIPCHECK; # 毛利计算规则 [毛利] N: [销售额] - [成本]; FEEDERS; # 当销售额或成本有数据时标记毛利需要计算 [销售额] [毛利]; [成本] [毛利];逻辑说明两条 Feeders 分别声明销售额和成本是毛利的源。参数说明N:依然表示数值型规则。操作步骤是打开立方体的规则编辑器粘贴上述内容保存后执行一次CubeProcessFeeders或者通过 TI 进程调用CubeProcessFeeders(销售立方体)让 Feeders 生效。验证方法是往销售额和成本里各输入一个数看毛利是否自动算出再把 SKIPCHECK 注释掉对比重算时间通常能看到明显差异。提示修改 Feeders 后必须重新处理 Feeders否则引擎用的还是旧的依赖图。在 Architect 里可以通过右键立方体选择「Process Feeders」来完成。3. Feeders 的常见写法与性能陷阱从全量标记到精准打击3.1 用 DB() 跨立方体取数时 Feeders 怎么写跨立方体取数是 TM1 规则里最常见的操作也是最容易把 Feeders 写崩的地方。假设销售立方体里有一条规则从汇率立方体取汇率来换算本币金额。SKIPCHECK; [本币金额] N: [销售额] * DB(汇率立方体, !年份, !月份, USD, 本币); FEEDERS; [销售额] [本币金额];这里 Feeders 只标记了销售额没有标记汇率立方体。原因在于汇率立方体通常是手工维护或定期导入的静态数据它的变化频率远低于销售额。如果给汇率也写 Feeders每次汇率更新都会触发所有销售记录的本币金额重算代价太大。常见做法是汇率更新后单独跑一个 TI 进程强制重算本币金额而不是依赖 Feeders 自动触发。参数说明DB()函数的第一个参数是立方体名后面依次是各维度的元素引用。!年份和!月份是当前立方体的维度变量直接传给汇率立方体使用。如果两个立方体的维度名不一致需要用DB()的维度映射语法比如DB(汇率立方体, !年份, !月份, USD, 本币)要求两个立方体的年份和月份维度同名。3.2 条件 Feeders 的写法与边界有时候规则里带了 IF 判断Feeders 也要相应地加条件否则会标记过多或过少。SKIPCHECK; [奖金] N: IF([销售额] 100000, [销售额] * 0.05, 0); FEEDERS; [销售额] [奖金];这条 Feeders 没有加条件意味着只要销售额有数据奖金就会被标记重算。即使销售额小于 100000奖金算出来是 0引擎也会走一遍计算。如果数据量很大这种无条件的 Feeders 会浪费大量计算资源。优化写法是给 Feeders 也加上条件FEEDERS; [销售额] DB(, !年份, !月份, !产品, 奖金);但 TM1 的 Feeders 语法不支持直接在左边写 IF 条件。变通做法是在规则里用一个辅助度量来标记或者接受这种粒度因为 Feeders 的标记本身是轻量级的真正的开销在于被标记后的规则计算。如果 IF 条件里的判断字段本身也是规则算出来的那就要小心循环依赖。我一般会评估如果条件过滤掉的数据比例超过 70%就值得用辅助列或者 TI 进程来替代 Feeders 自动触发如果过滤比例不高直接写无条件 Feeders 更简单维护成本更低。3.3 Feeders 范围过大的典型症状与排查Feeders 写得太宽最直接的表现就是数据加载后重算时间异常长。比如下面这条FEEDERS; [销售额] [毛利], [本币金额], [奖金], [税额], [净利];一条 Feeders 标记了五个目标如果这些目标之间还有依赖关系标记会继续传播。排查方法是打开 TM1 的}StatsByCube立方体看FeedersCount和FeedersTime两个指标。如果 FeedersCount 远大于实际有数据的单元格数说明标记范围过宽。另一个常见问题是 Feeders 里用了!维度变量但维度顺序写错。比如立方体维度顺序是年份、月份、产品、度量Feeders 里写成了[销售额] DB(, !产品, !年份, !月份, 毛利)维度错位会导致标记到错误的单元格表现为某些该算的没算不该算的算了。解决方法是保持 Feeders 里的维度顺序和立方体定义一致或者用DB()时显式写出所有维度。4. Feeders 避坑指南五条血泪经验4.1 现象数据加载后报表数字不更新手动重算才出数原因Feeders 漏写或者 Feeders 里的源区域没有覆盖到实际数据加载的维度组合。比如数据加载时写入了「销售额」的某个产品版本但 Feeders 只标记了另一个版本。解决检查 Feeders 的源区域是否和规则里引用的源单元格完全一致。可以用CubeProcessFeeders强制刷新然后往源单元格写一个测试值看目标单元格是否自动变化。如果不变化逐条注释 Feeders 定位漏网的那条。4.2 现象规则保存时报「Feeders 循环引用」错误原因Feeders 的依赖关系形成了环。比如 A 标记 BB 标记 CC 又标记 A。TM1 在保存规则时会检测这种循环并拒绝。解决画出依赖图找到环上的边把其中一条 Feeders 改成由 TI 进程手动触发。常见做法是打破跨立方体的循环让一个方向走 Feeders另一个方向走 TI。4.3 现象重算时间随数据量线性增长Feeders 数量爆炸原因Feeders 用了过于宽泛的维度引用比如[销售额] [毛利]没有限定任何维度导致所有年份、所有月份、所有产品的销售额都标记了对应的毛利。如果立方体有 10 年 × 12 月 × 1000 产品标记数量就是 12 万条。解决在 Feeders 里加上必要的维度限定比如只标记当前年份[销售额] [毛利]配合DB()限定年份。或者用 TI 进程在数据加载后只重算受影响的产品范围。4.4 现象SKIPCHECK 打开后某些通过 ATTRS() 取属性算出的值丢失原因Feeders 没有覆盖维度属性变化的情况。ATTRS() 取的是维度元素的属性属性变化不会触发 Feeders 标记因为 Feeders 只跟踪立方体单元格的数据变化。解决对于依赖属性的规则要么在属性更新后跑 TI 强制重算要么在 Feeders 里把属性也作为一个源来标记。但 TM1 的 Feeders 不支持直接标记属性所以通常用 TI 方案。4.5 现象Feeders 处理时间很长}StatsByCube里 FeedersTime 居高不下原因Feeders 的依赖链太长或者 Feeders 本身写在了规则文件里但每次数据加载都重新处理。Feeders 处理是批量操作如果立方体维度多、数据稠密处理时间会很长。解决把 Feeders 处理安排在数据加载之后、用户使用之前避免在高峰时段执行。如果 Feeders 处理时间超过可接受范围考虑用 TI 进程替代部分 Feeders只对受影响的数据区域做定向重算。注意修改 Feeders 后一定要重新处理 Feeders否则引擎用的还是旧的依赖图。在 TM1 Architect 里可以通过右键立方体选择「Process Feeders」来完成在 TI 里用CubeProcessFeeders(立方体名)。5. 用 TI 进程替代 Feeders 的进阶技巧定向重算与性能验证当 Feeders 的标记范围难以精确控制或者依赖链太复杂导致处理时间过长时用 TI 进程做定向重算是一个值得考虑的方案。核心思路是不用 Feeders 自动标记而是在数据加载完成后由 TI 进程根据业务逻辑计算出受影响的单元格范围直接对这些单元格执行重算。下面是一个 TI 进程的代码片段用于在销售额数据加载后只重算受影响产品的毛利和本币金额。# TI 进程定向重算受影响产品 # 参数pYear, pMonth, pProduct # 先关闭 Feeders 自动标记避免重复计算 CubeProcessFeeders(销售立方体); # 用 ViewZeroOut 清空受影响范围的旧值 ViewZeroOut(销售立方体, 受影响视图); # 用 CellPutN 触发规则重算 CellPutN( CellGetN(销售立方体, pYear, pMonth, pProduct, 销售额), 销售立方体, pYear, pMonth, pProduct, 毛利 ); # 重算完成后重新处理 Feeders CubeProcessFeeders(销售立方体);逻辑说明这段 TI 先调用CubeProcessFeeders刷新依赖图然后用ViewZeroOut清空受影响范围接着用CellPutN写入销售额的值触发规则引擎计算毛利。参数说明pYear、pMonth、pProduct是 TI 进程的运行时参数通常从数据加载的源文件或临时立方体中获取。ViewZeroOut需要一个预先定义好的视图视图里包含要清空的维度范围。验证方法是在 TI 执行前后分别记录}StatsByCube里的FeedersCount和CalculationTime对比定向重算和全量 Feeders 的差异。我一般会在测试环境跑三组数据小数据量、中等数据量、大数据量分别记录两种方案的处理时间。如果定向重算在大数据量下优势明显就值得在生产环境推广。另一个技巧是用CubeLockOverride在重算期间锁定立方体避免用户查询到中间状态的数据。但锁定时长要控制好超过几秒钟就会影响用户体验。我自己的习惯是新建立方体时先用 Feeders 快速跑通等数据量上来、性能瓶颈出现后再逐步把热点规则改成 TI 定向重算。Feeders 不是银弹它解决的是「标记哪些需要算」的问题而 TI 解决的是「什么时候算、算多少」的问题。两者配合才能让 TM1 模型在数据量增长后依然保持可用的响应速度。希望帮到你。本文还有配套的精品资源点击获取
