如何仅恢复Delta Lake表的指定分区至历史版本？

方案1：临时分区兜底法 #

• 处理目标分区前，先把该分区的当前数据导到一个临时分区（比如_tmp/partition_key=xxx），和原分区物理隔离开。
• 正常处理目标分区的增删改，成功就删掉临时分区完事；要是失败，就执行下面的SQL把临时分区的数据覆盖回去：

  DELETE FROM delta.`path/to/table` WHERE partition_key = 'xxx';
  INSERT INTO delta.`path/to/table` PARTITION (partition_key='xxx') SELECT * FROM delta.`path/to/table/_tmp/partition_key=xxx`;
  

• 好处：纯原生操作，并发场景下其他分区的写入完全不受影响——Delta Lake对分区写入的锁是分区粒度，不是全表锁，所以不会冲突。

方案2：分区克隆快照法 #

• 处理分区前，给目标分区做个深度克隆（只克隆指定分区，不是全表）：

  from delta.tables import DeltaTable
  
  delta_table = DeltaTable.forPath(spark, "path/to/table")
  # 克隆指定分区到临时路径
  delta_table.clone(
    target_path="path/to/table/_clone/partition_key=xxx",
    is_shallow=False,
    condition="partition_key = 'xxx'"
  )
  

• 操作失败时，先删掉原分区的错误数据，再把克隆的数据插回去就行。
• 注意：深度克隆会复制数据文件，适合数据量不大的分区；如果分区数据量特别大，用浅克隆（is_shallow=True），但浅克隆依赖原表的历史文件，得确保原表没清理过历史版本。

方案3：自定义分区版本回滚 #

• 处理分区前，先记录该分区的最新版本号（可以通过delta_table.history().filter(f"partition_key = 'xxx'").select("version").first()拿到）。
• 要是操作失败，就对比操作前后的分区文件列表，删掉本次操作新增的文件，再从历史版本里把该分区的旧文件恢复回来。
• 这个方法需要你对Delta Lake的底层文件结构熟，适合有一定定制需求的场景。

为啥表级恢复在并发场景下不好使？ #

表级恢复（RESTORE TABLE ... VERSION AS OF）是把整个表回滚到指定版本，会直接覆盖其他并发写入的分区数据，等于把别人写的东西也给删了，肯定不能用在多分区并发处理的场景里。

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