趙嘉凌++蔡文偉++白偉華

摘 要：文中從大數(shù)據(jù)應(yīng)用環(huán)境下以數(shù)據(jù)處理、云存儲(chǔ)和容錯(cuò)處理等方面與網(wǎng)絡(luò)進(jìn)行協(xié)同工作的需求為基礎(chǔ)，分析了大數(shù)據(jù)應(yīng)用下底層數(shù)據(jù)和網(wǎng)絡(luò)多方面的問(wèn)題，為大數(shù)據(jù)框架中底層數(shù)據(jù)的傳輸和網(wǎng)絡(luò)優(yōu)化提供了研究基礎(chǔ)。

關(guān)鍵詞：大數(shù)據(jù)；應(yīng)用感知；云計(jì)算；軟件定義網(wǎng)絡(luò)；云存儲(chǔ)

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：2095-1302（2017）07-00-06

0 引 言

大數(shù)據(jù)（Big Data）[1]可被定義為具有4V特征的數(shù)據(jù)，即數(shù)據(jù)量及規(guī)模巨大且持續(xù)增長(zhǎng)（Volume，一般指數(shù)據(jù)量達(dá)到PB以上級(jí)別）；多源/多樣/多結(jié)構(gòu)性，不同的數(shù)據(jù)源、數(shù)據(jù)類型（Variety，復(fù)雜文檔及多媒體，結(jié)構(gòu)化、半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)）；高速性，由于存在用戶數(shù)量龐大與實(shí)時(shí)性等因素，數(shù)據(jù)的生成、增長(zhǎng)速率快，數(shù)據(jù)處理、分析的速度要求也高（Velocity）；有價(jià)值性/精確性，數(shù)據(jù)量龐大，雖然價(jià)值密度低或個(gè)別數(shù)據(jù)無(wú)價(jià)值，但數(shù)據(jù)總體上是有價(jià)值的（Value/Veracity）。

大數(shù)據(jù)環(huán)境已成熟，云計(jì)算中的大數(shù)據(jù)分析/處理，大數(shù)據(jù)處理與網(wǎng)絡(luò)/硬件的協(xié)同工作，大數(shù)據(jù)的私有性及云平臺(tái)的能耗等方面對(duì)網(wǎng)絡(luò)及其資源調(diào)度的需求，使得大數(shù)據(jù)應(yīng)用與物理網(wǎng)絡(luò)之間的交互尤顯重要，一方面讓網(wǎng)絡(luò)呈現(xiàn)出“應(yīng)用感知網(wǎng)絡(luò)（Application Aware）”的特性，使之更好地服務(wù)于大數(shù)據(jù)應(yīng)用；另一方面，如何讓大數(shù)據(jù)應(yīng)用/用戶方便高效地訪問(wèn)、調(diào)度網(wǎng)絡(luò)資源，減輕大數(shù)據(jù)應(yīng)用在網(wǎng)絡(luò)訪問(wèn)決策上的負(fù)擔(dān)是當(dāng)前大數(shù)據(jù)應(yīng)用研究中的熱點(diǎn)問(wèn)題。

1 云計(jì)算環(huán)境下的虛擬化

云計(jì)算[2]作為下一代計(jì)算模式，具有超大規(guī)模、高可擴(kuò)展性、高可靠性、虛擬化、按需服務(wù)和價(jià)格低廉等特點(diǎn)，通過(guò)調(diào)用網(wǎng)絡(luò)中大量計(jì)算節(jié)點(diǎn)/服務(wù)器完成核心計(jì)算業(yè)務(wù)的任務(wù)，向用戶提供多層次的服務(wù)如基礎(chǔ)設(shè)施、平臺(tái)、存儲(chǔ)服務(wù)和軟件服務(wù)等。在大數(shù)據(jù)應(yīng)用中，云計(jì)算的核心功能主要有數(shù)據(jù)存儲(chǔ)/管理（以數(shù)據(jù)存儲(chǔ)為主的存儲(chǔ)型云平臺(tái)）和數(shù)據(jù)分析/處理（以數(shù)據(jù)處理為主的計(jì)算型云平臺(tái)）。云計(jì)算提供商將大量計(jì)算節(jié)點(diǎn)與網(wǎng)絡(luò)設(shè)備連在一起，構(gòu)建一個(gè)或若干個(gè)大規(guī)模（由具有萬(wàn)甚至百萬(wàn)級(jí)以上的計(jì)算節(jié)點(diǎn)所組成）數(shù)據(jù)中心，通過(guò)云平臺(tái)實(shí)時(shí)訪問(wèn)、調(diào)用網(wǎng)絡(luò)、存儲(chǔ)、計(jì)算等資源為用戶服務(wù)。

云計(jì)算核心組成邏輯如圖1所示。云計(jì)算主要由服務(wù)器、存儲(chǔ)和網(wǎng)絡(luò)組成。為了使得云能夠更快、更方便地響應(yīng)企業(yè)用戶的需求，服務(wù)器（層）和存儲(chǔ)（層）已經(jīng)通過(guò)在實(shí)際基礎(chǔ)設(shè)施和云環(huán)境之間構(gòu)建抽象層實(shí)現(xiàn)虛擬化，滿足配置、管理和使用服務(wù)器及存儲(chǔ)資源的要求。但最終還需要依靠網(wǎng)絡(luò)將資源連接集成以搭建一個(gè)完整的云環(huán)境?！按髷?shù)據(jù)應(yīng)用環(huán)境下與網(wǎng)絡(luò)的交互”以及“網(wǎng)絡(luò)與計(jì)算資源的交互”面臨以下三方面的要求：

