场景痛点：HTTP 接口返回超大 JSON 数组，传统一次性全量加载整个 JSON 报文到 JVM 内存，大报文直接触发 OOM，无法拉取百万级、GB 级接口数据。
一、原有 HTTP Source 的问题
早期 SeaTunnel HTTP Source format=json 的工作模式：
HTTP 接口完整响应全部下载到内存，得到完整大 JSON 字符串；
将整个完整 JSON 一次性解析成完整 JsonObject/JsonArray 对象；
再遍历数组输出一条条数据记录。
致命缺陷
如果接口返回
[{"...}, {...}, {...}]十万 / 百万条的 JSON 数组，整个响应体几十 GB，全部加载进 JVM 堆，内存直接打爆 OOM；数据量越大，内存占用与报文总大小成正比，调大 Xmx 也治标不治本；
分页 API 也无法彻底规避，单页返回上万条大对象依然内存压力巨大。
二、JSONL（JSON Lines）方案是什么
JSONL 格式：每行一条独立 JSON 对象，无外层数组包裹，换行符分割，示例：
json
{"id":1,"name":"a"}
{"id":2,"name":"b"}
{"id":3,"name":"c"}
不需要等待全部响应接收完毕；
流式按行读取 HTTP response 输入流，读一行、解析一行、输出一条记录，不需要把全量报文放入内存。
关键：HTTP 服务端返回
application/jsonlines，响应体是流式 JSONL，SeaTunnel 直接对 InputStream 逐行解析，内存只维持很小缓冲区。
三、SeaTunnel JSONL HTTP Source 核心能力
新增format = jsonl，基于 HTTP response InputStream 流式解析，边下载边解析，不缓存完整报文。
核心优势
✅ 内存占用稳定，和总数据量无关，仅由缓冲区大小决定，GB 级接口响应也不会 OOM；
✅ 支持 Batch 流式拉取 HTTP 接口 JSONL 数据流；
✅ 逐行映射 SeaTunnel 行记录，直接下游写入 Doris、MySQL、Hive 等；
✅ 支持 schema 定义、字段映射、过滤转换；
❗前提：后端接口必须输出标准 JSONL 格式，不能返回外层包裹的 JSON 数组。
配置示例（HOCON）
hocon
source {
Http {
url = "http://api.example.com/bigdata/stream"
method = "GET"
headers {
Accept = "application/jsonlines"
}
format = "jsonl" # 开启JSONL流式解析
schema {
fields {
id = BIGINT
name = STRING
create_time = TIMESTAMP
}
}
}
}
sink {
Doris {
...
}
}
四、两种模式对比
表格
五、现实业务约束与改造方案
很多业务接口只返回传统 JSON 数组{"code":200,"data":[{}]}，不支持 JSONL 输出，有两条路径：
服务端改造（最优）：接口增加流式输出接口，返回 JSONL，不要组装外层大数组；
中间代理层：开发轻量代理服务，消费原接口大 JSON 数组，流式拆解转为 JSONL 输出，再给 SeaTunnel 读取；
不推荐：单纯调大 JVM 堆
-Xmx16g，数据持续上涨依然会 OOM，资源成本高。
六、配套注意事项
网络稳定性：长 HTTP 连接，网络中断需要重试机制；
分页场景：JSONL 适合流式导出接口；普通分页 API 还是需要 page 循环调用；
Checkpoint：JSONL HTTP Source 为 batch 读取，无 offset，不支持 exactly‑once；需要业务侧做幂等；
换行符：JSONL 标准是
\n换行，注意接口返回不要混用\r\n；二进制大文件：超大非 JSON 数据，使用
format=binary分片下载模式。
七、总结
传统
format=json是全报文加载模型，受限于 JVM 堆内存；JSONL 是流式迭代模型，把内存压力从计算引擎转移到服务端输出侧。
当需要从 HTTP 接口同步千万级大量业务数据，优先推动服务端输出 JSON Lines，使用 SeaTunnel format=jsonl，彻底解决大 JSON 报文 OOM 问题，不需要疯狂调高 JVM 堆内存。
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