關(guān)于大數(shù)據(jù)框架中底層數(shù)據(jù)傳輸和網(wǎng)絡(luò)的分析與研究

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

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

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

中圖分類號：TP391 文獻標識碼：A 文章編號：2095-1302（2017）07-00-06

0 引 言

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

大數(shù)據(jù)環(huán)境已成熟，云計算中的大數(shù)據(jù)分析/處理，大數(shù)據(jù)處理與網(wǎng)絡(luò)/硬件的協(xié)同工作，大數(shù)據(jù)的私有性及云平臺的能耗等方面對網(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)用/用戶方便高效地訪問、調(diào)度網(wǎng)絡(luò)資源，減輕大數(shù)據(jù)應(yīng)用在網(wǎng)絡(luò)訪問決策上的負擔是當前大數(shù)據(jù)應(yīng)用研究中的熱點問題。

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

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

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

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

圖1 云計算核心組成邏輯圖

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

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

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

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

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

2 開放式協(xié)同平臺的中介——SDN

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

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

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

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

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

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

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

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

3 存在問題及分析

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

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

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

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

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

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

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

圖3 MapReduce計算過程示意圖

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

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

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

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

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

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

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

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

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

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

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

3.2 從云存儲的角度分析

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

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

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

（1）硬件故障/錯誤及副本策略

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

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

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

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

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

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

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

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

HDFS能夠在集群機器上可靠地存儲超大文件，其將文件分割成若干“塊”，除了最后一個，所有“塊”大小一致。為了容錯，文件的所有數(shù)據(jù)塊都有副本。每個文件的數(shù)據(jù)塊大小和副本系數(shù)都可配置，應(yīng)用程序可以指定某個文件的副本數(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ā)生在同機架的不同存儲節(jié)點之間及不同機架的不同存儲節(jié)點之間，這個過程必然依靠網(wǎng)絡(luò)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié) 語

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

參考文獻

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