Spark Structured Streaming作业延迟过高问题排查与咨询

1. 该现象是否正常？ #

不正常。仅505行数据的批处理耗时近64秒，且addBatch和commitBatch阶段耗时占比超99%，完全不符合低负载下Structured Streaming的正常处理效率，属于明显的性能异常。

2. 可能的原因分析 #

• 多流竞争Kinesis分片资源：4个作业同时读取同一个Kinesis流，而Kinesis的每个分片同一时间仅能被一个消费者占用，多作业抢分片会引发频繁的分片重平衡，大幅增加数据拉取的等待时间，进而拉长整个批处理周期。
• S3存储层IO瓶颈：写入外部Delta表到S3时，addBatch（写入数据文件）和commitBatch（写入事务日志、更新表元数据）都依赖S3交互。S3作为对象存储，小文件频繁写入、跨区域访问（集群与S3不在同一AWS区域）或集群到S3的网络带宽不足，都会导致IO耗时剧增。
• Delta表小文件与元数据开销：低负载下每个批次生成极小的数据文件，频繁的小文件操作会让Delta的元数据维护（如commit阶段的日志合并、文件列表更新）变得异常沉重，直接推高commitBatch的耗时。
• 集群资源不足：2节点集群（m6g.large worker + m6g.xlarge driver）的CPU、内存资源有限，4个流作业并行运行会抢占资源，导致每个作业的执行线程不足，IO操作等待时间被拉长；且m6g.large worker本身仅2vCPU、8GB内存，无法支撑多流并发的IO密集型操作。
• Kinesis读取配置缺失：当前读取代码未设置maxRecordsPerShard、fetchInterval等参数，可能导致每次拉取数据量过小，触发频繁的小批次处理，累加IO开销；若未指定startingPosition，还可能存在不必要的数据回溯或重复消费。
• Schema合并的额外开销：开启mergeSchema=true后，每次commit都会检查并合并Schema，即使是无状态转换，频繁的Schema检查也会增加commitBatch的耗时。

3. 同一作业中多流的拉取方式 #

同一Spark作业内的多个流（由多个readStream创建）是并行拉取数据的。Spark Structured Streaming会为每个流分配独立的查询执行线程，各自独立完成Kinesis拉取、数据转换、Delta写入的全流程，不会依次执行。但多个流读取同一Kinesis流时，会受限于Kinesis的分片并发规则，实际拉取效率会因分片竞争而下降。

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