（1）大數(shù)據(jù)應(yīng)用層與網(wǎng)絡(luò)的交互：網(wǎng)絡(luò)結(jié)構(gòu)相對(duì)穩(wěn)定，但由于云環(huán)境的高擴(kuò)展性以及節(jié)點(diǎn)規(guī)模的龐大，使得服務(wù)器和存儲(chǔ)這兩方面的資源會(huì)時(shí)常發(fā)生變化，如服務(wù)器/節(jié)點(diǎn)的添加——斷電、故障、恢復(fù)、新增節(jié)點(diǎn)等或存儲(chǔ)磁盤的故障、失效等。面對(duì)這些變化，上層大數(shù)據(jù)應(yīng)用如何能更好、更快地獲取計(jì)算資源的變化？

圖1 云計(jì)算核心組成邏輯圖

（2）計(jì)算資源與網(wǎng)絡(luò)的交互：在大數(shù)據(jù)處理中，各計(jì)算資源的狀態(tài)與承擔(dān)的任務(wù)及負(fù)荷各不相同，為合理使用計(jì)算資源并計(jì)算資源負(fù)載平衡，網(wǎng)絡(luò)如何能更快更方便地告知上層大數(shù)據(jù)應(yīng)用其所獲得的感知信息，并讓應(yīng)用或用戶調(diào)整其調(diào)用計(jì)算資源的策略？

（3）計(jì)算資源按上層大數(shù)據(jù)應(yīng)用的需求動(dòng)態(tài)調(diào)整：上層應(yīng)用復(fù)雜多變，面對(duì)應(yīng)用/服務(wù)的變化，其所需的計(jì)算資源也不同，如何更快地調(diào)整、組織計(jì)算資源讓其適應(yīng)并為上層應(yīng)用提供服務(wù)？

為滿足上述需求，添加兩個(gè)具有擴(kuò)展性的接口層形成大數(shù)據(jù)應(yīng)用與計(jì)算資源（服務(wù)器/存儲(chǔ)）的中間層，這兩個(gè)接口層如下：

（1）大數(shù)據(jù)應(yīng)用層與網(wǎng)絡(luò)層之間的交互接口層；

（2）網(wǎng)絡(luò)層與計(jì)算資源層（服務(wù)器/存儲(chǔ)）之間的交互接口層。

2 開(kāi)放式協(xié)同平臺(tái)的中介——SDN

2011年10月，美國(guó)麻省理工大學(xué)Kate Greene教授提出了SDN （Software-Defined Networking，SDN）軟件定義網(wǎng)絡(luò)技術(shù)的概念[3]。所謂SDN，是指根據(jù)不同的使用需要，通過(guò)軟件來(lái)完成所有路由器與交換機(jī)的動(dòng)態(tài)配置。并于2011年3月成立了以實(shí)現(xiàn)該概念為目的的網(wǎng)絡(luò)聯(lián)盟Open Network Foundation （ONF），提倡使用OpenFlow作為實(shí)現(xiàn)SDN的重要技術(shù)。

OpenFlow網(wǎng)絡(luò)的最大特點(diǎn)是將傳統(tǒng)的交換機(jī)路由控制部分與數(shù)據(jù)傳送部分分離，使得網(wǎng)絡(luò)設(shè)備可以專注于數(shù)據(jù)包轉(zhuǎn)發(fā)，從而極大地簡(jiǎn)化了交換機(jī)的體系。OpenFlow網(wǎng)絡(luò)的主要構(gòu)成元素包括支持OpenFlow協(xié)議的交換機(jī)（OpenFlow Switch），交換機(jī)控制器（OpenFlow Controller）以及用于交換機(jī)與控制器之間的控制協(xié)議（OpenFlow Protocol），其體系結(jié)構(gòu)如圖2所示。

OpenFlow網(wǎng)絡(luò)可以處理包含在數(shù)據(jù)包中的各種信息，如MAC地址，IP地址，VLANID，MPLS標(biāo)識(shí)，TCP端口等共15類，將這些信息與數(shù)據(jù)包的處理方法相結(jié)合，用于設(shè)計(jì)OpenFlow交換機(jī)的Flow Table。Flow Table即數(shù)據(jù)包的處理規(guī)則與處理方法對(duì)照表，如對(duì)含有特定VLANID信息的數(shù)據(jù)包執(zhí)行數(shù)據(jù)包轉(zhuǎn)發(fā)、丟棄或多播等操作。

網(wǎng)絡(luò)管理人員通過(guò)對(duì)Flow Table進(jìn)行詳細(xì)設(shè)計(jì)便可輕松實(shí)現(xiàn)對(duì)數(shù)據(jù)包交換路徑的精準(zhǔn)控制。隨著云計(jì)算應(yīng)用的不斷增多，頻繁的網(wǎng)絡(luò)重新配置不可避免。VLAN組網(wǎng)技術(shù)支持網(wǎng)絡(luò)管理員動(dòng)態(tài)對(duì)網(wǎng)絡(luò)進(jìn)行配置，是目前HDFS云存儲(chǔ)的主要組網(wǎng)技術(shù)。但VLAN組網(wǎng)技術(shù)面臨以下問(wèn)題：

（1）當(dāng)子網(wǎng)數(shù)量不斷增加時(shí)，采用VLAN對(duì)網(wǎng)絡(luò)進(jìn)行管理將會(huì)使情況變得很復(fù)雜；

