Pentaho中获取表Decimal值时部分列出现浮点尾差的问题

问题根因 #

输出结果中出现21007.170000000002、28088.850000000002这类无意义的尾差，本质是计算链路中隐式使用了双精度浮点类型做数值运算，二进制浮点的固有精度偏移直接转化为了输出值，不属于真实业务数据，简单的字符串截断无法从根本上解决这类问题。

正确操作步骤 #

• 从源头锁定原生Decimal类型
  • 在数据库连接的高级配置中，开启DECIMAL类型的原生映射，禁止JDBC驱动将数据库端的DECIMAL字段自动转换为Java的float/double类型，避免驱动层的隐式精度损耗。
  • 数值计算环节禁用默认浮点模式的公式计算：使用计算器步骤时，必须选择BigDecimal精度计算模式，全程不要让业务数值经过普通浮点类型中转。
• 显式做精度规整处理
  • 通过字段选择步骤对输出数值字段做强制类型定义：指定字段类型为BigDecimal，配置匹配业务场景的小数精度（如金额类场景固定2位小数），设置舍入规则为常规四舍五入（HALF_UP）。
  • 对最终输出的字段，使用格式化字段步骤做固定格式裁剪，移除所有无意义的尾随零，保证输出值的小数位严格匹配业务要求。
• 避坑提示
  • 不要使用JavaScript脚本块处理业务数值：Pentaho内置的JS引擎底层基于双精度浮点实现，即使传入BigDecimal类型值，转换为JS Number类型时也会立刻引入浮点尾差。
  • 手写Java代码做类型转换时，禁止直接用double值构造BigDecimal对象，会把已经产生的尾差原样带入；正确写法是通过字符串中转构造，或直接接收上游传递的原生BigDecimal值。
  • 不要依赖数据库落库时的Decimal类型校验做规整：如果传入落库的值已经带精度偏移，数据库端会按实际传入值存储，无法自动修正运算阶段产生的尾差。

处理效果 #

按照上述流程调整后，带尾差的实际输出：

NORMAL (06:00--17:00)    3  14341.54    43024.62            
OFF_PEAK (22:00--06:00)  3  7002.39     21007.170000000002          
PEAK (17:00--22:00)      3   9362.95    28088.850000000002

会自动规整为符合要求的标准Decimal格式：

NORMAL (06:00--17:00)    3  14341.54    43024.62            
OFF_PEAK (22:00--06:00)  3  7002.39     21007.17            
PEAK (17:00--22:00)      3   9362.95    28088.85

内容的提问来源于stack exchange，提问作者Naresh Varun Guttula