大數據流式計算：關鍵技術及系統實例

大數據流式計算：關鍵技術及系統實例

孫大爲 ¹ , 張廣豔 ^1,2 , 鄭緯民 ¹     

摘要：大數據計算主要有批量計算和流式計算兩種形態，目前，關於大數據批量計算系統的研究和討論相對充分，而如何構建低延遲、高吞吐且持續可靠運行的大數據流式計算系統是當前亟待解決的問題且研究成果和實踐經驗相對較少.總結了典型應用領域中流式大數據所呈現出的實時性、易失性、突發性、無序性、無限性等特徵，給出了理想的大數據流式計算系統在系統結構、數據傳輸、應用接口、高可用技術等方面應該具備的關鍵技術特徵，論述並對比了已有的大數據流式計算系統的典型實例，最後闡述了大數據流式計算系統在可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的技術挑戰.

關鍵詞： 大數據計算     流式計算     流式大數據     內存計算     系統實例    

Big Data Stream Computing：Technologies and Instances

SUN Da-Wei ¹ , ZHANG Guang-Yan ^1,2 , ZHENG Wei-Min ¹     

Abstract: Batch computing and stream computing are two important forms of big data computing. The research and discussions on batch computing in big data environment are comparatively sufficient. But how to efficiently deal with stream computing to meet many requirements, such as low latency, high throughput and continuously reliable running, and how to build efficient stream big data computing systems, are great challenges in the big data computing research. This paper provides a research of the data computing architecture and the key issues in stream computing in big data environments. Firstly, the research gives a brief summary of three application scenarios of stream computing in business intelligence, marketing and public service. It also shows distinctive features of the stream computing in big data environment, such as real time, volatility, burstiness, irregularity and infinity. A well-designed stream computing system always optimizes in system structure, data transmission, application interfaces, high-availability, and so on. Subsequently, the research offers detailed analyses and comparisons of five typical and open-source stream computing systems in big data environment. Finally, the research specifically addresses some new challenges of the stream big data systems, such as scalability, fault tolerance, consistency, load balancing and throughput.

Key words: big data computing     stream computing     stream big data     memory computing     system instance    

雲計算、物聯網、移動互連、社交媒體等新興信息技術和應用模式的快速發展,促使全球數據量急劇增長,推進人類社會邁入大數據時代^{[1，2，3，4]}.通常意義上,大數據是指利用現有理論、方法、技術和工具難以在可接受的時間內完成分析計算、總體呈現高價值的海量複雜數據集合.大數據呈現出多種鮮明特徵^{[3, 4, 5, 6, 7]}:

· 在數據量方面,當前,全球所擁有的數據總量已經遠遠超過歷史上的任什麼時候期,更爲重要的是,數據量的增長速度呈現出倍增趨勢,而且每一個應用所計算的數據量也大幅增長;

· 在數據速率方面,數據的產生、傳播的速度更快,在不一樣時空中流轉,呈現出鮮明的流式特徵,更爲重要的是,數據價值的有效時間急劇減小,也要求愈來愈高的數據計算和使用能力;

· 在數據複雜性方面,數據種類繁多,數據在編碼方式、存儲格式、應用特徵等多個方面也存在多層次、多方面的差別性,結構化、半結構化、非結構化數據並存,而且半結構化、非結構化數據所佔的比例不斷增長;

· 在數據價值方面,數據規模增大到必定程度以後,隱含於數據中的知識的價值也隨之增大,並將更多地推進社會的發展和科技的進步.此外,大數據每每還呈現出個性化、不完備化、價值稀疏、交叉複用等特徵.

大數據蘊含大信息,大信息提煉大知識,大知識將在更高的層面、更廣的視角、更大的範圍幫助用戶提升洞察力、提高決策力,將爲人類社會創造史無前例的重大價值.但與此同時,這些總量極大的價值每每隱藏在大數據中,表現出了價值密度極低、分佈極其不規律、信息隱藏程度極深、發現有用價值極其困難的鮮明特徵.這些特徵必然爲大數據的計算環節帶來史無前例的挑戰和機遇,並要求大數據計算系統具有高性能、實時性、分佈式、易用性、可擴展性等特徵.

大數據價值的有效實現離不開A,B,C這三大要素,即,大分析(big Analytic)、大帶寬(big Bandwidth)和大內容(big Content).其中,

(1) 大分析.經過創新性的數據分析方法實現對大量數據的快速、高效、及時的分析與計算,得出跨數據間的、隱含於數據中的規律、關係和內在邏輯,幫助用戶理清事件背後的緣由、預測發展趨勢、獲取新價值;

(2) 大帶寬.經過大帶寬提供良好的基礎設施,以便在更大範圍內進行數據的收集,以更快的速度進行數據的傳輸,爲大數據的分析、計算等環節提供時間和數據量方面的基本保障;

(3) 大內容.只有在數據內容足夠豐富、數據量足夠大的前提下,隱含於大數據中的規律、特徵才能被識別出來.

因而可知,大分析是實現途徑,大帶寬是基本保障,大內容是前提條件.

大數據的計算模式^{[7, 8, 9, 10]}能夠分爲批量計算(batch computing)和流式計算(stream computing)兩種形態:

· 如圖 1所示,批量計算首先進行數據的存儲,而後再對存儲的靜態數據進行集中計算.Hadoop是典型的大數據批量計算架構,由HDFS分佈式文件系統負責靜態數據的存儲,並經過MapReduce將計算邏輯分配到各數據節點進行數據計算和價值發現;

Fig. 1 Big data batch computing圖 1 大數據批量計算

· 如圖 2所示,流式計算中,沒法肯定數據的到來時刻和到來順序,也沒法將所有數據存儲起來.所以,再也不進行流式數據的存儲,而是當流動的數據到來後在內存中直接進行數據的實時計算.如Twitter的Storm、Yahoo的S4就是典型的流式數據計算架構,數據在任務拓撲中被計算,並輸出有價值的信息.

Fig. 2 Big data stream computing圖 2 大數據流式計算

流式計算和批量計算分別適用於不一樣的大數據應用場景:對於先存儲後計算,實時性要求不高,同時,數據的準確性、全面性更爲重要的應用場景,批量計算模式更合適;對於無需先存儲,能夠直接進行數據計算,實時性要求很嚴格,但數據的精確度要求稍微寬鬆的應用場景,流式計算具備明顯優點.流式計算中,數據每每是最近一個時間窗口內的,所以數據延遲每每較短,實時性較強,但數據的精確程度每每較低.流式計算和批量計算具備明顯的優劣互補特徵,在多種應用場合下能夠將二者結合起來使用.經過發揮流式計算的實時性優點和批量計算的計算精度優點,知足多種應用場景在不一樣階段的數據計算要求.

目前,關於大數據批量計算相關技術的研究相對成熟^{[3, 4, 5, 6, 7, 8, 9, 10]},造成了以Google的MapReduce編程模型、開源的Hadoop計算系統爲表明的高效、穩定的批量計算系統,在理論上和實踐中均取得了顯著成果^[7, 11].關於流式計算的早期研究每每集中在數據庫環境中開展數據計算的流式化,數據規模較小,數據對象比較單一.因爲新時期的流式大數據呈現出實時性、易失性、突發性、無序性、無限性等特徵,對系統提出了不少新的更高的要求.2010年,Yahoo推出S4流式計算系統,2011年,Twitter推出Storm流式計算系統,在必定程度上推進了大數據流式計算技術的發展和應用.可是,這些系統在可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等諸多方面仍然存在着明顯不足.如何構建低延遲、高吞吐且持續可靠運行的大數據流式計算系統,是當前亟待解決的問題.

本文以大數據流式計算系統的設計、優化和挑戰爲核心,系統地梳理和分析了當前大數據流式計算系統的研究和發展示狀,總結了在金融銀行業應用、互聯網應用和物聯網應用這三大典型領域中,流式大數據所呈現出的實時性、易失性、突發性、無序性、無限性等特徵.給出了理想的大數據流式計算系統在系統結構、數據傳輸、應用接口、高可用技術等方面應該具備的關鍵技術特性,論述並對比了5款大數據流式計算系統,即, Twitter的Storm系統、Yahoo的S4系統、Facebook的Data Freeway and Puma系統、Linkedin的Kafka系統、Microsoft的TimeStream系統.闡述了大數據流式計算系統在可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的技術挑戰.本文工做爲構建低延遲、高吞吐且持續可靠運行的大數據流式計算系統提供了一些指導性原則,彌補了當前關於大數據流式計算的研究成果不足的局面.

本文第1節分析大數據流式計算的典型應用領域及其特徵.第2節論述設計優良的大數據流式計算系統在系統結構、數據傳輸、應用接口、高可用技術等方面應該知足的關鍵技術要求.第3節分析對比5款比較典型的大數據流式計算系統.第4節具體闡述大數據流式計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的新的挑戰.最後,第5節對全文進行總結.

1 應用場景及數據特徵

大數據流式計算主要用於對動態產生的數據進行實時計算並及時反饋結果,但每每不要求結果絕對精確的應用場景.在數據的有效時間內獲取其價值,是大數據流式計算系統的首要設計目標,所以,當數據到來後將當即對其進行計算,而再也不對其進行緩存等待後續所有數據到來再進行計算.

1.1 應用場景