（2）只能利用VLANID進(jìn)行組網(wǎng)，組網(wǎng)的靈活性不高，無(wú)法適應(yīng)來(lái)自云計(jì)算的不同需求。

（3）除電信運(yùn)營(yíng)商級(jí)的VLAN技術(shù)外，數(shù)據(jù)中心級(jí)VLAN技術(shù)幾乎不能實(shí)現(xiàn)異地云存儲(chǔ)服務(wù)器之間的連接。異地云存儲(chǔ)系統(tǒng)互連的重要性在于通過(guò)將數(shù)據(jù)備份在不同的物理地點(diǎn)來(lái)消除單一故障（電力中斷，火災(zāi)等）引起的服務(wù)中斷，這正是ONF聯(lián)盟將OpenFlow列為云計(jì)算網(wǎng)絡(luò)控制技術(shù)之一的主要原因。

圖2 OpenFlow體系架構(gòu)

3 存在問(wèn)題及分析

3.1 從大數(shù)據(jù)處理的角度分析

在大數(shù)據(jù)應(yīng)用的環(huán)境下，大數(shù)據(jù)分析/處理的計(jì)算框架以MapReduce編程模型最具代表性。MapReduce計(jì)算模型在執(zhí)行中，首先對(duì)數(shù)據(jù)源進(jìn)行分塊，然后交給不同Map任務(wù)區(qū)來(lái)處理，執(zhí)行Map函數(shù)，根據(jù)數(shù)據(jù)處理的規(guī)則對(duì)數(shù)據(jù)分類，并寫入本地磁盤；Map階段完成后，進(jìn)入Reduce階段，執(zhí)行Reduce函數(shù)，具有同樣Key值的中間結(jié)果從多個(gè)Map任務(wù)所在的節(jié)點(diǎn)被收集到一起（稱為Shuffle）進(jìn)行合并處理（稱為Merge），輸出結(jié)果寫入本地磁盤。最終通過(guò)合并所有Reduce任務(wù)得到最終結(jié)果。

以MapReduce計(jì)算模型為基本核心原理，相似的計(jì)算模型有如下幾種：

Hadoop[4]：核心由HDFS和MapReduce組成，其中Hadoop-MapReduce是Google MapReduce的開(kāi)源實(shí)現(xiàn)。

Dryad[5]：與MapReduce計(jì)算模型相似，其總體構(gòu)建用來(lái)支持有向無(wú)環(huán)圖（Directed Acycline Graph，DAG）類型數(shù)據(jù)流的并行程序。Dryad的整體框架根據(jù)程序的要求完成調(diào)度工作，自動(dòng)完成任務(wù)在各節(jié)點(diǎn)上的運(yùn)行。

Hadoop++[6]：Hadoop++是通過(guò)自定義Hadoop框架中的split等函數(shù)來(lái)提升數(shù)據(jù)查詢和聯(lián)接性能，即通過(guò)Hadoop用戶自定義函數(shù)方式對(duì)Hadoop-MapReduce實(shí)現(xiàn)非入侵式優(yōu)化。

CoHadoop[7]：Hadoop無(wú)法突破把相關(guān)數(shù)據(jù)定位到同一個(gè)node集合下的性能瓶頸。CoHadoop是對(duì)Hadoop的一個(gè)輕量級(jí)擴(kuò)展，目的是允許應(yīng)用層控制數(shù)據(jù)的存儲(chǔ)。應(yīng)用層通過(guò)某種方式提示CoHadoop某些集合里的文件相關(guān)性較大，可能需要合并，之后CoHadoop嘗試轉(zhuǎn)移這些文件以提高數(shù)據(jù)讀取效率。MapReduce計(jì)算過(guò)程示意如圖3所示。

圖3 MapReduce計(jì)算過(guò)程示意圖

Haloop[8]：Haloop是一個(gè)Hadoop-MapReduce框架的修改版本，其目標(biāo)是為了高效支持迭代，遞歸數(shù)據(jù)分析任務(wù)。遞歸的連接可能在Map端，也可能在Reduce端。Haloop的基本思想是緩存循環(huán)不變量（即靜態(tài)變量）到salve nodes。每次迭代重用這些數(shù)據(jù)。

HadoopDB[9]：HadoopDB是一個(gè)混合系統(tǒng)。其基本思想是采用現(xiàn)有的MapReduce作為與正在運(yùn)行著單節(jié)點(diǎn)DBMS實(shí)例的多樣化節(jié)點(diǎn)的通信層，實(shí)現(xiàn)并行化數(shù)據(jù)庫(kù)。查詢語(yǔ)言采用SQL表示，并使用現(xiàn)有工具將其翻譯成MapReduce可以接受的語(yǔ)言，使得盡可能多的任務(wù)被推送到每個(gè)高性能的單節(jié)點(diǎn)數(shù)據(jù)庫(kù)。

G-Hadoop[10]：通過(guò)現(xiàn)有的MapReduce計(jì)算模型配合高速的存儲(chǔ)區(qū)域網(wǎng)（Storage Area Network，SAN）實(shí)現(xiàn)在多群聚環(huán)境，為大數(shù)據(jù)應(yīng)用提供一個(gè)并行處理的環(huán)境。

P2P-MapReduce[11]：是一個(gè)動(dòng)態(tài)分布式環(huán)境中自適應(yīng)的MapReduce框架（2P-MapReduce），利用P2P模式在動(dòng)態(tài)分布式環(huán)境中管理計(jì)算節(jié)點(diǎn)的參與、主機(jī)失敗和作業(yè)恢復(fù)等，為大數(shù)據(jù)應(yīng)用提供服務(wù)。

