APP下载

关于大数据框架中底层数据传输和网络的分析与研究

2017-07-20赵嘉凌蔡文伟白伟华

物联网技术 2017年7期
关键词:软件定义网络云存储云计算

赵嘉凌++蔡文伟++白伟华

摘 要:文中从大数据应用环境下以数据处理、云存储和容错处理等方面与网络进行协同工作的需求为基础,分析了大数据应用下底层数据和网络多方面的问题,为大数据框架中底层数据的传输和网络优化提供了研究基础。

关键词:大数据;应用感知;云计算;软件定义网络;云存储

中图分类号:TP391 文献标识码:A 文章编号:2095-1302(2017)07-00-06

0 引 言

大数据(Big Data)[1]可被定义为具有4V特征的数据,即数据量及规模巨大且持续增长(Volume,一般指数据量达到PB以上级别);多源/多样/多结构性,不同的数据源、数据类型(Variety,复杂文档及多媒体,结构化、半结构化和非结构化数据);高速性,由于存在用户数量庞大与实时性等因素,数据的生成、增长速率快,数据处理、分析的速度要求也高(Velocity);有价值性/精确性,数据量庞大,虽然价值密度低或个别数据无价值,但数据总体上是有价值的(Value/Veracity)。

大数据环境已成熟,云计算中的大数据分析/处理,大数据处理与网络/硬件的协同工作,大数据的私有性及云平台的能耗等方面对网络及其资源调度的需求,使得大数据应用与物理网络之间的交互尤显重要,一方面让网络呈现出“应用感知网络(Application Aware)”的特性,使之更好地服务于大数据应用;另一方面,如何让大数据应用/用户方便高效地访问、调度网络资源,减轻大数据应用在网络访问决策上的负担是当前大数据应用研究中的热点问题。

1 云计算环境下的虚拟化

云计算[2]作为下一代计算模式,具有超大规模、高可扩展性、高可靠性、虚拟化、按需服务和价格低廉等特点,通过调用网络中大量计算节点/服务器完成核心计算业务的任务,向用户提供多层次的服务如基础设施、平台、存储服务和软件服务等。在大数据应用中,云计算的核心功能主要有数据存储/管理(以数据存储为主的存储型云平台)和数据分析/处理(以数据处理为主的计算型云平台)。云计算提供商将大量计算节点与网络设备连在一起,构建一个或若干个大规模(由具有万甚至百万级以上的计算节点所组成)数据中心,通过云平台实时访问、调用网络、存储、计算等资源为用户服务。

云计算核心组成逻辑如图1所示。云计算主要由服务器、存储和网络组成。为了使得云能够更快、更方便地响应企业用户的需求,服务器(层)和存储(层)已经通过在实际基础设施和云环境之间构建抽象层实现虚拟化,满足配置、管理和使用服务器及存储资源的要求。但最终还需要依靠网络将资源连接集成以搭建一个完整的云环境。“大数据应用环境下与网络的交互”以及“网络与计算资源的交互”面临以下三方面的要求:

(1)大数据应用层与网络的交互:网络结构相对稳定,但由于云环境的高扩展性以及节点规模的庞大,使得服务器和存储这两方面的资源会时常发生变化,如服务器/节点的添加——断电、故障、恢复、新增节点等或存储磁盘的故障、失效等。面对这些变化,上层大数据应用如何能更好、更快地获取计算资源的变化?

图1 云计算核心组成逻辑图

(2)计算资源与网络的交互:在大数据处理中,各计算资源的状态与承担的任务及负荷各不相同,为合理使用计算资源并计算资源负载平衡,网络如何能更快更方便地告知上层大数据应用其所获得的感知信息,并让应用或用户调整其调用计算资源的策略?

(3)计算资源按上层大数据应用的需求动态调整:上层应用复杂多变,面对应用/服务的变化,其所需的计算资源也不同,如何更快地调整、组织计算资源让其适应并为上层应用提供服务?

