Spark写入Hive后缓存DataFrame行数异常膨胀问题排查

你遇到的问题是三个Spark核心机制共同作用的结果，本质是初期把Spark DataFrame当成了Java中存储固定数据的内存集合，对懒执行和缓存逻辑存在认知偏差：

1. DataFrame是执行计划模板，不是固定数据集：你写的所有select、join、map、cache操作全都是懒执行的，调用这些方法时Spark只会记录计算逻辑，不会真正启动计算。只有碰到count、write这类action算子时，才会顺着记录的血缘（即完整计算链路）从头执行计算。
2. 缓存不会永久生效，会随上游数据源变更自动失效：你调用的.cache()本质是persist(MEMORY_ONLY)，调用时只是给Spark打了个标记——“第一次算完DF_B把结果存在executor内存里”。当你用SaveMode.Overwrite覆盖写入DF_B依赖的源表T_B时，Spark会自动失效所有依赖T_B的缓存块，避免读到不一致的数据，失效的缓存不会自动重算，下一次触发action时会重新顺着血缘执行计算。
3. 重算时读到了被自己覆盖的T_B数据：第一次调用DF_B.count()打日志时，T_B还是原始状态，join结果为3条，这时候缓存里确实存了3条数据。但当你把DF_C overwrite进T_B之后，DF_B的缓存已经被标记为失效，后面再调用DF_B.count()时，Spark会重新跑DF_B的计算逻辑：读T_A -> 读T_B（这时候T_B已经被你写成了DF_C的3条数据）-> 执行join，3条T_A数据和3条新的T_B数据匹配后自然得到9条结果，也就是你观察到的3*N异常行数。

你测试到的两种现象完全符合这个逻辑：

• 不做持久化或用persist(MEMORY_AND_DISK)时：磁盘缓存同样会在上游表被覆盖时失效，写完T_B后重算自然得到9条结果；DF_C因为没有做持久化，写入前触发count时得到的是计算链路未被污染时的3条结果，所以写入后立刻count DF_C还是3条。
• 用默认cache()时：内存缓存被失效后，DF_C的血缘也没有被截断，重算DF_C时同样会读取已经被修改的T_B数据，所以结果也变成9条。

按生产环境可靠性从高到低给出三个方案：

• 方案1：用Checkpoint截断DF_B的血缘，彻底隔离对原T_B的依赖
  生成DF_B之后立刻用localCheckpoint()（数据存在executor本地磁盘，不需要额外配置HDFS路径）切断血缘，再触发一次action强制物化结果，这样DF_B后续的计算就和原T_B完全解绑，你后面怎么修改T_B都不会影响DF_B的数据。示例代码：

  val DF_B = DF_A.join(extraData,
              col("something_else") === other_thing, "left"
          ).toDF().localCheckpoint().cache()
  // 立刻触发action，强制完成checkpoint和缓存物化
  DF_B.count()
  

  如果数据量特别大，担心executor本地磁盘空间不足，可以配置HDFS checkpoint路径用普通checkpoint()，可靠性更高。
• 方案2：将DF_B物化到独立临时存储，完全脱离原表链路
  第一次生成DF_B之后，立刻把它写到一个和T_B完全无关的临时存储（比如HDFS临时parquet目录、独立的Hive临时表），后面要用到DF_B的时候直接从这个临时路径读取，完全不会受T_B写入操作的影响。这个方案是生产环境最稳妥的，不会出现缓存丢失、内存不足的问题。
• 方案3：调整作业执行顺序，提前算完所有结果再写表
  不要边依赖T_B计算边覆盖写T_B，你可以先把DF_C、DF_D都基于初始的DF_B算好，分别写到两个独立的临时路径，最后再依次把临时路径的数据覆盖写入T_B，从流程上避免写入操作影响上游计算。

额外提醒：你代码里的join条件写法存在语法问题，col(something_else=other_thing)不是正确的Spark Column写法，正常应该是col("something_else") === other_thing，这个虽然不是本次行数异常的原因，但建议修正避免后续出现隐式转换导致的逻辑错误。

你可以顺着以下几个点补充Spark核心机制知识，就能彻底规避这类问题：

• Spark懒执行（Lazy Evaluation）与血缘（Lineage）的核心原理
• Cache/Persist缓存的触发条件、失效场景，以及和Checkpoint的核心区别
• Spark写入Hive表时SaveMode.Overwrite的执行流程，尤其是动态分区覆盖下的文件清理时机
• Spark数仓开发通用规范：禁止在同一个作业中边读取某张表边覆盖写入同一张表，除非已经把读取的结果完全物化、切断和原表的血缘

内容的提问来源于stack exchange，提问作者Carlos S. Na