Spark[12]：Spark是一個(gè)與Hadoop相似的開(kāi)源云計(jì)算系統(tǒng)，支持分布式數(shù)據(jù)集上的迭代作業(yè)，是對(duì)Hadoop的補(bǔ)充，用于快速數(shù)據(jù)分析，包括快速運(yùn)行和快速寫操作。Spark啟用內(nèi)存分布數(shù)據(jù)集，除能夠提供交互式查詢外，還可優(yōu)化迭代工作負(fù)載。

Hyracks[13]：一個(gè)受MapReduce啟發(fā)，基于分區(qū)并行數(shù)據(jù)流的大數(shù)據(jù)并行處理系統(tǒng)，用戶可將計(jì)算表示成數(shù)據(jù)操作器和連接器的有向無(wú)環(huán)圖（Directed Acycline Graph，DAG）類型數(shù)據(jù)流。

大數(shù)據(jù)處理框架的設(shè)計(jì)思想見(jiàn)表1所列。

（1）MapReduce計(jì)算執(zhí)行過(guò)程中的Shuffle階段——執(zhí)行完Map階段后會(huì)產(chǎn)生大量中間結(jié)果數(shù)據(jù)，該階段根據(jù)中間輸出結(jié)果中的Key值進(jìn)行分類并分發(fā)到相關(guān)節(jié)點(diǎn)執(zhí)行Reduce函數(shù)；

（2）其余類MapReduce計(jì)算模式、迭代、遞歸等也需要進(jìn)行大量分片和合并操作。

在這兩個(gè)過(guò)程中產(chǎn)生的大量中間結(jié)果數(shù)據(jù)要在不同的節(jié)點(diǎn)（Map節(jié)點(diǎn)/Reduce節(jié)點(diǎn)）之間傳輸，數(shù)據(jù)規(guī)模越大、參與計(jì)算的節(jié)點(diǎn)越多、Map-Reduce的迭代/遞歸次數(shù)越多，節(jié)點(diǎn)間傳輸?shù)念l度及數(shù)據(jù)量也越大，占用網(wǎng)絡(luò)的帶寬及時(shí)間也越長(zhǎng)，最終可能導(dǎo)致網(wǎng)絡(luò)擁擠與堵塞，嚴(yán)重影響大數(shù)據(jù)處理框架的性能。

缺乏應(yīng)用感知網(wǎng)絡(luò)的支持，這些大數(shù)據(jù)處理框架其性能得不到很好的發(fā)揮，因此，在大數(shù)據(jù)處理框架與網(wǎng)絡(luò)之間構(gòu)建一抽象層，通過(guò)抽象層實(shí)現(xiàn)大數(shù)據(jù)處理框架與網(wǎng)絡(luò)之間的交互是一個(gè)有效的解決方式。一方面大數(shù)據(jù)處理框架無(wú)需修改現(xiàn)有的計(jì)算模式，直接通過(guò)該層告知基礎(chǔ)設(shè)施其所需計(jì)算資源的類別，而非特定的某一計(jì)算資源，從而讓計(jì)算資源調(diào)度策略從數(shù)據(jù)處理框架中脫離出來(lái)，使得計(jì)算過(guò)程主要關(guān)注數(shù)據(jù)的分析/處理，減輕大數(shù)據(jù)處理框架的包袱；另一方面通過(guò)該抽象層為第三方提供網(wǎng)絡(luò)訪問(wèn)/調(diào)整的接口，在網(wǎng)絡(luò)物理結(jié)構(gòu)不變的前提下按大數(shù)據(jù)應(yīng)用需求調(diào)整網(wǎng)絡(luò)邏輯結(jié)構(gòu)，方便資源調(diào)度策略的優(yōu)化和實(shí)施，構(gòu)建應(yīng)用感知網(wǎng)絡(luò)更好地為大數(shù)據(jù)應(yīng)用提供服務(wù)。

3.2 從云存儲(chǔ)的角度分析

在大數(shù)據(jù)應(yīng)用的環(huán)境下，存儲(chǔ)是核心的組成之一，HDFS（Hadoop Distributed File System，HDFS）是當(dāng)前主流的一款開(kāi)源云存儲(chǔ)框架，是一個(gè)分布式文件系統(tǒng)，更是適合運(yùn)行在普通硬件上的分布式高容錯(cuò)文件系統(tǒng)，當(dāng)前絕大多數(shù)云存儲(chǔ)系統(tǒng)都通過(guò)HDFS實(shí)現(xiàn)。

HDFS的系統(tǒng)架構(gòu)如圖4所示。

HDFS采用Master/Slave架構(gòu)。HDFS主要由Namenode（master）和一系列Datanode（workers）構(gòu)成。一個(gè)HDFS集群由一個(gè)Namenode和一定數(shù)目的Datanode組成。HDFS支持傳統(tǒng)的層次型文件組織。Namenode是一個(gè)中心服務(wù)器，負(fù)責(zé)管理文件系統(tǒng)的namespace以及客戶端對(duì)文件的訪問(wèn)。HDFS有著高容錯(cuò)性的特點(diǎn)，部署在低廉的硬件上，提供高傳輸率來(lái)訪問(wèn)應(yīng)用程序的數(shù)據(jù)，是為以流的方式存取大文件而設(shè)計(jì)，適合擁有超大數(shù)據(jù)集的應(yīng)用程序。HDFS支持大數(shù)據(jù)文件，能夠提供大數(shù)據(jù)傳輸?shù)膸捄蛿?shù)百個(gè)節(jié)點(diǎn)的集群服務(wù)，能夠支持千萬(wàn)級(jí)別的文件。所有的HDFS通訊協(xié)議都構(gòu)建在TCP/IP協(xié)議上。HDFS設(shè)計(jì)目標(biāo)對(duì)網(wǎng)絡(luò)的需求：

