并行处理之惑——“大”数据一定就是MapReduce的菜？

我曾经以为，成为一个出色的IT经理，应具备三大素质：技术领域的大咖、管理界的伯乐、职场社交的一朵花。

最近公司业务系统冒出一个头疼的事儿，让我瞬间明白:有对儿火眼金睛才是IT经理最重要的素质，选对产品和选对媳妇一样重要。

近几年，公司业务发展迅速，特别是电话、电商等渠道开通后，公司出单量大幅增长，除了北上广深之外，江浙沪地区增长十分迅猛。公司业务系统有个数据接收功能模块，每天特定时间从其他地区子系统接收数据，数据以文本格式的数据。系统需要解析这些数据，并对解析出的每一条记录进行一系列的合规性检查。如果数据合法，将存储至关系型数据库中。要求全部业务操作，在4小时内完成。

目前运行的这套是系统是三年前设计的，采用的技术方案是前端机（单台服务器）用于接收子系统上传数据；处理端（单台服务器）用于解析前端机中传入的数据文件，进行合规性检查，合法数据写入MongoDB的结构。

但随着业务增长，系统每日接收数据量日益增大，现在已经达到700多G，接收系统处理时间早就超出既定的4小时，因为超出时间不太长，通过将后续步骤延后等等方式，面向保证系统正常运行，但运维、业务部门对这种情况早就抱怨不断了。按照现在业务增长速度，数据量有可能会达到1T。要解决这个问题，最简单的办法就是升级硬件，如果升级到小型机，处理能力将会有效提升，可公司今年开始政策性不再采购小型机，只配备x86架构服务器，况且以目前的预算，也不够采购小型机的。因此必须想别的办法。

数据接收业务是典型的批量业务场景，系统每次接收多个数据文件，多个数据文件中的数据处理上没有依赖关系，完全可以并行化处理。现有技术方案瓶颈出现在单机架构的处理端。由于处理端CPU资源有限，数据太大，导致无法在业务规定时间内完成。因此，解决这个问题的思路也很明确——采用并行处理，使用多台主机作为处理端，同时完成数据的解析、检查与入库。

提到并行处理，很容易会想到使用MapReduce、Spark。MapReduce、Spark作为现今最流行的大数据处理方案，通过采用多机并行处理架构，可以很好的胜任海量数据的分析类工作。虽然目前系统数据量还不到TB的门槛，但超过TB是迟早的事。从数据量看，已经符合大数据处理特征，且公司前几个月刚上线过一个基于MapReduce的数据处理系统，就想到是否可以借鉴一下这方面的经验。

按照这个思路，我们团队很快启动了基于MapReduce进行并行数据接收的方案的设计。在设计中，问题渐渐凸显出来：数据接收模块的业务是单机多线程的，每个线程中读取前端机中的一个文件，打开文件流，解析出一条数据后，进行数据合规性检查，如果合规，将之存入MongoDB，如果非法，则丢弃。如上反复，直至所有记录处理完毕。那么问题来了，使用MapReduce，首先要解决的是如何使用MapReduce的模型，实现上述逻辑。按照MapReduce的计算模型，最基本的任务需要实现Mapper、Reducer。按照数据接收系统的逻辑，大致应该在Mapper中实现单线程的逻辑，无需Reducer，自然也不需要Combiner，Partitioner。MapReduce的Mapper并发数通常是由HDFS中的存储内容的大小来确定，Mapper的执行位置和输入数据的分布位置有关，如果不将接收的任务存储至HDFS，将很难控制Mappper的并发数量及位置。各子系统数据传入时，就已经存储在前端数据存储上了，如果使用MapReduce，就必须将文件先传输至HDFS，再启动MapReduce任务进行并行处理，将大量的数据写入HDFS本身就会耗费较多的时间，再并行处理，会提升多少效率不得而知，整个过程似乎变得更复杂了。为了验证数据写入的效率，团队还专门做了一个1T数据写入3台集群HDFS的验证，发现写入时间大致就需要2.5小时。多种迹象表明，此路不通。