为满足上述需求,添加两个具有扩展性的接口层形成大数据应用与计算资源(服务器/存储)的中间层,这两个接口层如下:

(1)大数据应用层与网络层之间的交互接口层;

(2)网络层与计算资源层(服务器/存储)之间的交互接口层。

2 开放式协同平台的中介——SDN

2011年10月,美国麻省理工大学Kate Greene教授提出了SDN (Software-Defined Networking,SDN)软件定义网络技术的概念[3]。所谓SDN,是指根据不同的使用需要,通过软件来完成所有路由器与交换机的动态配置。并于2011年3月成立了以实现该概念为目的的网络联盟Open Network Foundation (ONF),提倡使用OpenFlow作为实现SDN的重要技术。

OpenFlow网络的最大特点是将传统的交换机路由控制部分与数据传送部分分离,使得网络设备可以专注于数据包转发,从而极大地简化了交换机的体系。OpenFlow网络的主要构成元素包括支持OpenFlow协议的交换机(OpenFlow Switch),交换机控制器(OpenFlow Controller)以及用于交换机与控制器之间的控制协议(OpenFlow Protocol),其体系结构如图2所示。

OpenFlow網络可以处理包含在数据包中的各种信息,如MAC地址,IP地址,VLANID,MPLS标识,TCP端口等共15类,将这些信息与数据包的处理方法相结合,用于设计OpenFlow交换机的Flow Table。Flow Table即数据包的处理规则与处理方法对照表,如对含有特定VLANID信息的数据包执行数据包转发、丢弃或多播等操作。

网络管理人员通过对Flow Table进行详细设计便可轻松实现对数据包交换路径的精准控制。随着云计算应用的不断增多,频繁的网络重新配置不可避免。VLAN组网技术支持网络管理员动态对网络进行配置,是目前HDFS云存储的主要组网技术。但VLAN组网技术面临以下问题:

(1)当子网数量不断增加时,采用VLAN对网络进行管理将会使情况变得很复杂;

(2)只能利用VLANID进行组网,组网的灵活性不高,无法适应来自云计算的不同需求。

(3)除电信运营商级的VLAN技术外,数据中心级VLAN技术几乎不能实现异地云存储服务器之间的连接。异地云存储系统互连的重要性在于通过将数据备份在不同的物理地点来消除单一故障(电力中断,火灾等)引起的服务中断,这正是ONF联盟将OpenFlow列为云计算网络控制技术之一的主要原因。

图2 OpenFlow体系架构

3 存在问题及分析

3.1 从大数据处理的角度分析

在大数据应用的环境下,大数据分析/处理的计算框架以MapReduce编程模型最具代表性。MapReduce计算模型在执行中,首先对数据源进行分块,然后交给不同Map任务区来处理,执行Map函数,根据数据处理的规则对数据分类,并写入本地磁盘;Map阶段完成后,进入Reduce阶段,执行Reduce函数,具有同样Key值的中间结果从多个Map任务所在的节点被收集到一起(称为Shuffle)进行合并处理(称为Merge),输出结果写入本地磁盘。最终通过合并所有Reduce任务得到最终结果。

以MapReduce计算模型为基本核心原理,相似的计算模型有如下几种:

Hadoop[4]:核心由HDFS和MapReduce组成,其中Hadoop-MapReduce是Google MapReduce的开源实现。

Dryad[5]:与MapReduce计算模型相似,其总体构建用来支持有向无环图(Directed Acycline Graph,DAG)类型数据流的并行程序。Dryad的整体框架根据程序的要求完成调度工作,自动完成任务在各节点上的运行。

Hadoop++[6]:Hadoop++是通过自定义Hadoop框架中的split等函数来提升数据查询和联接性能,即通过Hadoop用户自定义函数方式对Hadoop-MapReduce实现非入侵式优化。

