简介面向IBM Cognos TM1开发人员的FEEDERS实战经验整理专门解决规则计算导致立方体性能下降的问题。文档从SKIPCHECK与FEEDERS的协作机制讲起说明规则文件为何会关闭稀疏聚合算法以及如何通过FEEDERS在保证汇总正确的同时恢复速度。内容重点剖析了Overfeeding与Underfeeding的成因总结了条件feeder、乘法除法场景下的feed策略并强调已feed单元会保持状态直到服务器回收或执行CubeProcessFeeders()函数同时解释FEEDERS只作用于叶级单元、使用合并元素只是简写规则等易混淆点。文中借助Sales Cube示例展示维度规模对稀疏立方体性能的影响给出了避免内存膨胀和查询变慢的具体做法。包体为1个PDF文件约993KB结构完整覆盖定义、原理、示例和注意事项。已有595人学习下载适合具备TM1基础、希望深入掌握规则性能调优的开发及运维人员。1. 为什么说 FEEDERS 是 TM1 性能问题的头号真凶一个 Cube 在 IBM Cognos TM1 里跑得飞快还是卡成 PPT真正拉开差距的往往不是规则写得有多花哨而是 FEEDERS 有没有把「该算的格子」喂对。FEEDERS 决定了稀疏规则计算时哪些单元格被激活、何时被激活它的质量直接影响内存占用、查询速度和 TI 加载效率。对于做建模、规则开发和系统调优的 TM1 从业者来说FEEDERS 不是规则文件的附属品而是 Cube 性能的底层契约。这篇内容不绕弯子直接把在生产环境中反复验证过的 FEEDERS 经验整理出来从语法原理、编写思路到性能排障覆盖你最容易踩坑的地方。2. Cube 设计中的 FEEDERS 语法与执行原理2.1 规则计算必须依赖 FEEDERS——稀疏激活机制TM1 是内存 OLAP 引擎规则声明式地定义了单元格的计算方式用户查询一个未被存储的交叉点时TM1 按规则实时计算。但如果库里有上千万个稀疏组合TM1 不可能在每次查询时都扫描全部组合。FEEDERS 在这中间承担了「预标记」的职责——在数据加载阶段把规则计算可能涉及的稀疏单元格标记出来查询时直接命中而不是现场遍历。换句话说FEEDER 不是规则的一部分它是规则的索引。没有索引规则写得再对TM1 也不知道该在哪片区域执行最后只能返回空白。尤其在 Cube 维度多、单个稀疏维度基数超过几万时FEEDERS 的覆盖范围直接决定内存占用和查询响应速度覆盖太小查询出不来覆盖太大内存被无谓占用。提示FEEDERS 只影响稀疏维度的计算状态对密集维度没有显著作用。因此在建模阶段先判断哪些维度是稀疏的再决定 FEEDER 应该写到多细比上线后反复调优要省力得多。2.2 FEEDERS 声明的基本语法与维度对应FEEDERS 写在规则文件 .rux 的FEEDERS;之后。每一条 FEEDER 的基本结构是「触发区域 目标区域」。假设 SalesCube 的维度顺序为 Version、Scenario、Year、Product、Region、Measures规则文件里有一段把 Sales 换算成 Units 的计算[VersionActual, ScenarioFY, MeasuresSales] [MeasuresUnits] [MeasuresSales] / [MeasuresPrice];对应的 FEEDER 写成FEEDERS; [VersionActual, ScenarioFY, MeasuresSales] DB( SalesCube, !Version, !Scenario, !Year, !Product, !Region, Units );逻辑说明这条 FEEDER 声明的是当数据落在 VersionActual、ScenarioFY 且 MeasuresSales 的交叉区域时TM1 会把 SalesCube 中与当前上下文对应的 Year、Product、Region 的所有组合标记为被 feed 状态。规则引擎遇到这些交叉点时会直接执行换算逻辑把结果写入 Units。参数说明左侧区域是触发条件可以写死维度元素也可以省略维度省略表示该维度所有元素多个限定用逗号分隔。右侧 DB() 的第一个参数是目标 Cube 名后面的参数依次是该 Cube 的各个维度成员可以使用 !DimensionName 方式把当前上下文的成员传进去也可以写带引号的固定元素名。最重要的规则是DB() 里的参数顺序必须与目标 Cube 定义时的维度顺序完全一致否则 FEEDER 会把值映射到错误的位置上。如果触发条件不只限于一个版本可以用集合写法合并[Version{Actual,Budget}, ScenarioFY, MeasuresSales] DB( SalesCube, !Version, !Scenario, !Year, !Product, !Region, Units );这样一条 FEEDER 就能覆盖 Actual 和 Budget 两个版本下的同一条规则代码量减半后续维护时也只需要改一处。2.3 FEEDERS 与规则的协作原则规则负责定义怎么算FEEDER 负责标记在哪片区域上执行两者最终必须指向同一块逻辑区域。下表列出了常见的对应关系。规则目标规则触发条件FEEDER 右侧应覆盖的目标MeasuresUnitsVersionActual, MeasuresSalesDB(..., Actual, ..., Sales) 映射到 UnitsMeasuresRevenueVersionBudget, MeasuresSalesDB(..., Budget, ..., Sales) 映射到 RevenueMeasuresVarianceVersionBudget, MeasuresActual vs Budget两条路径都需要 feed这个对应关系里最容易出问题的点是 FEEDER 右侧覆盖面积和规则条件不匹配。覆盖面积大于规则条件会出现「多余 feed」白白占用内存覆盖面积小于规则条件则表现为查询返回 0 而不是规则结果。在后端日志里这两种情况都不会有报错只能靠抽检和统计去发现。第 5 章会给一套具体的检查脚本。3. FEEDERS 规则编写实战从最小场景到复杂模式3.1 最小可行 FEEDERS单度量、单条件怎么喂先看最简单的维度布局一个销售 Cube维度顺序为 Version、Year、Product、Measures。需求是把 Actual 版本下的 Sales 换算成 LocalSales规则部分和 FEEDER 部分如下# 规则部分 [VersionActual, MeasuresSales] [MeasuresLocalSales] [MeasuresSales] * 1.0; # FEEDERS 部分 FEEDERS; [VersionActual, MeasuresSales] DB( SalesCube, !Version, !Year, !Product, LocalSales );逻辑说明只要某个单元格满足 VersionActual 且 MeasuresSalesTM1 就会把同一维组合下的 LocalSales 标记为待计算值。查询 LocalSales 时规则引擎直接返回已经计算好的结果而不是在查询瞬间临时算一遍。参数说明右侧如果把 !Year 换成 2024就表示只喂 2024 年的 LocalSales其他年份不会被规则计算。除非业务明确只关心某一年否则不要这样写死否则会出现「换一年查就是 0」的诡异问题。同样道理!Product 保持上下文变量产品维度新增成员时 FEEDER 会自动覆盖新成员。下面这个速查表是我在项目中经常对照的 FEEDER 区域写法写法覆盖范围典型使用场景[VersionActual]仅 Actual 版本版本唯一且确定[Version{Actual,Budget}]Actual 和 Budget多版本共用同一规则[MeasuresSales]Sales 度量相关的全部交叉点度量维度做条件DB(Cube, Budget, !Year, DepCost)目标区域写死某个元素跨版本、跨度量映射3.2 跨 Cube 的 FEEDERS用 DB() 关联事实表和汇总表生产环境里 FEEDER 最常见的场景是从事实 Cube 喂给汇总 Cube。假设事实 Cube FactCube 的维度顺序是 Version、Year、Product、Region、Measures汇总 Cube SummaryCube 的维度顺序是 Version、Year、Product、Measures。SummaryCube 要汇总 FactCube 中所有区域的 Sales规则写在 SummaryCube.rux 里# SummaryCube.rux 中的规则 [VersionActual, MeasuresSales] [MeasuresAllRegionSales] DB( FactCube, !Version, !Year, !Product, Total Region, Sales ); # SummaryCube 的 FEEDERS [VersionActual, MeasuresSales] DB( SummaryCube, !Version, !Year, !Product, AllRegionSales );逻辑说明SummaryCube 里的 Sales 是直接通过 TI 加载的输入值当 Sales 有值时FEEDER 激活同一交叉点下的 AllRegionSalesTM1 在加载阶段执行规则从 FactCube 中把 Total Region 对应的 Sales 取回来写入 AllRegionSales。参数说明右侧 DB() 的目标 Cube 是 SummaryCube 本身AllRegionSales 是 SummaryCube 里的度量。如果把目标写成了 FactCube那就变成在 FactCube 里激活一个同名度量两侧语义完全不同。这类错误在代码 review 里很难发现只有跑数据时才能看出来。如果希望把多个版本或区域群体一次性映射可以继续用集合写法把左侧条件或右侧目标中的固定元素换成集合。但前提是集合里的所有元素映射到同一个目标映射路径不同就不能合并否则 FEEDER 会漏掉一部分区域。3.3 条件 FEEDERS百分比分摊与跨版本引用预算分摊是财务模型里最常见的 FEEDER 需求。以一个简化的版本为例Actual 版本的 TotalCost 有值按 20% 分摊到 Budget 版本的 DepCost。规则和 FEEDER 分别写成# 规则部分 [VersionActual, MeasuresTotalCost] [VersionBudget, MeasuresDepCost] [VersionActual, MeasuresTotalCost] * 0.2; # FEEDERS 部分 [VersionActual, MeasuresTotalCost] DB( SourceCube, Budget, !Year, !Product, DepCost );逻辑说明这里规则右侧把 Version 从 Actual 映射到 BudgetFEEDER 也做了同样的映射把 Actual 版本下 TotalCost 有值的每个交叉点映射到 Budget 版本下 DepCost 的对应位置。如果没有这个映射FEEDER 会沿用当前上下文的 Version 也就是 ActualBudget 版本的 DepCost 永远不会被标为已喂规则计算自然也不会执行。参数说明DB() 中 Budget 是写死的目标版本!Year 和 !Product 是来自当前上下文的元素。如果比例 0.2 也需要跟着业务变动推荐把比例放入 Cube 的输入数据而非写死在规则里这样 FEEDER 的映射不随比例调整而改变维护成本更低。还有一个细节如果规则里要处理除数可能为零的情况用 IF 判断写在规则里FEEDER 不需要做任何特殊处理。FEEDER 只关注「哪个区域要激活」不负责具体数值的合法性判断。4. FEEDERS 性能调优内存、溢出与加载效率4.1 用 FEEDSTRINGS 处理字符串度量与冗余TM1 的字符串度量默认不会被 FEEDER 自动覆盖需要单独声明。字符串 FEEDER 对内存的压力比数值 FEEDER 更大因为每个被喂的字符串单元格都会保留一份字符串引用。如果同一个描述在成千上万个组合里重复出现这种冗余会变成非常可观的内存开销。# 普通字符串 FEEDER [MeasuresDescription] DB( Cube, !Version, !Year, !Product, Description ); # 使用 FEEDSTRINGS 的写法 [MeasuresDescription] FEEDSTRINGS( DB( Cube, !Version, !Year, !Product, Description ) );逻辑说明FEEDSTRINGS 包裹的 DB() 不会直接创建一份「已喂」标记而是记录一个字符串依赖关系当源单元格的字符串值变化时目标单元格会同步失效并重新加载。字符串内容相同的多个组合共享同一份依赖内存占用显著低于普通字符串 FEEDER。参数说明FEEDSTRINGS 只能用于字符串度量的 FEEDER目标度量必须是字符串类型。如果 Cube 里同时有数值度量和字符串度量两类 FEEDER 可以共存于同一个规则文件各自覆盖各自的度量。不要试图用 FEEDSTRINGS 去喂数值单元格那是无效写法TM1 会直接报语法错误。4.2 合并多个 FEEDER 声明减少区域膨胀FEEDER 数量越多TM1 在加载和查询时需要维护的索引就越大。一个常见的问题是为了覆盖多种条件写了十几条内容几乎相同的 FEEDER每条只差一个元素。把它们合并成集合写法TM1 可以建立更紧凑的区域描述。# 合并前 [VersionActual, RegionNorth] DB( Cube, !Version, !Year, !Product, LocalSales ); [VersionActual, RegionSouth] DB( Cube, !Version, !Year, !Product, LocalSales ); # 合并后 [VersionActual, Region{North,South}] DB( Cube, !Version, !Year, !Product, LocalSales );逻辑说明集合写法在语法上更简洁TM1 内部也按一个区域对象处理而不是逐条展开。尤其是当集合里有几十个元素时合并前后的加载时间差异非常明显。参数说明合并的前提是这些元素的 FEEDER 右侧目标完全相同。如果 North 映射到 LocalSalesSouth 映射到 ForeignSales则不能合并只能分开写或通过 TI 自动生成。对于几十万个元素的高基数维度手写任何形式的 FEEDER 都不现实。常见做法是用 TI 脚本把需要喂的产品清单动态拼成规则文本再写入 .rux 文件包含进来。这样产物既保持了紧凑的覆盖区域又避免人工维护长列表。参考粒度对照场景推荐写法说明低基数维度如 Version[VersionActual]直接覆盖无需细分中基数维度如 Region100[Region{North,South}]集合写法维护成本低高基数维度如 Product10000只喂业务相关元素用 TI 生成 FEEDER 文本条件依赖字段较多用 DB() 固定元素缩小范围尽量避免全维度通配4.3 稀疏维度顺序对 FEEDERS 的影响维度顺序在 TM1 中对 FEEDER 的内存结构有直接影响。TM1 在内存里把稀疏维度的组合展平成索引FEEDER 的覆盖区域按维度从左到右分段存储。假设 Cube 的维度顺序是 Version、Measures、Product、Region其中 Product 是高基数维度Region 是低基数维度。FEEDER 覆盖同一地区多个产品时TM1 需要按产品逐个建立稀疏指针内存开销较大。如果把 Region 移到 Product 前面维度顺序调整为 Version、Measures、Region、Product同一 Region 下的多个产品可以共享一段区域头FEEDER 的存储结构更紧凑。这个调整在开发阶段做最容易上线后再动维度顺序涉及数据重刷和规则重写成本很高。需要说明的是这只是一个设计倾向而不是硬性规则。维度顺序还受规则计算方向、视图使用习惯等因素影响。如果两个方向冲突优先保证业务查询的可用性再考虑用 TI 生成 FEEDER 来压缩内存。先列出各稀疏维度的基数从低到高排列再写规则和 FEEDER是我在新模型里默认采用的方式。还有一个常见误解需要澄清如果维度上有多个层级FEEDER 默认会覆盖目标区域中出现的所有元素组合包括汇总元素。但 TM1 原生的 consolidation 汇总值由叶子值自动聚合不需要额外 feed只有当汇总元素本身出现在规则计算的左侧或右侧时才需要为它单独写 FEEDER。5. 排查与验证FEEDERS 不出数的几种典型困境5.1 用 TI 抽检验证哪些单元格被 Feed写完 FEEDER 后最常见的疑问是「到底生效没有」。用 Cube Viewer 逐个点很慢还容易受显示层缓存影响。更可靠的方式是用 TI 脚本做抽检直接从 TM1 内核取数。# 检查 SalesCube 中某产品在特定维度组合下的 LocalSales sCube SalesCube; sVersion Actual; sYear 2024; sProduct P001; sRegion East; nValue CellGetN( sCube, sVersion, sYear, sProduct, sRegion, LocalSales ); If( nValue 0 ); ASCIIOutput( feed_check.log, LocalSales not feed: , sProduct, | , sRegion ); EndIf;逻辑说明CellGetN 从 Cube 中读取数值单元格的值。如果 FEEDER 已经覆盖了该交叉点规则会计算出 LocalSales 并返回非 0 值如果返回 0说明这个点位没有被喂或者规则条件没有命中。参数说明CellGetN 的参数从左到右对应 Cube 的维度顺序这里的顺序是 Version、Year、Product、Region、Measures。参数顺序和维度顺序不一致时TM1 会静默返回 0这是排障时最容易误判的原因。批量检查时可以把产品代码放入一个控制维度用 While 循环遍历把未命中的组合追加写入日志。5.2 常见问题维度顺序错误、区域不匹配、漏写 FEEDERS;日常维护中 FEEDERS 相关的问题基本都集中在这几类。维度顺序错误是最普遍的。DB() 中的参数顺序和目标 Cube 不一致时TM1 通常不会立刻报错而是把值映射到错误的维度组合上。表现是 Cube Viewer 里「某几个交叉点有值另外几个没有」。处理办法是先打开 Cube 的维度列表从左到右逐个核对不要凭记忆写。区域不匹配体现在 FEEDER 左侧触发区域和右侧目标区域的语义不一致。典型例子左侧条件是 MeasuresSales右侧 DB() 里却写了 SalesAmount。如果 SalesAmount 在 Measures 维度中不存在规则文件加载时会报语法错误如果存在但不是规则要计算的度量则表现为查询有结果但数值不符合预期。这类问题靠对齐左右两侧的维度元素就能发现。漏写 FEEDERS; 分隔符同样隐蔽。.rux 文件中 FEEDERS; 必须单独占一行作为规则部分结束、FEEDER 部分开始的标记。漏了它后面的内容会被当成规则去解析整个文件加载失败。常见表现是 TI 报「Rule Compilation Error」但报错行不在原始 FEEDER 行——因为 TM1 已经把它当成规则语句了。症状可能原因优先排查方向查询返回 0FEEDER 未覆盖目标点用 CellGetN 抽检部分区域有值、部分为 0DB() 维度顺序错误核对 Cube 维度列表规则文件加载报错漏写 FEEDERS;查看报错行的实际内容系统性能持续下降FEEDER 覆盖面积过大检查被喂区域大小和内存指标5.3 数据加载后如何强制重建 FEEDER 索引FEEDER 索引不会因为数据量变化而自动保持精确尤其是维度结构调整、元素重命名或规则条件变化之后旧的 FEEDER 索引很可能与实际数据脱节。最直接的恢复手段是强制重建。CubeProcessFeeders( SalesCube );逻辑说明CubeProcessFeeders 清空当前 Cube 的已喂区域然后按规则文件重新扫描基础数据并建立新的索引。它会重新评估所有规则条件因此能解决大多数 FEEDER 索引过期问题。参数说明这个函数接受一个参数即 Cube 名称。执行时长取决于数据量、维度基数以及规则复杂度生产环境通常需要几分钟到几十分钟。建议放在维护窗口内执行并记录耗时用于趋势对比。如果批处理链路很长把它放在最后一步避免多次重建导致的不必要开销。6. 最后一套可复用的 FEEDER 验证与回归检查脚本在项目里维护一套 FEEDER 回归脚本能有效减少「改了一处规则另外几处悄悄不更新」的情况。基本思路是把关键交叉点抽样放到固定清单里每次规则变更后跑一遍 TI输出未命中明细。# FEEDER 回归检查脚本示例 sCube SalesCube; sVersion Actual; sYear 2024; nFailed 0; nVal CellGetN( sCube, sVersion, sYear, P001, East, LocalSales ); If( nVal 0 ); ASCIIOutput( feed_regression.log, P001/East/LocalSales 0 ); nFailed nFailed 1; EndIf; nVal CellGetN( sCube, sVersion, sYear, P002, West, LocalSales ); If( nVal 0 ); ASCIIOutput( feed_regression.log, P002/West/LocalSales 0 ); nFailed nFailed 1; EndIf; If( nFailed 0 ); ASCIIOutput( feed_regression.log, ALL FEEDER CHECKS PASSED ); EndIf;逻辑说明这是一个最简实现。实际项目中可以把抽样元素放入一个控制维度用 While 循环配合子集遍历覆盖所有需要验证的业务组合并把日志写入带时间戳的文件方便对比历史结果。参数说明ASCIIOutput 的第一个参数是输出文件名日志默认写到 TM1 服务器数据目录下。看到「ALL FEEDER CHECKS PASSED」说明本轮抽样全部通过否则按文件里的产品/地区组合逐个排查规则或 FEEDER。另一个值得养成的习惯是每次维度结构调整或加载方式变化后在开发环境先跑一轮 CubeProcessFeeders再执行一遍抽样检查把 FEEDER 覆盖面积和内存指标记录到变更单里。长期坚持这条「规则变更—FEEDER 覆盖—内存变化」的基线会让性能问题有迹可循比临时拉开内存图逐个找块要有效得多。本文还有配套的精品资源点击获取
TM1性能优化：FEEDERS规则编写与调优实战指南
简介面向IBM Cognos TM1开发人员的FEEDERS实战经验整理专门解决规则计算导致立方体性能下降的问题。文档从SKIPCHECK与FEEDERS的协作机制讲起说明规则文件为何会关闭稀疏聚合算法以及如何通过FEEDERS在保证汇总正确的同时恢复速度。内容重点剖析了Overfeeding与Underfeeding的成因总结了条件feeder、乘法除法场景下的feed策略并强调已feed单元会保持状态直到服务器回收或执行CubeProcessFeeders()函数同时解释FEEDERS只作用于叶级单元、使用合并元素只是简写规则等易混淆点。文中借助Sales Cube示例展示维度规模对稀疏立方体性能的影响给出了避免内存膨胀和查询变慢的具体做法。包体为1个PDF文件约993KB结构完整覆盖定义、原理、示例和注意事项。已有595人学习下载适合具备TM1基础、希望深入掌握规则性能调优的开发及运维人员。1. 为什么说 FEEDERS 是 TM1 性能问题的头号真凶一个 Cube 在 IBM Cognos TM1 里跑得飞快还是卡成 PPT真正拉开差距的往往不是规则写得有多花哨而是 FEEDERS 有没有把「该算的格子」喂对。FEEDERS 决定了稀疏规则计算时哪些单元格被激活、何时被激活它的质量直接影响内存占用、查询速度和 TI 加载效率。对于做建模、规则开发和系统调优的 TM1 从业者来说FEEDERS 不是规则文件的附属品而是 Cube 性能的底层契约。这篇内容不绕弯子直接把在生产环境中反复验证过的 FEEDERS 经验整理出来从语法原理、编写思路到性能排障覆盖你最容易踩坑的地方。2. Cube 设计中的 FEEDERS 语法与执行原理2.1 规则计算必须依赖 FEEDERS——稀疏激活机制TM1 是内存 OLAP 引擎规则声明式地定义了单元格的计算方式用户查询一个未被存储的交叉点时TM1 按规则实时计算。但如果库里有上千万个稀疏组合TM1 不可能在每次查询时都扫描全部组合。FEEDERS 在这中间承担了「预标记」的职责——在数据加载阶段把规则计算可能涉及的稀疏单元格标记出来查询时直接命中而不是现场遍历。换句话说FEEDER 不是规则的一部分它是规则的索引。没有索引规则写得再对TM1 也不知道该在哪片区域执行最后只能返回空白。尤其在 Cube 维度多、单个稀疏维度基数超过几万时FEEDERS 的覆盖范围直接决定内存占用和查询响应速度覆盖太小查询出不来覆盖太大内存被无谓占用。提示FEEDERS 只影响稀疏维度的计算状态对密集维度没有显著作用。因此在建模阶段先判断哪些维度是稀疏的再决定 FEEDER 应该写到多细比上线后反复调优要省力得多。2.2 FEEDERS 声明的基本语法与维度对应FEEDERS 写在规则文件 .rux 的FEEDERS;之后。每一条 FEEDER 的基本结构是「触发区域 目标区域」。假设 SalesCube 的维度顺序为 Version、Scenario、Year、Product、Region、Measures规则文件里有一段把 Sales 换算成 Units 的计算[VersionActual, ScenarioFY, MeasuresSales] [MeasuresUnits] [MeasuresSales] / [MeasuresPrice];对应的 FEEDER 写成FEEDERS; [VersionActual, ScenarioFY, MeasuresSales] DB( SalesCube, !Version, !Scenario, !Year, !Product, !Region, Units );逻辑说明这条 FEEDER 声明的是当数据落在 VersionActual、ScenarioFY 且 MeasuresSales 的交叉区域时TM1 会把 SalesCube 中与当前上下文对应的 Year、Product、Region 的所有组合标记为被 feed 状态。规则引擎遇到这些交叉点时会直接执行换算逻辑把结果写入 Units。参数说明左侧区域是触发条件可以写死维度元素也可以省略维度省略表示该维度所有元素多个限定用逗号分隔。右侧 DB() 的第一个参数是目标 Cube 名后面的参数依次是该 Cube 的各个维度成员可以使用 !DimensionName 方式把当前上下文的成员传进去也可以写带引号的固定元素名。最重要的规则是DB() 里的参数顺序必须与目标 Cube 定义时的维度顺序完全一致否则 FEEDER 会把值映射到错误的位置上。如果触发条件不只限于一个版本可以用集合写法合并[Version{Actual,Budget}, ScenarioFY, MeasuresSales] DB( SalesCube, !Version, !Scenario, !Year, !Product, !Region, Units );这样一条 FEEDER 就能覆盖 Actual 和 Budget 两个版本下的同一条规则代码量减半后续维护时也只需要改一处。2.3 FEEDERS 与规则的协作原则规则负责定义怎么算FEEDER 负责标记在哪片区域上执行两者最终必须指向同一块逻辑区域。下表列出了常见的对应关系。规则目标规则触发条件FEEDER 右侧应覆盖的目标MeasuresUnitsVersionActual, MeasuresSalesDB(..., Actual, ..., Sales) 映射到 UnitsMeasuresRevenueVersionBudget, MeasuresSalesDB(..., Budget, ..., Sales) 映射到 RevenueMeasuresVarianceVersionBudget, MeasuresActual vs Budget两条路径都需要 feed这个对应关系里最容易出问题的点是 FEEDER 右侧覆盖面积和规则条件不匹配。覆盖面积大于规则条件会出现「多余 feed」白白占用内存覆盖面积小于规则条件则表现为查询返回 0 而不是规则结果。在后端日志里这两种情况都不会有报错只能靠抽检和统计去发现。第 5 章会给一套具体的检查脚本。3. FEEDERS 规则编写实战从最小场景到复杂模式3.1 最小可行 FEEDERS单度量、单条件怎么喂先看最简单的维度布局一个销售 Cube维度顺序为 Version、Year、Product、Measures。需求是把 Actual 版本下的 Sales 换算成 LocalSales规则部分和 FEEDER 部分如下# 规则部分 [VersionActual, MeasuresSales] [MeasuresLocalSales] [MeasuresSales] * 1.0; # FEEDERS 部分 FEEDERS; [VersionActual, MeasuresSales] DB( SalesCube, !Version, !Year, !Product, LocalSales );逻辑说明只要某个单元格满足 VersionActual 且 MeasuresSalesTM1 就会把同一维组合下的 LocalSales 标记为待计算值。查询 LocalSales 时规则引擎直接返回已经计算好的结果而不是在查询瞬间临时算一遍。参数说明右侧如果把 !Year 换成 2024就表示只喂 2024 年的 LocalSales其他年份不会被规则计算。除非业务明确只关心某一年否则不要这样写死否则会出现「换一年查就是 0」的诡异问题。同样道理!Product 保持上下文变量产品维度新增成员时 FEEDER 会自动覆盖新成员。下面这个速查表是我在项目中经常对照的 FEEDER 区域写法写法覆盖范围典型使用场景[VersionActual]仅 Actual 版本版本唯一且确定[Version{Actual,Budget}]Actual 和 Budget多版本共用同一规则[MeasuresSales]Sales 度量相关的全部交叉点度量维度做条件DB(Cube, Budget, !Year, DepCost)目标区域写死某个元素跨版本、跨度量映射3.2 跨 Cube 的 FEEDERS用 DB() 关联事实表和汇总表生产环境里 FEEDER 最常见的场景是从事实 Cube 喂给汇总 Cube。假设事实 Cube FactCube 的维度顺序是 Version、Year、Product、Region、Measures汇总 Cube SummaryCube 的维度顺序是 Version、Year、Product、Measures。SummaryCube 要汇总 FactCube 中所有区域的 Sales规则写在 SummaryCube.rux 里# SummaryCube.rux 中的规则 [VersionActual, MeasuresSales] [MeasuresAllRegionSales] DB( FactCube, !Version, !Year, !Product, Total Region, Sales ); # SummaryCube 的 FEEDERS [VersionActual, MeasuresSales] DB( SummaryCube, !Version, !Year, !Product, AllRegionSales );逻辑说明SummaryCube 里的 Sales 是直接通过 TI 加载的输入值当 Sales 有值时FEEDER 激活同一交叉点下的 AllRegionSalesTM1 在加载阶段执行规则从 FactCube 中把 Total Region 对应的 Sales 取回来写入 AllRegionSales。参数说明右侧 DB() 的目标 Cube 是 SummaryCube 本身AllRegionSales 是 SummaryCube 里的度量。如果把目标写成了 FactCube那就变成在 FactCube 里激活一个同名度量两侧语义完全不同。这类错误在代码 review 里很难发现只有跑数据时才能看出来。如果希望把多个版本或区域群体一次性映射可以继续用集合写法把左侧条件或右侧目标中的固定元素换成集合。但前提是集合里的所有元素映射到同一个目标映射路径不同就不能合并否则 FEEDER 会漏掉一部分区域。3.3 条件 FEEDERS百分比分摊与跨版本引用预算分摊是财务模型里最常见的 FEEDER 需求。以一个简化的版本为例Actual 版本的 TotalCost 有值按 20% 分摊到 Budget 版本的 DepCost。规则和 FEEDER 分别写成# 规则部分 [VersionActual, MeasuresTotalCost] [VersionBudget, MeasuresDepCost] [VersionActual, MeasuresTotalCost] * 0.2; # FEEDERS 部分 [VersionActual, MeasuresTotalCost] DB( SourceCube, Budget, !Year, !Product, DepCost );逻辑说明这里规则右侧把 Version 从 Actual 映射到 BudgetFEEDER 也做了同样的映射把 Actual 版本下 TotalCost 有值的每个交叉点映射到 Budget 版本下 DepCost 的对应位置。如果没有这个映射FEEDER 会沿用当前上下文的 Version 也就是 ActualBudget 版本的 DepCost 永远不会被标为已喂规则计算自然也不会执行。参数说明DB() 中 Budget 是写死的目标版本!Year 和 !Product 是来自当前上下文的元素。如果比例 0.2 也需要跟着业务变动推荐把比例放入 Cube 的输入数据而非写死在规则里这样 FEEDER 的映射不随比例调整而改变维护成本更低。还有一个细节如果规则里要处理除数可能为零的情况用 IF 判断写在规则里FEEDER 不需要做任何特殊处理。FEEDER 只关注「哪个区域要激活」不负责具体数值的合法性判断。4. FEEDERS 性能调优内存、溢出与加载效率4.1 用 FEEDSTRINGS 处理字符串度量与冗余TM1 的字符串度量默认不会被 FEEDER 自动覆盖需要单独声明。字符串 FEEDER 对内存的压力比数值 FEEDER 更大因为每个被喂的字符串单元格都会保留一份字符串引用。如果同一个描述在成千上万个组合里重复出现这种冗余会变成非常可观的内存开销。# 普通字符串 FEEDER [MeasuresDescription] DB( Cube, !Version, !Year, !Product, Description ); # 使用 FEEDSTRINGS 的写法 [MeasuresDescription] FEEDSTRINGS( DB( Cube, !Version, !Year, !Product, Description ) );逻辑说明FEEDSTRINGS 包裹的 DB() 不会直接创建一份「已喂」标记而是记录一个字符串依赖关系当源单元格的字符串值变化时目标单元格会同步失效并重新加载。字符串内容相同的多个组合共享同一份依赖内存占用显著低于普通字符串 FEEDER。参数说明FEEDSTRINGS 只能用于字符串度量的 FEEDER目标度量必须是字符串类型。如果 Cube 里同时有数值度量和字符串度量两类 FEEDER 可以共存于同一个规则文件各自覆盖各自的度量。不要试图用 FEEDSTRINGS 去喂数值单元格那是无效写法TM1 会直接报语法错误。4.2 合并多个 FEEDER 声明减少区域膨胀FEEDER 数量越多TM1 在加载和查询时需要维护的索引就越大。一个常见的问题是为了覆盖多种条件写了十几条内容几乎相同的 FEEDER每条只差一个元素。把它们合并成集合写法TM1 可以建立更紧凑的区域描述。# 合并前 [VersionActual, RegionNorth] DB( Cube, !Version, !Year, !Product, LocalSales ); [VersionActual, RegionSouth] DB( Cube, !Version, !Year, !Product, LocalSales ); # 合并后 [VersionActual, Region{North,South}] DB( Cube, !Version, !Year, !Product, LocalSales );逻辑说明集合写法在语法上更简洁TM1 内部也按一个区域对象处理而不是逐条展开。尤其是当集合里有几十个元素时合并前后的加载时间差异非常明显。参数说明合并的前提是这些元素的 FEEDER 右侧目标完全相同。如果 North 映射到 LocalSalesSouth 映射到 ForeignSales则不能合并只能分开写或通过 TI 自动生成。对于几十万个元素的高基数维度手写任何形式的 FEEDER 都不现实。常见做法是用 TI 脚本把需要喂的产品清单动态拼成规则文本再写入 .rux 文件包含进来。这样产物既保持了紧凑的覆盖区域又避免人工维护长列表。参考粒度对照场景推荐写法说明低基数维度如 Version[VersionActual]直接覆盖无需细分中基数维度如 Region100[Region{North,South}]集合写法维护成本低高基数维度如 Product10000只喂业务相关元素用 TI 生成 FEEDER 文本条件依赖字段较多用 DB() 固定元素缩小范围尽量避免全维度通配4.3 稀疏维度顺序对 FEEDERS 的影响维度顺序在 TM1 中对 FEEDER 的内存结构有直接影响。TM1 在内存里把稀疏维度的组合展平成索引FEEDER 的覆盖区域按维度从左到右分段存储。假设 Cube 的维度顺序是 Version、Measures、Product、Region其中 Product 是高基数维度Region 是低基数维度。FEEDER 覆盖同一地区多个产品时TM1 需要按产品逐个建立稀疏指针内存开销较大。如果把 Region 移到 Product 前面维度顺序调整为 Version、Measures、Region、Product同一 Region 下的多个产品可以共享一段区域头FEEDER 的存储结构更紧凑。这个调整在开发阶段做最容易上线后再动维度顺序涉及数据重刷和规则重写成本很高。需要说明的是这只是一个设计倾向而不是硬性规则。维度顺序还受规则计算方向、视图使用习惯等因素影响。如果两个方向冲突优先保证业务查询的可用性再考虑用 TI 生成 FEEDER 来压缩内存。先列出各稀疏维度的基数从低到高排列再写规则和 FEEDER是我在新模型里默认采用的方式。还有一个常见误解需要澄清如果维度上有多个层级FEEDER 默认会覆盖目标区域中出现的所有元素组合包括汇总元素。但 TM1 原生的 consolidation 汇总值由叶子值自动聚合不需要额外 feed只有当汇总元素本身出现在规则计算的左侧或右侧时才需要为它单独写 FEEDER。5. 排查与验证FEEDERS 不出数的几种典型困境5.1 用 TI 抽检验证哪些单元格被 Feed写完 FEEDER 后最常见的疑问是「到底生效没有」。用 Cube Viewer 逐个点很慢还容易受显示层缓存影响。更可靠的方式是用 TI 脚本做抽检直接从 TM1 内核取数。# 检查 SalesCube 中某产品在特定维度组合下的 LocalSales sCube SalesCube; sVersion Actual; sYear 2024; sProduct P001; sRegion East; nValue CellGetN( sCube, sVersion, sYear, sProduct, sRegion, LocalSales ); If( nValue 0 ); ASCIIOutput( feed_check.log, LocalSales not feed: , sProduct, | , sRegion ); EndIf;逻辑说明CellGetN 从 Cube 中读取数值单元格的值。如果 FEEDER 已经覆盖了该交叉点规则会计算出 LocalSales 并返回非 0 值如果返回 0说明这个点位没有被喂或者规则条件没有命中。参数说明CellGetN 的参数从左到右对应 Cube 的维度顺序这里的顺序是 Version、Year、Product、Region、Measures。参数顺序和维度顺序不一致时TM1 会静默返回 0这是排障时最容易误判的原因。批量检查时可以把产品代码放入一个控制维度用 While 循环遍历把未命中的组合追加写入日志。5.2 常见问题维度顺序错误、区域不匹配、漏写 FEEDERS;日常维护中 FEEDERS 相关的问题基本都集中在这几类。维度顺序错误是最普遍的。DB() 中的参数顺序和目标 Cube 不一致时TM1 通常不会立刻报错而是把值映射到错误的维度组合上。表现是 Cube Viewer 里「某几个交叉点有值另外几个没有」。处理办法是先打开 Cube 的维度列表从左到右逐个核对不要凭记忆写。区域不匹配体现在 FEEDER 左侧触发区域和右侧目标区域的语义不一致。典型例子左侧条件是 MeasuresSales右侧 DB() 里却写了 SalesAmount。如果 SalesAmount 在 Measures 维度中不存在规则文件加载时会报语法错误如果存在但不是规则要计算的度量则表现为查询有结果但数值不符合预期。这类问题靠对齐左右两侧的维度元素就能发现。漏写 FEEDERS; 分隔符同样隐蔽。.rux 文件中 FEEDERS; 必须单独占一行作为规则部分结束、FEEDER 部分开始的标记。漏了它后面的内容会被当成规则去解析整个文件加载失败。常见表现是 TI 报「Rule Compilation Error」但报错行不在原始 FEEDER 行——因为 TM1 已经把它当成规则语句了。症状可能原因优先排查方向查询返回 0FEEDER 未覆盖目标点用 CellGetN 抽检部分区域有值、部分为 0DB() 维度顺序错误核对 Cube 维度列表规则文件加载报错漏写 FEEDERS;查看报错行的实际内容系统性能持续下降FEEDER 覆盖面积过大检查被喂区域大小和内存指标5.3 数据加载后如何强制重建 FEEDER 索引FEEDER 索引不会因为数据量变化而自动保持精确尤其是维度结构调整、元素重命名或规则条件变化之后旧的 FEEDER 索引很可能与实际数据脱节。最直接的恢复手段是强制重建。CubeProcessFeeders( SalesCube );逻辑说明CubeProcessFeeders 清空当前 Cube 的已喂区域然后按规则文件重新扫描基础数据并建立新的索引。它会重新评估所有规则条件因此能解决大多数 FEEDER 索引过期问题。参数说明这个函数接受一个参数即 Cube 名称。执行时长取决于数据量、维度基数以及规则复杂度生产环境通常需要几分钟到几十分钟。建议放在维护窗口内执行并记录耗时用于趋势对比。如果批处理链路很长把它放在最后一步避免多次重建导致的不必要开销。6. 最后一套可复用的 FEEDER 验证与回归检查脚本在项目里维护一套 FEEDER 回归脚本能有效减少「改了一处规则另外几处悄悄不更新」的情况。基本思路是把关键交叉点抽样放到固定清单里每次规则变更后跑一遍 TI输出未命中明细。# FEEDER 回归检查脚本示例 sCube SalesCube; sVersion Actual; sYear 2024; nFailed 0; nVal CellGetN( sCube, sVersion, sYear, P001, East, LocalSales ); If( nVal 0 ); ASCIIOutput( feed_regression.log, P001/East/LocalSales 0 ); nFailed nFailed 1; EndIf; nVal CellGetN( sCube, sVersion, sYear, P002, West, LocalSales ); If( nVal 0 ); ASCIIOutput( feed_regression.log, P002/West/LocalSales 0 ); nFailed nFailed 1; EndIf; If( nFailed 0 ); ASCIIOutput( feed_regression.log, ALL FEEDER CHECKS PASSED ); EndIf;逻辑说明这是一个最简实现。实际项目中可以把抽样元素放入一个控制维度用 While 循环配合子集遍历覆盖所有需要验证的业务组合并把日志写入带时间戳的文件方便对比历史结果。参数说明ASCIIOutput 的第一个参数是输出文件名日志默认写到 TM1 服务器数据目录下。看到「ALL FEEDER CHECKS PASSED」说明本轮抽样全部通过否则按文件里的产品/地区组合逐个排查规则或 FEEDER。另一个值得养成的习惯是每次维度结构调整或加载方式变化后在开发环境先跑一轮 CubeProcessFeeders再执行一遍抽样检查把 FEEDER 覆盖面积和内存指标记录到变更单里。长期坚持这条「规则变更—FEEDER 覆盖—内存变化」的基线会让性能问题有迹可循比临时拉开内存图逐个找块要有效得多。本文还有配套的精品资源点击获取