回想问题的关键，数据接收问题在于处理端处理性能不足，导致大量数据无法按时处理。解决思路是使用多台处理端进行并行处理，提升整体性能。原有系统使用单机多线程模式进行处理，其过程并无不妥，只要可以将单机多线程扩展为多机多线程，已经可以解决问题，并不需要对原有的数据处理方式做调整。

总结下来，数据接收模块并行化改造实际需要一个平台，通过平台可以实现最小的改造，即可将数据处理由单机单线程扩展到多机多线程，每个线程沿用原来的处理模式，从前端机获取数据文件进行处理，随后写入MongoDB，平台可以均衡地将处理任务平均分配到多台主机，保证最大效率处理。满足这样需求的，是面向批量业务处理场景的并行处理产品，而不是MapReduce类大数据产品。最初计划使用大数据处理类产品，是出于对实际问题思考不够深入所致，公司以往的经验也干扰了我的判断，导致对“批量业务处理”场景滥用了大数据处理类产品。

最终，我们选用了SaCa P3并行处理平台实现了数据接收并行化改造（部署结构如下图）。SaCa P3平台是一款专门用于批量业务处理场景的产品，提供了类似于单机多线程处理方式的并发模型，较快的完成了现有系统并行化改造，实现单机多线程扩展为多机多线程。智能调度算法，可以最大程度保证所有节点处于满载状态，最大程度提升并行处理效率。这正是我们需要的。此外，P3还可以自动处理节点宕机、断网等故障情况，自动转移故障节点的任务，此外，P3还支持在集群不停机的情况下随时增减节点的动态扩展模式。健壮性和可扩展性都不错。

根据多次测算，最终使用3台x86服务器作为并行数据处理端，部署了SaCa P3集群（3管理节点+3代理节点，每个主机1个管理节点1个代理节点）。系统仍沿用原有的调度方式，在各子系统上传数据截止时间之后，由定时任务触发并行处理任务，由SaCa P3集群将多个数据文件分配到3个并行处理节点上完成并行处理，实际测试结果表明，3节点并发部署后，1T数据处理在3小时左右即可完成。

使用SaCa P3并行化改造后的数据接收系统

细看新的并行化后的数据接收模块：并行处理方式和原有单机多线程方案一致，使用SaCa P3实现了单机多线程到多机多线程的蜕变。任务处理流程如下：启动数据处理任务（Job），首先获取前端存储机上待处理的文件列表，按照一个线程处理一个文件的模式，将任务拆分成若干块（Task），多块（Task）并行处理。P3按照每个节点并行处理能力，分配合适数量的任务块（Task）给各个节点并行处理，并实时监控每个块（Task）的处理进度，一旦某块完成，P3平台会立即将未处理的任务块（Task）发送至有空闲处理能力的节点，直至所有任务块（Task）处理完毕，最大程度保证并行处理效率。

细细品味这事儿的整个过程：业务系统遇到问题时，虽然从数据量来看，的确已经纳入了“大数据”的范畴，但进入“大数据”范畴的问题，却不都是“大数据分析”类产品的菜。本次数据接收模块遇到的问题，其实应该划归到“批量业务”的范畴，即广泛存在于各类IT系统中，大致符合如下特点：处理过程无需干预（可全自动处理），业务逻辑相对复杂、处理数据量较大，在一定条件下多次触发（定时触发或者随机触发）等特点的业务。

随着业务的发展， “批量业务”处理数据量逐渐增长，甚至直到进入“大数据”的范畴的案例已经屡见不鲜，采用多机并行方式提升处理能力，是大势所趋。对于跨入“大数据”范畴的“批量业务”处理，我们需要的是拥有多机并行处理能力，具有云特征的可动态伸缩的并行批量处理产品，这类产品才是解决“大数据”时代海量“批量业务”处理的关键所在。作为IT部门负责人，有对儿火眼金睛才是IT经理最重要的素质，为合适的场景，选合适的产品，恰到好处方为上。