大數據流式計算的應用場景較多^{[12, 13, 14, 15, 16, 17]},本文按照數據產生方式、數據規模大小以及技術成熟度高低這3個不一樣維度,選擇金融銀行業應用、互聯網應用和物聯網應用這3種典型應用場景,用於分析說明大數據流式計算的基本特徵.從數據產生方式上看,它們分別是被動產生數據、主動產生數據和自動產生數據;從數據規模上看,它們處理的數據分別是小規模、中規模和大規模;從技術成熟度上看,它們分別是成熟度高、成熟度中和成熟度低的數據.

(1) 金融銀行業的應用

在金融銀行領域的平常運營過程當中,每每會產生大量數據,這些數據的時效性每每較短.所以,金融銀行領域是大數據流式計算最典型的應用場景之一,也是大數據流式計算最先的應用領域.在金融銀行系統內部,每時每刻都有大量的每每是結構化的數據在各個系統間流動,並須要實時計算.同時,金融銀行系統與其餘系統也有着大量的數據流動,這些數據不只有結構化數據,也會有半結構化和非結構化數據.經過對這些大數據的流式計算,發現隱含於其中的內在特徵,能夠幫助金融銀行系統進行實時決策.

在金融銀行的實時監控場景中,大數據流式計算每每體現出了自身的優點.如:

· 風險管理.包括信用卡詐騙、保險詐騙、證券交易詐騙、程序交易等,須要實時跟蹤發現;

· 營銷管理.如,根據客戶信用卡消費記錄,掌握客戶的消費習慣和偏好,預測客戶將來的消費需求,併爲其推薦個性化的金融產品和服務;

· 商業智能.如,掌握金融銀行系統內部各系統的實時數據,實現對全局狀態的監控和優化,並提供決策支持.

(2) 互聯網領域的應用

隨着互聯網技術的不斷髮展,特別是Web 2.0時代的到來,用戶能夠實時分享和提供各種數據.不只使得數據量大爲增長,也使得數據更多地以半結構化和非結構化的形態呈現.據統計,目前互聯網中75%的數據來源於我的,主要以圖片、音頻、視頻數據形式存在,須要實時分析和計算這些大量、動態的數據.

在互聯網領域中,大數據流式計算的典型應用場景包括:

· 搜索引擎.搜索引擎提供商們每每會在反饋給客戶的搜索頁面中加入點擊付費的廣告信息.插入什麼廣告、在什麼位置插入這些廣告才能獲得最佳效果,每每須要根據客戶的查詢偏好、瀏覽歷史、地理位置等綜合語義進行決定.而這種計算對於搜索服務器而言每每是大量的:一方面,每時每刻都會有大量客戶進行搜索請求;另外一方面,數據計算的時效性極低,須要保證極短的響應時間;

· 社交網站.須要實時分析用戶的狀態信息,及時提供最新的用戶分享信息到相關的朋友,準確地推薦朋友,推薦主題,提高用戶體驗,並能及時發現和屏蔽各類欺騙行爲.

(3) 物聯網領域的應用

在物聯網環境中,各個傳感器產生大量數據.這些數據一般包含時間、位置、環境和行爲等內容,具備明顯的顆粒性.因爲傳感器的多元化、差別化以及環境的多樣化,這些數據呈現出鮮明的異構性、多樣性、非結構化、有噪聲、高增加率等特徵.所產生的數據量之密集、實時性之強、價值密度之低是史無前例的,須要進行實時、高效的計算.

在物聯網領域中,大數據流式計算的典型應用場景包括:

· 智能交通.經過傳感器實時感知車輛、道路的狀態,並分析和預測必定範圍、一段時間內的道路流量狀況,以便有效地進行分流、調度和指揮;

· 環境監控.經過傳感器和移動終端,對一個地區的環境綜合指標進行實時監控、遠程查看、智能聯動、遠程控制,系統地解決綜合環境問題.

這些對計算系統的實時性、吞吐量、可靠性等方面都提出很高要求.

大數據流式計算的3種典型應用場景的對比見表 1.

Table 1 Scenarios contrast of stream computing of big data表 1 大數據流式計算應用場景對比

· 從數據的產生方式看,金融銀行領域的數據每每是在系統中被動產生的,互聯網領域的數據每每是人爲主動產生的,物聯網領域的數據每每是由傳感器等設備自動產生的;

· 從數據的規模來看:金融銀行領域的數據與互聯網、物聯網領域的數據相比較少;物聯網領域的數據規模是最大的,但受制於物聯網的發展階段,當前實際擁有數據規模最大的是互聯網領域;

· 從技術成熟度來看:金融銀行領域的流式大數據應用最爲成熟,從早期的復瑣事件處理^[18, 19]開始就呈現了大數據流式計算的思想;互聯網領域的發展,將大數據流式計算真正推向歷史舞臺;物聯網領域的發展爲大數據流式計算提供了重要的歷史機遇.

1.2 流式大數據特徵

圖 3用有向無環圖(directed acyclic graph,簡稱DAG)描述了大數據流的計算過程,其中,圓形表示數據的計算節點,箭頭表示數據的流動方向.

Fig. 3 irected acyclic graph圖 3 有向無環圖

與大數據批量計算不一樣,大數據流式計算中的數據流主要體現了以下5個特徵^{[11, 20, 21]}:

 

(1) 實時性

流式大數據是實時產生、實時計算,結果反饋每每也須要保證及時性.流式大數據價值的有效時間每每較短,大部分數據到來後直接在內存中進行計算並丟棄,只有少許數據才被長久保存到硬盤中.這就須要系統有足夠的低延遲計算能力,能夠快速地進行數據計算,在數據價值有效的時間內,體現數據的有用性.對於時效性特別短、潛在價值又很大的數據能夠優先計算.

(2) 易失性

在大數據流式計算環境中,數據流每每是到達後當即被計算並使用,只有極少數的數據纔會被持久化地保存下來,大多數數據每每會被直接丟棄.數據的使用每每是一次性的、易失的,即便重放,獲得的數據流和以前的數據流每每也是不一樣的.這就須要系統具備必定的容錯能力,要充分地利用好僅有的一次數據計算機會,儘量全面、準確、有效地從數據流中得出有價值的信息.

(3) 突發性

在大數據流式計算環境中,數據的產生徹底由數據源肯定,因爲不一樣的數據源在不一樣時空範圍內的狀態不統一且發生動態變化,致使數據流的速率呈現出了突發性的特徵.前一時刻數據速率和後一時刻數據速率可能會有巨大的差別,這就須要系統具備很好的可伸縮性,可以動態適應不肯定流入的數據流,具備很強的系統計算能力和大數據流量動態匹配的能力.一方面,在突發高數據流速的狀況下,保證不丟棄數據,或者識別並選擇性地丟棄部分不重要的數據;另外一方面,在低數據速率的狀況下,保證不會過久或過多地佔用系統資源.

(4) 無序性

在大數據流式計算環境中,各數據流之間、同一數據流內部各數據元素之間是無序的:一方面,因爲各個數據源之間是相互獨立的,所處的時空環境也不盡相同,所以沒法保證數據流間的各個數據元素的相對順序;另外一方面,即便是同一個數據流,因爲時間和環境的動態變化,也沒法保證重放數據流和以前數據流中數據元素順序的一致性.這就須要系統在數據計算過程當中具備很好的數據分析和發現規律的能力,不能過多地依賴數據流間的內在邏輯或者數據流內部的內在邏輯.

(5) 無限性

在大數據流式計算中,數據是實時產生、動態增長的,只要數據源處於活動狀態,數據就會一直產生和持續增長下去.能夠說,潛在的數據量是無限的,沒法用一個具體肯定的數據實現對其進行量化.系統在數據計算過程當中,沒法保存所有數據:一方面,硬件中沒有足夠大的空間來存儲這些無限增加的數據;另外一方面,也沒有合適的軟件來有效地管理這麼多數據;而且,須要系統具備很好的穩定性,保證系統長期而穩定地運行.

表 2對比了大數據流式計算和大數據批量計算的需求.

Table 2 Scenario contrast between stream and batch big data表 2 大數據流式、批量需求對比

2 大數據流式計算關鍵技術

針對具備實時性、易失性、突發性、無序性、無限性等特徵的流式大數據,理想的大數據流式計算系統應該表現出低延遲、高吞吐、持續穩定運行和彈性可伸縮等特性,這其中離不開系統架構、數據傳輸、編程接口、高可用技術等關鍵技術的合理規劃和良好設計.

2.1 系統架構

系統架構是系統中各子系統間的組合方式,屬於大數據計算所共有的關鍵技術,大數據流式計算須要選擇特定的系統架構進行流式計算任務的部署.當前,大數據流式計算系統採用的系統架構^{[22, 23, 24]}能夠分爲無中心節點的對稱式系統架構(如S4,Puma等系統)以及有中心節點的主從式架構(如Storm系統):

(1) 對稱式架構.如圖 4所示:系統中各個節點的功能是相同的,具備良好的可伸縮性;但因爲不存在中心節點,在資源調度、系統容錯、負載均衡等方面須要經過分佈式協議實現.例如,S4經過Zookeeper實現系統容錯、負載均衡等功能;

Fig. 4 Symmetric architecture圖 4 對稱式架構

(2) 主從式系統架構.如圖 5所示:系統存在一個主節點和多個從節點,主節點負責系統資源的管理和任務的協調,並完成系統容錯、負載均衡等方面的工做;從節點負責接收來自於主節點的任務,並在計算完成後進行反饋.各個從節點間沒有數據往來,整個系統的運行徹底依賴於主節點控制.

Fig. 5 Master-Slave architecture圖 5 主從式架構

2.2 數據傳輸

