趙晟　姜進(jìn)磊

摘要：認(rèn)為大數(shù)據(jù)計(jì)算技術(shù)已逐漸形成了批量計(jì)算和流計(jì)算兩個(gè)技術(shù)發(fā)展方向。批量計(jì)算技術(shù)主要針對(duì)靜態(tài)數(shù)據(jù)的離線計(jì)算，吞吐量好，但是不能保證實(shí)時(shí)性；流計(jì)算技術(shù)主要針對(duì)動(dòng)態(tài)數(shù)據(jù)的在線實(shí)時(shí)計(jì)算，時(shí)效性好，但是難以獲取數(shù)據(jù)全貌。從可擴(kuò)展性、容錯(cuò)性、任務(wù)調(diào)度、資源利用率、時(shí)效性、輸入輸出（IO）等方面對(duì)現(xiàn)有的主流大數(shù)據(jù)計(jì)算框架進(jìn)行了分析與總結(jié)，指出了未來的發(fā)展方向和研究熱點(diǎn)。

關(guān)鍵詞：大數(shù)據(jù)分類；大數(shù)據(jù)計(jì)算；批量計(jì)算；流計(jì)算；計(jì)算框架

Abstract：Big data computing technologies have two typical processing modes： batch computing and stream computing. Batch computing is mainly used for high-throughput processing of static data and does not produce results in real time. Stream computing is used for processing dynamic data online in real time but has difficulty providing a full view of data. In this paper， we analyze some typical big data computing frameworks from the perspective of scalability， fault-tolerance， task scheduling， resource utilization， real time guarantee， and input/output （IO） overhead. We then points out some future trends and hot research topics.

Key words：big data； big data computing； batch computing； stream computing； computing framework

近年來，隨著互聯(lián)網(wǎng)進(jìn)入Web 2.0時(shí)代以及物聯(lián)網(wǎng)和云計(jì)算的迅猛發(fā)展，人類社會(huì)逐漸步入了大數(shù)據(jù)時(shí)代。根據(jù)維基百科的描述，所謂的大數(shù)據(jù)，是指所涉及的數(shù)據(jù)量規(guī)模巨大，無法通過人工在合理時(shí)間內(nèi)達(dá)到截取、管理、處理、并整理成為人類所能解讀的信息。大數(shù)據(jù)在帶來發(fā)展機(jī)遇的同時(shí)，也帶來了新的挑戰(zhàn)，催生了新技術(shù)的發(fā)展和舊技術(shù)的革新。例如，不斷增長的數(shù)據(jù)規(guī)模和數(shù)據(jù)的動(dòng)態(tài)快速產(chǎn)生要求必須采用分布式計(jì)算框架才能實(shí)現(xiàn)與之相匹配的吞吐和實(shí)時(shí)性，而數(shù)據(jù)的持久化保存也離不開分布式存儲(chǔ)。

圖1展示了大數(shù)據(jù)應(yīng)用的一般架構(gòu)，其中的核心部分就是大數(shù)據(jù)計(jì)算框架和大數(shù)據(jù)存儲(chǔ)。大數(shù)據(jù)存儲(chǔ)提供可靠的數(shù)據(jù)存儲(chǔ)服務(wù)，在此之上搭建高效、可擴(kuò)展、可自動(dòng)進(jìn)行錯(cuò)誤恢復(fù)的分布式大數(shù)據(jù)計(jì)算框架，計(jì)算依賴存儲(chǔ)，兩者共同構(gòu)成數(shù)據(jù)處理的核心服務(wù)。由于文獻(xiàn)[1]已經(jīng)對(duì)大數(shù)據(jù)存儲(chǔ)進(jìn)行總結(jié)，詳述了文件系統(tǒng)、數(shù)據(jù)庫系統(tǒng)、索引技術(shù)，因此文中將重點(diǎn)對(duì)大數(shù)據(jù)計(jì)算框架進(jìn)行分析。

1 大數(shù)據(jù)計(jì)算技術(shù)面臨的

問題與挑戰(zhàn)

