大數據處理框架
說起大數據處理啊，一切都起源於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大數據處理框架的選擇
-
對於初學者
由於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存在一定風險。
大數據處理框架