背景
在做一些大数据量的处理过程中，比如上线前的资源处理，某些T+1日的定时任务job
随着数据量的增大，带来的挑战越来越多。
挑战
对机器性能会有更高要求
高性能的机器配置是完成大数据量数据治理的必要条件之一。如果机器配置不行，再好的算法，再巧妙的设计，在大数据量的数据治理之中，会很快出现性能瓶颈。
幸运的是，追求高性能的机器配置并不是软件工程师所关注的重点。大部分情况下，机器采用业内的标准配置，能够应对绝大部分场景。一些特殊的业务场景，需要一些更好的治理策略、
对执行效率会有更高要求
随着数据量的增大，所有微小的处理偏差都会被放大。
哪怕是处理一条数据时多打印了一行日志，多处理1ms，
那么一百万条数据就会多1000s，约等于16.7min，
一千万条数据就会多10000s，约等于167min，
一亿条数据就会多100000s，约等于1670min，约等于27.8h。
对回滚策略会有更高要求
如果数据量不多，一般的回滚策略可以是
1，备份原表，job执行失败切回原表,
2，执行update回滚脚本，job执行失败执行脚本把数据还原。
但是数据量上来之后
1，存储空间太大，动则几百G或者几个T的数据，备份起来，需要预留好更多的空间和时间。
2，在固定的时间窗口内，对update回滚脚本执行的效率要求更高。需要考虑执行效率如何，能否在时间窗口内执行完，如果执行不完，数据就脏了，如何补救。
面对挑战，如何处理？
接着分享一种二阶段治理实战的方法。
治理
1，治理前
如果原始表数据量过大，可以考虑分表，我这里以32张分表为例。
2，一阶段治理
不停机游标查询原表写入tem表，重点在于不停机，对线上用户无感知，原表的绝大多数数据都能够治理到。
3，二阶段治理
在一阶段治理结束之后的某一个时机停机，去做一阶段治理时间点 到 此次停机前 原表增量数据的治理。
4，停机改表名
此操作可以通过代码去操作，也可以通过sql脚本操作，在停机的状态下，该操作很快，大概秒级。
5，治理后
此时可以启动服务了，服务操作的表还是sub_table表，而tem_table表可以做为数据的备份，便于回滚和排查历史问题。
总结
1，大数据量处理任务的总时间可以是一定的，但是可以通过把数据拆分成存量和增量，存量不停机处理，增量才停机处理，这样可以停机时间降到最短。
2，也是一种空间换时间的思路，如果要在原表上直接治理，确实是节省了空间，但是执行效率不一定高。