CoHadoop[7]:Hadoop无法突破把相关数据定位到同一个node集合下的性能瓶颈。CoHadoop是对Hadoop的一个轻量级扩展,目的是允许应用层控制数据的存储。应用层通过某种方式提示CoHadoop某些集合里的文件相关性较大,可能需要合并,之后CoHadoop尝试转移这些文件以提高数据读取效率。MapReduce计算过程示意如图3所示。

图3 MapReduce计算过程示意图

Haloop[8]:Haloop是一个Hadoop-MapReduce框架的修改版本,其目标是为了高效支持迭代,递归数据分析任务。递归的连接可能在Map端,也可能在Reduce端。Haloop的基本思想是缓存循环不变量(即静态变量)到salve nodes。每次迭代重用这些数据。

HadoopDB[9]:HadoopDB是一個混合系统。其基本思想是采用现有的MapReduce作为与正在运行着单节点DBMS实例的多样化节点的通信层,实现并行化数据库。查询语言采用SQL表示,并使用现有工具将其翻译成MapReduce可以接受的语言,使得尽可能多的任务被推送到每个高性能的单节点数据库。

G-Hadoop[10]:通过现有的MapReduce计算模型配合高速的存储区域网(Storage Area Network,SAN)实现在多群聚环境,为大数据应用提供一个并行处理的环境。

P2P-MapReduce[11]:是一个动态分布式环境中自适应的MapReduce框架(2P-MapReduce),利用P2P模式在动态分布式环境中管理计算节点的参与、主机失败和作业恢复等,为大数据应用提供服务。

Spark[12]:Spark是一个与Hadoop相似的开源云计算系统,支持分布式数据集上的迭代作业,是对Hadoop的补充,用于快速数据分析,包括快速运行和快速写操作。Spark启用内存分布数据集,除能够提供交互式查询外,还可优化迭代工作负载。

Hyracks[13]:一个受MapReduce启发,基于分区并行数据流的大数据并行处理系统,用户可将计算表示成数据操作器和连接器的有向无环图(Directed Acycline Graph,DAG)类型数据流。

大数据处理框架的设计思想见表1所列。

(1)MapReduce计算执行过程中的Shuffle阶段——执行完Map阶段后会产生大量中间结果数据,该阶段根据中间输出结果中的Key值进行分类并分发到相关节点执行Reduce函数;

(2)其余类MapReduce计算模式、迭代、递归等也需要进行大量分片和合并操作。

在这两个过程中产生的大量中间结果数据要在不同的节点(Map节点/Reduce节点)之间传输,数据规模越大、参与计算的节点越多、Map-Reduce的迭代/递归次数越多,节点间传输的频度及数据量也越大,占用网络的带宽及时间也越长,最终可能导致网络拥挤与堵塞,严重影响大数据处理框架的性能。

缺乏应用感知网络的支持,这些大数据处理框架其性能得不到很好的发挥,因此,在大数据处理框架与网络之间构建一抽象层,通过抽象层实现大数据处理框架与网络之间的交互是一个有效的解决方式。一方面大数据处理框架无需修改现有的计算模式,直接通过该层告知基础设施其所需计算资源的类别,而非特定的某一计算资源,从而让计算资源调度策略从数据处理框架中脱离出来,使得计算过程主要关注数据的分析/处理,减轻大数据处理框架的包袱;另一方面通过该抽象层为第三方提供网络访问/调整的接口,在网络物理结构不变的前提下按大数据应用需求调整网络逻辑结构,方便资源调度策略的优化和实施,构建应用感知网络更好地为大数据应用提供服务。

3.2 从云存储的角度分析

在大数据应用的环境下,存储是核心的组成之一,HDFS(Hadoop Distributed File System,HDFS)是当前主流的一款开源云存储框架,是一个分布式文件系统,更是适合运行在普通硬件上的分布式高容错文件系统,当前绝大多数云存储系统都通过HDFS实现。

HDFS的系统架构如图4所示。

