從Hadoop到Spark、Flink，大數據處理框架十年激盪發展史！

當前這個數據時代，各領域各業務場景時時刻刻都有大量的數據產生，如何理解大數據，對這些數據進行有效的處理成爲不少企業和研究機構所面臨的問題。本文將從大數據的基礎特性開始，進而解釋分而治之的處理思想，最後介紹一些流行的大數據技術和組件，讀者可以經過本文了解大數據的概念、處理方法和流行技術。

什麼是大數據？

大數據，顧名思義，就是擁有龐大致量的數據。關於什麼是大數據，如何定義大數據，如何使用大數據等一系列問題，不一樣領域背景的朋友理解各不相同。IBM將大數據概括爲5個V，涵蓋了大數據絕大多數的特性。

• Volume：數據量大，從TB（1,024 GB）、PB（1,024 TB）、EB（1,024 PB）、ZB（1,024 EB）甚至到YB（1,024 ZB）。紐約證交所天天產生的交易數據大約在TB級，瑞士日內瓦附近的大型強子對撞機每一年產生的數據約爲PB級，而目前全球數據總量已經在ZB級，至關於 1,000,000 PB，也就是你們更熟悉的10億 TB。基於更大規模的數據，咱們能夠對某個研究對象的歷史、現狀和將來有更加全面的瞭解。

• Velocity：數據產生速度快，所要求的處理速度和時效性高，由於時間就是金錢。金融市場的交易數據必須以秒級的速度進行處理，搜索和推薦引擎須要在分鐘級將實時新聞推送給用戶。更快的數據處理速度，讓咱們基於最新的數據上作更加實時的決策。

• Variety：數據類型繁多，包括數字、文字、圖片、視頻等不一樣的數據形式，也包括來自社交網絡、視頻網站、可穿戴設備以及各種傳感器的數據。數據多是Excel裏高度結構化的數據，也多是圖片和視頻這種非結構化的數據。

• Veracity：數據真實性。一方面，數據並不是自然具備高價值，一些異常值會被摻雜進來，例如，統計誤差、人的情感影響、天氣、經濟因素甚至謊報數據等。另外一方面，數據源類型不一樣，數據源多樣，如何將這些多元異構數據鏈接、匹配、清洗和轉化，造成具備高置信度的數據是一項很是有挑戰的工做。

• Value：數據價值。咱們研究和利用大數據的最終目的是提供更有價值的決策支持，基於以上提到的四個V，挖掘大數據的深層價值。

在數據分析領域，研究對象的所有被稱爲整體（Population），整體包含大量的數據，甚至說數據多是無限的。好比調查15個國家的國民的誠信狀況，全部國民是整體。不少狀況下，咱們沒法保證能收集和分析整體的全部數據，所以研究者通常基於研究對象的一個子集進行數據分析。樣本（Sample）是從整體中抽取的個體，是研究對象的子集，經過對樣本的調查和分析，研究者能夠推測整體的狀況。在誠信調查的案例中，咱們能夠在每一個國家抽取一部分國民做爲樣本，以此推測該國國民的誠信水平。

在大數據技術成熟以前，受限於數據收集、存儲和分析能力，樣本數量相對較小，大數據技術的出現讓數據存儲和分析能力再也不是瓶頸，研究者能夠在更大規模的數據上，以更快地速度進行數據分析。但數據並不是自然有價值，如何讓數據點石成金很是有挑戰。在誠信調查中，若是咱們直接詢問樣本對象：「你是否謊報了本身和家庭的資產以獲取更大的金融借貸額度？」十之八九，咱們得不到真實的答案，但咱們能夠綜合多種渠道來分析該問題，好比結合樣本對象的工做經歷、徵信記錄等數據。

可見，大數據具備更大的數據量、更快的速度、更多的數據類型的特色。在必定的數據真實性基礎上，大數據技術最終爲數據背後的價值服務。

隨着大數據技術的發展，數據的複雜性愈來愈高，有人在這5個V的基礎上，又提出了一些補充，好比增長了動態性（Vitality），強調整個數據體系的動態性；增長了可視性（Visualization），強調數據的顯性化展示；增長了合法性（Validity），強調數據採集和應用的合法性，特別是對於我的隱私數據的合理使用等；增長了數據在線（Online），強調數據永遠在線，能隨時調用和計算。

分佈式計算 分而治之

計算機誕生以後，通常是在單臺計算機上處理數據。大數據時代到來後，一些傳統的數據處理方法沒法知足大數據的處理需求，將一組計算機組織到一塊兒造成一個集羣，利用集羣的力量來處理大數據的工程實踐逐漸成爲主流方案。這種使用集羣進行計算的方式被稱爲分佈式計算，當前幾乎全部的大數據系統都是在集羣進行分佈式計算。

