大數據處理框架

 

提及大數據處理啊，一切都起源於Google公司的經典論文。在當時（2000年左右），因爲網頁數量急劇增長，Google公司內部平時要編寫不少的程序來處理大量的原始數據：爬蟲爬到的網頁、網頁請求日誌；計算各類類型的派生數據：倒排索引、網頁的各類圖結構等等。這些計算在概念上很容易理解，但因爲輸入數據量很大，單機難以處理。因此須要利用分佈式的方式完成計算，而且須要考慮如何進行並行計算、分配數據和處理失敗等等問題。

 

針對這些複雜的問題，Google決定設計一套抽象模型來執行這些簡單計算，並隱藏併發、容錯、數據分佈和均衡負載等方面的細節。受到Lisp和其它函數式編程語言map、reduce思想的啓發，論文的做者意識到許多計算都涉及對每條數據執行map操做，獲得一批中間key/value對，而後利用reduce操做合併那些key值相同的k-v對。這種模型能很容易實現大規模並行計算。

 

事實上，與不少人理解不一樣的是，MapReduce對大數據計算的最大貢獻，其實並非它名字直觀顯示的Map和Reduce思想（正如上文提到的，Map和Reduce思想在Lisp等函數式編程語言中很早就存在了），而是這個計算框架能夠運行在一羣廉價的PC機上。MapReduce的偉大之處在於給大衆們普及了工業界對於大數據計算的理解：它提供了良好的橫向擴展性和容錯處理機制，至此大數據計算由集中式過渡至分佈式。之前，想對更多的數據進行計算就要造更快的計算機，而如今只須要添加計算節點。

 

話說當年的Google有三寶：MapReduce、GFS和BigTable。但Google三寶雖好，尋常百姓想用卻用不上，緣由很簡單：它們都不開源。因而Hadoop應運而生，初代Hadoop的MapReduce和HDFS即爲Google的MapReduce和GFS的開源實現（另外一寶BigTable的開源實現是一樣大名鼎鼎的HBase）。自此，大數據處理框架的歷史大幕正式的緩緩拉開。

 

今天咱們要講的數據處理框架，按照對所處理的數據形式和獲得結果的時效性分類，能夠分爲兩類：

1.批處理系統

2.流處理系統

 

 

1批處理系統

批處理的過程包括將任務分解爲較小的任務，分別在集羣中的每一個計算機上進行計算，根據中間結果從新組合數據，而後計算和組合最終結果。因此批處理系統主要操做大量的、靜態的數據，而且等到所有處理完成後才能獲得返回的結果。

 

因爲批處理系統在處理海量的持久數據方面表現出色，因此它一般被用來處理歷史數據，不少OLAP（在線分析處理）系統的底層計算框架就是使用的批處理系統。可是因爲海量數據的處理須要耗費不少時間，因此批處理系統通常不適合用於對延時要求較高的場景。

而後批處理系統的表明就是Hadoop。Hadoop是首個在開源社區得到極大關注的大數據處理框架，在很長一段時間內，它幾乎能夠做爲大數據技術的代名詞。

 

在2.0版本之後，Hadoop由如下組件組成：

1.分佈式文件系統HDFS

2.資源管理器YARN

3.MapReduce

關於它們，AI菌已經在以前的文章討論過了。沒有看過的朋友能夠去翻一翻。

 

並且Hadoop不斷髮展完善，還集成了衆多優秀的產品如非關係數據庫HBase、數據倉庫Hive、數據處理工具Sqoop、機器學習算法庫Mahout、一致性服務軟件ZooKeeper、管理工具Ambari等，造成了相對完整的生態圈和分佈式計算事實上的標準。

 

2流處理系統

流處理系統好理解，那什麼是流處理系統呢？小學的時候咱們都作過這麼一道數學題：一個水池有一個進水管和一個出水管，只打開進水管x個小時充滿水，只打開出水管y個小時流光水，那麼同時打開進水管和出水管，水池多長時間充滿水？

 

流處理系統就至關於這個水池，把流進來的水（數據）進行加工，好比加鹽讓它變成鹽水，而後再把加工過的水（數據）從出水管放出去。這樣，數據就像水流同樣永不中止，並且在水池中就被處理過了。因此，這種處理永不中止的接入數據的系統就叫作流處理系統。

 

流處理系統與批處理系統所處理的數據不一樣之處在於，流處理系統並不對已經存在的數據集進行操做，而是對從外部系統接入的的數據進行處理。流處理系統能夠分爲兩種：

逐項處理：每次處理一條數據，是真正意義上的流處理。

微批處理：這種處理方式把一小段時間內的數據看成一個微批次，對這個微批次內的數據進行處理。

 

不管是哪一種處理方式，其實時性都要遠遠好於批處理系統。所以，流處理系統很是適合應用於對實時性要求較高的場景，好比日誌分析，設備監控、網站實時流量變化等等。

而後流處理系統的表明就是Apache Storm與Apache Samza了。

Apache Storm是一種側重於低延遲的流處理框架，它能夠處理海量的接入數據，以近實時方式處理數據。Storm延時能夠達到亞秒級。

 