HDFS采用Master/Slave架构。HDFS主要由Namenode(master)和一系列Datanode(workers)构成。一个HDFS集群由一个Namenode和一定数目的Datanode组成。HDFS支持传统的层次型文件组织。Namenode是一个中心服务器,负责管理文件系统的namespace以及客戶端对文件的访问。HDFS有着高容错性的特点,部署在低廉的硬件上,提供高传输率来访问应用程序的数据,是为以流的方式存取大文件而设计,适合拥有超大数据集的应用程序。HDFS支持大数据文件,能够提供大数据传输的带宽和数百个节点的集群服务,能够支持千万级别的文件。所有的HDFS通讯协议都构建在TCP/IP协议上。HDFS设计目标对网络的需求:

(1)硬件故障/错误及副本策略

硬件故障/错误是常态而非异常。HDFS集群由成百上千的服务器构成,每个服务器上存储着文件系统中数据的一部分,任一个服务器都有可能失效。因此错误检测和快速、自动恢复是HDFS最为核心的架构目标。此时,在网络上需解决网络可用的计算节点数量减少,一部分文件的可用副本数减少等问题。为确保文件副本的数量,数据需备份,以防故障。

(2)流式数据访问

HDFS应用程序需要流式访问数据集。HDFS进行的是数据批处理,而非用户交互处理;相比数据访问的低延迟,更应保证数据访问的高吞吐量。

(3)大规模数据集

大数据应用中的应用程序是在大规模数据集基础上的计算。HDFS上一个典型文件的大小一般都为G字节至T字节。因此,大文件存储且能提供整体上数据传输的高带宽,能在一个集群里扩展到数百个节点,使得网络中的计算节点之间、存储节点之间必然有大量数据传输。

(4)计算移到数据附近

数据离应用程序越近,计算就越高效,尤其是在数据达到海量级别时。因为这样就能降低网络阻塞的影响,提高系统数据的吞吐量。

(5)数据复制及副本存放

HDFS能够在集群机器上可靠地存储超大文件,其将文件分割成若干“块”,除了最后一个,所有“块”大小一致。为了容错,文件的所有数据块都有副本。每个文件的数据块大小和副本系数都可配置,应用程序可以指定某个文件的副本数目。数据复制与采用的副本策略有关,且由于故障、更新、备份(HA的主要解决方案:Hadoop的元数据备份方案、Secondary NameNode方案、Checkpoint node方案、Backup Node方案、DRDB、Facebook的Avatarnode方案)等原因,数据复制经常发生在同机架的不同存储节点之间及不同机架的不同存储节点之间,这个过程必然依靠网络。

其他一些云存储系统如GFS(HDFS是GFS的开源实现)、CoHadoop、StorNext FS、Lustr、Total Storage SAN File System、DDFS(Disco Distributed File System)等,其设计目标主要为上述几个方面。

云存储系统设计目标的实现依赖于畅通的网络。云存储作为大数据应用的核心支撑,其效能直接影响到大数据应用的性能,云存储框架与网络及计算资源的(服务器/存储)高耦合(数据调度、存储调度、副本存放、数据操作等与具体计算资源的选择与使用高耦合)关系,将影响应用框架的可扩展性。在云存储的文件操作与网络中的存储资源之间插入中间抽象层,云存储系统只需告知抽象层申请的计算资源的类别,通过抽象层与计算资源之间的接口访问某类资源,实现文件的相关操作,一方面能方便地直接访问抽象层反馈的计算资源集,另一方面将操作的具体实现过程标准化,通过抽象的接口简化云存储系统的操作。

3.3 从大数据分析/处理任务调度的角度分析

大数据分析/处理都在集群(Cluster)的基础上完成,通过网络连接多个成为节点的计算机为应用提供计算、数据存储和通信资源等。以Hadoop集群所提供的大数据分析/处理为代表,Hadoop集群中节点负责数据存储、集群维护管理和数据分析/处理的任务。在作业/任务调度中,分为JobTracker(控制节点)和TaskTracker(任务节点/执行节点)。一般情况下,Namenode和 JobTracker合并在同一台物理服务器上,Datanode和TaskTracker作为集群的主要部分也会被安装在相同节点上且大量散布于集群中。