分佈式計算的概念聽起來很高深，其背後的思想十分樸素，即分而治之（Divide and Conquer），又被稱爲分治法。分治法將一個原始問題分解爲子問題，多個子問題分別在多臺機器上求解，藉助必要的數據交換和合並策略，將子結果彙總便可求出最終結果。具體而言，不一樣的分佈式計算系統所使用的算法和策略根據所要解決的問題各有不一樣，但基本上都是將計算拆分，把子問題放到多臺機器上，分而治之地計算求解。分佈式計算的每臺機器（物理機或虛擬機）又被稱爲一個節點。

分佈式計算在科研界已經有不少比較成熟的方案，其中比較有名的有消息傳遞接口（Message Passing Interface，MPI）和MapReduce。

MPI

MPI是一個老牌分佈式計算框架，主要解決節點間數據通訊的問題。在前MapReduce時代，MPI是分佈式計算的業界標準。MPI程序如今依然普遍運行在全球各大超級計算中心、大學、政府和軍隊下屬研究機構中，許多物理、生物、化學、能源、航空航天等基礎學科的大規模分佈式計算都依賴MPI。

分治法將問題切分紅子問題，在不一樣節點上分而治之地求解，MPI提供了一個在多進程多節點間進行數據通訊的方案，由於絕大多數狀況下，在中間計算和最終合併的過程當中，須要對多個節點上的數據進行交換和同步。

MPI中最重要的兩個操做爲數據發送（Send）和數據接收（Recv），Send表示將本進程中某塊數據發送給其餘進程，Recv表示接收其餘進程的數據。上圖展現了MPI架構在4臺服務器上並行計算的示意圖。在實際的代碼開發過程當中，用戶須要自行設計分治算法，將複雜問題切分爲子問題，手動調用MPI庫，將數據發送給指定的進程。

MPI可以在很細的粒度上控制數據的通訊，這是它的優點，同時也是它的劣勢，由於細粒度的控制意味着從分治算法設計到數據通訊到結果彙總都須要編程人員手動控制。有經驗的程序員能夠對程序進行底層優化，取得成倍的速度提高。但若是對計算機和分佈式系統沒有太多經驗，編碼、調試和運行MPI程序的時間成本極高，加上數據在不一樣節點上不均衡和通訊延遲等問題，一個節點進程失敗將會致使整個程序失敗，所以，MPI對於大部分程序員來講簡直就是噩夢。

並不是全部的編程人員都能熟練掌握MPI編程，衡量一個程序的時間成本，不只要考慮程序運行的時間，也要考慮程序員學習、開發和調試的時間。就像C語言運算速度極快，可是Python語言卻更受歡迎同樣，MPI雖然能提供極快的分佈式計算加速，但不太接地氣。

MapReduce

爲了解決分佈式計算學習和使用成本高的問題，研究人員提出了更簡單易用的MapReduce編程模型。MapReduce是Google 2004年提出的一種編程範式，比起MPI將全部事情交給程序員控制不一樣，MapReduce編程模型只須要程序員定義兩個操做：map和reduce。

網絡上有不少MapReduce的介紹和解釋，這裏咱們用三明治的製做過程對MapReduce進行了分解。假設咱們須要大批量地製做三明治，三明治的每種食材能夠分別單獨處理， map階段將原材料在不一樣的節點上分別進行處理，生成一些中間食材， shuffle階段將不一樣的中間食材進行組合， reduce最終將一組中間食材組合成爲三明治成品。能夠看到，這種 map + shuffle + reduce的方式就是分而治之思想的一種實現。

基於MapReduce編程模型，不一樣的團隊分別實現了本身的大數據框架：Hadoop是最先的一種開源實現，現在已經成爲大數據領域的業界標杆，以後又出現了Spark和Flink。這些框架提供了編程接口和API，輔助程序員存儲、處理和分析大數據。

比起MPI，MapReduce編程模型將更多的中間過程作了封裝，程序員只須要將原始問題轉化爲更高層次的API，至於原始問題如何切分爲更小的子問題、中間數據如何傳輸和交換、如何將計算伸縮擴展到多個節點等一系列細節問題能夠交給大數據框架來解決。所以，MapReduce相對來講學習門檻更低，使用更方便，編程開發速度更快。

批處理和流處理

數據與數據流

在大數據的5V定義中咱們已經提到，數據的容量大且產生速度快。從時間維度上來說，數據源源不斷地產生，造成一個無界的數據流（Unbounded Stream）。例如咱們每時每刻的運動數據都會累積到手機傳感器上，金融交易隨時隨地發生着，傳感器會持續監控並生成數據。數據流中的某段有界數據流（Bounded Stream）能夠組成一個數據集。咱們一般所說的對某份數據進行分析，指的是對某個數據集進行分析。隨着數據的產生速度愈來愈快，數據源愈來愈多，人們對時效性的重視程度愈來愈高，如何處理數據流成了你們更爲關注的問題。

