HADOOP_CONF_DIR与SPARK_CONF_DIR的log4j配置优先级异常原因排查

1. Log4j版本兼容与初始化顺序冲突 #

Spark 2.x及以后默认采用Log4j2，但Hadoop生态部分依赖仍保留Log4j1的配置逻辑。当HADOOP_CONF_DIR下存在log4j.properties（Log4j1格式）时，JVM启动初期会优先加载该文件——因为Redhat虚拟机环境中可能存在系统级Hadoop依赖残留、环境变量优先级更高等情况，导致Hadoop的类路径被提前注入，直接初始化了Log4j1的日志上下文，接管了根日志配置。而Spark、Parquet等依赖是后续加载的，它们适配Log4j2，会读取SPARK_CONF_DIR下的log4j2.properties，最终造成两类日志配置分裂的现象。

Docker环境是隔离的干净环境，没有系统级Hadoop依赖干扰，JVM启动时优先加载Spark的Log4j2配置，因此根日志完全遵循log4j2.properties。

2. Python虚拟环境的类路径加载干扰 #

在Redhat虚拟机的Python虚拟环境中，即便SPARK_HOME指向虚拟环境内的PySpark目录，系统中仍可能存在全局的HADOOP_CONF_DIR环境变量或Hadoop类路径配置，JVM启动时会优先读取全局的Hadoop配置，而非虚拟环境内的Spark配置。Docker环境则不存在这种全局干扰，Spark的配置路径优先级更高。

3. spark.driver.extraJavaOptions生效时机滞后 #

spark.driver.extraJavaOptions中设置的-Dlog4j.configurationFile是Spark驱动进程启动后才传递的参数，但Log4j的配置初始化是在JVM启动的最早期阶段完成的。如果HADOOP_CONF_DIR的log4j.properties已经在JVM启动时初始化了Log4j1上下文，后续的Log4j2配置参数无法覆盖已初始化的根日志上下文，只能对后续加载的类（如Spark、Iceberg依赖）生效，这就是修改该参数后根日志仍不受影响的原因。

4. HADOOP_CONF_DIR的配置优先级高于SPARK_CONF_DIR #

在Redhat环境中，当HADOOP_CONF_DIR作为系统环境变量存在时，Spark启动脚本会默认优先加载Hadoop的所有配置文件，包括日志配置。而SPARK_CONF_DIR的配置加载顺序在后，此时根日志上下文已经被Hadoop的log4j.properties初始化完成，无法被后续的Log4j2配置替换。Docker环境中可能未设置全局HADOOP_CONF_DIR，或者Spark启动脚本优先处理了SPARK_CONF_DIR的配置。

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