两个Spark应用并行读写Hive表是否会引发数据不一致？

嘿，这个场景在生产环境里挺常见的——当写入和读取任务并行运行时，确实大概率会出现数据不一致的情况，我来给你捋清楚原因，再分享几个靠谱的规避方案：

为什么会出现不一致？ #

核心原因主要有两个：

1. 写入的分步执行逻辑：你用的saveAsTable+partitionBy写入时，Spark是先把数据写到临时分区目录，等数据完全落盘后才会去更新Hive Metastore的元数据（比如新增分区记录）。如果读取任务刚好卡在「数据写了一部分但元数据还没更新」这个窗口，要么读不到新分区，要么读到的分区里数据不完整（比如部分文件还在写入中，Spark读取时可能会跳过不完整文件，或者读到半截数据）。
2. 元数据缓存延迟：Spark默认会缓存Hive表的元数据信息，就算Metastore已经更新了，读取任务如果没主动刷新缓存，还是会用旧的元数据来读取，自然看不到新写入的数据。

怎么规避这种问题？ #

根据不同的业务场景，这里有几个实用的方案：

1. 改用Hive ACID事务表（生产级首选方案） #

Hive 3.0+支持ACID事务，Spark也能很好兼容。把表改成事务性的之后，写入操作会被封装成原子事务——只有当整个写入任务完全提交成功，读取任务才能看到新数据，直接避免了中间状态的读取。

• 首先要创建ACID表（注意只能用ORC格式）：

  CREATE TABLE sample (col1 string, other_col string)
  PARTITIONED BY (col1)
  STORED AS ORC
  TBLPROPERTIES ('transactional'='true');
  

• 写入时不需要额外复杂配置，保持Append模式即可，Spark会自动适配事务逻辑。
• 前提是要在Hive配置里开启事务支持：比如设置hive.support.concurrency=true、hive.enforce.bucketing=true等参数。

2. 用临时目录做原子写入（无ACID时的替代方案） #

如果没法用ACID表，那就手动实现原子写入逻辑：先把数据写到临时目录，等写入完全完成后，再把临时目录的数据移动到目标表的分区，最后刷新元数据。这样读取任务要么看到完整的新数据，要么完全看不到，不会出现中间状态。

• 步骤示例：
  1. 先写临时目录：

     df.write
       .option("path", "adl:///test-data/temp_sample")
       .mode(SaveMode.Overwrite)
       .format("json")
       .partitionBy("col1")
       .save()
     

  2. 确认写入完成后，把临时分区的数据移动到目标表的对应分区目录（可以用HDFS命令或者Spark的文件操作API）。
  3. 最后刷新元数据：

     // 刷新Spark的元数据缓存
     spark.catalog.refreshTable("sample")
     // 或者修复Hive元数据（如果是新增分区）
     spark.sql("MSCK REPAIR TABLE sample")
     

3. 强制读写任务的执行顺序（最简单但牺牲并行性） #

如果业务场景对并行性要求不高，直接用调度工具（比如Airflow、Oozie）把写入任务设为读取任务的依赖——只有写入任务完全执行成功，才触发读取任务。这种方式零复杂配置，但缺点是没法并行运行，适合数据更新频率不高的场景。

4. 每次读取前刷新元数据（辅助方案） #

如果只是因为Spark的元数据缓存导致看不到新数据，可以在读取任务里强制刷新缓存：

spark.catalog.refreshTable("sample")
val df = spark.read.table("sample")

不过这个只能解决元数据缓存的问题，没法解决写入过程中数据文件不完整的问题，所以通常要和其他方案配合使用。

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