Kettle 写 Doris 上亿大表经常 OOM？用 Doris Bulk Loader 把表输出换掉

下载地址
提取码：p8uu

下载内容：

  • doris-bulk-loader-plugins-9.3.0.0-428.zip：Doris 批量加载插件包,支持Pentaho社区或商业版8.2及以上
  • doris-bulk-loader.lic：Doris 批量加载插件授权文件
  • pdi-ce-9.3.0.0-428.zip：Kettle/PDI 客户端
  • pentaho-server-ce-9.3.0.0-428.zip：Pentaho Server
  • jdbc/：相关 JDBC 驱动

如果你还在用 Kettle/PDI 的“表输出”组件往 Apache Doris 写大表，大概率遇到过这些问题：

  • 几百万行还能跑，上千万行开始变慢，上亿大表经常跑不完。
  • JDBC 批量写入时间长，任务一直占着 pentaho-server 资源。
  • JVM 内存被打满，严重时 pentaho-server 直接 down 掉。
  • CPU 长时间拉高，其他转换和作业也被拖慢。
  • 为了扛峰值不断加机器、加内存、加授权，成本越来越高。

我们在实际项目里把 Doris 写入方式从“表输出”换成 Doris Bulk Loader 后，最明显的变化不是界面多了一个插件，而是整个链路轻了：

  • 上亿大表抽取时间显著降低，只有原先的1/5。
  • pentaho-server 不再因为大批量表输出频繁 OOM。
  • CPU 和内存占用大幅下降。
  • 服务器配置后续降了接近一半。
  • 硬件成本和按资源/机器/核心计费的软件授权费用都降下来了。

本文就按真实落地场景讲：为什么 Kettle 表输出写 Doris 容易出问题，Doris Bulk Loader 怎么解决，以及怎么部署、配置和排查。

1. 真实场景：不是慢一点，是会把服务打挂

某企业的数据平台用 Kettle 做离线同步，Doris 做分析库。

典型数据任务包括：

数据类型 数据量 同步要求
订单明细 单表上亿行 支持全量校准和月度重跑
门店销售流水 每天千万级 每天固定窗口完成
会员行为 字段多、文本复杂 要处理引号、换行、分隔符
库存快照 定时追加或覆盖 调度稳定，失败可重跑

原来的方案很简单：Kettle 抽数，清洗后用“表输出”写 Doris。

小表没问题，但数据量上来以后问题集中爆发：

  1. 表输出走 JDBC，写入链路太重。
  2. 大批次写入持续占用 JVM 内存。
  3. pentaho-server 运行一段时间后内存回收压力很大。
  4. 高峰期多个任务并发，CPU 和内存一起打满。
  5. 一旦 OOM，整个 pentaho-server down，影响的不只是当前任务。

这个问题的关键不是“批量提交数再调大一点”，而是写入方式不适合。

2. 为什么表输出不适合上亿大表写 Doris

Kettle 的表输出更适合传统关系库的小批量写入。

它的问题在 Doris 大表场景里会被放大：

  • JDBC 网络往返多，吞吐上限明显。
  • Kettle 侧要长期维护写入缓冲和连接状态。
  • 大字段、文本字段、日期格式转换都会增加 JVM 压力。
  • 失败时经常只看到 JDBC 异常，定位到具体脏数据成本高。
  • 上亿行写入持续时间长，服务端资源一直被占着。

Doris 本身更擅长批量导入，而不是被当成普通 MySQL 一行行写。

所以思路要变：

不要让 Kettle 用 JDBC 慢慢 insert，而是让 Kettle 生成 Doris 能高效加载的数据文件，再由 Doris 批量导入。

3. 方案对比

常见方案有三种：

方案 优点 问题 适合场景
Kettle 表输出 配置简单 大表慢，容易 OOM，资源占用高 小表、低频同步
Kettle 输出 CSV + 手写脚本 LOAD DATA 性能较好 流程割裂，脚本多，失败重跑麻烦 临时任务、少量链路
Doris Bulk Loader 插件 保留 Kettle 流程，自动生成文件并执行导入 需要部署插件和规范路径 大表、批量、稳定调度

Doris Bulk Loader 的价值在于：它不是让你放弃 Kettle，而是把 Kettle 最后一步的“表输出”换成更适合 Doris 的批量加载。

1781677649666

4. Doris Bulk Loader 怎么工作

插件的工作方式可以理解成四步：

  1. 从上游 Kettle 流接收数据。
  2. 按字段映射和格式配置生成 CSV 批次文件。
  3. 自动执行 Doris LOAD DATA LOCAL INFILE。
  4. 导入成功后按配置清理 CSV 文件。

也就是说，用户仍然在 Kettle 里拖拽组件、配置字段、调度作业。

变化只发生在写入端：

  • 原来：Kettle 表输出 -> JDBC -> Doris。
  • 现在：Kettle 行流 -> CSV 批次文件 -> Doris LOAD DATA。

这会把大量写入压力从 pentaho-server JVM 侧释放出去，交给 Doris 更擅长的批量加载链路处理。

5. 环境准备

建议先确认这些条件：

项目 建议
Kettle/PDI 与插件版本匹配，例如 9.3.x
Doris 已开启 MySQL 协议访问
网络 Kettle 服务器能访问 Doris FE
账号 具备目标库表写入权限
临时目录 Kettle 运行用户有写权限
磁盘 CSV 临时目录要预留批次文件空间

如果是在 pentaho-server 上跑，重点确认：运行服务的系统用户是否有 CSV 目录写权限。

很多本地 Spoon 能跑、服务器调度失败的问题，最后都是权限或路径不一致。

6. 插件部署

