虽然说对账是一个离线流程，允许对账完成时间可以久一点。但是对账流程是后续其他任务的前置流程，整个对账流程还是需要在中午之前完成，这样运营同学就可以在下午处理。
第二个问题，OOM。
上面流程中，我们把把全部数据加载到内存中，小数据量下没什么问题。
但是在千万级数据情况下，数据都加载到内存中，并且还是加载了两份数据（本端、对端）,这就很容易吃完整个应用内存，从而导致 Full GC，甚至还有可能导致应用 OOM。
而且这还会导致级联反应，一个任务引发 Full GC，导致其他渠道对账收到影响。
第三个问题，性能问题。
原先系统设计上，单一渠道对账处理流程只能在单个机器上处理，无法并行处理。
这就导致系统设计伸缩性很差，服务器资源也被大量的浪费。
千万数据级对账解决办法上面系统代码，实际上还是存在优化空间，可以利用单机多线程并行处理，但是大数据下其实带来效果不是很好。
那主要原因是因为发生在系统架构上，当前系统使用底层使用 MySQL 处理的。
传统的 MySQL 是 OLTP （on-line transaction processing），这个结构决定它适合用于高并发，小事务 业务数据处理。
但是对账业务特性动辄就是百万级，千万级数据，数据量处理非常大。但是对账数据处理大多是一次性，不会频繁更新。
上面业务特性决定了，MySQL 这种 OLTP 系统不太适合大数据级对账业务。
那专业的事应该交给专业的人去做，对账业务也一样，这种大数据级业务比较适合由 Hive、Spark SQL 等 OLAP去做。
总结今天本篇文章只是一个序曲，主要聊聊对账业务基本流程，聊聊之前系统架构在大数据下存在的问题。
后面文章再会介绍下大数据下对账系统如何设计，对账之后差错数据如何处理，尽请期待。