大數(shù)據(jù)計(jì)算技術(shù)采用分布式計(jì)算框架來完成大數(shù)據(jù)的處理和分析任務(wù)。作為分布式計(jì)算框架，不僅要提供高效的計(jì)算模型、簡單的編程接口，還要考慮可擴(kuò)展性和容錯(cuò)能力。作為大數(shù)據(jù)處理的框架，需要有高效可靠的輸入輸出（IO），滿足數(shù)據(jù)實(shí)時(shí)處理的需求。當(dāng)前大數(shù)據(jù)處理需要解決如下問題和挑戰(zhàn)，這些問題和挑戰(zhàn)也是對(duì)大數(shù)據(jù)計(jì)算框架進(jìn)行分析的重要指標(biāo)。

（1）可擴(kuò)展性：計(jì)算框架的可擴(kuò)展性決定可計(jì)算規(guī)模，計(jì)算并發(fā)度等指標(biāo)?，F(xiàn)有計(jì)算框架通常采用主從模式的架構(gòu)設(shè)計(jì)，便于集群的管理和任務(wù)調(diào)度，但主節(jié)點(diǎn)會(huì)成為系統(tǒng)的性能瓶頸，限制了可擴(kuò)展性。另外，在現(xiàn)有彈性計(jì)算集群部署中，不斷動(dòng)態(tài)添加、刪除計(jì)算節(jié)點(diǎn)，快速平衡負(fù)載等也對(duì)系統(tǒng)可擴(kuò)展性提出挑戰(zhàn)。

（2）容錯(cuò)和自動(dòng)恢復(fù)：大數(shù)據(jù)計(jì)算框架需要考慮底層存儲(chǔ)系統(tǒng)的不可靠性，支持出現(xiàn)錯(cuò)誤后自動(dòng)恢復(fù)的能力。用戶不需要增加額外的代碼進(jìn)行快照等中間結(jié)果的備份，只需要編寫相應(yīng)的功能函數(shù)，就可以在有輸入的條件下得到預(yù)期的輸出，中間運(yùn)行時(shí)產(chǎn)生的錯(cuò)誤對(duì)使用人員透明，由計(jì)算框架負(fù)責(zé)任務(wù)重做。

（3）任務(wù)調(diào)度模型：大數(shù)據(jù)計(jì)算平臺(tái)中往往存在多租戶共同使用，多任務(wù)共同執(zhí)行的情況。既要保證各用戶之間使用計(jì)算資源的公平性，又要保證整個(gè)系統(tǒng)合理利用資源，保持高吞吐率，還要保證調(diào)度算法足夠簡單高效，額外開銷小。因此調(diào)度器設(shè)計(jì)需要綜合大量真實(shí)的任務(wù)運(yùn)行結(jié)果，從全局的角度進(jìn)行設(shè)計(jì)。

（4）計(jì)算資源的利用率：計(jì)算資源的利用率代表機(jī)器能夠?qū)嶋H創(chuàng)造的價(jià)值。數(shù)據(jù)中心運(yùn)轉(zhuǎn)時(shí)，能耗問題非常突出，設(shè)備和制冷系統(tǒng)都在消耗能源。由于不合理的架構(gòu)設(shè)計(jì)，導(dǎo)致集群中非計(jì)算開銷大，計(jì)算出現(xiàn)忙等待的現(xiàn)象時(shí)有發(fā)生。高效的計(jì)算框架需要和硬件環(huán)境共同作用達(dá)到更高的計(jì)算資源利用率。

（5）時(shí)效性：數(shù)據(jù)的價(jià)值往往存在時(shí)效性，隨著時(shí)間的推移，新數(shù)據(jù)不斷產(chǎn)生，舊數(shù)據(jù)的利用價(jià)值就會(huì)降低。離線批量處理往往導(dǎo)致運(yùn)算的時(shí)間長，達(dá)不到實(shí)時(shí)的數(shù)據(jù)處理。流計(jì)算方案減少了響應(yīng)的時(shí)間，但是不能夠獲得數(shù)據(jù)的全貌。因此增量計(jì)算的方法是當(dāng)今的一個(gè)解決思路。