（1）硬件故障/錯(cuò)誤及副本策略

硬件故障/錯(cuò)誤是常態(tài)而非異常。HDFS集群由成百上千的服務(wù)器構(gòu)成，每個(gè)服務(wù)器上存儲(chǔ)著文件系統(tǒng)中數(shù)據(jù)的一部分，任一個(gè)服務(wù)器都有可能失效。因此錯(cuò)誤檢測(cè)和快速、自動(dòng)恢復(fù)是HDFS最為核心的架構(gòu)目標(biāo)。此時(shí)，在網(wǎng)絡(luò)上需解決網(wǎng)絡(luò)可用的計(jì)算節(jié)點(diǎn)數(shù)量減少，一部分文件的可用副本數(shù)減少等問(wèn)題。為確保文件副本的數(shù)量，數(shù)據(jù)需備份，以防故障。

（2）流式數(shù)據(jù)訪問(wèn)

HDFS應(yīng)用程序需要流式訪問(wèn)數(shù)據(jù)集。HDFS進(jìn)行的是數(shù)據(jù)批處理，而非用戶交互處理；相比數(shù)據(jù)訪問(wèn)的低延遲，更應(yīng)保證數(shù)據(jù)訪問(wèn)的高吞吐量。

（3）大規(guī)模數(shù)據(jù)集

大數(shù)據(jù)應(yīng)用中的應(yīng)用程序是在大規(guī)模數(shù)據(jù)集基礎(chǔ)上的計(jì)算。HDFS上一個(gè)典型文件的大小一般都為G字節(jié)至T字節(jié)。因此，大文件存儲(chǔ)且能提供整體上數(shù)據(jù)傳輸?shù)母邘?，能在一個(gè)集群里擴(kuò)展到數(shù)百個(gè)節(jié)點(diǎn)，使得網(wǎng)絡(luò)中的計(jì)算節(jié)點(diǎn)之間、存儲(chǔ)節(jié)點(diǎn)之間必然有大量數(shù)據(jù)傳輸。

（4）計(jì)算移到數(shù)據(jù)附近

數(shù)據(jù)離應(yīng)用程序越近，計(jì)算就越高效，尤其是在數(shù)據(jù)達(dá)到海量級(jí)別時(shí)。因?yàn)檫@樣就能降低網(wǎng)絡(luò)阻塞的影響，提高系統(tǒng)數(shù)據(jù)的吞吐量。

（5）數(shù)據(jù)復(fù)制及副本存放

HDFS能夠在集群機(jī)器上可靠地存儲(chǔ)超大文件，其將文件分割成若干“塊”，除了最后一個(gè)，所有“塊”大小一致。為了容錯(cuò)，文件的所有數(shù)據(jù)塊都有副本。每個(gè)文件的數(shù)據(jù)塊大小和副本系數(shù)都可配置，應(yīng)用程序可以指定某個(gè)文件的副本數(shù)目。數(shù)據(jù)復(fù)制與采用的副本策略有關(guān)，且由于故障、更新、備份（HA的主要解決方案：Hadoop的元數(shù)據(jù)備份方案、Secondary NameNode方案、Checkpoint node方案、Backup Node方案、DRDB、Facebook的Avatarnode方案）等原因，數(shù)據(jù)復(fù)制經(jīng)常發(fā)生在同機(jī)架的不同存儲(chǔ)節(jié)點(diǎn)之間及不同機(jī)架的不同存儲(chǔ)節(jié)點(diǎn)之間，這個(gè)過(guò)程必然依靠網(wǎng)絡(luò)。

其他一些云存儲(chǔ)系統(tǒng)如GFS（HDFS是GFS的開(kāi)源實(shí)現(xiàn)）、CoHadoop、StorNext FS、Lustr、Total Storage SAN File System、DDFS（Disco Distributed File System）等，其設(shè)計(jì)目標(biāo)主要為上述幾個(gè)方面。

云存儲(chǔ)系統(tǒng)設(shè)計(jì)目標(biāo)的實(shí)現(xiàn)依賴于暢通的網(wǎng)絡(luò)。云存儲(chǔ)作為大數(shù)據(jù)應(yīng)用的核心支撐，其效能直接影響到大數(shù)據(jù)應(yīng)用的性能，云存儲(chǔ)框架與網(wǎng)絡(luò)及計(jì)算資源的（服務(wù)器/存儲(chǔ)）高耦合（數(shù)據(jù)調(diào)度、存儲(chǔ)調(diào)度、副本存放、數(shù)據(jù)操作等與具體計(jì)算資源的選擇與使用高耦合）關(guān)系，將影響應(yīng)用框架的可擴(kuò)展性。在云存儲(chǔ)的文件操作與網(wǎng)絡(luò)中的存儲(chǔ)資源之間插入中間抽象層，云存儲(chǔ)系統(tǒng)只需告知抽象層申請(qǐng)的計(jì)算資源的類別，通過(guò)抽象層與計(jì)算資源之間的接口訪問(wèn)某類資源，實(shí)現(xiàn)文件的相關(guān)操作，一方面能方便地直接訪問(wèn)抽象層反饋的計(jì)算資源集，另一方面將操作的具體實(shí)現(xiàn)過(guò)程標(biāo)準(zhǔn)化，通過(guò)抽象的接口簡(jiǎn)化云存儲(chǔ)系統(tǒng)的操作。

