使用spark.readStream.format("s3-sqs")读取SQS消息全为null问题排查

我之前也踩过类似的SQS消费坑，结合你描述的情况，给你几个针对性的排查方向，应该能帮你找到问题根源：

• Schema 匹配的隐性问题
  虽然本地Python能拿到符合Schema的JSON，但很可能存在容易忽略的匹配细节：

  • 检查字段名大小写是否完全一致：比如SQS消息里的字段是userName，但你的Schema定义成了username，这种大小写差异会导致解析失败返回null
  • 确认嵌套字段的解析逻辑：如果消息体是嵌套结构（比如{"data": {"orderId": 123}}），但你的Schema直接定义了orderId字段而没有嵌套层级，也会无法解析
  • 严格核对字段类型：比如消息里的数字是字符串格式（"count": "100"），但Schema把count定义成了整数类型，这种类型不匹配也会导致解析后字段为null

  举个典型的错误例子：
  消息体：

  {"userName": "john_doe", "age": "30"}
  

  错误的Schema定义：

  class User(BaseModel):
      username: str
      age: int
  

  这种情况下解析出来的User实例会是username=None, age=None。

• 消息解码/序列化方式不匹配
  确保你当前消费代码的解码逻辑和本地Python一致：

  • 本地Python是不是直接用json.loads()解析消息体？而当前消费代码如果用了其他序列化库（比如Jackson、Pydantic的严格模式），可能因为格式兼容问题解析失败
  • 检查消息体是否有编码问题：比如消息是带BOM的UTF-8格式，部分解析库会无法正确识别，导致解析结果为null
  • 确认消息体是否被base64编码：如果生产者在发送消息时做了base64编码，消费时需要先解码再解析JSON

• 混淆SQS消息属性与消息体
  有时候生产者会把业务数据放在**消息属性（MessageAttributes）**里，而不是消息体（Body）中。你看到的队列记录数是总消息数，但如果消费代码只读取消息体，自然会拿到null。可以登录AWS控制台，查看一条消息的详情，确认数据是在Body字段还是MessageAttributes里。

• "rate"格式消费的特殊逻辑差异
  既然用"rate"格式时代码正常，重点对比两种消费方式的差异：

  • 检查"rate"模式是否使用了不同的消息解析逻辑：比如自动处理了编码兼容、Schema宽松匹配
  • 确认批量消费的处理逻辑：非rate模式如果是批量拉取消息，有没有在循环处理时出现逻辑错误（比如只处理第一条，其他消息直接返回null）
  • 排查是否有消息过滤逻辑：rate模式可能自动跳过了解析失败的无效消息，而另一种模式把这些无效消息返回成null

• SDK版本或配置问题

  • 核对SDK版本：当前消费代码用的AWS SDK版本和本地Python的boto3版本是否一致？部分旧版本SDK在处理特定格式消息时存在解析bug
  • 检查长轮询配置：如果消费用的是短轮询，偶尔会出现空响应，但你说能看到记录数，这个可能性较低，但可以确认是否开启了WaitTimeSeconds长轮询
  • 确认队列URL正确性：虽然权限正常，但如果误连了其他环境的队列（比如测试 vs 生产），可能队列里的消息格式不符合当前Schema，导致解析为null

最后给个快速定位的小技巧：从AWS控制台手动拉取一条消息的Body内容，复制到当前消费代码的解析逻辑中单独测试，看能不能正确解析成目标数据结构。如果单独测试正常，那问题大概率出在消费流程的其他环节；如果单独测试也返回null，那就是Schema或解析逻辑的问题。

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