结构化Spark Streaming数据丢失排查：Glue4+PySpark Kafka场景

一、Kafka消费端验证 #

• 先确认Kafka Topic数据完整性：用kafka-consumer-groups.sh查看消费组的offset提交状态，对比Topic总消息数与作业实际消费的消息数，排查是否存在offset跳变、提交滞后或漏提交的情况。
• 检查消费者配置：确认auto.offset.reset参数是否为earliest（若需要全量消费），避免作业重启时跳过历史消息；调整max.poll.records至合理值，防止单次拉取过多导致处理超时，引发丢数或重复消费。

二、数据处理环节排查 #

• repartition/partitionBy逻辑校验：
  • repartition后统计各分区数据量，对比原始输入总数，确认repartition过程是否丢数。若分区数设置不合理（过大/过小），易引发数据倾斜或任务失败，需根据数据量调整分区数。
  • 检查partitionBy字段是否存在null值：Spark会将null值数据写入__HIVE_DEFAULT_PARTITION__目录，排查该目录是否有遗漏数据，必要时对null值做兜底处理（如替换为默认值）。
• foreachBatch执行逻辑：
  • 确保offset提交与写入操作绑定：在foreachBatch内，只有当batchDF.write成功完成后，再调用offsetRange.commit()，避免写入失败但offset已提交导致的丢数。
  • 排查批次失败日志：在Glue作业日志中搜索Task failed、Exception关键词，确认是否存在某批次处理失败未重试，导致该批次数据丢失。

三、Parquet写入环节验证 #

• append模式分区覆盖问题：若按时间字段分区，开启spark.sql.sources.partitionOverwriteMode=dynamic，确保仅覆盖目标分区数据，避免因默认的静态覆盖逻辑导致其他分区数据丢失。
• 存储系统一致性检查：若写入S3等最终一致性存储，需确认文件是否完全落地——可在写入后添加短延迟，或通过存储API校验文件存在性与大小，排除因存储一致性导致的“假丢数”。
• 持久化有效性确认：若使用cache()，改为persist(StorageLevel.DISK_ONLY)，避免内存溢出导致数据丢失；在后续操作前通过isCached()校验缓存有效性。

四、Glue作业配置优化 #

• 调整资源配置：增大spark.executor.memory与spark.executor.cores，缓解OOM或任务超时问题，减少因资源不足导致的数据丢失。
• 开启DEBUG日志：设置spark.log.level=DEBUG，查看每个批次的数据流、分区变化、写入细节，定位具体丢数环节。

五、端到端数据校验 #

• 唯一ID校验：在Kafka生产端为每条消息生成唯一ID，写入Parquet后定期对比Kafka侧ID总数与Parquet侧ID总数，定位丢失的具体消息。
• 批次采样对比：随机抽取多个批次的Kafka消息与对应Parquet数据，逐批校验内容，排查是否存在特殊数据（如大字段、特殊字符）导致的丢数。

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