数据流之间传递大批量明细数据
跨数据流传递大批量明细时，不要把明细直接放入被调用数据流的启动参数，也不要通过【响应】节点返回完整明细。
严重风险：不要使用启动参数或【响应】节点传递大批量明细！
大批量明细会在查询结果收集、Python 列表转换、序列化、网络传输和接收方解析等阶段产生多份数据副本，可能造成：
-
请求体过大，网关拒绝请求、传输超时，接口响应极慢或完全无响应；
-
CPU 和内存瞬时大幅升高，运行进程被系统强制终止，甚至发生 OOM、容器重启；
-
重试、批量调用或多个实例同时触发后，资源消耗被进一步放大，导致实例长期排队；
-
运行参数、结果和日志持续增长，监控页面可能无法正常打开，问题实例也更难查询和清理；
-
严重时会抢占同一环境的共享资源，影响其他原本正常运行的数据流和服务。
这不是单个接口“慢一点”的问题，而是可能影响整个数据流运行环境的稳定性。
错误示例：将约 25 万条明细放入启动参数
下图把查询结果转换为 Python 列表，并将约 25 万条明细作为 pk_range 参数传给另一个数据流：
图中的明细数量、字段数量或并发实例继续增加时，上述风险还会进一步放大。并发和内存方面的处理建议参见并发、队列与内存优化。
启动参数应以批次 ID、期间、组织、文件位置等轻量信息为主。请求体是否低于某个固定大小，不是判断这种设计是否合理的唯一标准；只要参数中包含会随业务量持续增长的逐行明细，就应改用“先存储，再传递标识”或分块处理。同步、异步和批量异步调用都应遵循这一原则。
推荐方案一：先存储，再传递标识
这是优先推荐的方式：
-
创建数据表、对象、文件或其他受管存储，用于保存待处理明细。
-
使用业务批次 ID 或调用方实例 ID 标记本批数据。
-
调用方数据流先写入明细，调用其他数据流时只传批次 ID、期间、组织等轻量参数。
-
被调用数据流按批次 ID 查询明细；需要调用方实例 ID 时，可使用
Pipeline.run.parent_run_id。 -
为中间数据设置状态、保留期限和失败后的清理规则。
推荐方案二：分块调用
无法使用中间存储时，将数据拆成多个小批次，并限制同一时间提交的批次数。每批 1000～5000 行只能作为起始参考，字段较宽或内存较小时应继续减小，并通过压测确定。
同时注意
-
查询时只取需要的行和列，优先按期间、组织或主键范围分区。
-
分批读取只能降低读取阶段的瞬时内存；后续全量连接、排序或 Python 收集仍可能再次加载全部数据。
-
如果错误用法已经造成异常，应先暂停相关定时计划和调用，避免继续生成大请求；确认实例不再需要后，再删除异常实例并按磁盘占用优化与清理处理历史数据。
回到顶部
咨询热线
400-821-9199
