很多数据开发人员在处理大数据分区数据时，误删分区是常遇到的紧急问题，轻则延误业务，重则影响线上服务。今天就给大家讲一个用Iceberg时间旅行功能快速救回误删分区数据的真实实践。
一、真实业务里的误删分区事故
1.1 那天的紧急情况
上个月我负责的电商平台订单数据，是按天做分区存的，2024年5月20号的分区里存了当天所有的用户订单，到第二天上班时运营说看不到当天的交易数据。我一查，才发现前一天下班前，实习生小王在清理冗余分区的命令里写错了日期，把2024-05-20的分区当成要删的旧分区给删了。当时离早高峰还有不到3小时，要是找跨机房备份再恢复，至少要2小时，肯定赶不上，那运营就得被老板骂了。
1.2 为什么Iceberg是救星？
我们的订单数据用的是Apache Iceberg做表格式，之前只知道它能简化表管理，没想到这次靠它的时间旅行功能救了场。Iceberg和普通的Hive表不一样，它会把每一次对表的修改（包括删分区、插数据这些）都生成一个快照，相当于给每一步操作留了个“版本记录”，就像你玩游戏时存的多个存档点，要是当前关卡打输了，读最近的存档就能回到之前的状态，不用从头再来。
二、先搞懂Iceberg的时间旅行和快照回滚
2.1 时间旅行到底是啥？
可能有同学会问，时间旅行听起来像科幻，实际用起来很简单。你可以把Iceberg表想象成一本写满内容的活页本，每一页的内容对应一个“快照”，每次你在本上改东西（比如删某一页的内容），Iceberg不会直接删掉那一页，而是在目录里记一下“现在看到的是第X页，之前是第Y页”。想回到之前的状态时，只要把“现在看到的页面”改成Y对应的那一页就行，也就是我们说的“时间旅行”到之前的某个时刻。
2.2 快照回滚和普通删分区的区别
要是用普通的Hive表，直接删分区后数据可能真的从存储里删掉了，找起来非常麻烦。但用Iceberg时，删分区的操作只是把该分区在当前快照里的信息标记为无效，并没有真的删数据文件，只要能找到删分区之前的快照ID，就能把表回滚到删分区之前的状态，相当于让时间倒流，把删错的分区找回来。
三、具体的操作步骤（完整示例）
这里我们用Spark SQL作为操作工具，整个过程都是纯命令行操作，只要有集群权限就能做，不用额外装东西。技术栈明确为Spark SQL + Apache Iceberg，单一技术栈。
3.1 先确认要恢复的表和分区
第一步得先确认我们要操作的是不是那张出问题的表，以及要恢复的分区是否存在过。假设我们的Iceberg表叫demo.orders，分区字段是dt，要恢复的是dt='2024-05-20'这个分区。
# 用Spark SQL连接到Iceberg表，查看表的分区信息
spark-sql --iceberg-namespace demo -e "
# 查看orders表的所有分区，确认2024-05-20分区确实存在过
SHOW PARTITIONS demo.orders;
"
这个命令执行后，会输出所有分区的dt值，我们可以找到2024-05-20对应的分区，确认它之前确实在列表里。
3.2 找到删分区之前的快照ID
接下来要找到在执行删分区操作之前的那个快照ID，这个ID是Iceberg的核心，就像打开存档的钥匙。我们先查demo.orders表的所有快照，找到删分区操作之前的最新快照。
# 查看orders表的所有快照列表，包含ID、时间、操作类型等关键信息
spark-sql --iceberg-namespace demo -e "
# 按时间倒序排列，最新的快照会显示在最上方，方便快速找到目标
SELECT snapshot_id, committed_at, operation FROM demo.orders.snapshots ORDER BY committed_at DESC;
"
执行这个命令后，会得到很多条快照记录，我们要找的是在“删分区”操作之前的那条。比如假设删分区是在5月21号凌晨2点执行的，那我们就找在2点之前的最新快照，比如快照ID是123456789，这个后面要用到。
3.3 用时间旅行回滚到删分区前的状态
找到正确的快照ID后，直接用Spark SQL的时间旅行语法，把表回滚到那个快照的状态，这样被删的分区就回来了。
# 用时间旅行功能回滚到指定快照，快速恢复误删的分区
spark-sql --iceberg-namespace demo -e "
# 关键命令：调用Iceberg的系统存储过程，回滚到指定快照ID的状态
CALL demo.system.rollback_to_snapshot('orders', 123456789);
"
这里要注意，表名要和实际的表名完全一致，快照ID要换成你实际查到的那个，要是用错了就会回滚到不对的状态，所以最好先多查两次确认。
3.4 验证数据是否真的恢复了
回滚完不能就完事，得确认分区的数据真的回来了，不然早上高峰出问题就麻烦了。
# 验证分区数据是否恢复，避免操作失误影响业务
spark-sql --iceberg-namespace demo -e "
# 先查2024-05-20分区的订单数量，确认数据量和删之前是否一致
SELECT COUNT(*) FROM demo.orders WHERE dt='2024-05-20';
# 也可以直接查分区列表，确认该分区是否存在
SHOW PARTITIONS demo.orders PARTITION(dt='2024-05-20');
"
执行后要是看到分区存在，数据数量和删之前差不多，就说明恢复成功了。
四、这个方法的优缺点和注意事项
4.1 优点和缺点
优点很明显：一是速度快，正常情况只要几十秒，比找备份快很多；二是不用额外的备份资源，也不用做复杂的恢复流程；三是操作简单，只要会查快照和回滚命令就行，不用懂太多底层存储的东西。 缺点也得说清楚：一是快照是有保留时间的，Iceberg默认的快照保留时间是7天，要是超过7天再恢复，就可能找不到对应的快照了；二是回滚操作会丢失之后的所有数据，要是回滚的快照太旧，会把5月20号之后的其他数据也删掉，所以要选对快照。
4.2 必须注意的几件事
首先，删分区前一定要提前确认快照的保留时间，别等误删了才发现快照没了；其次，操作前最好先在测试环境练一遍整个流程，别直接在生产上试；第三，查快照ID的时候要注意时间顺序，别把删分区之后的快照当成之前的；第四，要是操作失误，别慌，Iceberg的快照是存在元数据里的，只要元数据没丢，就还有机会恢复。
五、总结
这次用Iceberg时间旅行恢复误删分区的经历，让我觉得Iceberg的这个功能真的很实用，尤其是对经常接触大数据分区数据的同学来说，相当于给自己买了份“数据保险”。平时用的时候，多留意快照的保留时间，别等出事了才想起来。要是不小心删错了分区，赶紧查快照，找对回滚的点，大概率就能快速救回来，不会耽误业务。
Comments