（6）高效可靠的IO：大數(shù)據(jù)計(jì)算中，IO開銷主要分為兩部分，序列化反序列化時(shí)數(shù)據(jù)在硬盤上讀寫的IO開銷，不同節(jié)點(diǎn)間交換數(shù)據(jù)的網(wǎng)絡(luò)IO開銷。由于硬盤和網(wǎng)絡(luò)的IO讀寫速率遠(yuǎn)遠(yuǎn)低于內(nèi)存的讀寫速率，導(dǎo)致整個(gè)任務(wù)的執(zhí)行效率降低，計(jì)算資源被浪費(fèi)。在現(xiàn)有的計(jì)算機(jī)體系結(jié)構(gòu)下，盡可能使用內(nèi)存能夠有效提高處理的速度，但是預(yù)取算法的合理性和內(nèi)存的不可靠性都是需要考慮的問題。

2 大數(shù)據(jù)批量計(jì)算技術(shù)

大數(shù)據(jù)批量計(jì)算技術(shù)應(yīng)用于靜態(tài)數(shù)據(jù)的離線計(jì)算和處理，框架設(shè)計(jì)初衷是為了解決大規(guī)模、非實(shí)時(shí)數(shù)據(jù)計(jì)算，更加關(guān)注整個(gè)計(jì)算框架的吞吐量。MapReduce低成本、高可靠性、高可擴(kuò)展的特點(diǎn)降低了大數(shù)據(jù)計(jì)算分析的門檻，自Google提出以來，得到了廣泛應(yīng)用。在此基礎(chǔ)上，人們?cè)O(shè)計(jì)出眾多的批處理計(jì)算框架，從編程模型、存儲(chǔ)介質(zhì)等角度不斷提高批處理的性能，使其適應(yīng)更多的應(yīng)用場(chǎng)景。

（1）MapReduce計(jì)算框架：MapReduce計(jì)算框架通過提供簡單的編程接口，在大規(guī)模廉價(jià)的服務(wù)器上搭建起一個(gè)計(jì)算和IO處理能力強(qiáng)大的框架，并行度高，容錯(cuò)性好，其開源項(xiàng)目Hadoop已經(jīng)形成完整的大數(shù)據(jù)分析生態(tài)系統(tǒng)，并在不斷改進(jìn)?？蓴U(kuò)展性方面，通過引入新的資源管理框架YARN，減輕主節(jié)點(diǎn)的負(fù)載，集群規(guī)模提高，資源管理更加有效。任務(wù)調(diào)度方面，提出如公平調(diào)度[2]、能力調(diào)度[3]、延遲調(diào)度[4]等調(diào)度器，更加關(guān)注數(shù)據(jù)中心內(nèi)資源使用的公平性、執(zhí)行環(huán)境的異構(gòu)性和高吞吐的目標(biāo)。另外也采用啟發(fā)式方法進(jìn)行預(yù)測(cè)調(diào)度，能夠?qū)崟r(shí)跟蹤節(jié)點(diǎn)負(fù)載變化，提供更優(yōu)的執(zhí)行序列和資源分配方案。容錯(cuò)性方面，MapReduce框架本身支持任務(wù)級(jí)容錯(cuò)，任務(wù)失敗后會(huì)重新計(jì)算，但是對(duì)于Master節(jié)點(diǎn)的容錯(cuò)一直忽略，現(xiàn)有的解決方法采用備份的方式解決，通過共享存儲(chǔ)同步數(shù)據(jù)，采用網(wǎng)絡(luò)文件系統(tǒng)（NFS）或者Zookeeper的方式來支持共享存儲(chǔ)。另外，MapReduce也已經(jīng)添加了多平臺(tái)支持，可以部署在圖像處理單元（GPU）等高性能計(jì)算環(huán)境中。