數據傳輸是指完成有向任務圖到物理計算節點的部署以後,各個計算節點之間的數據傳輸方式.在大數據流式計算環境中,爲了實現高吞吐和低延遲,須要更加系統地優化有向任務圖以及有向任務圖到物理計算節點的映射方式.如圖 6所示,在大數據流式計算環境中,數據的傳輸方式分爲主動推送方式(基於push方式)和被動拉取方式(基於pull方式)^{[24, 25, 26]}:

Fig. 6 Transformation of data stream圖 6 數據流傳輸方式

(1) 主動推送方式.在上游節點產生或計算完數據後,主動將數據發送到相應的下游節點,其本質是讓相關數據主動尋找下游的計算節點,當下遊節點報告發生故障或負載太重時,將後續數據流推送到其餘相應節點.主動推送方式的優點在於數據計算的主動性和及時性,但因爲數據是主動推送到下游節點,每每不會過多地考慮到下游節點的負載狀態、工做狀態等因素,可能會致使下游部分節點負載不夠均衡;

(2) 被動拉取方式.只有下游節點顯式進行數據請求,上游節點纔會將數據傳輸到下游節點,其本質是讓相關數據被動地傳輸到下游計算節點.被動拉取方式的優點在於下游節點能夠根據自身的負載狀態、工做狀態適時地進行數據請求,但上游節點的數據可能未必獲得及時的計算.

大數據流式計算的實時性要求較高,數據須要獲得及時處理,每每選擇主動推送的數據傳輸方式.固然,主動推送方式和被動拉取方式不是徹底對立的,也能夠將二者進行融合,從而在必定程度上實現更好的效果.

2.3 編程接口

編程接口是方便用戶根據流式計算的任務特徵,經過有向任務圖來描述任務內在邏輯和依賴關係,並編程實現任務圖中各節點的處理功能.用戶策略的定製、業務流程的描述和具體應用的實現,須要經過大數據流式計算系統提供的應用編程接口.良好的應用編程接口能夠方便用戶實現業務邏輯,能夠減小用戶的編程工做量,並下降用戶系統功能的實現門檻^{[27, 28, 29]}.

當前,大多數開源大數據流式計算系統均提供了相似於MapReduce的類MR用戶編程接口.例如:Storm提供Spout和Bolt應用編程接口,用戶只須要定製Spout和Bolt的功能,並規定數據流在各個Bolt間的內在流向,明確數據流的有向無環圖,其餘具體細節的實現方式用戶不須要太多關心,便可知足對流式大數據的高效、實時計算;也有部分大數據流式計算系統爲用戶提供了類SQL的應用編程接口,並給出了相應的組件,便於應用功能的實現;StreamBase系統不只爲用戶提供了類SQL的應用編程接口來描述計算過程,也藉助圖形化用戶視窗爲用戶提供了豐富的組件.

2.4 高可用技術

大數據批量計算將數據事先存儲到持久設備上,節點失效後容易實現數據重放;而大數據流式計算對數據不進行持久化存儲.所以,批量計算中的高可用技術不徹底適用於流式計算環境,須要根據流式計算新特徵及其新的高可用要求,有針對性地研究更加輕量、高效的高可用技術和方法.

大數據流式計算系統高可用是經過狀態備份和故障恢復策略實現的.當故障發生後,系統根據預先定義的策略進行數據的重放和恢復.按照實現策略,能夠細分爲被動等待(passive standby)、主動等待(active standby)和上游備份(upstream backup)這3種策略^{[30, 31, 32, 33, 34]}:

(1) 被動等待策略

如圖 7所示:主節點B進行數據計算,副本節點B¢處於待命狀態,系統會按期地將主節點B上的最新的狀態備份到副本節點B¢上.出現故障時,系統從備份數據中進行狀態恢復.被動等待策略支持數據負載較高、吞吐量較大的場景,但故障恢復時間較長,能夠經過對備份數據的分佈式存儲縮短恢復時間.該方式更適合於精確式數據恢復,能夠很好地支持不肯定性計算應用,在當前流式數據計算中應用最爲普遍.

Fig. 7 Passive standby圖 7 被動等待策略

(2) 主動等待策略

如圖 8所示:系統在爲主節點B傳輸數據的同時,也爲副本節點B¢傳輸一份數據副本.以主節點B爲主進行數據計算,當主節點B出現故障時,副本節點B¢徹底接管主節點B的工做,主副節點須要分配一樣的系統資源.該種方式故障恢復時間最短,但數據吞吐量較小,也浪費了較多的系統資源.在廣域網環境中,系統負載每每不是過大時,主動等待策略是一個比較好的選擇,能夠在較短的時間內實現系統恢復.

Fig. 8 Active standby圖 8 主動等待策略

(3) 上游備份策略

如圖 9所示:每一個主節點均記錄其自身的狀態和輸出數據到日誌文件,當某個主節點B出現故障後,上游主節點會重放日誌文件中的數據到相應副本節點Bspan lang="EN-US" style='font-family:Symbol' xml:lang="EN-US">¢中,進行數據的從新計算.上游備份策略所佔用的系統資源最小,在無端障期間,因爲副本節點B¢保持空閒狀態,數據的執行效率很高.但因爲其須要較長的時間進行恢復狀態的重構,故障的恢復時間每每較長.如當須要恢復時間窗口爲30分鐘的聚類計算,就須要重放該30分鐘內的全部元組.可見,對於系統資源比較稀缺、算子狀態較少的狀況,上游備份策略是一個比較好的選擇方案.

Fig. 9 Upstream backup圖 9 上游備份策略

表 3從5個方面詳細對比了上述3種高可用策略,實際應用中能夠根據具體環境進行選擇.

Table 3 Contrast of three high availability strategies表 3 3種高可用策略對比

2.5 其餘關鍵技術

此外,大數據流式計算系統也離不開其餘相關關鍵技術的支持,包括:

· 系統故障恢復.快速地實現從故障狀態到一種正確狀態的恢復,知足系統的高效運行需求;

· 系統資源調度.實現對系統中資源的最佳利用,提升資源的利用率,保證任務的完成和能耗的節省;

· 負載均衡策略.實現對系統中的任務的動態、合理的分配,動態適應系統負載狀況,保證系統中的任務均衡和穩定地運行;

· 數據在任務拓撲中的路由策略.促進系統中負載均衡策略的高效實現、數據的合理流動及快速處理.

3 系統實例分析

現有的大數據流式計算系統實例有Twitter的Storm系統^[35]、Yahoo的S4(simple scalable streaming system)系統^[36]、Facebook的Data Freeway and Puma系統^[37]、Linkedin的Kafka系統^[38]、Microsoft的TimeStream系統^[39]、Hadoop之上的數據分析系統HStreaming^[40]、IBM的商業流式計算系統StreamBase^[41]、Berkeley的交互式實時計算系統Spark^[42] 、專門進行復瑣事件處理(complex event processing,簡稱CEP)的Esper^[43]系統等.本文選擇當前比較典型的、應用較爲普遍的、具備表明性的前5款大數據流式計算系統進行實例分析.

3.1Storm系統

Storm^{[35, 44, 45, 46]}是Twitter支持開發的一款分佈式的、開源的、實時的、主從式大數據流式計算系統,最新版本是Storm 0.8.2,使用的協議爲Eclipse Public License 1.0,其核心部分使用了高效流式計算的函數式語言Clojure編寫,極大地提升了系統性能.但爲了方便用戶使用,支持用戶使用任意編程語言進行項目的開發.

(1) 任務拓撲

任務拓撲(topology)是Storm的邏輯單元,一個實時應用的計算任務將被打包爲任務拓撲後發佈,任務拓撲一旦提交後將會一直運行着,除非顯式地去停止.一個任務拓撲是由一系列Spout和Bolt構成的有向無環圖,經過數據流(stream)實現Spout和Bolt之間的關聯,如圖 10所示.其中,Spout負責從外部數據源不間斷地讀取數據,並以Tuple元組的形式發送給相應的Bolt;Bolt負責對接收到的數據流進行計算,實現過濾、聚合、查詢等具體功能,能夠級聯,也能夠向外發送數據流.

Fig. 10 Task topology of storm圖 10 Storm任務拓撲

數據流是Storm對數據進行的抽象,它是時間上無窮的Tuple元組序列,如圖 11所示,數據流是經過流分組(stream grouping)所提供的不一樣策略實如今任務拓撲中流動.此外,爲了知足確保消息能且僅能被計算1次的需求,Storm還提供了事務任務拓撲.

Fig. 11 Data stream group of storm圖 11 Storm數據流組

(2) 做業級容錯機制

 

用戶能夠爲一個或多個數據流做業(如下簡稱數據流)進行編號,分配一個惟一的ID,Storm能夠保障每一個編號的數據流在任務拓撲中被徹底執行.所謂的徹底執行,是指由該ID綁定的源數據流以及由該源數據流後續生成的新數據流通過任務拓撲中每個應該到達的Bolt,並被徹底執行.如圖 12所示,兩個數據流被分配一個ID=1,當且僅當兩個數據流分別通過Bolt 1和Bolt 2,最終都到達Bolt 3並均被徹底處理後,才代表數據流被徹底執行.

Fig. 12 Fully implement of data stream task圖 12 數據流做業徹底執行

Storm經過系統級組件Acker實現對數據流的全局計算路徑的跟蹤,並保證該數據流被徹底執行.其基本原理是爲數據流中的每一個分組進行編號,並經過異或運算來實現對其計算路徑的跟蹤.

做業級容錯的基本原理是:

A xor A=0.

A xor B … xor B xor A=0,當且僅當每一個編號僅出現2次.

