设计数据密集型应用 - 批量处理中有趣设计模式和问题 (batch processing - mapreducer)

前面介绍了不少分布式系的内容，在这不免需要介绍分布式系统中关于批量处理(batch processing)问题, 对比与在线系统（online system）， 批量处理属于离线数据处理范围，对响应时间的要求相对会低一些，在评估系统的性能时，更优先考察系统的容错性(fault toleration)和稳定性(stability);

借鉴与unix的管道设计理念，批量处理流程(主要是mapred模式)简化各个处理环节，环节间通过字节文件进行通信(即处理节点接受的是字节，输出的也是字节);

批量处理封装很多细节内容（包括通信调度，任务监控和重试，排序等），使的用户只需要关注节点上数据处理流程;

这里想分享的是在设计mapreducer 任务中关于join/merge操作的一些有趣模式，为了让问题更具体，我们简单借用一个任务例子；

假设有两张表，内容分别是用户id和对应站内网站（URL）的访问日志和用户属性表(如性别，年龄等), 现在想分析各个站点消费用户人群特点, 我们不可避免将两个表进行join/merge操作, 而join操作即可在map阶段也可在reducer阶段，我们先介绍在map阶段的join:

• 场景一，如果其中一个表小到可以加载到单机内存(Broadcast Hash Join)

  该场景下，简单将小表加载到内存，全量扫另一张表，并合并相关信息，在reducer阶段进行merge;

• 场景二，如果两个表都达到无法load到单机内存 (Partitioned Hash Join)

  这种情况，事宜对用户表进行分片，对每一个片区读取和处理全量日志表，并过滤相关用户活动日志;

• 场景三，如果用户日志信息和用户属性已完美分区(Map-side Merge Join)

  只需要key已分好区，并按升降序排序，只需顺序处理即可；

reducer阶段join方案:

方案，在reducer阶段将相同key的用户属性和用户活动日志分到相同分区(partition), 并通过字段将用户属性排到用户日志前面（即用户A的属性信息一定在该用户活动日志前）, 进行融合(merge)处理;

问题部分

在批量处理这种模型下，仍存在部分业务处理任务无法胜任的情况，如需要多次数据迭代的模型收敛训练，社交型网路遍历问题等, 最简单的例子，计算明星和大众用户的平均距离（即社交关系距离）; 这类问题普遍需要多次的迭代计算，并将前一次的计算结果用做下一次的计算输入；

这其中引入了另个一个问题，是否把中间结果实例化（即分布存储中间结果），因为如果存，涉及网络传输耗时较久，如果不存如何进行容错处理（即部分节点crash后如何恢复的问题）；

基于mapreducer 这个批量计算框架，工业界在上层有搭建了其他计算模型来解决上述问题，具体的有Pregel Processing Model