（2）Dryad計(jì)算框架：Dryad是構(gòu)建微軟云計(jì)算基礎(chǔ)設(shè)施的核心技術(shù)。編程模型相比于MapReduce更具一般性——用有向無環(huán)圖（DAG）描述任務(wù)的執(zhí)行，其中用戶指定的程序是DAG圖的節(jié)點(diǎn)，數(shù)據(jù)傳輸?shù)耐ǖ朗沁?，可通過文件、共享內(nèi)存或者傳輸控制協(xié)議（TCP）通道來傳遞數(shù)據(jù)，任務(wù)相當(dāng)于圖的生成器，可以合成任何圖，甚至在執(zhí)行的過程中這些圖也可以發(fā)生變化，以響應(yīng)計(jì)算過程中發(fā)生的事件。圖2給出了整個(gè)任務(wù)的處理流程。Dryad在容錯(cuò)方面支持良好，底層的數(shù)據(jù)存儲(chǔ)支持?jǐn)?shù)據(jù)備份；在任務(wù)調(diào)度方面，Dryad的適用性更廣，不僅適用于云計(jì)算，在多核和多處理器以及異構(gòu)集群上同樣有良好的性能；在擴(kuò)展性方面，可伸縮于各種規(guī)模的集群計(jì)算平臺(tái)，從單機(jī)多核計(jì)算機(jī)到由多臺(tái)計(jì)算機(jī)組成的集群，甚至擁有數(shù)千臺(tái)計(jì)算機(jī)的數(shù)據(jù)中心。Microsoft借助Dryad，在大數(shù)據(jù)處理方面也形成了完整的軟件棧，部署了分布式存儲(chǔ)系統(tǒng)Cosmos[5]，提供DryadLINQ編程語言，使普通程序員可以輕易進(jìn)行大規(guī)模的分布式計(jì)算。

（3）Spark計(jì)算框架：Spark是一種高效通用的分布式計(jì)算框架，采用基于DAG圖的編程模型，提供了豐富的編程接口。不同于MapReduce只能通過串聯(lián)多個(gè)任務(wù)實(shí)現(xiàn)復(fù)雜應(yīng)用，Spark可以在DAG圖中劃分不同的階段，完成復(fù)雜應(yīng)用的定義。在計(jì)算效率方面，Spark將結(jié)果以及重復(fù)使用的數(shù)據(jù)緩存在內(nèi)存中，減少了磁盤IO帶來的開銷，更適用于機(jī)器學(xué)習(xí)等需要迭代計(jì)算的算法；在容錯(cuò)性方面，Spark表現(xiàn)突出，數(shù)據(jù)以彈性分布式數(shù)據(jù)集（RDD）[6]的形式存在，依靠Lineage的支持（記錄RDD的演變），能夠以操作本地集合的方式來操作分布式數(shù)據(jù)集。當(dāng)RDD的部分分區(qū)數(shù)據(jù)丟失時(shí)，它可以通過Lineage獲取足夠的信息來重新運(yùn)算和恢復(fù)丟失的數(shù)據(jù)分區(qū)。通過記錄跟蹤所有RDD的轉(zhuǎn)換流程，可以保證Spark計(jì)算框架的容錯(cuò)性。資源管理及任務(wù)調(diào)度方面，Spark借助Mesos或者YARN來進(jìn)行集群資源的管理，部署在集群中使用。Spark發(fā)展至今，已經(jīng)形成了完整的軟件棧，在Spark的上層，已經(jīng)能夠支持可在分布式內(nèi)存中進(jìn)行快速數(shù)據(jù)分析的Shark[7]、流計(jì)算Spark Streaming、機(jī)器學(xué)習(xí)算法庫Mllib、面向圖計(jì)算的GraphX等。