做業級容錯的基本流程是:在Spout中,系統會爲數據流的每一個分組生成一個惟一的64位整數,做爲該分組的根ID.根ID會被傳遞給Acker及後續的Bolt做爲該分組單元的惟一標識符.同時,不管是Spout仍是Bolt,每次新生成一個分組的時候,都會從新賦予該分組一個新的64位的整數的ID.Spout發送完某個數據流對應的源分組後,並告知Acker本身所發射分組的根ID及生成的那些分組的新ID,而Bolt每次接受到一個輸入分組並計算完以後,也將告知 Acker本身計算的輸入分組的ID及新生成的那些分組的ID,Acker只須要對這些ID作一個簡單的異或運算,就能判斷出該根ID對應的消息單元是否計算完成.

(3) 整體架構

Storm採用主從系統架構,如圖 13所示,在一個Storm系統中有兩類節點(即,一個主節點Nimbus、多個從節點Supervisor)及3種運行環境(即,master,cluster和slaves)構成,其中,

Fig. 13 Storm architecture圖 13 Storm系統架構

· 主節點Nimbus運行在master環境中,是無狀態的,負責全局的資源分配、任務調度、狀態監控和故障檢測:一方面,主節點Nimbus接收客戶端提交來的任務,驗證後分配任務到從節點Supervisor上,同時把該任務的元信息寫入Zookeeper目錄中;另外一方面,主節點Nimbus須要經過Zookeeper實時監控任務的執行狀況,當出現故障時進行故障檢測,並重啓失敗的從節點Supervisor和工做進程Worker;

· 從節點Supervisor運行在slaves環境中,也是無狀態的,負責監聽並接受來自於主節點Nimbus所分配的任務,並啓動或中止本身所管理的工做進程Worker,其中,工做進程Worker負責具體任務的執行.一個完整的任務拓撲每每由分佈在多個從節點Supervisor上的Worker進程來協調執行,每一個Worker都執行且僅執行任務拓撲中的一個子集.在每一個Worker內部,會有多個Executor,每一個Executor對應一個線程.Task負責具體數據的計算,即,用戶所實現的Spout/Blot實例.每一個Executor會對應一個或多個Task,所以,系統中Executor的數量老是小於等於Task的數量.

Zookeeper是一個針對大型分佈式系統的可靠協調服務和元數據存儲系統,經過配置Zookeeper集羣,可使用Zookeeper系統所提供的高可靠性服務.Storm系統引入Zookeeper,極大地簡化了Nimbus,Supervisor, Worker之間的設計,保障了系統的穩定性.Zookeeper在Storm系統中具體實現瞭如下功能:(a) 存儲客戶端提交的任務拓撲信息、任務分配信息、任務的執行狀態信息等,便於主節點Nimbus監控任務的執行狀況;(b) 存儲從節點Supervisor、工做進程Worker的狀態和心跳信息,便於主節點Nimbus監控系統各節點運行狀態;(c) 存儲整個集羣的全部狀態信息和配置信息,便於主節點 Nimbus監控Zookeeper集羣的狀態,在出現主Zookeeper節點掛掉後能夠從新選取一個節點做爲主Zookeeper節點,並進行恢復.

(4) 系統特徵

Storm系統的主要特徵爲:(a) 簡單編程模型.用戶只需編寫Spout和Bolt部分的實現,所以極大地下降了實時大數據流式計算的複雜性;(b) 支持多種編程語言.默認支持Clojure,Java,Ruby和Python,也能夠經過添加相關協議實現對新增語言的支持;(c) 做業級容錯性.能夠保證每一個數據流做業被徹底執行;(d) 水平可擴展.計算能夠在多個線程、進程和服務器之間併發執行;(e) 快速消息計算.經過ZeroMQ做爲其底層消息隊列,保證了消息可以獲得快速的計算.

(5) 存在不足

Storm系統存在的不足主要包括:資源分配沒有考慮任務拓撲的結構特徵,沒法適應數據負載的動態變化;採用集中式的做業級容錯機制,在必定程度上限制了系統的可擴展性.

3.2S4系統

S4^{[36, 46, 47, 48, 49]}是Yahoo支持開發的一款分佈式的、可擴展的、可插拔的、對稱的大數據流式計算系統,最新版本是S4 0.6.0,使用的協議爲Apache License 2.0,編程語言爲Java.

(1) 處理單元PE

處理單元PE(processing element)如圖 14所示,是S4中的基本計算單元,由4個組件構成,即:(a) 函數.實現了與該處理單元PE相對應的功能和配置;(b) 事件類型.規定了該處理單元PE所接收的事件類型;(c) 主鍵.規定了該處理單元PE所關心的事件主鍵;(d) 鍵值.規定了該處理單元PE所匹配的鍵值.

Fig. 14 Processing element PE圖 14 處理單元PE

處理單元PE只關心與其事件類型相匹配的事件,並僅僅處理與其主鍵、鍵值相一致的事件,即,只有事件類型、主鍵、鍵值所有匹配後,處理單元PE纔會處理該類事件.當一個新事件沒有能夠匹配的處理單元PE時,系統將會爲該事件新建立一個處理單元PE.所以,須要高效、動態地建立、管理和刪除處理單元PE;同時,處理單元PE的類型設計及其拓撲結構也須要更合理地規劃.

有一類處理單元PE位於S4的輸入層,它們沒有主鍵、鍵值,只需事件類型相匹配,即對該類事件進行處理.一般狀況下,該類處理單元PE所計算的事件爲原始輸入事件,其輸出事件會被新增主鍵、鍵值,以便後續處理單元PE進行計算.

(2) 任務拓撲結構

在S4系統中,數據流是由事件的有序序列(K,A)構成的,其中,K,A分別表示該類型事件的若干個key和若干個attribute,key和attribute都是tuple-valued,即,key=value的元組值.事件在各個處理單元PE中被計算,在處理單元PE之間流動,處理單元PE之間的邏輯構成了一個有向無環圖.

圖 15描述了一個統計Top K熱點單詞的實例.

Fig. 15 Task topology instance圖 15 任務拓撲實例

在圖 15所示的有向無環圖中,節點表示處理單元PE,實現對數據流的計算和新數據流的輸出,有向邊表示事件的有序序列(K,A)及其流向.在該實例中,實現了對於流式數據中的Top K熱點單詞的統計,其數據流的具體內容見表 4,其中,數據流1是初始化數據流,所以其主鍵值爲空,鍵值爲實時流入的文本數據,在處理單元PE1中被分割爲各個單詞,造成了新的數據流,其事件類型爲單詞統計,主鍵爲word=x,鍵值爲count=y,並分別分流處處理單元PE二、處理 單元PE三、處理單元PE4等節點中進行計算,並再次造成了新的數據流,其事件類型爲單詞數更新,主鍵爲SortID=x,鍵值爲word=y,count=z,並分別分流處處理單元PE五、處理單元PE六、處理單元PE7等節點中進行計算,最後在處理單元PE8中進行彙總和排序,得出當前的Top K個熱點單詞.

Table 4 CData stream content表 4 數據流內容

(3) 處理節點Pnode

在S4的處理節點Pnode中,如圖 16所示,由處理空間和傳輸空間組成,其中,

Fig. 16 Processing node PNode圖 16 處理節點PNode

· 在處理空間中,事件監聽系統主要用於監聽並分發接收到的事件計算請求,並由調度分配系統將事件分配處處理單元集PEC(processing element container)上進行計算,處理單元集PEC以適當的順序調用適當的處理單元PE,並保證每一個主鍵key的處理單元PE都會被映射到一個肯定的處理節點Pnode上.以後,處理節點Pnode或者發出輸出事件,或者向傳輸層請求協助,向指定邏輯節點發送消息.其中,處理單元集PEC由一個處理節點Pnode中內部的多個處理單元PE組成.處理單元PE是事件計算的最小單元,接受一個或多個來自於事件源或其餘處理單元PE的事件進行計算,以後,分發一個或多個計算後的事件到其餘處理單元PE或輸出結果.各個處理單元PE間相互獨立,它們之間經過事件構成關聯,事件在各處理單元PE間以數據流的形式進行傳輸;

· 在傳輸空間中,主要經過路由管理、負載均衡、集羣管理、容錯管理等實現對事件流的路由選擇、負載均衡、邏輯影射、故障恢復到備用節點等方面的管理和功能,並經過Zookeeper系統在S4集羣節點間實現一致性協做.S4經過插件式的架構來動態選擇信息傳輸協議,對於控制信息,一般採用可靠傳輸協議,如TCP,保障控制信息傳輸的可靠性.對於數據信息,一般採用不可靠傳輸協議,如UDP,保障數據信息的高吞吐量.

(4) 系統架構

S4採用了對等式系統架構,如圖 17所示.

Fig. 17 S4 architecture圖 17 S4系統結構

在一個S4系統中,由用戶空間、資源調度空間和S4處理節點空間組成,其中,在用戶空間中,多個用戶能夠經過本地的客戶端驅動實現服務的請求訪問;在資源調度空間中,爲用戶提供了客戶適配器,經過TCP/IP協議實現用戶的客戶端驅動與客戶適配器間的鏈接和通訊,多個用戶能夠併發地與多個客戶適配器進行服務請求;在S4處理節點空間中,提供了多個處理節點Pnode,進行用戶服務請求的計算.各個處理節點間保持相對的獨立性、對等性和高併發性,極大地提升了系統的性能,並經過Hash方式將事件路由到一個或多個目標處理節點Pnode上.

(5) 存在不足