批處理

批處理（Batch Processing）是對一批數據進行處理。咱們身邊批量計算比比皆是，最簡單的批量計算例子有：微信運動天天晚上有一個批量任務，把用戶好友一天所走的步數統計一遍，生成排序結果後推送給用戶；銀行信用卡中心每個月帳單日有一個批量任務，把一個月的消費總額統計一次，生成用戶月度帳單；國家統計局每季度對經濟數據作一次統計，公佈季度GDP增速。可見，批量任務通常是對一段時間的數據聚合後進行處理。對於數據量龐大的應用，如微信運動、銀行信用卡等情景，一段時間內積累的數據總量很是大，計算很是耗時。

批量計算的歷史能夠追溯的計算機剛剛起步的上世紀60年代，當前應用最爲普遍的當屬數據倉庫的ETL（Extract Transform Load）數據轉化工做，如以Oracle爲表明的商業數據倉庫和以Hadoop/Spark爲表明的開源數據倉庫。

流處理

如前文所說，數據實際上是以流（Stream）的方式持續不斷地產生着，流處理（Stream Processing）就是對數據流進行處理。時間就是金錢，對數據流進行分析和處理，獲取實時數據價值愈加重要。我的用戶每晚看一次微信運動排名以爲是一個比較溫馨的節奏，可是對於金融界來講，時間是以百萬、千萬甚至上億爲單位的金錢！雙十一電商大促銷，管理者要以秒級的響應時間查看實時銷售業績、庫存信息以及與競品的對比結果，以爭取更多的決策時間；股票交易要以毫秒級的速度來對新信息作出響應；風險控制要對每一份欺詐交易迅速作出處理，以減小沒必要要的損失；網絡運營商要以極快速度發現網絡和數據中心的故障等等。以上這些場景，一旦出現故障，形成了服務的延遲，損失都難以估量，所以，響應速度越快，越能減小損失，增長收入。而IoT物聯網和5G通訊的興起將爲數據生成提供更完美的底層技術基礎，海量的數據在IoT設備上採集生成，並經過更高速的5G通道傳輸到服務器，更龐大的實時數據流將洶涌而至，流式處理的需求確定會爆炸式增加。

表明性大數據技術

如前文所述，MapReduce編程模型的提出爲大數據分析和處理開創了一條先河，以後陸續涌現出了Hadoop、Spark和Flink等大數據框架。

Hadoop

2004年，Hadoop的創始人受MapReduce編程模型等一系列論文的啓發，對論文中說起的思想進行了編程實現。Hadoop的名字來源於創始人Doug Cutting兒子的玩具大象。因爲創始人Doug Cutting當時加入了雅虎，並在此期間支持了大量Hadoop的研發工做，所以Hadoop也常常被認爲是雅虎開源的一款大數據框架。時至今日，Hadoop不只僅是整個大數據領域的先行者和領導者，更造成了一套圍繞Hadoop的生態系統，Hadoop和它的生態是絕大多數企業首選的大數據解決方案。

儘管Hadoop生態中的組件衆多，其核心組件主要有三個：

• Hadoop MapReduce：Hadoop版本的MapReduce編程模型，能夠處理海量數據，主要面向批處理。
• HDFS：HDFS全稱爲Hadoop Distributed File System，是Hadoop提供的分佈式文件系統，有很好的擴展性和容錯性。
• YARN：YARN是Yet Another Resource Negotiator的縮寫，是Hadoop生態系統中的資源調度器，能夠管理一個Hadoop集羣，併爲各類類型的大數據任務分配計算資源。

這三大組件中，數據存儲在HDFS上，由MapReduce負責計算，YARN負責集羣的資源管理。除了三大核心組件，Hadoop生態圈還有不少其餘著名的組件：

• Hive：藉助Hive，用戶能夠編寫SQL語句來查詢HDFS上的結構化數據，SQL會被轉化成MapReduce執行。
• HBase：HDFS上的數據量很是龐大，但訪問和查詢速度比較慢，HBase能夠提供給用戶毫秒級的實時查詢服務，是一個基於HDFS的分佈式數據庫。
• Storm：Strom是一款實時計算框架，主要負責流處理。
• Zookeeper：Hadoop生態圈不少組件使用動物來命名，造成了一個大型動物園，Zookeeper是這個動物園的管理者，主要負責分佈式環境的協調。

Spark