（4）GraphLab計(jì)算框架：圖計(jì)算框架GraphLab的提出是為了解決大規(guī)模機(jī)器學(xué)習(xí)問題。相比于信息傳遞接口（MPI），GraphLab提供了更簡單的編程接口，抽象的圖模型使用戶不必關(guān)注進(jìn)程間的通信。相比于MapReduce計(jì)算框架，GraphLab更適合處理各數(shù)據(jù)之間依賴程度強(qiáng)、數(shù)據(jù)與數(shù)據(jù)之間需要頻繁計(jì)算和信息交互的場(chǎng)景。GraphLab提出的圖計(jì)算理論和方法不僅解決了集群中圖處理的擴(kuò)展問題，也解決了單機(jī)系統(tǒng)中大規(guī)模的圖計(jì)算問題，可形成完整的面向機(jī)器學(xué)習(xí)的并行計(jì)算框架。但是，對(duì)于大規(guī)模自然圖的處理，GraphLab仍然存在負(fù)載極不均衡、可擴(kuò)展性差等缺點(diǎn)，因而GraphLab團(tuán)隊(duì)進(jìn)一步提出了PowerGraph[8]。PowerGraph并行的核心思想是根據(jù)邊的規(guī)模對(duì)頂點(diǎn)進(jìn)行分割并部署在不同的機(jī)器上，由于不需要將同一個(gè)節(jié)點(diǎn)所對(duì)應(yīng)的所有邊的信息載入單機(jī)的內(nèi)存中，因而消除了單機(jī)內(nèi)存的約束。在系統(tǒng)的容錯(cuò)性方面，PowerGraph采用檢查點(diǎn)技術(shù)，未來也考慮使用節(jié)點(diǎn)的副本冗余來提高容錯(cuò)性，能夠在提高計(jì)算效率的同時(shí)完成快速恢復(fù)。

3 大數(shù)據(jù)流計(jì)算技術(shù)

大數(shù)據(jù)批量計(jì)算技術(shù)關(guān)注數(shù)據(jù)處理的吞吐量，而大數(shù)據(jù)流計(jì)算技術(shù)更關(guān)注數(shù)據(jù)處理的實(shí)時(shí)性，能夠更加快速地為決策提供支持。大數(shù)據(jù)的流計(jì)算技術(shù)是由復(fù)雜事件處理（CEP）發(fā)展而來的，現(xiàn)在流計(jì)算的典型框架包括Storm、S4、Samza、Spark Streaming等。

（1）Storm計(jì)算框架：Storm提供了可靠的流數(shù)據(jù)處理，可以用于實(shí)時(shí)分析、在線機(jī)器學(xué)習(xí)、分布式遠(yuǎn)程過程調(diào)用（RPC），數(shù)據(jù)抽取、轉(zhuǎn)換、加載（ETL）等。Storm運(yùn)行用戶自定義的拓?fù)洌煌贛apReduce作業(yè)，用戶拓?fù)溆肋h(yuǎn)運(yùn)行，只要有數(shù)據(jù)進(jìn)入就可以進(jìn)行相應(yīng)的處理。Storm采用主從架構(gòu)，如圖3所示，主節(jié)點(diǎn)中部署Nimbus，主要負(fù)責(zé)接收客戶端提交的拓?fù)洌M(jìn)行資源管理和任務(wù)分配。從節(jié)點(diǎn)上運(yùn)行監(jiān)控器，負(fù)責(zé)從節(jié)點(diǎn)上工作進(jìn)程也就是應(yīng)用邏輯的運(yùn)行?？蓴U(kuò)展性方面，Storm借助于Zookeeper很好地解決了可擴(kuò)展性的問題，集群非常容易進(jìn)行橫向擴(kuò)展，便于統(tǒng)一的配置、管理和監(jiān)控。容錯(cuò)性方面，使用 ZeroMQ 傳送消息，消除了中間的排隊(duì)過程，使得消息能夠直接在任務(wù)之間流動(dòng)，其注重容錯(cuò)和管理，實(shí)現(xiàn)了有保障的消息處理，保證每一個(gè)元組都會(huì)通過整個(gè)拓?fù)溥M(jìn)行處理，未處理的元組，它會(huì)自動(dòng)重放，再次進(jìn)行。Storm的缺點(diǎn)是：集群存在負(fù)載不均衡的情況；任務(wù)部署不夠靈活，不同的拓?fù)渲g不能相互通信，結(jié)果不能共用。