S4系統存在的不足主要包括:當數據流到達速度超過必定界限時,到達速度越高,系統數據處理的錯誤率越大;不支持系統節點的熱插拔,全部對節點的調整都必須離線進行;僅支持部分容錯,即,節點失效轉移時會丟失原節點內存中的狀態信息.

3.3 Data Freeway and Puma 系統

Data Freeway and Puma^{[29,37,50,51,52,53]}是Facebook支持開發的一款基於Hive/Hadoop的、分佈式的、高效率的、數據傳輸通道和大數據流式計算系統.

(1) Data Freeway系統

Data Freeway是Facebook支持開發的一款可擴展數據流架構(scalable data stream framework),能夠有效地支持4種數據間的傳輸,即,文件到文件、文件到消息、消息到消息和消息到文件.其系統結構如圖 18所示,Data Freeway數據流架構由4個組件構成,即,Scribe,Calligraphus,Continuous Copier和PTail.Scribe組件位於用戶端,其功能是將用戶的數據經過RPC發送到服務器端;Calligraphus組件實現了對日誌類型的維護與管理,其功能是經過Zookeeper系統,將位於緩衝區中的數據併發寫到HDFS中;Continuous Copier組件的功能是實如今各個HDFS系統間進行文件的遷移;PTail組件實現了並行地將文件輸出.

Fig. 18 An example of database圖 18 Data Freeway系統架構

(2) Puma系統

Puma是Facebook的可靠數據流聚合引擎(reliable stream aggregation engine)系統,如圖 19所示,當前最新版本爲Puma3系統.

Fig. 19 Puma3 architecture圖 19 Puma3系統架構

Puma3在本地內存中實現了數據聚合功能,極大地提升了數據的計算能力,有效地下降了系統延遲.Puma3系統實現時,在Calligraphus階段經過聚合主鍵完成對數據的分片,其中,每一個分片都是內存中的哈希表,每一個表項對應一個Key及用戶定義的聚合方法,如統計、求和、平均值等操做.HBase子系統會按期地從Puma3中將內存中的數據備份到HBase中,進行數據的持久化存儲.只有當Puma3發生故障時,才從HBase中讀取副本,進行數據的重放,實現對因故障丟失數據的恢復;在無端障的狀況下,HBase子系統不參與數據的計算,所以提升了數據的計算能力.

(3) 存在不足

Data Freeway and Puma系統存在的不足主要包括:數據延遲在秒級,沒法知足大數據流式計算所須要的毫秒級應用需求;將哈希表徹底放入內存的加速機制,致使內存需求量大;資源調度策略不夠簡單、高效,不能靈活適應連續的工做負載.

3.4Kafka系統

Kafka^{[38, 54, 55, 56]}是Linkedin所支持的一款開源的、分佈式的、高吞吐量的發佈訂閱消息系統,能夠有效地處理互聯網中活躍的流式數據,如網站的頁面瀏覽量、用戶訪問頻率、訪問統計、好友動態等,最新版本是Kafka 0.8,開發語言是Scala,可使用Java進行編寫.

Kafka系統在設計過程當中主要考慮到了如下需求特徵:消息持久化是一種常態需求;吞吐量是系統須要知足的首要目標;消息的狀態做爲訂閱者(consumer)存儲信息的一部分,在訂閱者服務器中進行存儲;將發佈者(producer)、代理(broker)和訂閱者(consumer)顯式地分佈在多臺機器上,構成顯式的分佈式系統.造成了如下關鍵特性:在磁盤中實現消息持久化的時間複雜度爲O(1),數據規模能夠達到TB級別;實現了數據的高吞吐量,能夠知足每秒數十萬條消息的處理需求;實現了在服務器集羣中進行消息的分片和序列管理;實現了對Hadoop系統的兼容,能夠將數據並行地加載到 Hadoop集羣中.

(1) 系統架構

Kafka消息系統的架構是由發佈者(producer)、代理(broker)和訂閱者(consumer)共同構成的顯式分佈式架構,即,分別位於不一樣的節點上,如圖 20所示.各部分構成一個完整的邏輯組,並對外界提供服務,各部分間經過消息(message)進行數據傳輸.其中,發佈者能夠向一個主題(topic)推送相關消息,訂閱者以組爲單位,能夠關注並拉取本身感興趣的消息,經過Zookeeper實現對訂閱者和代理的全局狀態信息的管理,及其負載均衡的實現.

Fig. 20 Kafka architecture圖 20 Kafka系統架構

(2) 數據存儲

Kafka消息系統經過僅僅進行數據追加的方式實現對磁盤數據的持久化保存,實現了對大數據的穩定存儲,並有效地提升了系統的計算能力.經過採用Sendfile^[38, 54]系統調用方式優化了網絡傳輸,減小了1次內存拷貝,提升了系統的吞吐量,即便對於普通的硬件,Kafka消息系統也能夠支持每秒數十萬的消息處理能力.此外,在Kafka消息系統中,經過僅保存訂閱者已經計算數據的偏量信息,一方面能夠有效地節省數據的存儲空間,另外一方面,也簡化了系統的計算方式,方便了系統的故障恢復.

(3) 消息傳輸

Kafka消息系統採用了推送、拉取相結合的方式進行消息的傳輸,其中,當發佈者須要傳輸消息時,會主動地推送該消息到相關的代理節點;當訂閱者須要訪問數據時,其會從代理節點中進行拉取.一般狀況下,訂閱者能夠從代理節點中拉取本身感興趣的主題消息.

(4) 負載均衡

在Kafka消息系統中,發佈者和代理節點之間沒有負載均衡機制,但能夠經過專用的第4層負載均衡器在Kafka代理之上實現基於TCP鏈接的負載均衡的調整.訂閱者和代理節點之間經過Zookeeper實現了負載均衡機制,在Zookeeper中管理所有活動的訂閱者和代理節點信息,當有訂閱者和代理節點的狀態發生變化時,才實時進行系統的負載均衡的調整,保障整個系統處於一個良好的均衡狀態.

(5) 存在不足

Kafka系統存在的不足主要包括:只支持部分容錯,即,節點失效轉移時會丟失原節點內存中的狀態信息;代理節點沒有副本機制保護,一旦代理節點出現故障,該代理節點中的數據將再也不可用;代理節點不保存訂閱者的狀態,刪除消息時沒法判斷該消息是否已被閱讀.

3.5TimeStream系統

TimeStream^{[39, 57, 58, 59, 60]}是Microsoft在StreamInsight的基礎上開發的一款分佈式的、低延遲的、實時連續的大數據流式計算系統,經過彈性替代機制,能夠自適應因故障恢復和動態配置所致使的系統負載均衡的變化,使用C#.NET來編寫.

TimeStream的開發是基於大數據流式計算如下兩點來考慮的:(a) 連續到達的流式大數據已經遠遠超出了單臺物理機器的計算能力,分佈式的計算架構成爲必然的選擇;(b) 新產生的流式大數據必須在極短的時間延遲內,通過相關任務拓撲進行計算後,產生出可以反映該輸入數據特徵的計算結果.

(1) 任務拓撲結構

TimeStream中的數據計算邏輯是基於數據流DAG實現的,如圖 21所示,在數據流DAG中的每一個頂點v,在獲取輸入數據流i後,觸發相關操做f_v,產生新數據流o,並更新頂點v的狀態從t到t¢,即,(t¢,o)=f_v(t,i).

Fig. 21 Vertex of task topology in data stream圖 21 數據流任務拓撲頂點

在TimeStream中,一個數據流子圖sub-DAG是指在數據流DAG中,兩頂點及該兩頂點間的所有頂點和有向邊的集合,即,知足:對於數據流子圖sub-DAG中任意兩頂點v₁和v₂,以及數據流DAG中任意一頂點v,若頂點v位於頂點v₁和v₂的有向邊上,那麼頂點v必定是數據流子圖sub-DA G的一個頂點.數據流子圖sub-DAG在邏輯上能夠簡化爲一個與其功能相同的頂點,如圖 22所示,在一個由7個頂點所組成的數據流DAG中,由頂點v₂, v₃,v₄和v₅及其有向邊所構成的數據流子圖sub-DAG,能夠簡化爲一個輸入數據流爲i、輸出數據流爲o的邏輯頂點.

(2) 彈性等價替代

在TimeStream中,當出現服務器故障或系統負載劇烈持續變化的狀況時,能夠經過數據流子圖sub-DAG間、數據流子圖sub-DAG與頂點間以及各頂點間的彈性等價替代,動態、實時地適應系統的負載變化需求.具體而言,彈性等價替代能夠進一步細分爲3種狀況:

(a) 頂點間的彈性等價替代.當數據流DAG中的任意一頂點v出現故障不能正常工做時,系統會啓動一個具備相同功能的頂點v¢,並接管頂點v的工做;

(b) 數據流子圖sub-DAG與頂點間的彈性等價替代.如圖 22所示,當整個系統的負載太輕時,爲了節省系統的資源,能夠經過一個新的頂點v代替由頂點v₂,v₃,v₄和v₅所組成的數據流子圖sub-DAG,該新頂點v將實現數據流子圖sub-DAG的所有功能;反之,當系統的負載太重時,也能夠用一個數據流子圖sub-DAG代替任意一個頂點v,實現功能的分解和任務的分擔;

Fig. 22 Data stream sub-DAG圖 22 數據流子圖sub-DAG

(c) 數據流子圖sub-DAG間的彈性等價替代.如圖 23所示,右側由頂點v₂,v₃,v₄和v₅所組成的數據流子圖sub-DAG實現了HashPartition,Computation和Union等功能,但當系統的Computation功能的計算量忽然持續增大後,用左側由頂點v₈,v₉,v₁₀,v₁₁,v₁₂和v₁₃所組成的數據流子圖sub-DAG彈性等價替代右側的 子圖,實現了將Computation計算節點由2個增長到4個,提升了Computation的計算能力.