3.3 從大數(shù)據(jù)分析/處理任務(wù)調(diào)度的角度分析

大數(shù)據(jù)分析/處理都在集群（Cluster）的基礎(chǔ)上完成，通過(guò)網(wǎng)絡(luò)連接多個(gè)成為節(jié)點(diǎn)的計(jì)算機(jī)為應(yīng)用提供計(jì)算、數(shù)據(jù)存儲(chǔ)和通信資源等。以Hadoop集群所提供的大數(shù)據(jù)分析/處理為代表，Hadoop集群中節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)存儲(chǔ)、集群維護(hù)管理和數(shù)據(jù)分析/處理的任務(wù)。在作業(yè)/任務(wù)調(diào)度中，分為JobTracker（控制節(jié)點(diǎn)）和TaskTracker（任務(wù)節(jié)點(diǎn)/執(zhí)行節(jié)點(diǎn)）。一般情況下，Namenode和 JobTracker合并在同一臺(tái)物理服務(wù)器上，Datanode和TaskTracker作為集群的主要部分也會(huì)被安裝在相同節(jié)點(diǎn)上且大量散布于集群中。

集群結(jié)構(gòu)如圖5所示[14，15]。

控制節(jié)點(diǎn)負(fù)責(zé)HDFS和MapReduce執(zhí)行的管理（JobTracker），其余節(jié)點(diǎn)為執(zhí)行節(jié)點(diǎn)（TaskTracker），負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和計(jì)算。任務(wù)調(diào)度是JobTracker指派任務(wù)（tasks）到相應(yīng)TaskTracker上執(zhí)行的過(guò)程。任務(wù)調(diào)度過(guò)程如下：

（1）JobTracker調(diào)度和管理其它TaskTracker，并將Map任務(wù)和Reduce任務(wù)分發(fā)給空閑的TaskTracker，讓這些任務(wù)并行運(yùn)行，并負(fù)責(zé)監(jiān)控任務(wù)的運(yùn)行情況。

（2）TaskTracker負(fù)責(zé)具體任務(wù)的執(zhí)行，并向JobTracker報(bào)告自己所處的狀態(tài)，接受其管理調(diào)度；一個(gè)重要的任務(wù)是原始輸入數(shù)據(jù)和中間運(yùn)算結(jié)果的存儲(chǔ)和傳遞（在網(wǎng)絡(luò)中不同TaskTracker之間傳遞中間結(jié)果數(shù)據(jù)）。

（3）JobTracker和TaskTracker之間通過(guò)網(wǎng)絡(luò)以心跳機(jī)制實(shí)現(xiàn)通信。

（4）當(dāng)一個(gè)Map任務(wù)被分配到執(zhí)行節(jié)點(diǎn)執(zhí)行時(shí)，系統(tǒng)會(huì)移動(dòng)Map計(jì)算程序到該節(jié)點(diǎn)——在數(shù)據(jù)存儲(chǔ)的Datanode節(jié)點(diǎn)上執(zhí)行這部分?jǐn)?shù)據(jù)的計(jì)算，以減少數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸，降低對(duì)網(wǎng)絡(luò)帶寬的需求。

（5）在一個(gè)Reduce任務(wù)被分配到一個(gè)空閑的TaskTracker節(jié)點(diǎn)上執(zhí)行時(shí)，JobTracker會(huì)先將中間結(jié)果的key/value對(duì)在執(zhí)行Map任務(wù)的TaskTracker節(jié)點(diǎn)上局部磁盤位置信息發(fā)送給Reduce任務(wù)，Reduce任務(wù)采用遠(yuǎn)程過(guò)程調(diào)用機(jī)制從Map任務(wù)節(jié)點(diǎn)的磁盤中讀取數(shù)據(jù)。

任務(wù)/作業(yè)調(diào)度方法直接關(guān)系到Hadoop集群的整體系統(tǒng)和系統(tǒng)資源的利用情況。針對(duì)MapReduce集群先后提出了很多調(diào)度策略，包括FIFO調(diào)度、HOD調(diào)度、計(jì)算能力調(diào)度、公平調(diào)度等。

在任務(wù)/作業(yè)的調(diào)度中，無(wú)論何種調(diào)度策略，對(duì)網(wǎng)絡(luò)的使用及需求如下：

（1）JobTracker在分配任務(wù)前，必須與該任務(wù)使用的數(shù)據(jù)源所存儲(chǔ)的節(jié)點(diǎn)（節(jié)點(diǎn)集）建立聯(lián)系，并通過(guò)節(jié)點(diǎn)的空閑狀態(tài)以判斷是否在該節(jié)點(diǎn)啟動(dòng)任務(wù)。針對(duì)一個(gè)文件，其被劃分為多個(gè)塊存儲(chǔ)在各節(jié)點(diǎn)上，每個(gè)文件塊對(duì)應(yīng)多個(gè)（默認(rèn)設(shè)置為3）副本，每個(gè)副本存儲(chǔ)在不同的節(jié)點(diǎn)上，因此，一個(gè)任務(wù)對(duì)應(yīng)要判斷多個(gè)節(jié)點(diǎn)的狀態(tài)。當(dāng)多個(gè)任務(wù)并行時(shí)，JobTracker要審閱大規(guī)模節(jié)點(diǎn)的狀態(tài)，當(dāng)前JobTracker節(jié)點(diǎn)與這些節(jié)點(diǎn)之間的網(wǎng)絡(luò)狀態(tài)對(duì)任務(wù)啟動(dòng)的策略及判斷有非常大的影響；