（2）S4計(jì)算框架：S4是Yahoo發(fā)布的開源流計(jì)算平臺(tái)，它是通用的、可擴(kuò)展性良好、具有分區(qū)容錯(cuò)能力、支持插件的分布式流計(jì)算平臺(tái)。S4采用分散對(duì)稱的架構(gòu)，沒有中心節(jié)點(diǎn)，計(jì)算框架更加易于部署和維護(hù)。在計(jì)算過程中，每個(gè)計(jì)算節(jié)點(diǎn)都在本地內(nèi)存中進(jìn)行處理，避免了IO給計(jì)算帶來的巨大瓶頸。S4的核心思想是將整個(gè)任務(wù)處理分為多個(gè)流事件，抽象成為一個(gè)DAG圖，每個(gè)事件對(duì)應(yīng)DAG圖中的一條有向邊，并用（K，A）的形式表示，其中K和A分別表示對(duì)應(yīng)事件的鍵和屬性。這種表示類似MapReduce中的鍵/價(jià)值設(shè)計(jì)，適合多個(gè)處理進(jìn)行連接。S4的結(jié)構(gòu)如圖4所示，它采用Zookeeper來管理集群，提高了集群的可擴(kuò)展性。在通信層，提供備用節(jié)點(diǎn)，如果有節(jié)點(diǎn)失敗，處理框架會(huì)自動(dòng)切換到備用節(jié)點(diǎn)，但是在內(nèi)存中的數(shù)據(jù)會(huì)發(fā)生丟失。主從備份雖然在一定程度上提高了容錯(cuò)能力，但是相對(duì)較弱。同時(shí)通信層還使用一個(gè)插件式的架構(gòu)來選擇網(wǎng)絡(luò)協(xié)議，通過TCP和用戶數(shù)據(jù)報(bào)協(xié)議（UDP）之間的權(quán)衡來提高網(wǎng)絡(luò)IO的速率。S4框架的主要缺點(diǎn)是：持久化相對(duì)簡單，數(shù)據(jù)存在丟失的風(fēng)險(xiǎn)；節(jié)點(diǎn)失敗切換到備份節(jié)點(diǎn)之后，任務(wù)都需要重做；缺乏自動(dòng)負(fù)載均衡的相關(guān)能力。

（3）Samza計(jì)算框架：Samza是Linkedin開源的分布式流處理框架，其架構(gòu)如圖5所示，由Kafka[9]提供底層數(shù)據(jù)流，由YARN提供資源管理、任務(wù)分配等功能。圖5也給出了Samza的作業(yè)處理流程，即Samza客戶端負(fù)責(zé)將任務(wù)提交給YARN的資源管理器，后者分配相應(yīng)的資源完成任務(wù)的執(zhí)行。在每個(gè)容器中運(yùn)行的流任務(wù)相對(duì)于Kafka是消息訂閱者，負(fù)責(zé)拉取消息并執(zhí)行相應(yīng)的邏輯。在可擴(kuò)展性方面，底層的Kafka通過Zookeeper實(shí)現(xiàn)了動(dòng)態(tài)的集群水平擴(kuò)展，可提供高吞吐、可水平擴(kuò)展的消息隊(duì)列，YARN為Samza提供了分布式的環(huán)境和執(zhí)行容器，因此也很容易擴(kuò)展；在容錯(cuò)性方面，如果服務(wù)器出現(xiàn)故障，Samza和YARN將一起進(jìn)行任務(wù)的遷移、重啟和重新執(zhí)行，YARN還能提供任務(wù)調(diào)度、執(zhí)行狀態(tài)監(jiān)控等功能；在數(shù)據(jù)可靠性方面，Samza按照Kafka中的消息分區(qū)進(jìn)行處理，分區(qū)內(nèi)保證消息有序，分區(qū)間并發(fā)執(zhí)行，Kafka將消息持久化到硬盤保證數(shù)據(jù)安全。另外，Samza還提供了對(duì)流數(shù)據(jù)狀態(tài)管理的支持。在需要記錄歷史數(shù)據(jù)的場(chǎng)景里，數(shù)據(jù)實(shí)時(shí)流動(dòng)導(dǎo)致狀態(tài)管理難以實(shí)現(xiàn)，為此，Samza提供了一個(gè)內(nèi)建的鍵/價(jià)值數(shù)據(jù)庫用來存儲(chǔ)歷史數(shù)據(jù)。