值得一提的是，一些國內的公司在Storm的基礎上進行了改進，爲推進流處理系統的發展作出了很大貢獻。阿里巴巴的JStorm參考了Storm，並在網絡IO、線程模型、資源調度及穩定性上作了改進。

 

提到Apache Samza，就不得不提到當前最流行的大數據消息中間件：Apache Kafka。Apache Kafka是一個分佈式的消息中間件系統，具備高吞吐、低延時等特色，而且自帶了容錯機制。

 

若是已經擁有Hadoop集羣和Kafka集羣環境，那麼使用Samza做爲流處理系統無疑是一個很是好的選擇。因爲能夠很方便的將處理過的數據再次寫入Kafka，Samza尤爲適合不一樣團隊之間合做開發，處理不一樣階段的多個數據流。

3混合處理系統

一些處理框架既能夠進行批處理，也能夠進行流處理。這些框架可使用相同或相關的API處理歷史和實時數據。

雖然專一於一種處理方式可能很是適合特定場景，可是混合框架爲數據處理提供了通用的解決方案。

而當前主流的混合處理框架主要爲Spark和Flink。

若是說現在大數據處理框架處於一個羣星閃耀的年代，那Spark無疑就是全部星星中最閃亮的那一顆。Spark由加州大學伯克利分校AMP實驗室開發，最初的設計受到了MapReduce思想的啓發，但不一樣於MapReduce的是，Spark經過內存計算模型和執行優化大幅提升了對數據的處理能力

 

並且除了最初開發用於批處理的Spark Core和用於流處理的Spark Streaming，Spark還提供了其餘編程模型用於支持圖計算（GraphX）、交互式查詢（Spark SQL）和機器學習（MLlib）。

 

有趣的是，一樣做爲混合處理框架，Flink的思想與Spark是徹底相反的：Spark把流拆分紅若干個小批次來處理，而Flink把批處理任務看成有界的流來處理。

 

除了流處理（DataStream API）和批處理（DataSet API）以外，Flink也提供了類SQL查詢（Table API）、圖計算（Gelly）和機器學習庫（Flink ML）。而使人驚訝的是，在不少性能測試中，Flink甚至略優於Spark。

 

在目前的數據處理框架領域，Flink可謂獨樹一幟。雖然Spark一樣也提供了批處理和流處理的能力，但Spark流處理的微批次架構使其響應時間略長。Flink流處理優先的方式實現了低延遲、高吞吐和真正逐條處理。

 

一樣，Flink也並非完美的。Flink目前最大的缺點就是缺少在大型公司實際生產項目中的成功應用案例。相對於Spark來說，它還不夠成熟，社區活躍度也沒有Spark那麼高。但假以時日，Flink必然會改變數據處理框架的格局。

 

4大數據處理框架的選擇

1. 對於初學者

    

因爲Apache Hadoop在大數據領域的普遍使用，所以仍推薦做爲初學者學習數據處理框架的首選。雖然MapReduce由於性能緣由之後的應用會愈來愈少，可是YARN和HDFS依然做爲其餘框架的基礎組件被大量使用（好比HBase依賴於HDFS，YARN能夠爲Spark、Samza等框架提供資源管理）。學習Hadoop能夠爲之後的進階打下基礎。

 

Apache Spark在目前的企業應用中應該是當之無愧的王者。在批處理領域，雖然Spark與MapReduce的市場佔有率不相上下，但Spark穩定上升，而MapReduce卻穩定降低。而在流處理領域，Spark Streaming與另外一大流處理系統Apache Storm共同佔據了大部分市場（固然不少公司會使用內部研發的數據處理框架，但它們多數並不開源）。伯克利的正統出身、活躍的社區以及大量的商用案例都是Spark的優點。除了可用於批處理和流處理系統，Spark還支持交互式查詢、圖計算和機器學習。Spark在將來幾年內仍然會是大數據處理的主流框架，推薦同窗們認真學習。

 

另外一個做爲混合處理框架的Apache Flink則潛力無限，被稱做「下一代數據處理框架」。雖然目前存在社區活躍度不夠高、商用案例較少等狀況，不過「是金子總會發光」，若是Flink能在商業應用上有突出表現，則可能挑戰Spark的地位。

 

2.對於企業應用

 

若是企業中只須要批處理工做，而且對時間並不敏感，那麼可使用成本較其餘解決方案更低的Hadoop集羣。

 

若是企業僅進行流處理，而且對低延遲有着較高要求，Storm更加適合，若是對延遲不很是敏感，可使用Spark Streaming。而若是企業內部已經存在Kafka和Hadoop集羣，而且須要多團隊合做開發（下游團隊會使用上游團隊處理過的數據做爲數據源），那麼Samza是一個很好的選擇。

 

若是須要同時兼顧批處理與流處理任務，那麼Spark是一個很好的選擇。混合處理框架的另外一個好處是，下降了開發人員的學習成本，從而爲企業節約人力成本。Flink提供了真正的流處理能力而且一樣具有批處理能力，但商用案例較少，對於初次嘗試數據處理的企業來講，大規模使用Flink存在必定風險。