（2）JobTracker無(wú)法判斷及獲知被選中的計(jì)算節(jié)點(diǎn)的當(dāng)前網(wǎng)絡(luò)狀況及其歷史網(wǎng)絡(luò)情況，因此計(jì)算節(jié)點(diǎn)的網(wǎng)絡(luò)狀況這一因素在任務(wù)調(diào)度中被忽略，不利于有效利用網(wǎng)絡(luò)以提高大數(shù)據(jù)分析/處理性能；

（3）在Reduce任務(wù)分配時(shí)，JobTracker由于不了解TaskTracker節(jié)點(diǎn)的當(dāng)前網(wǎng)絡(luò)狀況及其歷史網(wǎng)絡(luò)情況，無(wú)法根據(jù)TaskTracker節(jié)點(diǎn)的網(wǎng)絡(luò)狀況來(lái)選擇最優(yōu)的節(jié)點(diǎn)啟動(dòng)Reduce任務(wù)，故無(wú)法高效快速地獲取Map任務(wù)產(chǎn)生的大量中間數(shù)據(jù)，從而影響了數(shù)據(jù)分析/處理的性能；

（4）在任務(wù)執(zhí)行的過(guò)程中，JobTracker與大規(guī)模的TaskTracker節(jié)點(diǎn)之間利用網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)心跳機(jī)制的通信，JobTracker需要有穩(wěn)定的網(wǎng)絡(luò)來(lái)支持。

其它如表1所列的大數(shù)據(jù)處理框架中的任務(wù)調(diào)度也存在類似問(wèn)題。所以，針對(duì)上述問(wèn)題，在計(jì)算資源及網(wǎng)絡(luò)的上層架設(shè)一抽象層，負(fù)責(zé)統(tǒng)計(jì)網(wǎng)絡(luò)的當(dāng)前狀況及各節(jié)點(diǎn)的網(wǎng)絡(luò)狀態(tài)，維護(hù)計(jì)算資源的狀態(tài)，任務(wù)調(diào)度器只需向該抽象層提出執(zhí)行的任務(wù)（主要為TaskTracker的任務(wù)）及申請(qǐng)使用的計(jì)算資源的類別，從抽象層中獲取得到相應(yīng)類別的計(jì)算資源，最后執(zhí)行任務(wù)。通過(guò)架設(shè)這一抽象層，可以做到：

（1）大數(shù)據(jù)應(yīng)用環(huán)境下的任務(wù)調(diào)度器，只需關(guān)注調(diào)度策略及使用的計(jì)算資源類別，抽象層負(fù)責(zé)維護(hù)具體的計(jì)算資源的狀態(tài)，反饋告知調(diào)度器可按需查詢抽象層中所維護(hù)的計(jì)算資源的信息，實(shí)現(xiàn)計(jì)算資源對(duì)調(diào)度器的虛擬化；

（2）通過(guò)向抽象層中加載針對(duì)計(jì)算資源狀態(tài)分析、網(wǎng)絡(luò)歷史情況分析及節(jié)點(diǎn)網(wǎng)絡(luò)狀況分析的第三方策略獲得計(jì)算資源的最優(yōu)或次優(yōu)集，能更有效地利用網(wǎng)絡(luò)來(lái)優(yōu)化任務(wù)調(diào)度，通過(guò)提供計(jì)算資源調(diào)度策略的接口，有利于提高當(dāng)前計(jì)算框架的數(shù)據(jù)分析/處理性能；

（3）由于抽象層對(duì)任務(wù)調(diào)度器反饋的是某類計(jì)算資源中最優(yōu)或次優(yōu)的可選節(jié)點(diǎn)集，能實(shí)現(xiàn)節(jié)點(diǎn)及網(wǎng)絡(luò)的負(fù)載平衡，預(yù)防Map/Reduce任務(wù)之間大數(shù)據(jù)量傳輸所造成的網(wǎng)絡(luò)擁擠及堵塞，避開(kāi)網(wǎng)絡(luò)帶寬的瓶頸。

3.4 從大數(shù)據(jù)處理中容錯(cuò)處理的角度分析

由于大數(shù)據(jù)應(yīng)用環(huán)境下，數(shù)據(jù)的規(guī)模、計(jì)算資源（存儲(chǔ)、服務(wù)器）的規(guī)模和同時(shí)并行處理的任務(wù)規(guī)模都極其龐大，各種情況的失效[16，17]（服務(wù)器故障、軟件故障、存儲(chǔ)器故障、運(yùn)行環(huán)境故障等）已成為一種常態(tài)行為。

MapReduce是一種并行編程模型，作為典型的大數(shù)據(jù)處理框架，被經(jīng)常用以處理和生成大數(shù)據(jù)集。任務(wù)調(diào)度以及容錯(cuò)機(jī)制作為模型的重要組成部分，會(huì)對(duì)整個(gè)大數(shù)據(jù)處理框架的性能產(chǎn)生直接影響[18，19]。提高整個(gè)大數(shù)據(jù)應(yīng)用環(huán)境的容錯(cuò)性[20]（分布存儲(chǔ)的容錯(cuò)性、物理拓?fù)浣Y(jié)構(gòu)的容錯(cuò)性、數(shù)據(jù)的容錯(cuò)性等）是云計(jì)算面臨的一項(xiàng)挑戰(zhàn)。大數(shù)據(jù)應(yīng)用環(huán)境下，為提高容錯(cuò)性對(duì)網(wǎng)絡(luò)的需求主要有以下幾個(gè)方面：

