本文共 1631 字，大约阅读时间需要 5 分钟。
传统MapReduce与迭代计算优化之路
传统MapReduce系统具有以下特点：一旦提交Job，Map阶段完成后会将中间结果写入本地磁盘。仅当所有Map任务完成后，Reduce任务才会启动。这种设计在处理大规模数据时表现不佳。同时，Reduce完成后会将最终结果写入HDFS，而这个过程依赖于网络I/O操作，导致性能瓶颈。此外，传统MapReduce并不适合迭代计算场景。
迭代计算的特性显著不同于传统批量处理。迭代计算的输入数据通常由static和variable两部分组成。static数据通常量大于variable数据。计算过程按如下方式进行：static与variable数据协同计算后，产生新的variable数据，此时需要与static数据再次进行计算。如此反复循环，直到满足迭代结束条件。此外，迭代计算的单个任务数据集往往较小，这使得传统MapReduce所需资源与效率难以匹配。
为了将传统MapReduce优化为适用于迭代计算的系统，主要需要做以下改动：
职责模块化与循环体控制
传统MapReduce通过多次提交Job来实现迭代计算，每次Job的启动都会带来额外的启动时间消耗。此外，Map和Reduce任务的配置常常需要重复提交，导致资源利用率低下。相比之下，优化后的MapReduce应该在单个Job中嵌入迭代循环体。通过这种方式，减少scheduler的负担，大幅提升迭代效率。静态数据缓存与本地化策略
为了提升性能，优化后的MapReduce需要在静态数据上进行本地化存储。一种常见的做法是将关键数据缓存至本地内存或存储介质，让Map任务能够快速访问数据减少磁盘I/O开销。然而这一优化要求scheduler支持数据的本地化策略，确保数据能够按照计算任务的分布策略存储，以发挥计算节点的内存和本地化优势。优化Map/Reduce阶段与迭代终止控制
优化后的系统需要在Reduce阶段进行迭代判断。一旦 Reduce处理完当前迭代数据并生成新的输出，立即判断是否需要继续迭代。这种方式能够有效避免不必要的任务启动，为迭代过程提供更灵活的控制能力。此外，在Reduce阶段增加一个额外的combine阶段，可以用作迭代结果的汇总和检查点，用于确定是否需要退出迭代。在架构方面，优化后的MapReduce采用master/slave模式与Broker Network通信机制。Slave节点作为Task处理单元负责执行Map和Reduce任务。Pub/Sub消息传递机制被用于数据传输和控制事件。系统能够支撑以下几种数据传输类型：本地磁盘读取和Broker Network获取。
在迭代MapReduce架构中，Job复用是核心改进。这意味着迭代循环体嵌入于单个Job中，避免多次Job提交的性能开销。一旦Job启动后，仅需通过控制事件管理迭代流程。数据读取可通过两种方式实现，本地磁盘和Broker Network。当使用Broker Network传输变量数据时，可以有效支持迭代过程需要的高效传输。
任务调度方面，优化后的系统通过static分配策略提升数据缓存效率。在同一工作节点上，多次Map任务如果涉及不同的Key，可以通过static分配策略确保缓存发挥作用。这需要scheduler支持本地化数据分布。
在容错方面，优化后的系统面临诸多挑战。系统假设master宕机概率极低，Broker Network可靠性以及数据中断处理机制仍需完善。这些问题需要在实际应用中通过冗余设计和监控工具加以应对。
总体而言，迭代MapReduce的设计使得系统能够应对需要迭代计算的复杂算法。通过Job复用、数据缓存优化和迭代终止控制策略，系统性能得到了显著提升。但当前的容错方案仍需改进，hack && iterate until convergence.
参考文献：
发表评论
最新留言
关于作者