集群结构如图5所示[14,15]。

控制节点负责HDFS和MapReduce执行的管理(JobTracker),其余节点为执行节点(TaskTracker),负责数据的存储和计算。任务调度是JobTracker指派任务(tasks)到相应TaskTracker上执行的过程。任务调度过程如下:

(1)JobTracker调度和管理其它TaskTracker,并将Map任务和Reduce任务分发给空闲的TaskTracker,让这些任务并行运行,并负责监控任务的运行情况。

(2)TaskTracker负责具体任务的执行,并向JobTracker报告自己所处的状态,接受其管理调度;一个重要的任务是原始输入数据和中间运算结果的存储和传递(在网络中不同TaskTracker之间传递中间结果数据)。

(3)JobTracker和TaskTracker之间通过网络以心跳机制实现通信。

(4)当一个Map任务被分配到执行节点执行时,系统会移动Map计算程序到该节点——在数据存储的Datanode节点上执行这部分数据的计算,以减少数据在网络上的传输,降低对网络带宽的需求。

(5)在一个Reduce任务被分配到一个空闲的TaskTracker节点上执行时,JobTracker会先将中间结果的key/value对在执行Map任务的TaskTracker节点上局部磁盘位置信息发送给Reduce任务,Reduce任务采用远程过程调用机制从Map任务节点的磁盘中读取数据。

任务/作业调度方法直接关系到Hadoop集群的整体系统和系统资源的利用情况。针对MapReduce集群先后提出了很多调度策略,包括FIFO调度、HOD调度、计算能力调度、公平調度等。

在任务/作业的调度中,无论何种调度策略,对网络的使用及需求如下:

(1)JobTracker在分配任务前,必须与该任务使用的数据源所存储的节点(节点集)建立联系,并通过节点的空闲状态以判断是否在该节点启动任务。针对一个文件,其被划分为多个块存储在各节点上,每个文件块对应多个(默认设置为3)副本,每个副本存储在不同的节点上,因此,一个任务对应要判断多个节点的状态。当多个任务并行时,JobTracker要审阅大规模节点的状态,当前JobTracker节点与这些节点之间的网络状态对任务启动的策略及判断有非常大的影响;

(2)JobTracker无法判断及获知被选中的计算节点的当前网络状况及其历史网络情况,因此计算节点的网络状况这一因素在任务调度中被忽略,不利于有效利用网络以提高大数据分析/处理性能;

(3)在Reduce任务分配时,JobTracker由于不了解TaskTracker节点的当前网络状况及其历史网络情况,无法根据TaskTracker节点的网络状况来选择最优的节点启动Reduce任务,故无法高效快速地获取Map任务产生的大量中间数据,从而影响了数据分析/处理的性能;

(4)在任务执行的过程中,JobTracker与大规模的TaskTracker节点之间利用网络来实现心跳机制的通信,JobTracker需要有稳定的网络来支持。

其它如表1所列的大数据处理框架中的任务调度也存在类似问题。所以,针对上述问题,在计算资源及网络的上层架设一抽象层,负责统计网络的当前状况及各节点的网络状态,维护计算资源的状态,任务调度器只需向该抽象层提出执行的任务(主要为TaskTracker的任务)及申请使用的计算资源的类别,从抽象层中获取得到相应类别的计算资源,最后执行任务。通过架设这一抽象层,可以做到:

(1)大数据应用环境下的任务调度器,只需关注调度策略及使用的计算资源类别,抽象层负责维护具体的计算资源的状态,反馈告知调度器可按需查询抽象层中所维护的计算资源的信息,实现计算资源对调度器的虚拟化;

(2)通过向抽象层中加载针对计算资源状态分析、网络历史情况分析及节点网络状况分析的第三方策略获得计算资源的最优或次优集,能更有效地利用网络来优化任务调度,通过提供计算资源调度策略的接口,有利于提高当前计算框架的数据分析/处理性能;