Fig. 23 Resilient substitution of data stream sub-DAG圖 23 數據流子圖sub-DAG彈性等價替代

經過彈性等價替代機制能夠有效地適應系統因故障和負載的變化對系統性能產生的影響,保證系統性能的穩定性;但在彈性等價替代的過程當中,必定要實現替代子圖或頂點間的等價,並儘量地進行狀態的恢復.所謂的等價,即對於相同的輸入,子圖或頂點能夠在功能上產生相同的輸出,惟一存在的區別在於其性能的不一樣.狀態的恢復是經過對數據流DAG中的依賴關係跟蹤機制^[39]來實現,並儘量全面地進行系統狀態的恢復.

(3) 系統架構

在TimeStream的系統結構中,實現了資源分配、節點調度、故障檢測等功能.

如圖 24所示,位於頭節點(head node)中的集羣管理器(cluster manager,簡稱CM)實現了對系統資源的管理和任務的分配,位於計算節點(compute node)的節點服務器(node service,簡稱NS)實現了對計算節點的管理和維護.當一個新的數據流任務進入系統被計算時:首先,系統爲該任務分配一個全局惟一的查詢協調器(query coordinator,簡稱QC),查詢協調器QC向集羣管理器CM請求資源運行任務的數據流DAG;其次,向節點服務器NS請求調度頂點處理器(vertex processes,簡稱VP),並實現數據流DAG的構建;再次,實施數據計算;最後,查詢協調器QC和頂點處理器VP均會實時地跟蹤系統的運行狀況,並按期地將相關元數據信息保持到數據庫中,在出現系統故障或負載劇烈持續變化的狀況時,能夠經過這些被永久保存的元數據進行系統狀態的恢復和實時動態的調整.

Fig. 24 TimeStream architecture圖 24 TimeStream系統架構

(4) 存在不足

TimeStream系統存在的不足主要包括:數據延遲在秒級,沒法知足毫秒級的應用需求;基於依賴關係跟蹤的容錯機制下降了系統性能,當系統規模爲16個節點時,系統吞吐量降低了10%左右.

3.6 對比分析

表 5從13個主要方面對Storm系統、S4系統、Data Freeway and Puma系統、Kafka系統和TimeStream系統進行了對比分析.

Table 5 Contrast of data stream systems表 5 數據流系統對比

能夠看到:

· 在體系結構方面:Storm,Kafka,TimeStream選擇了主從式體系結構,S4和Data Freeway and Puma均選擇了對稱式體系結構;

· 在應用接口方面:Storm,S4,Puma,Kafka均選擇了類MapReduce接口,簡化了用戶的編程;TimeStream選擇了用戶更爲熟悉的類SQL接口.此外,HStreaming已爲用戶提供了更爲方便的基於拖拽的可視化接口;

· 在開發語言方面:S4和Puma均選擇了Java語言;Storm的核心代碼雖然選擇了Clojure語言,但也支持Java語言;

· 在高可用策略方面:S4和Kafka均選擇了被動等待策略,所以其資源利用率比較低;Data Freeway and Puma選擇了主動等待策略;Storm,TimeStream選擇了上游備份策略,相應的資源利用率比較高;

· Storm,S4,Data Freeway and Puma和Kafka目前均不支持數據的精確恢復、負載均衡等功能,但面向金融領域的StreamBase支持數據的精確恢復.

如圖 25所示,批量計算相關的大數據系統,如批量處理系統(如MapReduce)、大規模並行數據庫等,在數據吞吐量方面具備明顯優點,但在系統響應時間方面每每在秒級以上.而當前的流式計算相關的大數據系統,如流式處理系統、內存數據庫、CEP(復瑣事件處理)等,在系統響應時間方面雖然維持在毫秒級的水平,但數據吞吐量每每在GB級別,遠遠知足不了大數據流式計算系統對數據吞吐量的要求.一般狀況下,一個理想的大數據流式計算系統在響應時間方面應維持在毫秒級的水平,而且數據吞吐量應該提升到PB級及其以上水平.

Fig. 25 Compare of streaming systems and batch systems in throughput and response time圖 25 流式系統和批量計算系統在吞吐量、響應時間方面的對比

4 面臨的技術挑戰

流式大數據在實時性、無序性、無限性、易失性、突發性等方面均呈現出了諸多新的鮮明特徵,所以,傳統的先存儲後計算的批量數據計算理念不適用於大數據流式計算的環境中,使得大數據流式環境中的數據計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面^{[61, 62, 63, 64, 65]}均面臨着史無前例的新的挑戰.

4.1 可伸縮性

在大數據流式計算環境中,系統的可伸縮性是制約大數據流式計算系統普遍應用的一個重要因素.Storm, Kafka,TimeStream等系統沒有實現對系統可伸縮性的良好支持:一方面,流式數據的產生速率在高峯時期會不斷增長且數據量巨大,持續時間每每很長,所以須要大數據流式系統具備很好的「可伸」的特徵,能夠實時適應數據增加的需求,實現對系統資源進行動態調整和快速部署,並保證整個系統的穩定性;另外一方面,當流式數據的產生速率持續減小時,須要及時回收在高峯時期所分配的但目前已處於閒置或低效利用的資源,實現整個系統「可縮」的友好特徵,並保障對用戶是透明的.所以,系統中資源動態的配置、高效的組織、合理的佈局、科學的架構和有效的分配,是保障整個系統可伸縮性的基礎,同時,又儘量地減小沒必要要的資源和能源的浪費.

大數據流式計算環境中的可伸縮性問題的解決,須要實現對系統架構的合理佈局、系統資源的有序組織、高效管理和靈活調度,在保證系統完成計算的前提下,儘可能少地過久、太多地佔用系統資源,經過虛擬化機制實現軟、硬件之間的低耦合,實現資源的在線遷移,並最終解決大數據流式計算環境中的可伸縮性問題.

4.2 系統容錯

在大數據流式計算環境中,系統容錯機制是進一步改善整個系統性能、提升計算結果的滿意度、保證系統可靠持續運行的一個重要措施,也是當前大多數大數據流式計算系統所缺失的.如S4,Puma,Kafka等系統實現了對部分容錯的支持,Storm系統實現了對做業級容錯的支持,TimeStream系統經過依賴關係跟蹤實現了對容錯的部分支持.大數據流式計算環境對容錯機制提出了新的挑戰:

· 一方面,數據流是實時、持續地到來,呈現出時間上不可逆的特徵,一旦數據流流過,再次重放數據流的成本是很大的,甚至是不現實的.因爲數據流所呈現出的持續性和無限性,也沒法預測將來流量的變化趨勢;

· 另外一方面,在流式大數據的計算過程當中,大部分「無用」的數據將被直接丟棄,能被永久保存下來的數據量是極少的,當須要進行系統容錯時,其中不可避免地會出現一個時間段內數據不完整的狀況;

· 再則,須要針對不一樣類型的應用,從系統層面上設計符合其應用特徵的數據容錯級別和容錯策略,避免沒必要要的資源浪費及應用需求的不吻合.

大數據流式計算環境中的容錯策略的肯定,須要根據具體的應用場景進行系統的設計和權衡,而且須要充分考慮到流式大數據的持續性、無限性、不可恢復性等關鍵特徵.可是,沒有任何數據丟失的容錯策略也未必是最佳的,須要綜合統籌容錯級別和資源利用、維護代價等要素間的關係.但在對系統資源佔用合理、對系統性能影響可接受的狀況下,容錯的精度越高必將越好.

4.3 狀態一致性

在大數據流式計算環境中,維持系統中各節點間狀態的一致性對於系統的穩定、高效運行、故障恢復都相當重要.然而,當前多數系統不能有效地支持系統狀態的一致性,如Storm,Kafka等系統尚不支持維護系統狀態的一致性,S4,TimeStream等系統也僅實現了在必定程度上對狀態一致性的支持.大數據流式計算環境對狀態一致性提出了新的挑戰:一方面,在系統實時性要求極高、數據速率動態變化的環境中,維護哪些數據的狀態一致性,如何從高速、海量的數據流中識別這些數據是一個巨大的挑戰;另外一方面,在大規模分佈式環境中,如何組織和管理實現系統狀態一致性的相關數據,知足系統對數據的高效組織和精準管理的要求,也是一個巨大的挑戰.

大數據流式計算環境中的狀態一致性問題的解決,須要從系統架構的設計層面上着手.存在全局惟一的中心節點的主從式架構方案無疑是實現系統狀態一致性的最佳解決方案,但須要有效避免單點故障問題.一般狀況下,在大數據流式計算環境中,程序和數據一旦啓動後,將會常駐內容,對系統的資源佔用也每每相對穩定.所以,單點故障問題在大數據流式計算環境中並無批量計算環境中那麼複雜.批量計算環境中的不少策略將具備很好的參考和借鑑價值.

4.4 負載均衡

在大數據流式計算環境中,系統的負載均衡機制是制約系統穩定運行、高吞吐量計算、快速響應的一個關鍵因素.然而,當前多數系統不能有效地支持系統的負載均衡,如Storm,S4等系統均不支持負載均衡機制, Kafka系統實現了對負載均衡機制的部分支持:一方面,在大數據流式計算環境中,系統的數據速率具備明顯的突變性,而且持續時間每每沒法有效預測,這就致使在傳統環境中具備很好的理論和實踐效果的負載均衡策略在大數據流式計算環境中將再也不適用;另外一方面,當前大多數開源的大數據流式計算系統在架構的設計上還沒有充分地、全面地考慮整個系統的負載均衡問題,在實踐應用中,相關經驗的積累又相對缺少,所以,給大數據流式計算環境中負載均衡問題的研究帶來了諸多實踐中的困難和挑戰.

