趙晟　姜進磊

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

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

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

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

問題與挑戰(zhàn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 框架比較

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

5 結(jié)束語

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

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

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

參考文獻

[1] 孟小峰， 慈祥. 大數(shù)據(jù)管理： 概念， 技術(shù)與挑戰(zhàn)[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