(3)由于抽象层对任务调度器反馈的是某类计算资源中最优或次优的可选节点集,能实现节点及网络的负载平衡,预防Map/Reduce任务之间大数据量传输所造成的网络拥挤及堵塞,避开网络带宽的瓶颈。

3.4 从大数据处理中容错处理的角度分析

由于大数据应用环境下,数据的规模、计算资源(存储、服务器)的规模和同时并行处理的任务规模都极其庞大,各种情况的失效[16,17](服务器故障、软件故障、存储器故障、运行环境故障等)已成为一种常态行为。

MapReduce是一种并行编程模型,作为典型的大数据处理框架,被经常用以处理和生成大数据集。任务调度以及容错机制作为模型的重要组成部分,会对整个大数据处理框架的性能产生直接影响[18,19]。提高整个大数据应用环境的容错性[20](分布存储的容错性、物理拓扑结构的容错性、数据的容错性等)是云计算面临的一项挑战。大数据应用环境下,为提高容错性对网络的需求主要有以下几个方面:

(1)节点失效、存储介质故障导致文件数据丢失。选择另外一个或多个有足够存储空间的节点来存储受影响的文件后,常态化需要在跨机架或同一机架跨节点之间进行数据的复制/迁移 ,因此需要得到网络在时间和带宽上的支持;

(2)元数据服务器失效/JobTracker失效。为防止元数据服务器失效,应对元数据备份众多方案,在实施方面,网络需在备份操作期间保持稳定且维持一定的带宽,以便传输日志、元数据信息等,保证数据的一致性;

(3)任务(Task)失效。任务失效分为Map任务失效和Reduce任务失效两种。针对Map任务失效,JobTracker会在从对应数据副本的节点上重新调度Map任务,此时面临如何在副本对应节点集上选择一个网络状态最好的节点,以便Map任务产生的中间结果数据传输出去;针对Reduce任务失效,JobTracker会在另一个节点重新调度Reduce任务,此时将面临如何选择其网络状态最好,能方便获取各Map任务产生的中间结果的节点。Map任务和Reduce任务的状态信息由TaskTracker向JobTracker汇报;

(4)TaskTracker失效。当TaskTracker失效时,JobTracker会将TaskTracker中的所有任务发配到另外的TaskTracker来执行,为防止TaskTracker失效产生的问题,在集群上会增加TaskTracker的数量。因此,JobTracker通过心跳机制获取和维护大规模的TaskTracker节点集信息,JobTracker对网络需求高。

針对上述4个大数据处理中容错对网络的需求,在数据处理框架与计算资源之间架设抽象层,有以下好处:

(1)在该抽象层中通过动态XML文件形成元数据备份方案逻辑映射、JobTracker管理TaskTracker的逻辑映射,方便数据处理应用程序按需获取计算资源信息,为实现利用或选择最优的有效计算资源提供数据支持和接口;

(2)抽象层在节点上的分布执行有利于将JobTracker对TaskTracker的管理分散层次化,以降低JobTracker过于集中管理带来的瓶颈(计算能力、网络带宽)问题;

(3)有利于实现JobTracker与TaskTracker之间联系的虚拟化,通过抽象层的网络访问接口,方便控制网络能按JobTracker与TaskTracker的需求进行调整(分配网络带宽、使用时间),体现网络的应用感知性,提高系统吞吐率。

4 结 语

本文从大数据应用环境下以数据处理、云存储和容错处理等方面对与网络进行协同工作的需求为基础,分别以大数据处理、云存储、大数据分析/处理任务调度和大数据处理中的容错处理这四个不同角度对与网络进行协同工作的需求为基础,分析了大数据应用下底层数据和网络的相关问题,为大数据框架中底层数据传输和网络的优化提供了研究基础。

参考文献

[1] NatureNews:Bigdata:Wikiomics[EB/OL].http://www.nature.com/news/2008/080903/full/455022a.html

