PySpark执行CREATE TABLE建表后查询抛出Py4JJavaError如何解决

你遇到的java.lang.NoSuchMethodError: org.apache.hadoop.fs.FileSystem.listLocatedStatus属于典型的Hadoop依赖版本冲突问题：

show tables、printSchema仅会请求Hive Metastore拉取元数据，不需要访问表对应的底层存储文件，因此不会触发报错；执行SELECT查询时需要扫描表的存储路径，才会调用FileSystem相关接口触发版本不兼容异常。插入数据后依然报错，也验证了问题和表是否为空无关，核心在存储层访问的依赖适配问题。

• 首先对齐各组件的Hadoop版本：
  执行spark-submit --version查看当前Spark环境绑定的Hadoop依赖版本，再核对Hive Metastore服务端、底层存储（HDFS/对象存储）服务端的Hadoop大版本，三者必须保持一致（比如同为Hadoop 3.3.x系列，不能混用2.7.x和3.x版本）。
• 排除作业提交时的依赖覆盖：
  提交PySpark作业时加上以下配置，优先使用集群侧的依赖包，避免本地环境自带的Hadoop包覆盖集群版本：

  --conf spark.driver.userClassPathFirst=false --conf spark.executor.userClassPathFirst=false
  

  如果是自定义打包的PySpark虚拟环境，移除环境内预装的hadoop-client、hadoop-hdfs等相关依赖，全部复用集群提供的依赖。
• 验证表存储路径的可用性：
  先通过Hive命令行执行DESCRIBE FORMATTED tabulated_ontologies.context_concept_table_code_q4拿到表的LOCATION存储路径，再用Hadoop命令行直接访问路径：

  hdfs dfs -ls <你的表存储路径>
  

  确认路径存在、提交作业的用户有读/写权限，排除路径不可访问导致的异常误报。如果表存在对象存储上，需要确认当前Hadoop版本对应的对象存储客户端jar包（比如hadoop-aws、aliyun-sdk-oss等）版本匹配，没有出现版本断层。
• 临时规避读取报错的方案：
  查询前开启Spark原生Parquet读取适配配置，跳过Hive SerDe的逻辑，减少对旧版Hadoop接口的调用：

  spark.conf.set("spark.sql.hive.convertMetastoreParquet", "true")
  spark.conf.set("spark.sql.hive.convertMetastoreOrc", "true")
  

  新插入数据时可以直接用Spark原生数据源建表，避免依赖Hive的旧接口：

  CREATE TABLE tabulated_ontologies.context_concept_table_code_q4 
  USING parquet
  AS SELECT ...
  

• 插入数据校验的兼容方案：
  依赖问题修复前，插入数据后可以先通过spark.sql("INSERT INTO ...").count()确认插入行数符合预期，同时比对写入前的DataFrame和从Metastore拉取的表schema是否一致，待依赖问题解决后再做全量内容校验。

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