（1）節(jié)點(diǎn)失效、存儲(chǔ)介質(zhì)故障導(dǎo)致文件數(shù)據(jù)丟失。選擇另外一個(gè)或多個(gè)有足夠存儲(chǔ)空間的節(jié)點(diǎn)來(lái)存儲(chǔ)受影響的文件后，常態(tài)化需要在跨機(jī)架或同一機(jī)架跨節(jié)點(diǎn)之間進(jìn)行數(shù)據(jù)的復(fù)制/遷移 ，因此需要得到網(wǎng)絡(luò)在時(shí)間和帶寬上的支持；

（2）元數(shù)據(jù)服務(wù)器失效/JobTracker失效。為防止元數(shù)據(jù)服務(wù)器失效，應(yīng)對(duì)元數(shù)據(jù)備份眾多方案，在實(shí)施方面，網(wǎng)絡(luò)需在備份操作期間保持穩(wěn)定且維持一定的帶寬，以便傳輸日志、元數(shù)據(jù)信息等，保證數(shù)據(jù)的一致性；

（3）任務(wù)（Task）失效。任務(wù)失效分為Map任務(wù)失效和Reduce任務(wù)失效兩種。針對(duì)Map任務(wù)失效，JobTracker會(huì)在從對(duì)應(yīng)數(shù)據(jù)副本的節(jié)點(diǎn)上重新調(diào)度Map任務(wù)，此時(shí)面臨如何在副本對(duì)應(yīng)節(jié)點(diǎn)集上選擇一個(gè)網(wǎng)絡(luò)狀態(tài)最好的節(jié)點(diǎn)，以便Map任務(wù)產(chǎn)生的中間結(jié)果數(shù)據(jù)傳輸出去；針對(duì)Reduce任務(wù)失效，JobTracker會(huì)在另一個(gè)節(jié)點(diǎn)重新調(diào)度Reduce任務(wù)，此時(shí)將面臨如何選擇其網(wǎng)絡(luò)狀態(tài)最好，能方便獲取各Map任務(wù)產(chǎn)生的中間結(jié)果的節(jié)點(diǎn)。Map任務(wù)和Reduce任務(wù)的狀態(tài)信息由TaskTracker向JobTracker匯報(bào)；

（4）TaskTracker失效。當(dāng)TaskTracker失效時(shí)，JobTracker會(huì)將TaskTracker中的所有任務(wù)發(fā)配到另外的TaskTracker來(lái)執(zhí)行，為防止TaskTracker失效產(chǎn)生的問(wèn)題，在集群上會(huì)增加TaskTracker的數(shù)量。因此，JobTracker通過(guò)心跳機(jī)制獲取和維護(hù)大規(guī)模的TaskTracker節(jié)點(diǎn)集信息，JobTracker對(duì)網(wǎng)絡(luò)需求高。

針對(duì)上述4個(gè)大數(shù)據(jù)處理中容錯(cuò)對(duì)網(wǎng)絡(luò)的需求，在數(shù)據(jù)處理框架與計(jì)算資源之間架設(shè)抽象層，有以下好處：

（1）在該抽象層中通過(guò)動(dòng)態(tài)XML文件形成元數(shù)據(jù)備份方案邏輯映射、JobTracker管理TaskTracker的邏輯映射，方便數(shù)據(jù)處理應(yīng)用程序按需獲取計(jì)算資源信息，為實(shí)現(xiàn)利用或選擇最優(yōu)的有效計(jì)算資源提供數(shù)據(jù)支持和接口；

（2）抽象層在節(jié)點(diǎn)上的分布執(zhí)行有利于將JobTracker對(duì)TaskTracker的管理分散層次化，以降低JobTracker過(guò)于集中管理帶來(lái)的瓶頸（計(jì)算能力、網(wǎng)絡(luò)帶寬）問(wèn)題；

（3）有利于實(shí)現(xiàn)JobTracker與TaskTracker之間聯(lián)系的虛擬化，通過(guò)抽象層的網(wǎng)絡(luò)訪問(wèn)接口，方便控制網(wǎng)絡(luò)能按JobTracker與TaskTracker的需求進(jìn)行調(diào)整（分配網(wǎng)絡(luò)帶寬、使用時(shí)間），體現(xiàn)網(wǎng)絡(luò)的應(yīng)用感知性，提高系統(tǒng)吞吐率。

4 結(jié) 語(yǔ)

本文從大數(shù)據(jù)應(yīng)用環(huán)境下以數(shù)據(jù)處理、云存儲(chǔ)和容錯(cuò)處理等方面對(duì)與網(wǎng)絡(luò)進(jìn)行協(xié)同工作的需求為基礎(chǔ)，分別以大數(shù)據(jù)處理、云存儲(chǔ)、大數(shù)據(jù)分析/處理任務(wù)調(diào)度和大數(shù)據(jù)處理中的容錯(cuò)處理這四個(gè)不同角度對(duì)與網(wǎng)絡(luò)進(jìn)行協(xié)同工作的需求為基礎(chǔ)，分析了大數(shù)據(jù)應(yīng)用下底層數(shù)據(jù)和網(wǎng)絡(luò)的相關(guān)問(wèn)題，為大數(shù)據(jù)框架中底層數(shù)據(jù)傳輸和網(wǎng)絡(luò)的優(yōu)化提供了研究基礎(chǔ)。

參考文獻(xiàn)

[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.