PySpark：spark-submit运行结果与CLI不一致问题求助

这种本地CLI逐行跑完全正常，一用spark-submit提交成应用就出异常的情况真的很闹心，我帮你梳理几个关键的排查方向，一步步定位问题：

一、数据被覆盖而非追加的排查点 #

• 确认Spark版本一致性：有时候CLI默认的Spark版本和spark-submit调用的版本可能不一样，不同版本对mode='append'的处理逻辑存在细微差异。你可以分别在CLI和spark-submit的应用里添加print(spark.version)，输出并对比两个环境的版本号。
• 检查表的分区结构匹配度：如果之前你用不同的分区规则创建过test2表，append模式可能因为分区结构不匹配，触发意外的覆盖逻辑。可以在CLI里执行spark.sql("DESCRIBE EXTENDED test2")，查看表的分区信息，确认和当前代码中partitionBy='date'的规则完全一致。
• 验证路径权限与实际写入位置：spark-submit运行的用户（比如集群模式下可能是YARN用户）和你本地CLI的用户权限可能不同，导致实际写入的路径并非你指定的parquet_dir，甚至可能因为路径不存在重新创建表，间接造成数据覆盖。建议在代码里添加日志输出：print(f"实际写入路径: {parquet_dir}")，提交后去文件系统（HDFS/本地）检查该路径下的文件变化。
• 显式指定存储格式：虽然saveAsTable默认会用Parquet，但有时候显式声明格式能避免环境默认配置的差异，修改写入代码为：

  df.write.format('parquet').saveAsTable('test2', mode='append', partitionBy='date', path=parquet_dir)
  

二、Parquet文件大小正常但SQL无数据返回的排查点 #

• 检查元数据仓库一致性：saveAsTable会将表信息写入Spark的元数据仓库（比如Hive Metastore），如果spark-submit运行的环境和CLI使用的元数据仓库不是同一个（比如一个用本地Metastore，一个用集群共享的），那你在CLI查询的表和应用创建的表根本不是同一张！可以在代码里添加spark.sql("SHOW TABLES").show()确认表存在，查询时尽量指定数据库（比如SELECT * FROM default.test2）。
• 验证分区列date的生成逻辑：你通过to_date('time_stamp')生成分区列，要注意时区问题可能导致不同环境下date列解析异常。比如CLI的时区和spark-submit的时区不一致，可能导致date列全为null，进而分区数据无法被SQL查询到。可以在代码里添加df.select('time_stamp', 'date').show(10)，将输出打到日志里，确认date列的生成是否正常。如果是时区问题，在初始化SparkConf时指定时区：

  conf = SparkConf().setAppName('import-ipfixminute').set("spark.sql.session.timeZone", "UTC")
  sc = SparkContext(conf=conf)
  

• 直接读取Parquet文件验证数据：既然Parquet文件大小符合预期，你可以在CLI里直接读取该路径的文件：spark.read.parquet(parquet_dir).show()，如果直接读有数据但SQL查不到，那肯定是元数据同步的问题。这时候可以执行spark.sql("MSCK REPAIR TABLE test2")，手动让元数据仓库同步分区信息。
• 检查df.drop('all')的合理性：你的TSV文件里是否真的存在all列？如果不存在，drop('all')不会报错，但某些环境下可能意外导致DataFrame数据丢失？可以尝试注释掉这一行，或者改成更严谨的写法：df = df.drop(col('all'))，避免列名大小写或不存在的问题影响数据。

额外调试技巧 #

• 用spark-submit提交时加上--verbose参数，查看详细的运行日志，重点关注写入表和分区的环节，有没有隐藏的异常提示。
• 在代码里添加数据量日志：print(f"待写入数据总行数: {df.count()}")，确认确实有数据要写入，排除DataFrame为空导致的“无数据返回”。

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