PySpark使用md5哈希时spark-submit与其他环境下timestamp列结果不一致

排查方向（按实际踩坑概率从高到低排序） #

• 会话时区配置不统一，导致timestamp转字符串的结果存在本质差异
  这是这类问题最常见的原因：Spark里把timestamp类型用cast("string")转成文本时，输出内容完全跟随当前会话的spark.sql.session.timeZone配置走。哪怕是同一个原始timestamp值，在UTC时区转出来是2024-01-01 00:00:00，在东八区转出来直接差8个小时，变成2023-12-31 16:00:00，输入的字符串都不一样，md5算出来的结果肯定对不上。
  排查的时候别拿之前在交互环境核验的结果当准数，直接在离线spark-submit任务里采10条数据，把转成string后的timestamp_col值落一小份文件，和另外两个环境的同批数据逐字符对比；再分别在三个环境里执行spark.conf.get("spark.sql.session.timeZone")，看时区配置是不是完全一致。很多人踩的坑就是pyspark shell默认拿节点的系统时区当会话时区，Databricks集群手动配了东八区，spark-submit提交的时候啥参数没加，直接用了集群节点默认的UTC，三个环境时区都不一样，结果自然差很多。
  解决的时候别依赖环境默认配置，直接在代码里显式把时区写死，SparkSession初始化之后加一行：spark.conf.set("spark.sql.session.timeZone", "Asia/Shanghai")，所有环境统一用同一个配置值。
• 转成字符串后带了肉眼看不见的特殊字符
  不同环境读Hive表用的SerDe、解析逻辑有差异的时候，cast成string的列值可能前后带空格、换行符，连null的转换规则都不一样——有的环境把null转成字符串"null"，有的直接转成空串，这些差异肉眼根本看不到，但只要输入字符串差一个字节，md5结果就完全不对。
  排查的时候直接对同一条数据的timestamp_col计算length(timestamp_col)、hex(timestamp_col)，逐字节看编码结果，如果多出来代表空格的20、代表换行的0a字节，就是这个问题。
  解决的时候别直接拿原字段算md5，先做标准化处理：把原来的md5("timestamp_col")替换成md5(coalesce(trim(timestamp_col), ""))，统一去掉前后空白字符，把null值处理成空串，消除这些环境带来的字符干扰。
• Spark和Hive客户端版本不匹配，导致类型转换逻辑有偏差
  spark-submit提交的时候，如果用的Spark版本、Hive Metastore客户端版本和pyspark shell、Databricks的版本对不上，可能会把timestamp列的元数据识别错——比如老版本Spark转timestamp字符串的时候会带着微秒精度，新版本默认把微秒截断了，输出的文本格式不一样，md5结果自然对不上。
  排查的时候分别在三个环境里看读出来的DataFrame列类型df_hive.select("timestamp_col").dtypes，对比Spark版本spark.version，确认三个环境连的是同一个Hive Metastore库，避免出现读表时元数据拿错的情况。
  解决的时候统一所有环境的Spark、Hive客户端版本，spark-submit提交的时候显式指定对应版本的依赖，别直接用集群节点上的公共依赖，版本差一点都可能出问题。
• 三个环境实际读进来的源数据就不一样
  如果不同环境的谓词下推配置、分区扫描规则有差异，实际读到的timestamp_col值本身就不一样，算出来的哈希肯定有差。
  排查的时候分别在三个环境对读出来的DataFrame做简单聚合：统计总行数，取min(timestamp_col)、max(timestamp_col)，把所有timestamp_col的长度加个总和，确认三个环境读进来的数据集完全一致，没有漏扫分区、过滤逻辑偏差的问题。

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