（4）Spark Streaming計(jì)算框架：Spark是當(dāng)前迭代式計(jì)算的典型代表，在前面的批量計(jì)算中已經(jīng)介紹了Spark在大數(shù)據(jù)計(jì)算、數(shù)據(jù)抽象和數(shù)據(jù)恢復(fù)等方面的成果。如今Spark也在向?qū)崟r(shí)計(jì)算領(lǐng)域發(fā)展，2013年發(fā)表于頂級(jí)會(huì)議SOSP上的論文介紹了Spark在流計(jì)算中取得的最新成果。Spark Streaming是建立在Spark上的應(yīng)用框架，利用Spark的底層框架作為其執(zhí)行基礎(chǔ)，并在其上構(gòu)建了DStream的行為抽象。利用DStream所提供的應(yīng)用程序編程接口（API），用戶可以在數(shù)據(jù)流上實(shí)時(shí)進(jìn)行count、join、aggregate等操作。Spark Streaming的原理是將流數(shù)據(jù)分成小的時(shí)間片斷，以類似批量處理的方式來處理這小部分?jǐn)?shù)據(jù)。DStream同時(shí)也是Spark Streaming容錯(cuò)性的一個(gè)重要保障。

4 框架比較

隨著數(shù)據(jù)的爆炸式增長，大數(shù)據(jù)計(jì)算平臺(tái)在數(shù)據(jù)分析和處理中扮演著越來越重要的角色。本文分析了現(xiàn)有大數(shù)據(jù)處理面臨的挑戰(zhàn)和問題，詳細(xì)分析了批處理和流處理相關(guān)計(jì)算框架的特點(diǎn)和重點(diǎn)解決的問題，結(jié)合存儲(chǔ)、應(yīng)用介紹了它們的核心創(chuàng)新點(diǎn)和軟件棧，這些框架的總結(jié)和對(duì)比如表1所示。

5 結(jié)束語

應(yīng)用推進(jìn)了技術(shù)的發(fā)展和革新，目前業(yè)界在不斷提高大數(shù)據(jù)計(jì)算框架的吞吐量、實(shí)時(shí)性、可擴(kuò)展性等特性以應(yīng)對(duì)日益增長的數(shù)據(jù)量和數(shù)據(jù)處理需求，大數(shù)據(jù)計(jì)算框架依然是現(xiàn)在以及未來一段時(shí)間內(nèi)的研究熱點(diǎn)。未來的發(fā)展趨勢(shì)是：隨著商業(yè)智能和計(jì)算廣告等領(lǐng)域的發(fā)展，更強(qiáng)調(diào)實(shí)時(shí)性的流計(jì)算框架將得到更加廣泛的關(guān)注；能夠縮短批量計(jì)算處理時(shí)間的Percolator[10]、Nectar[11]、Incoop[12]等增量計(jì)算模式將獲得進(jìn)一步的發(fā)展和應(yīng)用；批量計(jì)算和流計(jì)算模式將進(jìn)一步融合以減少框架維護(hù)開銷。而實(shí)際上，現(xiàn)在的Spark計(jì)算框架除了支持離線批處理任務(wù)以外，已經(jīng)能夠通過Spark Streaming支持在線的實(shí)時(shí)分析。

除了計(jì)算框架本身的改進(jìn)，消除磁盤IO和網(wǎng)絡(luò)IO對(duì)計(jì)算效率的影響也是重要的研究方向之一。這方面，內(nèi)存計(jì)算已經(jīng)取得了不錯(cuò)的應(yīng)用效果。例如，PACMan[13]用內(nèi)存緩存輸入數(shù)據(jù)，從而加速了MapReduce的執(zhí)行；文中提到的Spark也是盡可能將所有的數(shù)據(jù)放在內(nèi)存中，從而減少磁盤隨機(jī)讀寫的IO開銷，提高任務(wù)的執(zhí)行效率。由于內(nèi)存資源始終是寶貴的，難以滿足大數(shù)據(jù)的存儲(chǔ)需求，因此在很多情況下將仍然充當(dāng)緩存的角色，需要進(jìn)一步探究更為高效的緩存管理算法。另一方面，非易失性存儲(chǔ)（NVM）器件的發(fā)展將對(duì)計(jì)算機(jī)系統(tǒng)的存儲(chǔ)架構(gòu)帶來革命性的變化，如何充分利用新存儲(chǔ)介質(zhì)及其存儲(chǔ)架構(gòu)的特性提升計(jì)算效率也將是未來大數(shù)據(jù)計(jì)算框架研究的重要話題。