Spark於2009年誕生於加州大學伯克利分校，2013年被捐獻給Apache基金會。Spark是一款大數據計算框架，其初衷是改良Hadoop MapReduce的編程模型和執行速度。與Hadoop相比，Spark的改進主要有兩點：

• 易用性：比起MPI，MapReduce模型更友好，但仍然不夠方便，由於並非全部計算任務均可以簡單拆分紅map和reduce，有可能爲了解決一個問題，要設計多個MapReduce任務，任務之間相互依賴，整個程序很是複雜，致使代碼的可讀性差。Spark提供更加方便易用的接口，提供Java、Scala、Python和R幾種語言的API，支持SQL、機器學習和圖計算，覆蓋了絕大多數大數據計算的場景。
• 速度快：Hadoop的map和reduce之間的中間結果都須要落地到磁盤上，而Spark儘可能將大部分計算放在內存中，加上Spark的有向無環圖優化，在官方的基準測試中，Spark比Hadoop快一百倍以上。

  

  Spark的核心在於計算，主要目的在於優化Hadoop MapReduce計算部分，在計算層面提供更細緻的服務，好比提供了經常使用幾種數據科學語言的API，提供了SQL、機器學習和圖計算支持，這些服務都是最終面向計算的。Spark並不能徹底取代Hadoop，實際上，Spark融入到了Hadoop生態圈，成爲其中的重要一元。一個Spark任務極可能依賴HDFS上的數據，向YARN來申請計算資源，將HBase做爲輸出結果的目的地。固然，Spark也能夠不用依賴這些Hadoop組件，獨立地完成計算。

  

  Spark主要面向批處理需求，因其優異的性能和易用的接口，Spark已是批處理界絕對的王者。Spark Streaming提供了流處理的功能，它的流處理主要基於mini-batch的思想，即將輸入數據流拆分紅多個批次，每一個批次使用批處理的方式進行計算。所以，Spark是一款批量和流式於一體的計算框架。

Flink

Flink是由德國幾所大學發起的的學術項目，後來不斷髮展壯大，並於2014年底成爲Apache頂級項目。Flink主要面向流處理，若是說Spark是批處理界的王者，那麼Flink就是流處理領域的冉冉升起的新星。在Flink以前，不乏流式處理引擎，比較著名的有Storm、Spark Streaming，但某些特性遠不如Flink。

第一代被普遍採用的流處理框架是Strom。在多項基準測試中，Storm的數據吞吐量和延遲都遠遜於Flink。Storm只支持"at least once"和"at most once"，即數據流裏的事件投遞只能保證至少一次或至多一次，不能保證只有一次。對於不少對數據準確性要求較高的應用，Storm有必定劣勢。第二代很是流行的流處理框架是Spark Streaming。Spark Streaming使用mini-batch的思想，每次處理一小批數據，一小批數據包含多個事件，以接近實時處理的效果。由於它每次計算一小批數據，所以總有一些延遲。但Spark Streaming的優點是擁有Spark這個靠山，用戶從Spark遷移到Spark Streaming的成本較低，所以能給用戶提供一個批量和流式於一體的計算框架。

Flink是與上述兩代框架都不太同樣的新一代計算框架，它是一個支持在有界和無界數據流上作有狀態計算的大數據引擎。它以事件爲單位，而且支持SQL、State、WaterMark等特性。它支持"exactly once"，即事件投遞保證只有一次，很少也很多，這樣數據的準確性能獲得提高。比起Storm，它的吞吐量更高，延遲更低，準確性能獲得保障；比起Spark Streaming，它以事件爲單位，達到真正意義上的實時計算，且所需計算資源相對更少。

以前提到，數據都是以流的形式產生的。數據能夠分爲有界（bounded）和無界（unbounded），批量處理其實就是一個有界的數據流，是流處理的一個特例。Flink基於這種思想，逐步發展成一個可支持流式和批量處理的大數據框架。

通過幾年的發展，Flink的API已經很是完善，能夠支持Java、Scala和Python，而且支持SQL。Flink的Scala版API與Spark很是類似，有Spark經驗的程序員能夠用一個小時的時間熟悉Flink API。

與Spark相似，Flink目前主要面向計算，而且能夠與Hadoop生態高度集成。Spark和Flink各有所長，也在相互借鑑，一邊競爭，一邊學習，究竟最終誰能一統江湖，咱們拭目以待。

小結

大數據通常基於分而治之的思想，分佈式地進行計算。通過十幾年的發展，大數據生態圈涌現出一大批優秀的組件和框架，這些組件對一些底層技術作了封裝，提供給程序員簡單易用的API接口。在大數據分析和處理領域，Hadoop已經發展成爲一個很是成熟的生態圈，涵蓋了不少大數據相關的基礎服務，Spark和Flink主要針對大數據計算，分別在批處理和流處理方向創建了本身的優點。