EMR6.7运行Spark3.2.1 Kinesis流应用未生成DynamoDB检查表且RDD为空

按以下优先级逐一排查，绝大多数同类问题都能定位解决：

• 首先对齐连接器和集群Spark版本：你当前引入的spark-streaming-kinesis-asl 3.0.0和EMR 6.7.0内置的Spark 3.2.1版本不匹配，ASL连接器的版本必须和集群运行的Spark版本完全一致，直接把依赖替换为spark-streaming-kinesis-asl_2.12:3.2.1，打包时将Spark相关依赖设置为provided范围，不要把Spark本身的类打进业务Jar包。版本不匹配导致的API、序列化兼容问题大多不会抛出显性报错，只会静默失败返回空RDD，是这类场景的最高发原因。
• 修正消费初始位置配置，清空脏检查点：先把之前生成的空DynamoDB检查点表、S3/HDFS上的流处理检查点目录全部删除，首次测试时将Kinesis消费起始位置设置为TRIM_HORIZON，不要使用依赖检查点的续跑逻辑，也不要默认用LATEST位置——如果任务启动后短时间内没有数据写入Kinesis，LATEST位置会直接返回空结果，容易和故障混淆。
• 校验IAM权限与网络连通性：确认EMR集群关联的EC2实例角色已配置Kinesis数据拉取权限（包含kinesis:GetRecords、kinesis:GetShardIterator、kinesis:DescribeStream、kinesis:ListShards）以及DynamoDB检查点表的读写、建表权限。权限缺失、安全组拦截、VPC终端节点配置错误导致的拉取超时、鉴权失败，很多时候会被KCL客户端的重试逻辑吞掉，不会在Driver日志里打印显性错误。

验证基础连通性时，可以直接在EMR主节点调用AWS CLI的kinesis相关命令拉取流数据，用和集群任务相同的实例角色做验证，先排除网络、权限层面的基础问题，再排查Spark任务本身的配置问题。

• 移除手动放入Spark jars目录的高版本Guava包：EMR 6.7.0内置的Guava版本已经和Hadoop、Spark、AWS SDK做了兼容性适配，你手动放入的guava-31.0.1-jre.jar会触发类版本冲突，导致KCL客户端拉取数据时出现方法不存在的隐性异常。如果业务代码确实需要高版本Guava，要通过Maven Shade插件对Guava包做重定位，不要直接替换集群内置Jar。
• 开启DEBUG日志定位隐性报错：提交任务时调整日志配置，将com.amazonaws.services.kinesis、org.apache.spark.streaming.kinesis两个包的日志级别设置为DEBUG，到Executor日志（不要只看Driver日志）中查看Shard列表拉取、ShardIterator生成、数据拉取请求的具体返回，就能定位剩下的小众问题，比如分片被意外合并、迭代器过期等。

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