[2] SP Nist. A NIST definition of cloud computing[J]. Communications of the Acm, 2015,53(6):50.

[3] N.McKeown. Keynote talk: Software-defined networking[C].In Proc. of IEEE INFOCOM09, Apr.2009.

[4] Hadoop[EB/OL]. http://hadoop.apache.org/

[5] Isard M, Budiu M, Yu Y, et al. Dryad: distributed data-parallel programs from sequential building blocks[J].ACM Sigops Operating Systems Review,2007,41(3): 59-72.

[6] Dittrich J, Quiané-Ruiz J A, Jindal A, et al. Hadoop++: Making a yellow elephant run like a cheetah (without it even noticing)[J]. Proceedings of the VLDB Endowment, 2010, 3(1-2): 515-529.

[7] Eltabakh M Y, Tian Y, ?zcan F, et al. CoHadoop: Flexible data placement and its exploitation in hadoop[J]. Proceedings of the VLDB Endowment, 2012, 4(9): 575-585.

[8] Bu Y, Howe B, Balazinska M, et al. HaLoop: Efficient iterative data processing on large clusters[J].Proceedings of the VLDB Endowment, 2010, 3(1-2): 285-296.

[9] Abouzeid A, Bajda-Pawlikowski K, Abadi D, et al. HadoopDB: an architectural hybrid of MapReduce and DBMS technologies for analytical workloads[J]. Proceedings of the VLDB Endowment, 2009, 2(1): 922-933.

[10] Wang L, Tao J, Ranjan R, et al. G-Hadoop: MapReduce across distributed data centers for data-intensive computing[J].Future Generation Computer Systems, 2013,29(3):739-750.

[11] Marozzo F, Talia D, Trunfio P. P2P-MapReduce: Parallel data processing in dynamic Cloud environments[Z].Journal of Computer and System Sciences, 2011.

[12] Zaharia M, Chowdhury M, Franklin M J, et al. Spark: cluster computing with working sets[C].Proceedings of the 2nd USENIX conference on Hot topics in cloud computing. USENIX Association, 2010: 10.

[13] Borkar V, Carey M, Grover R, et al. Hyracks: A flexible and extensible foundation for data-intensive computing[C].Data Engineering (ICDE), 2011 IEEE 27th International Conference on. IEEE, 2011: 1151-1162.

[14] Apache Hadoop framework[EB/OL]. http://hadoop.apache.org. 2010-06-20/2010-11-07.

[15] Hadoop On Demand Documentation[EB/OL]. http://hadoop.apache.org/core/ docs/r0.172/hod.html. 2010-06-20/2010-11-07.

[16] J. Dean.Experiences with MapReduce, an Abstraction for Large-Scale Computation[C]. In Proc of PACT06.

[17] J. Dean.Designs. Lessons and Advice from Building Large Distributed Systems[C]. The 3rd ACM SIGOPS International Workshop on Large Scale Distributed Systems and Middleware (LADIS), Big Sky, MT, October 2009.

[18] S.Y. Ko, I. Hoque, B. Cho, I. Gupta. On Availability of Intermediate Data in Cloud Computations[C].the USENIX Workshop on Hot Topics in Operating Systems (HotOS), 2009.

[19] G. Wang, A.R. Butt, P. Pandey, K. Gupta. A Simulation Approach to Evaluating Design Decisions in MapReduce Setups[C]. In Proc of MASCOTS2009.

[20] Zheng Q. Improving MapReduce fault tolerance in the cloud[Z]. In: Taufer M, Rünger G, Du ZH, eds. Proc. of the Workshops and PhD Forum (IPDPS 2010). Atlanta: IEEE Presss, 2010.

猜你喜欢

软件定义网络云存储云计算
业务功能链技术及其应用探析
针对大规模软件定义网络的子域划分及控制器部署方法
一种新的SDN架构下端到端网络主动测量机制
浅析龙岩烟草业务数据与监控数据中的云存储与大数据
实验云:理论教学与实验教学深度融合的助推器