Pentaho文本文件输入步骤读取大CSV出现GC overhead内存溢出的咨询

一、Text File input步骤降内存、分段读取实现 #

首先明确：Text File input步骤原生支持流式逐行读取，无必须全量加载文件的设计限制，之前的OOM完全来自默认配置的适配问题，该步骤本身支持逐段（逐行）流式处理，无需拆分原文件，核心优化点如下：

• 关闭全量行缓存配置：打开步骤配置的「内容」面板，找到「缓存」分组：
  • 将读取行数参数从默认值-1（全量缓存所有已读行）修改为0，该参数原本是为了错误行重试、字段类型修正预留的内存空间，-1取值会把所有读入的行对象常驻堆内存，是6G堆被快速占满、GC占比98%的核心诱因
  • 关闭「延迟转换」开关：该开关默认开启，逻辑是先把整个CSV的所有行全量加载到内存，完成所有行的字段类型推断后再逐行向下游传递数据，对于42000行、180列的文件，该流程会直接占用4G以上的堆空间
• 降低类型推断内存占用：将「检查行数」参数从默认1000行修改为200行，减少类型推断阶段需要缓存的采样行数，适配动态列、列名不固定的场景
• 错误缓存限制：在步骤的「错误处理」面板，将错误行的最大缓存数从默认全量修改为最多10行，避免解析失败的错误行长期占用内存

完成上述配置后，Text File input会自动以逐行流式模式运行：每完成1行的解析就直接将行对象传递给下游步骤，内存中仅保留当前解析行的临时对象，处理该文件的整体堆内存峰值会从原本的接近6G降至500M-800M区间，完全适配现有JVM内存配额，不会触发GC过载。如果需要严格控制批处理粒度，可在步骤后追加内存分组步骤，设置每100行向下游传递一次，进一步降低瞬时内存峰值。

二、CSV input步骤与Text File input输出完全对齐的配置方法 #

两个步骤的底层CSV解析逻辑同源，默认输出不一致完全来自配置项的逻辑差异，逐项对齐后即可实现无差别输出，核心差异点及调整方式如下：

• 类型推断逻辑对齐：Text File input默认会基于采样行自动推断字段为Integer、Number、Date、String类型，CSV input默认会将所有字段解析为String类型。调整方式：打开CSV input配置页的「推测类型」开关，将采样行数设置为与Text File input完全一致，即可生成相同的字段类型定义
• 特殊字符解析逻辑对齐：Text File input默认会忽略双引号封闭符内的分隔符、自动解析转义的双引号、识别单元格内的换行符；CSV input默认不会处理封闭符内的转义字符。调整方式：在配置页开启「封闭符内分隔符忽略」「双引号转义解析」「单元格内换行识别」三个开关，与Text File input的解析规则保持一致
• 空值处理逻辑对齐：Text File input默认会将连续分隔符之间的空内容、空字符串统一转换为null值输出；CSV input默认会将空内容解析为空字符串。调整方式：在动态生成的字段配置列表中，将每个字段的空值替换规则设置为null，保持空值输出逻辑一致
• 表头识别逻辑对齐：Text File input默认将第一行作为表头，对表头中的空列自动重命名为「列N」格式；CSV input默认遇到空列名会保留空字符串作为字段名。调整方式：将CSV input的「头部行占用行数」设置为1，开启「空列名自动规范化重命名」开关，匹配Text File input的字段命名规则

针对动态列、列名不固定的场景，保持CSV input的「动态字段获取」开关开启即可，步骤会自动扫描表头生成字段列表，无需硬编码字段结构。完成上述配置后，两个步骤对同一份CSV的解析结果、字段类型、空值输出、特殊字符处理逻辑完全一致。

内容的提问来源于stack exchange，提问作者Llorieb