總之，應(yīng)用的推動(dòng)和技術(shù)的進(jìn)步將會(huì)產(chǎn)生新的問題。作為大數(shù)據(jù)應(yīng)用的核心，對(duì)于挖掘數(shù)據(jù)價(jià)值起著重要作用的計(jì)算框架將會(huì)面臨更多的挑戰(zhàn)，亟待解決。

參考文獻(xiàn)

[1] 孟小峰， 慈祥. 大數(shù)據(jù)管理： 概念， 技術(shù)與挑戰(zhàn)[J]. 計(jì)算機(jī)研究與發(fā)展， 2013， 50（1）： 146-169

[2] ZAGARIA M， BORTHAKUR D， SARMA J S， et al. Job Scheduling for Multi-User MapReduce Clusters [R]. USA： EECS Department， University of California， 2009

[3] Hadoop.[EB/OL].[2013-08-24]. http：//hadoop.apache.org/docs/r1.2.1/capacity_scheduler.html# Overview

[4] ZAHARIA M， KONWINSKI A， JOSEPH A D， et al. Improving MapReduce Performance in Heterogeneous Environments[C]// 8th USENIX Symposium on Operation Systems Design and Implementation（OSDI）. USA： ASM， 2008： 7

[5] CHAIKEN R， JENKINS B， LARSON P， et al. SCOPE： Easy and Efficient Parallel Processing of Massive Data Sets [J]. Proceedings of the VLDB Endowment， 2008， 1（2）： 1265-1276

[6] ZAHARIA M， CHOWDHURY M， DAS T， et al. Resilient Distributed Datasets： A Fault-Tolerant Abstraction for in-Memory Cluster Computing[C] //Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation. USA： USENIX Association， 2012： 2-2

[7] XIN R S， ROSEN J， ZAHARIA M， et al. Shark： SQL and Rich Analytics at Scale[C]//Proceedings of the 2013 ACM SIGMOD International Conference on Management of data. USA： ACM Press，2013： 13-24

[8] GONZALEZ J E， LOW Y， GU H， et al. PowerGraph： Distributed Graph-Parallel Computation on Natural Graphs[C]//Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation （OSDI）. USA： USENIX Association， 2012： 17-30

[9] KREPS J， NARKHEDE N， RAO J. Kafka： A Distributed Messaging System for Log Processing[C]//Proceedings of the 6th International Workshop on Networking Meets Databases （NetDB）. USA： ACM Press， 2011

[10] PENG D， DABEK F. Large-Scale Incremental Processing Using Distributed Transactions and Notifications[C]// Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation （OSDI）. USA： USENIX Association， 2010： 1-15

[11] GUNDA P K， RAVINDRANATH L， THEKKATH C A， et al. Nectar： Automatic Management of Data and Computation in Datacenters[C]// Proceedings of the 9th USENIX Symposium on Operating Systems Design and Implementation （OSDI）. USA： USENIX Association， 2010：75-88

[12] BHTOTIA P， WIDER A， RODRIGUES R， et al. Incoop： MapReduce for incremental computations[C]//Proceedings of the 2nd ACM Symposium on Cloud Computing. USA： ACM， 2011： 7

[13] ANANTHANARAYANAN G， GHODSI A， WANG A， et al. PACMan： Coordinated Memory Caching for Parallel Jobs[C]//9th USENIX Symposium on Networked Systems Design and Implementation（NSDI）. USA： USENIX Association， 2012