部署方式通常是：

  1. 将 Doris Bulk Loader 插件包解压。

  2. 放到 data-integration/plugins和pentaho-server/pentaho-solutions/system/kettle/plugins 目录下。

  3. 将doris-bulk-loader.lic放到解压后的doris-bulk-loader文件夹下

  4. 重启 Spoon 或 pentaho-server。

  5. 在 Kettle 转换的“批量加载”分类里找到 Doris 批量加载步骤。

部署后建议先做两个验证：

1. Spoon 能正常启动。
2. 新建转换时能看到 Doris 批量加载组件。

安装路径参考：

1781678301068

7. 推荐配置

在 Doris 批量加载步骤里，重点配置这些项：

配置项 推荐值/说明
数据库连接 Doris 的 MySQL 协议连接
目标模式 Doris database
目标表 Doris table
CSV 文件/路径 推荐填写固定可写目录
保留 CSV 默认不勾选；排查问题时临时勾选
字段分隔符 默认 TAB，文本里逗号多时不要轻易改逗号
封闭符 文本复杂时可用双引号
转义符 有换行、引号、分隔符时建议配置
本地数据 一般保持开启，对应 LOCAL
批量提交数 默认 100000，按 Doris 和磁盘压力调优

CSV 路径建议按表名拆开，例如：

/data/kettle/doris_load/order_detail
/data/kettle/doris_load/member_behavior
/data/kettle/doris_load/inventory_snapshot

插件会按批次生成类似文件：

/data/kettle/doris_load/order_detail_0.csv
/data/kettle/doris_load/order_detail_1.csv

导入成功后，如果没有勾选“保留 CSV”，临时文件会自动删除。

1781677516250

8. 一个典型转换模板

以上亿订单明细入 Doris 为例：

表输入(MySQL/Oracle)
  -> 字段选择
  -> 数据清洗
  -> Doris 批量加载

9. 效果怎么评估

建议从四个指标看收益：

指标 表输出 Doris Bulk Loader
抽取耗时 上亿大表耗时长 明显缩短
JVM 内存 高，容易 OOM 明显下降
CPU 占用 长时间高位 压力降低
运维成本 需要堆机器和内存 可降配，成本下降

我们实际落地后的核心收益是：

  • 大表抽取时间降低。
  • pentaho-server 稳定性提升。
  • CPU 和内存使用下降。
  • 服务器资源降配接近一半。
  • 硬件成本和软件授权费用减少。

这里建议每个团队上线前做一次自己的基准测试：

1. 同一张大表。
2. 同一批数据。
3. 分别用表输出和 Doris Bulk Loader 跑。
4. 记录耗时、CPU、内存、失败率。

10. 常见问题排查

1. 提示 CSV 父目录不存在或不可写

检查 CSV 路径的父目录是否存在。注意 pentaho-server 的运行用户具有读写权限。

2. 字段不存在

检查字段映射。目标表字段和上游流字段都要存在，大小写、别名、中文字段名都要确认。

3. 特殊字符导致导入失败

临时勾选“保留 CSV”，保留失败批次文件。重点检查文本里的换行、双引号、分隔符。

11. 适合谁用

这个方案特别适合：

  • 已经大量使用 Kettle/PDI 的团队。
  • Doris 已经作为数仓或分析库使用。
  • 表输出写 Doris 慢、OOM、服务不稳定。
  • 有上千万、上亿行批量同步任务。
  • 不想重写整条 ETL 链路。
  • 希望降低 pentaho-server 资源配置成本。

它不一定替代所有实时同步工具。

但在离线批量、准实时批次、历史全量校准、老 Kettle 流程迁移 Doris 这些场景里，用 Doris Bulk Loader 替换表输出，通常是投入小、收益直接的一步。

12. 商业授权

  • 下载链接里的lic可以在windows上免费使用
  • linux需要商业授权获取更多的技术支持。
  • 免费试用和商用有任何问题都可以联系邮箱:support@datafor.com.cn

结论

Kettle 写 Doris 的瓶颈，很多时候不是 Kettle 抽不动，也不是 Doris 写不动，而是中间用了不适合大表的 JDBC 表输出。

上亿大表场景下，继续堆内存、堆 CPU、堆服务器，只是在给错误的写入方式买单。

把表输出换成 Doris Bulk Loader 后，链路仍然留在 Kettle 里，但写入方式变成 Doris 更擅长的批量加载。实际收益包括：抽取时间降低、pentaho-server 更稳定、CPU/内存占用下降、服务器降配、硬件和软件授权费用下降。

如果你的 Kettle 任务也经常因为写 Doris 大表 OOM，可以优先从这个点改，肯定错不了。

关键词：Kettle、Pentaho Data Integration、PDI、Apache Doris、Doris Bulk Loader、表输出、JDBC、LOAD DATA、数据同步、批量加载、pentaho-server OOM

# etl # 大数据 # 数据仓库
Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

数据价值归谁：一套让消费者、商家、政府都受益的产业操作系统

整个系统围绕五个核心问题展开：数据属于谁（身份与确权）、谁创造了价值（贡献计量）、价值如何沉淀为资产（BCAP 行为贡献凭证）、资产怎么流通（SE 通证与三级市场）、不同主体的数据如何安全互通（可信空间与授权协议）。对于省级数据交易所，这套系统持续产出已确权、已计量、已审计的 DID 数据资产包，三权声明清晰，授权边界可验证，是真正可以登记和流通的数据要素产品，而不是"有 GMV 就挂牌"的空壳。

avatar openEuler 社区
cover

Task Graph：HarmonyOS PC 为什么重新定义任务调度？

avatar openEuler 社区
cover

HarmonyOS应用＜民族图鉴＞开发第1篇：开篇——为什么选择鸿蒙原生开发

avatar openEuler 社区