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

    一、引言

    随着信息技术的发展，人们对于大数据量的信息处理要求也越来越高，传统的基于单机数据库的处理方式已经无法承担大规模的数据量。尤其是手机产业的兴起，网络用户的数量巨增，对信息的响应速度和处理时间的要求也越来越苛刻。相比之下，对信息的准确性的要求不再那么严格，比如实时路况的处理等等。

    MapReduce框架是一种成功的想法，它被Google提出并已经被应用于多种运用，比如网页搜索和网页排序。它类似于现在的数据库系统，输入是key／value对，通过用户自定义一个map函数，将输人数据进行预处理，将相同的key的value发送到reduce端，然后这些value进行排序，由reduce函数进行处理，最后输出也是key／value对，这种编程模型现在很多应用中得以实现，而且很多传统的算法也可以通过变形在上面实现。

    MapReduce框架对处理传统的大数据量的信息很有优势，比如网页排序等。但随着网络用户的增加和对及时信息的需求，框架本身的局限性就显示出来，比如任务的准备时间和reduce阶段之前的排序时间太长等等，这些限制使得MapReduae不能够胜任流式信息的处理，对于MapReduce框架的这些短处，我们设计了一种新的FastMR，它对MapReudce框架做了一些改变，并用。语言实现了一个雏形，使它能够处理流式数据，性能优于现在的MapReudce框架。

    二、模型框架

    根据实际需要，我们设计了自己的MapReduce框架，即FasfMR。和Google的MapReduce框架类似，我们的从结点既是任务结点也是存储结点。我们的设计的目的是完成流式信息的处理，所以和传统的MapReduce框架有很大差别，主要体现在以下几个方面：

    1.任务获取方式

    在MapReduce模型中，采用的是主从式的任务获取方式。在一个集群中，有一个Master结点用来管理任务的执行，Master结点的负载相对较重，它需要负责接受客户端的任务、调度任务的执行。客户端将任务代码上传到分布式文件系统，然后通知Mater结点有任务到来。Master将任务信息加入等待任务列表。集群中的结点采用Slave方式运行，定期以心跳的方式连接Master，报告任务运行情况和请求任务。心跳的过程是通过RPC方式连接到Master，在报告的同时顺便请求任务。这种方式对于Slave来说，对任务的获取是有延迟的，不能够及时的得到任务执行。首先，这种方式会有任务获取的延迟。对于实时性要求非常苛刻的环境下，10秒种的获取任务延迟是不被允许的。其次，影响Map任务的本地化执行。例如，某一时刻，有一个Slave来请求任务，Master是不知道结点的情况的，只能根据这个结点的信息，给与该任务相应的输入数据，这个数据可能不在这个结点上，因为无法保证来请求的Slave结点都具有该任务的数据。

    FastMR的任务报告和任务获取是分开的，任务报告保留以前的RPC方式，而任务的获取采用阻塞方式，即Slave中有任务槽的结点与Master结点保持一个TCP连接，Master结点建立一个表，负责维护这些连接，当有客户端有作业提交的时候，Master结点通过配置的调度方式，分配任务给Slave结点。

    这种方式是FastMR针对云计算平台的改进，它可以减少任务获取的延迟和Map任务的本地化，因为在任务开始时，结点信息在Master中，Master对能够执行任务的结点不再是一无所知，它可以做到最大程度上的调度任务执行，来满足本地化要求。

    2.数据传递方式

    MapReduce模型中数据的传递有两种方式。首先在任务刚开始执行的时候，数据是通过分布式文件系统传递给Map任务，Map任务执行完以后，会将数据在本地执行Combine，在此过程中进行一个局部排序，然后保存到本地磁盘，等待其他Slave来取数据。当任务中所有的Map任务都执行完以后，Master统计任务中的执行情况然后进人Shuffle阶段，这时候Reduce任务的结点向Map任务结点获取数据。Shuffle阶段是MapReduce模型的核心，是保证并行性的关键。因为任务运行时，为了挖掘集群的潜力，需要将任务进行划分，获取最大程度上的并行眭。任务执行过程中有两次任务划分，在任务开始的时候，是通过对输入数据进行划分来分配任务，而在Map执行完以后reduce任务开始之前，是通过Shuffle方法进行划分，Shuffle阶段通常采用Hash的方式划分任务，或者客户端自己定义划分的方法。Shuffle阶段是Reduce任务结点向Map任务结点请求数据，采用Http请求的方式。这种方式对于注重吞吐率、稳定性和整体效率的后台是比较适宜的，但它不适合用于移动云计算平台。因为同步以及拉的方式在时间性能上都远不如推的方式。

    FastMR的改进是将Map端的数据在执行完以后直接推送出去，这种数据传递的方式可能要结合FastMR的另外两个改进才能做到，它们分别是流水式的任务执行方式和取消MapReduce中的排序阶段，采用推的方式结合和FastMR的特点能够很大程度上缩短任务的执行时间。

[page]    3.流水式的任务执行

    MapReduce任务中的Map阶段执行完以后会有一段同步时间，同步完以后Map任务将开启一个http端口供Reduce任务读取数据， 同步在MapReduce任务中是必须的，因为Reduce任务在运行前有排序阶段，需要得到完整的数据，这里就需要所有的map任务都运行结束才能得到。当一个任务出现错误的时候，MapReduce模型需要将任务进行重新调度运行，其他结点需要等待这个任务运行完成才能再运行，这个作业就阻塞在这个需要重新运行的结点上，这样非常影响作业的运行时间。

    FastMR的设想是将任务的运行看成是流水的方式，任务执行的过程中没有明的同步障。这种运行方式带来的好处是提高了单一任务的执行速度，符合移动云计算的需求。这种任务的运行类似与MapReduce Online的管道式的运行方式，在前一个任务还没有运行完的时候后一个任务就开始运行，事前可以根据集群的具体情况配置流水线的级数，然后集群根据这个参数执行，随着流水线级数的增加，任务的执行速度会提高很多，因为多级流水更加适合集群的任务调度，不过集群对任务的管理会增加复杂性。

    4.取消排序阶段

（编辑：核心网）

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