大數據流式計算環境中的負載均衡問題的解決,須要結合具體的應用場景,系統地分析和總結隱藏在大數據流式計算中的數據流變化的基本特徵和內在規律,結合傳統系統負載均衡的經驗,根據實踐檢驗狀況,不斷進行相關機制的持續優化和逐步完善.

4.5 數據吞吐量

在大數據流式計算環境中,數據吞吐量呈現出了根本性的增長.在傳統的流式數據環境中,如CEP,所處理的數據吞吐量每每在GB級別,知足不了大數據流式計算環境對數據的吞吐量的要求.在大數據流式計算環境中,數據的吞吐量每每在TB級別以上,且其增加的趨勢是顯著的.然而,當前流式數據處理系統,如Storm,S4等,均沒法知足TB級別的應用需求.

大數據流式計算環境中的數據吞吐量問題的解決,一方面須要從硬件的角度進行系統的優化,設計出更符合大數據流式計算環境的硬件產品,在數據的計算能力上實現大幅提高;另外一方面,更爲重要的是,從系統架構的設計中進行優化和提高,設計出更加符合大數據流式計算特徵的數據計算邏輯.

5 結 論

流式大數據做爲大數據的一種重要形態,在商業智能、市場營銷和公共服務等諸多領域有着普遍的應用前景,並已在金融銀行業、互聯網、物聯網等場景的應用中取得了顯著的成效.但流式大數據以其實時性、無序性、無限性、易失性、突發性等顯著特徵,使得其與傳統批量大數據在數據計算的要求、方式等方面有着明顯的不一樣,也使得當前諸多數據計算系統沒法進一步更好地適應流式大數據在系統可伸縮性、容錯、狀態一致性、負載均衡、數據吞吐量等方面所帶來的諸多新的技術挑戰.

本文從大數據環境中流式數據的特徵切入,以大數據流式計算架構的設計、優化和挑戰爲核心,系統地梳理和分析了當前大數據環境中的關於大數據流式計算系統的研究和發展示狀,從系統架構的角度分析了一個設計優良的大數據流式計算系統應該在系統結構、數據傳輸、應用接口、高可用技術等諸多關鍵技術上進行優化.同時,本文詳細地分析和對比了當前在實踐中具備很好的應用基礎、較爲典型的5款大數據流式計算系統,並具體闡述了大數據流式計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的新的挑戰,實現了對流式大數據環境中數據計算架構、關鍵問題及其技術挑戰的深刻研究.

能夠看出,大數據流式計算的研究和應用仍處於很不成熟的階段,這與其普遍的市場需求和應用前景很不吻合.爲了促進大數據流式計算的成熟、穩健發展,亟待全面、系統、深刻地開展相關理論和實踐的研究工做.在將來的研究工做中,將進一步深化對大數據流式計算架構及其關鍵技術的研究,並結合詳細的應用需求,開發、部署、測試並優化面向特定應用領域的大數據流式計算系統,進一步推進大數據流式計算理論、方法、技術與系統的研究與發展.

致謝 在此,咱們向對本文的工做給予支持和建議的老師和同窗表示感謝.

參考文獻

 

[1]	Lynch C. Big data: How do your data grow? Nature, 2008,455(7209):28-29 .

[2]Kobielus A. The role of stream computing in big data architectures. 2013. http://ibmdatamag.com/2013/01/the-role-of-stream-computing-in-big-data-architectures/[3]Li GJ, Cheng XQ. Research status and scientific thinking of big data. Bulletin of Chinese Academy of Sciences, 2012,27(6): 647-657 (in Chinese with English abstract).[4]Wang YZ, Jin XL, Cheng XQ. Network big data: Present and future. Chinese Journal of Computers, 2013,36(6):1125-1138 (in Chinese with English abstract).[5]Feng ZY, Guo XH, Zeng DJ, Chen YB, Chen GQ. On the research frontiers of business management in the context of big data. Journal of Management Sciences in China, 2013,16(1):1-9 (in Chinese with English abstract).[6]Morales GDF. SAMOA: A platform for mining big data streams. In: Proc. of the 22th Int’l World Wide Web Conf. (WWW 2013). Rio de Janeiro: ACM Press, 2013. 777-778. http://www.engineeringvillage.com/search/doc/detailed.url?SEARCHID=M3862b207 144cdd0c07bM34761017816565&pageType=quickSearch&CID=quickSearchDetailedFormat&DOCINDEX=1&database=7&forma t=quickSearchDetailedFormat&tagscope=&displayPagination=yes[7]Meng XF, Ci X. Big data management: Concepts, techniques and challenges. Journal of Computer Research and Development, 2013,50(1):146-169 (in Chinese with English abstract).[8]Lim L, Misra A, Mo TL. Adaptive data acquisition strategies for energy-efficient, smartphone-based, continuous processing of sensor streams. Distributed and Parallel Databases, 2013,31(2):321-351 .[9]Li BD, Mazur E, Diao YL. SCALLA: A platform for scalable one-pass analytics using MapReduce. ACM Trans. on Database Systems, 2012,37(4):1-43 .[10]Yang D, Rundensteiner EA, Ward M. Mining neighbor-based patterns in data streams. Information Systems, 2013,38(3):331-350 .[11]Qin XP, Wang HJ, Du XY, Wang S. Big data analysis—Competition and symbiosis of RDBMS and MapReduce. Ruan Jian Xue Bao/ Journal of Software, 2012,23(1):32-45 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/4091.htm[12]Tallon PP. Corporate governance of big data: Perspectives on value, risk, and cost. Computer, 2013,46(6):32-38 .[13]Talia D. Clouds for scalable big data analytics. Computer, 2013,46(5):98-101 .

