移动云计算的数据处理技巧

    MapReduce模型在Map任务执行完以后会在Map任务端执行排序，然后传到RedLIce任务端再进行归并排序，这个阶段对于Google的很多后台应用是非常有用的。同时，这个阶段也是相当耗时的，尤其是在超大规模的数据处理过程中更是如此。我们设想了很多移动云计算的应用，发现较多的移动云计算的应用对数据的排序基本没有要求。于是基于这个设想，可以将复杂费时的排序选用或者取消（如果保留，需要改变先前的排序方式，因为任务是流水的方式运行，任务之间没有同步）。我们的设想是如果保留排序，则进行局部排序，而且我们发现多数作业如果是由多个任务构成，那么一个任务产生的中间结果不会影响最终结果（中间会产生一些没有的输出）。当然也有例外的情况，所以流水线的方式不适合多有的应用。

    5.细粒度的任务设定

    MapReduce编程模型中的错误恢复机制继承了Google的一贯简单高效的作风，采用了最简单的方式，如果错误发生，则重新运行作业的机制。这种错误恢复机制非常简单，然而一旦发生错误，作业的执行时间将会非常长。

    FastMR采用的方式是细化一个任务的颗粒度，划分方式是通过输入数据进行块划分和记录数据偏移的方式。如果任务运行的结点出现异常，则错误恢复时只是将未处理的数据进行恢复。因为数据处理量不是实时记录的，所以可能出现已经处理过的数据重新处理一遍的情况，对于这种情况，对于集群来说并没有太大的影响，因为在Reduce任务端对这种冗余的数据可以简单的合并掉。

    三、设计细节

    为了提高系统的运行效率，采用e语言来实现设计，采用主结点管理名字空间，数据结点采用redis数据库模拟的方式，redis是一个高性能的数据库，吞吐率较高，尽管redis的数据本身没有标签，对于实验环境，将不同的标签的数据作为不同的值存储，能够满足实验的要求。

    FastMR中的通信均采用了redis数据传输协议，比如“*3 $3 SET $5＼nmykey $8 ＼nmyvalue＼ne 其中每个参数用＼r＼n分割，第一个 3说明有3个参数，后面一个$3说明这个参数有3个字节，这种通信协议容易实现并且易于解析。

    Master为Slave提供了多个远程调用的接口，比如SubmiOob，GetNewTask等等，这些接口均采用remote procedure calls的方式。利用redis通信协议，易于实现传输数据的序列化，每次RPC返回的数据也很容易实现反序列化。

[page]    四、性能分析

    为测试FastMR的性能，采用求无向图中一个点到其他点最短路径的算法。这个算法满足编程模型的需要，有多轮并且每一轮的map和reduce函数是一样的。

    算法设计思想

    该算法是Belman—F0rd算法的一种变形，在每轮开始信息的保存方式是这样的：

    Key=结点，Value=距离+当前最短路径（没有则为空）+邻接点及距离列表

    系统运行的过程

    map端：对于每个邻接点，最短路径上添加一个边，并修改最短路径的距离值为其自反加距离，发送出去。

    Reduce端：收集相同Key的Value，获取一个距离值最小的Value做为Reduce的结果，然后结束本轮。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!