[14]Chen HC, Chiang RHL, Storey VC. Business intelligence and analytics: From big data to big impact. MIS Quarterly, 2012,36(4): 1165-1188.[15]Li JZ, Liu XM. An important aspect of big data. Journal of Computer Research and Development, 2013,50(6):1147-1162 (in Chinese with English abstract).[16]Demirkan H, Delen D. Leveraging the capabilities of service-oriented decision support systems: Putting analytics and big data in cloud. Decision Support Systems, 2013,55(1):412-421 .[17]Agrawal D, Das S, El AA. Big data and cloud computing: Current state and future opportunities. In: Proc. of the 14th Int’l Conf. on Extending Database Technology (EDBT 2011). Uppsala: ACM Press, 2011. 530-533 .[18]Cugola G, Margara A. Deployment strategies for distributed complex event processing. Computing, 2013,95(2):129-156 .[19]Zappia I, Paganelli F, Parlanti D. A lightweight and extensible complex event processing system for sense and respond applications. Expert Systems with Applications, 2012,39(12):10408-10419 .[20]Hoi SCH, Wang JL, Zhao PL, Jin R. Online feature selection for mining big data. In: Proc. of the ACM SIGKDD Int’l Conf. on Knowledge Discovery and Data Mining (SIGKDD 2012). Beijing: ACM Press, 2012. 2012.93-100 .[21]Michael K, Miller KW. Big data: New opportunities and new challenges. Computer, 2013,46(6):22-24 .[22]Scalosub G, Marbach P, Liebeherr J. Buffer management for aggregated streaming data with packet dependencies. IEEE Trans.on Parallel and Distributed Systems, 2013,24(3):439-449 .[23]Malensek M, Pallickara SL, Pallickara S. Exploiting geospatial and chronological characteristics in data streams to enable efficient storage and retrievals. Future Generation Computer Systems, 2013,29(4):1049-1061 .[24]Cugola G, Margara A. Processing flows of information: From data stream to complex event processing. ACM Computing Surveys, 2012,44(3):15:1-62 .[25]Lim L, Misra A, Mo TL. Adaptive data acquisition strategies for energy-efficient, smartphone-based, continuous processing of sensor streams. Distributed and Parallel Databases, 2013,31(2):321-351 .[26]He JY, Chaintreau A, Diot C. A performance evaluation of scalable live video streaming with nano data centers. Computer Networks, 2009,53(2):153-167 .[27]Vianna E, Comarela G, Pontes T, Almeida J, Almeida V, Wilkinson K, Kuno H, Dayal U. Analytical performance models for MapReduce workloads. Int’l Journal of Parallel Programming, 2013,41(4):495-525 .[28]Chatziantoniou D, Pramatari K, Sotiropoulos Y. Supporting real-time supply chain decisions based on RFID data streams. Journal of Systems and Software, 2011,84(4):700-710 .[29]楊棟.Beyond MapReduce:談2011年風靡的數據流計算系統.2013. http://www.programmer.com.cn/9642/[30]Tatbul N, Ahmad Y, Çetintemel U, Hwang JH, Xing Y, Zdonik S. Load management and high availability in the borealis distributed stream processing engine. In: Proc. of the 2nd Int’l Conf. on GeoSensor Networks (GSN 2006). Boston: IEEE Press, 2006.66-85 .[31]Balazinska M, Hwang J, Shah MA. Fault-Tolerance and high availability in data stream management systems. In: Proc. of the Encyclopedia of Database Systems. 2009. 1109-1115 .[32]Zhang Z, Gu Y, Ye F, Yang H, Kim M, Lei H, Liu Z. A hybrid approach to high availability in stream processing systems. In: Proc. of the 30th IEEE Int’l Conf. on Distributed Computing Systems (ICDCS 2010). Genova: IEEE Press, 2010.2010. 138-148 .[33]Nagano K, Itokawa T, Kitasuka T, Aritsugi M. Exploitation of backup nodes for reducing recovery cost in high availability stream processing systems. In: Proc. of the 14th Int’l Database Engineering and Applications Symp. (IDEAS 2010). Montreal: ACM Press,2010. 61-63 .[34]Aritsugi M, Nagano K. Recovery processing for high availability stream processing systems in local area networks. In: Proc. of the IEEE Region 10 Conf. (TENCON 2010). Fukuoka: IEEE Press, 2010. 1036-1041 .[35]Storm. 2013. http://storm-project.net/[36]Neumeyer L, Robbins B, Nair A, Kesari A. S4: Distributed stream computing platform. In: Proc. of the 10th IEEE Int’l Conf. on Data Mining Workshops (ICDMW 2010). Sydney: IEEE Press, 2010. 2010.170-177 .[37]Borthakur D, Sarma JS, Gray J, Muthukkaruppan K, Spigeglberg N, Kuang HR, Ranganathan K, Molkov D, Mennon A, Rash S, Schmidt R, Aiyer A. Apache hadoop goes realtime at Facebook. In: Proc. of the ACM SIGMOD Int’l Conf. on Management of Data (SIGMOD 2011 and PODS 2011). Athens: ACM Press, 2011. 1071-1080 .[38]Apache Kafka, A high-throughput distributed messaging system. 2013. http://kafka.apache.org/design.html[39]Qian ZP, He Y, Su CZ, Wu ZJ, Zhu HY, Zhang TZ, Zhou LD, Yu Y, Zhang Z. TimeStream: Reliable stream computation in the cloud. In: Proc. of the 8th ACM European Conf. on Computer Systems (EuroSys 2013). Prague: ACM Press, 2013. 1-14 .[40]Stoess J, Steinberg U, Uhlig V, Kehne J, Appavoo J, Waterlang A. A lightweight virtual machine monitor for Blue Gene/P. Int’l Journal of High Performance Computing Applications, 2012,26(2):95-109 .[41]Hoppe A, Gryz J. Stream processing in a relational database: A case study. In: Proc. of the 11th Int’l Database Engineering and Applications Symp. (IDEAS 2007). Banff: IEEE Press, 2007. 216-224. http://www.engineeringvillage.com/search/doc/detailed.url? SEARCHID=M3862b207144cdd0c07bM2bd41017816565&pageType=quickSearch&CID=quickSearchDetailedFormat&DOCIND EX=1&database=1&format=quickSearchDetailedFormat&tagscope=&displayPagination=yes[42]Spark, lightning-fast cluster computing. 2013. http://spark-project.org/[43]Esper, event stream intelligence: Esper & NEsper. 2013. http://esper.codehaus.org/[44]Storm wiki. 2013. http://en.wikipedia.org/wiki/Storm[45]Storm tutorial. 2013. https://storm.canonical.com/Tutorial[46]Simoncelli D, Dusi M, Gringoli F, Niccolini S. Scaling out the performance of service monitoring applications with BlockMon. In: Proc. of the 14th Int’l Conf. on Passive and Active Measurement (PAM 2013). Hong Kong: IEEE Press, 2013.253-255 .[47]Chauhan J, Chowdhury SA, Makaroff D. Performance evaluation of Yahoo! S4: A first look. In: Proc. of the 7th Int’l Conf. on P2P, Parallel, Grid, Cloud and Internet Computing (3PGCIC 2012). Victoria: IEEE Press, 2012.2012. 58-65 .[48]S4, distributed stream computing platform.2013. http://incubator.apache.org/s4/ .[49]Zhong BY. Stream computing StreamBase Yahoo S4 borealis comparis. 2013. http://oracle-abc.wikidot.com/zh:stream-computing-streambase-yahoo-s4-borealis-comparison.[50]Squicciarini AC, Shehab M, Wede J. Privacy policies for shared content in social network sites. VLDB Journal, 2010,19(6): 777-796.[51]Deng DP, Chuang TR, Shao KT, Mai GS, Lin TE, Lennens R, Hsu CH, Lin HH, Kraak MJ. Using social media for collaborative species identification and occurrence: Issues, methods, and tools. In: Proc. of the 1st ACM SIGSPATIAL Int’l Workshop on Crowdsourced and Volunteered Geographic Information (GEOCROWD 2012). Redondo Beach: ACM Press, 2012.2012. 22-29 .[52]Segulja C, Abdelrahman TS. Architectural support for synchronization-free deterministic parallel programming. In: Proc. of the 18th IEEE Int’l Symp. on High Performance Computer Architecture (HPCA 2012). New Orleans: IEEE Press, 2012.2012. 1-12 .[53]HiC2011—Realtime data streams and Analytics-Data Freeway and Puma-Facebook. 2013.http://ishare.iask.sina.com.cn/f/22023896.html .[54]Auradkar A, Botev C, Das S, et al. Data infrastructure at LinkedIn. In: Proc. of the IEEE 28th Int’l Conf. on Data Engineering (ICDE 2012). Arlington: IEEE Press, 2012.1370-1381 .[55]Efficient data transfer through zero copy, zero copy, zero overhead. 2013. https://www.ibm.com/developerworks/linux/library/j-zerocopy/[56]Kafka, distributed publish-subscribe messaging system. 2013. http://data.linkedin.com/opensource/kafka/[57]Guo ZY, McDirmid S, Yang M, Zhuang L, Zhang P, Luo YW, Bergan T, Bodik P, Musuvathi M, Zhang Z, Zhou LD. Failure recovery: When the cure is worse than the disease. In: Proc. of the 14th USENIX Conf. on Hot Topics in Operating Systems (USENIX 2013). Santa Ana Pueblo: ACM Press, 2013. 1-6. http://research.microsoft.com/apps/pubs/default.aspx?id=191008[58]Ali M, Badrish C, Goldstein J, Schindlauer R. The extensibility framework in Microsoft StreamInsight. In: Proc. of the IEEE 27th Int’l Conf. on Data Engineering (ICDE 2011). Hannover: IEEE Press, 2011. 2011.1242-1253 .[59]Chandramouli B, Goldstein J, Barga R, Riedewald M, Santos I. Accurate latency estimation in a distributed event processing system. In: Proc. of the IEEE 27th Int’l Conf. on Data Engineering (ICDE 2011). Hannover: IEEE Press, 2011. 255-266.http://www.engineeringvillage.com/search/doc/detailed.url?SEARCHID=M3862b207144cdd0c07bM2d0a1017816565&pageType= quickSearch&CID=quickSearchDetailedFormat&DOCINDEX=1&database=1&format=quickSearchDetailedFormat&tagscope=&di splayPagination=yes[60]Ali M, Chandramouli B, Fay J, Wong C, Drucker S, Raman BS. Online visualization of geospatial stream data using the WorldWide telescope. VLDB Endowment, 2011,4(12):1379-1382.[61]Qin XP, Wang HJ, Li FR, Li CP, Chen H, Zhou H, Du XY, Wang S. New landscape of data management technologies. Ruan Jian Xue Bao/Journal of Software, 2013,24(2):175-197 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/4345.htm[62]Qi KY, Zhao ZF, Fang J, Ma Q. Real-Time processing for high speed data stream over larger scale data. Chinese Journal of Computers, 2012,35(3):477-490 (in Chinese with English abstract) .[63]Toyoda M, Sakurai Y, Ishikawa Y. Pattern discovery in data streams under the time warping distance. VLDB Journal, 2013,22(3): 295-318 .[64]Malensek M, Pallickara SL, Pallickara S. Exploiting geospatial and chronological characteristics in data streams to enable efficient storage and retrievals. Future Generation Computer Systems, 2013,29(4):1049-1061 .[65]Farid DW, Zhang L, Hossain A, Rahman CM, Strachan R, Sexton G, Dahal K. An adaptive ensemble classifier for mining concept drifting data streams. Expert Systems with Applications, 2013,40(15):5895-5906 .[3]李國傑,程學旗.大數據研究:將來科技及經濟社會發展的重大戰略領域——大數據的研究現狀與科學思考.中國科學院院刊, 2012,27(6):647-657.[4]王元卓,靳小龍,程學旗.網絡大數據:現狀與展望.計算機學報,2013,36(6):1125-1138.[5]馮芷豔,郭迅華,曾大軍,陳煜波,陳國青.大數據背景下商務管理研究若干前沿課題.管理科學學報,2013,16(1):1-9.[7]孟小峯,慈祥.大數據管理:概念、技術與挑戰.計算機研究與發展,2013,50(1):146-169.[11]覃雄派,王會舉,杜小勇,王珊.大數據分析——RDBMS與MapReduce的競爭與共生.軟件學報,2012,23(1):32-45.http://www.jos.org.cn/1000-9825/4091.htm[15]李建中,劉顯敏.大數據的一個重要方面:數據可用性.計算機研究與發展,2013,50(6):1147-1162.[61]覃雄派,王會舉,李芙蓉,李翠平,陳紅,周烜,杜小勇,王珊.數據管理技術的新格局.軟件學報,2013,24(2):175-197.http://www.jos.org.cn/1000-9825/4345.htm[62]亓開元,趙卓峯,房俊,馬強.針對高速數據流的大規模數據實時分析方法.計算機學報,2012,35(3):477-490.