導讀：一個完整的大數據平臺應該提供離線計算、即席查詢、實時計算、實時查詢這幾個方面的功能，這些都離不開大數據的處理框架，那麼如何針對不同大數據處理框架的類型進行比較和選擇呢？

科技改變世界

“科技改變世界”，這句話已經深入人心，科技滲透到各個領域，並且已經成為各行各業發展的重要元素。

毫無疑問，現在大家越來越重視科技，重視大數據。因為每一個數據的背後都代表著一個甚至無數個重要的隱藏信息，這些信息對於企業/個人鏖戰商海起著至關重要的作用。而一個完整的大數據平臺應該提供離線計算、即席查詢、實時計算、實時查詢這幾個方面的功能，這些都離不開大數據的處理框架，那麼如何針對大數據處理框架的類型進行比較和選擇呢？

一、大數據簡介

大家都知道，大數據並不僅僅只是字面上的意思，不能單純的理解為數據大。我們先來簡單介紹一下大數據的定義和特徵：

大數據

1、大數據的定義

大數據（big data），指無法在一定時間範圍內用常規軟件工具進行捕捉、管理和處理的數據集合，是需要新的處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的信息資產。

大數據的5V特點

2. 大數據的5V特點

大數據系統的基本需求與傳統系統並沒有本質上的不同。但大數據系統雖然具有海量的數據規模，但是對數據的接入和處理速度上也有較高的要求，而且在每個階段都要對數據進行處理。這些特點也為設計解決方案提供了新的挑戰，當然也會激發一切創新的可能性。

大數據5V特點 = Volume + Velocity + Variety + Value + Veracity

（1）Volume ：數據量大

第一個特徵是數據量大，即數據信息量巨大，從TB級別躍升到PB級別。大數據的起始計量單位至少是P(1000個T)、E(100萬個T)或Z(10億個T)。

（2）Velocity： 數據處理速度快、時效高

第二個特徵是處理速度快，時效性要求高。在數據處理速度方面，有一個著名的“1s定律”，也稱為“秒級定律”，即要求在秒級這樣的短時間範圍內作出正確的數據分析，一旦超出這個時間，數據的價值也會因此大打折扣。這正是大數據區分於傳統數據挖掘最顯著的特徵。

傳統的數據處理方法，因為其既有的技術架構和路線，已經無法高效處理如此海量的數據，而對於相關組織來說，如果投入巨大采集的信息成本，卻無法通過及時處理反饋有效信息，那將是得不償失的。可以說，大數據時代對人類的數據駕馭能力提出了新的挑戰，也為人們獲得更為深刻、全面的洞察能力提供了前所未有的空間與機遇。

（3）Variety 數據多樣性

第三個特徵是數據多樣性，即數據類型繁多，不僅包括傳統的格式化數據，還包括來自互聯網的網絡日誌、音頻、視頻、圖片、地理位置信息等等，多類型的數據對數據的處理能力提出了更高的要求。

（4）

第四個特徵是數據價值密度相對較低。如隨著物聯網的廣泛應用，信息感知無處不在，信息海量，但價值密度較低，如何通過強大的機器算法更迅速地完成數據的價值“提純”，是大數據時代亟待解決的難題。

（5）Veracity數據真實性

第五個特徵是數據真實性，即更加強調真實有價值的數據，一些企業或者個人為了達到某種商業目的，或者是為了所謂的“面子工程”，可能會偽造數據，或者數據的來源過於單一性，這都會造成的數據的真實性存在質疑。

大數據處理流程

二、大數據處理流程

通過上文，我們簡單的瞭解了大數據的概念，也明確了大數據的五大特徵，那麼大數據系統如何在實際中處理數據的呢?雖然不同公司的有著不同的架構設計，但基本流程是大致相同的，雖然接下來介紹的流程不適用於所有情況，但他們仍未大多數公司所使用。大數據處理的基本流程是：

1. 大數據採集

大數據的採集，又稱為數據獲取，是指從傳感器和其它待測設備等模擬和數字被測單元中自動採集信息的過程，並且用戶可以通過這些數據庫來進行簡單的查詢和處理工作。比如，電商會使用傳統的關係型數據庫MySQL和Oracle等來存儲每一筆事務數據，除此之外，Redis和MongoDB這樣的NoSQL數據庫也常用於數據的採集。

在大數據的採集過程中，其主要特點和挑戰是併發數高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網站和購物網站，它們併發的訪問量在峰值時達到上百萬，所以需要在採集端部署大量數據庫才能支撐。並且如何在這些數據庫之間 進行負載均衡和分片的確是需要深入的思考和設計。

2. 大數據導入/預處理

數據預處理的三個核心步驟是：清洗，轉換，簡化。雖然採集端本身會有很多數據庫，但是如果要對這些海量數據進行有效的分析，還是應該將這些來自前端的數據導入到一個集中的大型的分佈式數據庫，或者分佈式存儲集群，並且可以在導入基礎上做一些簡單的清洗和預處理工作。

許多入門教程在導入數據時只教如何導入預處理過的數據，例如手寫體數字或者電影評分數據，用一行代碼就能搞定，但實際操作沒那麼簡單。遇到實際問題，都需要先找到正確的數據集，最終預測的結論依賴於最初導入的數據。導入與預處理過程的特點和挑戰主要是導入的數據量大，每秒鐘的導入量經常會達到百兆，甚至千兆級別。

3. 大數據統計/分析

在大數據時代，統計是數據分析的靈魂。統計與分析主要利用分佈式數據庫，或者分佈式計算集群來對存儲於其內的海量數據進行普通的分析和分類彙總等，以滿足大多數常見的分析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及基於 MySQL的列式存儲Infobright等，而一些批處理，或者基於半結構化數據的需求可以使用Hadoop。統計與分析這部分的主要特點和挑戰是分析涉及的數據量大，其對系統資源，特別是I/O會有極大的佔用。

4. 大數據挖掘

與前面統計和分析過程不同的是，數據挖掘一般沒有什麼預先設定好的主題，數據挖掘基於數據庫理論，機器學習，人工智能，現代統計學等，從海量的數據中發現隱含的知識和規律，在很多領域中都有應用。比較典型算法有用於聚類的Kmeans、用於統計學習的SVM和用於分類的NaiveBayes，主要使用的工具有Hadoop的Mahout等。該過程的特點和挑戰主要是用於挖掘的算法很複雜，並且計算涉及的數據量和計算量都很大，常用數據挖掘算法都以單線程為主。

普遍的大數據處理流程至少應該滿足這以上四個點的步驟，才能算得上是一個比較完整的大數據處理過程。當然，更加深入研究大數據流程的話，還會有更多有特點的、更加深入的、更加專業的大數據分析方法。

5、數據質量和數據管理

大數據分析離不開數據質量和數據管理，高質量的數據和有效的數據管理，無論是在學術研究還是在商業應用領域，都能夠保證分析結果的真實和有價值。大數據最重要的應用領域之一就是預測性分析，從大數據中挖掘出特點，通過科學的建立模型，之後便可以通過模型帶入新的數據，從而預測未來的數據。

三、大數據處理框架

分析了這麼多大數據的方方面面，讓大家對大數據有個基本的瞭解，我們接下來來聊一聊本文的重點——大數據處理框架。

1、大數據框架的定義

大數據處理框架負責對大數據系統中的數據進行計算。數據包括從持久存儲中讀取的數據或通過消息隊列等方式接入到系統中的數據。大數據框架作為大數據系統一個最基本的組件。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。除了大數據處理框架，我們可能還聽到過“大數據計算框架”、“大數據框架”，這些術語沒有嚴格的區分，但基本可以理解為是一種東西，只不過是對“big data processing framework”不同的翻譯(大數據框架是“big data framework”的翻譯)。

（1）“引擎”和“框架”的區別與聯繫

還有一個名詞是“大數據處理引擎”，那麼這個“引擎”和我們說的“框架”又有什麼關係呢?非結構化數據的多元化給數據分析帶來新的挑戰和機遇，我們也需要一套更為系統號的工具的去分析數據，提煉數據。大數據處理引擎需要設計到有足夠的人工智能，讓氣足以從數據中主動地提取有價值的信息。

其實並沒有關於區分兩者概念的權威官方說法，但一般來說，前者是實際負責處理操作的組件，而後者可以理解為用來完成同樣工作的一系列組件。

接下來將為大家介紹這些框架：

僅批處理框架：

• Apache Hadoop

僅流處理框架：

• Apache Storm

• Apache Samza

混合框架：

• Apache Spark

• Apache Flink

四、不同的大數據處理框架分析 -

接下來我們將著重介紹以下大數據框架，按照對所處理的數據形式和得到結果的時效性分類，數據處理框架可以分為兩類，從不同方面分析他們，希望能為大家在選擇不同處理框架時。

1、僅批處理框架

（1）批處理框架簡介

批處理是一種用來計算大規模數據集的方法。批處理的過程包括將一個大的任務分解為較小的任務，分別在集群中的每個計算機上進行計算，根據中間結果重新組合數據，然後計算和組合最終結果。

（2）批處理框架特徵

批處理系統中的數據集一般符合以下特徵：

• ①、有限性：批處理數據集代表數據的有限集合(無限的數據，數據之所以無限，因為他不是一批量可以處理完成的，連續不斷的數據一般會使用流處理系統來進行處理，後面會提到)

• ②、持久性：批處理系統處理的數據，一般存儲在持久存儲系統上(比如存儲在硬盤上、數據庫中)

• ③、海量性：極海量的數據通常只能使用批處理系統來進行集中處理。批處理系統在設計之初就充分的考慮了數據量巨大的問題，實際上批處理系統也是為此而生的。

（3）適用對象：海量的持久數據

當處理非常巨大的數據集時，批處理系統最為有效。批處理系統在大數據世界中有著悠久的歷史。批處理系統主要適合操作大量的、靜態的數據，而且要等到這一批量處理完成後，才能得到相應的處理結果。

由於批處理系統在處理海量的持久數據方面的出色表現，所以批處理系統常常被用來處理歷史記錄信息。例如：很多OLAP(在線分析處理)系統的底層計算框架就是使用的批處理系統，但是由於處理海量數據需要耗費很多時間，所以批處理系統一般不適合用於對延時要求較高的場景數據。

Apache Hadoop框架

2、Apache Hadoop

說起大數據處理框架，永遠也繞不開Hadoop。Hadoop的處理功能來自MapReduce引擎。MapReduce的處理技術符合使用鍵值對的map、shuffle、reduce算法要求。

（1）基本處理過程包括：

• ①、 從HDFS文件系統讀取數據集

• ②、將數據集拆分成小塊並分配給所有可用節點

• ③、 針對每個節點上的數據子集進行計算(計算的中間態結果會重新寫入HDFS)

• ④、重新分配中間態結果並按照鍵進行分組

• ⑤、通過對每個節點計算的結果進行彙總和組合對每個鍵的值進行“Reducing”

• ⑥、將計算而來的最終結果重新寫入 HDFS

Hadoop分佈式文件系統HDFS：HDFS是一種分佈式文件系統，它具有很高的容錯性，適合部署在廉價的機器集群上。HDFS能提供高吞吐量的數據訪問，非常適合在大規模數據集上使用。它可以用於存儲數據源，也可以存儲計算的最終結果。

資源管理器YARN：YARN可以為上層應用提供統一的資源管理和調度，它可以管理服務器的資源(主要是CPU和內存)，並負責調度作業的運行。在Hadoop中，它被設計用來管理MapReduce的計算服務。但現在很多其他的大數據處理框架也可以將YARN作為資源管理器，比如Spark。

MapReduce：即為Hadoop中默認的數據處理引擎，也是Google的MapReduce論文思想的開源實現。使用HDFS作為數據源，使用YARN進行資源管理。

3、批處理框架的

由於這種方法嚴重依賴持久存儲，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁盤空間通常是服務器上最豐富的資源，這意味著MapReduce可以處理非常海量的數據集。同時也意味著相比其他類似技術，Hadoop的MapReduce通常可以在廉價硬件上運行，因為該技術並不需要將一切都存儲在內存中。MapReduce具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。

MapReduce的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop集群快速實現某些應用時依然需要注意這個問題。

圍繞Hadoop已經形成了遼闊的生態系統，Hadoop集群本身也經常被用作其他軟件的組成部件。很多其他處理框架和引擎通過與Hadoop集成也可以使用HDFS和YARN資源管理器。

4、批處理框架總結

從今天的眼光來看，MapReduce作為Hadoop默認的數據處理引擎，存在著很多的不足。比如：編程模型抽象程度較低，僅支持Map和Reduce兩種操作，需要手工編寫大量的代碼;Map的中間結果需要寫入磁盤，多個MR之間需要使用HDFS交換數據，因此不適合迭代計算(機器學習、圖計算);任務的啟動和調度開銷較大等。隨著更多高性能處理引擎的發展，目前在企業中使用MapReduce進行計算的應用已經呈下降趨勢(HDFS及YARN仍然被廣泛使用)，但雖然如此，MapReduce作為最早的大數據處理引擎，仍然值得被我們銘記。

五、不同的大數據處理框架分析 - 僅流處理框架

1、流處理框架

（1）、流處理框架定義

我們瞭解了批處理框架的定義，那麼什麼是流處理框架的定義呢？

小學的時候可能我們經常會遇到這樣的數學題類型：

一個水池有一個進水管和一個出水管，只打開進水管8個小時充滿水，只打開出水管6個小時流光水，那麼同時打開進水管和出水管，水池多長時間充滿水?

看到這裡，大家是不是在各種列方程式來解答這道題呢？大家的答案不知道是否和我的一樣，這個水池永遠也充不滿！因為出水管出水比較快。

“流處理系統”就相當於這個“水池”，把流進來的“水”就相當於“數據”，比如我們加“鹽”讓他變成“鹽水”，然後再把加工過“鹽水”，即“處理過的數據”，從出水管放出去。這樣，數據就像水流一樣永不停止，而且在水池中就被處理過了。舉這個例子大家是不是更好理解一點呢？所以，這種處理永不停止的接入數據的系統就叫做流處理系統。

（2）、流處理系統的方法

流處理系統與批處理系統所處理的數據不同之處在於，流處理系統並不對已經存在的數據集進行操作，而是對從外部系統接入的的數據進行處理。流處理系統可以分為兩種：

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

• ②、微批處理： 這種處理方式把一小段時間內的數據當作一個微批次，對這個微批次內的數據進行處理。

（3）、流處理數據的影響

流處理中的數據集是“無邊界”的，這就產生了幾個重要的影響：

• ①、完整數據集只能代表截至目前已經進入到系統中的數據總量。

• ②、工作數據集也許更相關，在特定時間只能代表某個單一數據項。

• ③、處理工作是基於事件的，除非明確停止否則沒有“盡頭”。

• ④、處理結果立刻可用，並會隨著新數據的抵達繼續更新。

（4）、流處理適應對象：（幾乎）無限量的且需要響應的數據

流處理系統可以處理幾乎無限量的數據，但同一時間只能處理一條(真正的流處理)或很少量(微批處理，Micro-batch Processing)數據，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理(Functional processing)進行優化。

功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個數據執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些類型的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。

此類處理非常適合某些類型的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、服務器或應用程序錯誤日誌，以及其他基於時間的衡量指標是最適合的類型，因為對這些領域的數據變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的數據。

Apache Storm

2、Apache Storm

（1）Apache Storm概念

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

Storm含有如下關鍵概念：

在Storm中，先要設計一個用於實時計算的圖狀結構，我們稱之為拓撲（topology）。Storm的流處理可對框架中名為Topology(拓撲)的DAG(Directed Acyclic Graph，有向無環圖)進行編排。這些拓撲描述了當數據片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。

這個拓撲將會被提交給集群，由集群中的主控節點（master node）分發代碼，將任務分配給工作節點（worker node）執行。一個拓撲中包括spout和bolt兩種角色，其中spout發送消息，負責將數據流以tuple元組的形式發送出去；而bolt則負責轉換這些數據流，在bolt中可以完成計算、過濾等操作，bolt自身也可以隨機將數據發送給其他bolt。由spout發射出的tuple是不可變數組，對應著固定的鍵值對。

拓撲包含：

• ①、Stream：普通的數據流，這是一種會持續抵達系統的無邊界數據。

• ②、Spout：位於拓撲邊緣的數據流來源，例如可以是API或查詢等，從這裡可以產生待處理的數據。

• ③、Bolt：Bolt代表需要消耗流數據，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨後相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。

（2）、Storm優勢和侷限

目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。

Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。

Core Storm無法保證消息的處理順序。Core Storm為消息提供了“至少一次”的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重複。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。

Trident拓撲包含：

• ①、流批(Stream batch)：這是指流數據的微批，可通過分塊提供批處理語義。

• ②、操作(Operation)：是指可以對數據執行的批處理過程。

在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。

（3）、Storm優勢和侷限

目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。

Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。

Core Storm無法保證消息的處理順序。Core Storm為消息提供了“至少一次”的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重複。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。

在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。

（4）、Storm總結

對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟件。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。

Samza

3、Apache Samza

（1）Apache Samza概念

Samza處理數據流時，會分別按次處理每條收到的消息。Samza的流單位既不是元組，也不是Dstream，而是一條條消息。在Samza中，數據流被切分開來，每個部分都由一組只讀消息的有序數列構成，而這些消息每條都有一個特定的ID（offset）。該系統還支持批處理，即逐次處理同一個數據流分區的多條消息。Samza的執行與數據流模塊都是可插拔式的，儘管Samza的特色是依賴Hadoop的Yarn（另一種資源調度器）和Apache Kafka。所以提到Apache Samza，就不得不提到當前最流行的大數據消息中間件：Apache Kafka。Apache Kafka是一個分佈式的消息中間件系統，具有高吞吐、低延時等特點，並且自帶了容錯機制。

Kafka

以下是Kafka的關鍵概念：

• ①、Broker：由於Kafka是分佈式消息中間件，所以需要多個節點來存儲數據。Broker即為Kafka集群中的單個節點。

• ②、Topic：用於存儲寫入Kafka的數據流。如同它的字面含義——主題，不同主題的數據流最好寫入不同的topic，方便後續的處理。

• ③、Partition：每個topic都有1到多個partition，便於分散到不同的borker中。多個partition的數據合併在一起組成了topic完整的數據。

• ④、Producer：消息的生產者，用來將消息寫入到Kafka集群。

• ⑤、Consumer：消息的消費者，用來讀取Kafka中的消息並進行處理。

雖然Kafka被廣泛應用於各種流處理系統做數據源，但Samza可以更好的發揮Kafka架構的優勢。根據官網的解釋，Samza由三個層次組成：

①.數據流層、②.執行層、③.處理層

性對應的支持三個層次的組件分別為：①.Kafka、②.YARN、③.Samza API

（2）、Samza優勢和侷限

也就是說，Samza使用Kafka提供了數據流，使用YARN進行資源管理，自身僅提供了操作數據流的API。Samza對Kafka和YARN的依賴在很多方面上與MapReduce對HDFS和YARN的依賴相似。

如果已經擁有Hadoop集群和Kafka集群環境，那麼使用Samza作為流處理系統無疑是一個非常好的選擇。由於可以很方便的將處理過的數據再次寫入Kafka，Samza尤其適合不同團隊之間合作開發，處理不同階段的多個數據流。

乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。

例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。

這種對Kafka的緊密依賴在很多方面類似於MapReduce引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。

Samza與Kafka之間緊密的關係使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理後創建的話題。這一切並不會對數據庫等負載密集型基礎架構造成額外的壓力。

直接寫入Kafka還可避免回壓(Backpressure)問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。

Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得“至少一次”的交付保障，但面對由於數據可能多次交付造成的失敗，該技術無法對彙總後狀態(例如計數)提供精確恢復。

Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元(Primitive)更易於配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。

（3）、Samza總結

對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用(但相互之間並不一定緊密協調)不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。

六、批處理系統與流處理系統的聯繫與區別

不論是哪種處理方式，其實時性都要遠遠好於批處理系統。因此，流處理系統非常適合應用於對實時性要求較高的場景，比如日誌分析，設備監控、網站實時流量變化等等。由於很多情況下，我們想要儘快看到計算結果，所以近些年流處理系統的應用越來越廣泛。

七、混合處理系統：批處理和流處理

一些處理框架既可以進行批處理，也可以進行流處理。這種情況我們可以把它稱之為混合處理系統。這些框架可以使用相同或相關的API處理歷史和實時數據。當前主流的混合處理框架主要為Spark和Flink。

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

Apache Spark

1、Apache Spark

如果說如今大數據處理框架處於一個群星閃耀的年代，那Spark無疑就是所有星星中最閃亮的那一顆。

（1）、Apache Spark的概念

Spark Streaming是核心Spark API的一個擴展，它並不會像Storm那樣一次一個地處理數據流，而是在處理前按時間間隔預先將其切分為一段一段的批處理作業。Spark針對持續性數據流的抽象稱為DStream（DiscretizedStream），一個DStream是一個微批處理（micro-batching）的RDD（彈性分佈式數據集）；而RDD則是一種分佈式數據集，能夠以兩種方式並行運作，分別是任意函數和滑動窗口數據的轉換。

（2）Spark的優勢

Spark由加州大學伯克利分校AMP實驗室開發，最初的設計受到了MapReduce思想的啟發，但不同於MapReduce的是，Spark通過內存計算模型和執行優化大幅提高了對數據的處理能力(在不同情況下，速度可以達到MR的10-100倍，甚至更高)。相比於MapReduce，Spark具有如下優點：

提供了內存計算模型RDD(Resilient Distributed Dataset，彈性分佈式數據集)，將數據讀入內存中生成一個RDD，再對RDD進行計算。並且每次計算結果可以緩存在內存中，減少了磁盤IO。因此很適用於迭代計算。

不同於MapReduce的MR模型，Spark採用了DAG編程模型，將不同步驟的操作串聯成一個有向無環圖，可以有效減少任務間的數據傳遞，提高了性能。

提供了豐富的編程模型，可以輕鬆實現過濾、連接、聚合等操作，代碼量相比MapReduce少到令人髮指，因此可以提高開發人員的生產力。

支持Java、Scala、Python和R四種編程語言，為不同語言的使用者降低了學習成本。

而Spark的流處理能力，則是由Spark Streaming模塊提供的。Spark在設計之初與MapReduce一樣是用於批處理系統，為了適應於流處理模式，Spark提出了微批次(Micro-Batch)的概念，即把一小段時間內的接入數據作為一個微批次來處理。這樣做的優點是在設計Spark Streaming時可以很大程度上重用批處理模塊(Spark Core)的代碼，開發人員也不必學習兩套編程模型。但缺點就是，與Storm等原生的流處理系統相比，Spark Streaming的延時會相對高一些。

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

（3）Spark的侷限性

但Spark也不是沒有缺點。在批處理領域，由於內存是比硬盤更昂貴的資源，所以Spark集群的成本比MapReduce集群更高。而在流處理領域，微批次的架構使得它的延時要比Storm等流處理系統略高。不過瑕不掩瑜，Spark依然是如今最炙手可熱的數據處理框架。

Apache Flink

2、Apache Flink

有趣的是，同樣作為混合處理框架，Flink的思想與Spark是完全相反的：Spark把流拆分成若干個小批次來處理，而Flink把批處理任務當作有界的流來處理。其本質原因是，Spark最初是被設計用來進行批處理的，而Flink最初是被設計用來進行流處理的。這種流處理優先的方式叫做Kappa架構，與之相對的使用批處理優先的架構叫做Lambda架構。Kappa架構會使用處理流的方式處理一切，以此來簡化編程模型。這一切是在最近流處理引擎逐漸成熟起來才有可能實現的。

（1）Flink流處理模型

Flink的流處理模型將逐項輸入的數據作為真實的流處理。Flink提供了DataStream API用於處理無盡的數據流。

Flink的基本組件包括：

①、Stream(流)是指在系統中流轉的，永恆不變的無邊界數據集

②、Operator：Operator(操作方)是指針對數據流執行操作以產生其他數據流的功能

③、Source：Source(源)是指數據流進入系統的入口點④、Sink：Sink是數據流(stream)流出Flink系統後的位置。

④、Sink(槽)是指數據流離開Flink系統後進入到的位置，槽可以是數據庫或到其他系統的連接器

Flink的流處理思想與Storm類似，以source接入數據，通過不同的operator進行transformation，最後輸出到sink。

（3）、Flink的優勢

與Spark相同，Flink也提供了較為完整的數據處理方式。除了上面介紹的流處理(DataStream API)和批處理(DataSet API)之外，Flink還提供了類SQL查詢(Table API)、圖計算(Gelly)和機器學習庫(Flink ML)。而令人驚訝的是，在很多性能測試中，Flink甚至略優於Spark。

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

（4）、Flink侷限性

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

（5）、Flink批處理模型

Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。

Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。

另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。藉此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。

（6）Flink批處理模型優勢和侷限

Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。

Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。

Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關係型數據庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行“增量迭代”，或僅對數據中有改動的部分進行迭代。

在用戶工具方面，Flink提供了基於Web的調度視圖，藉此可輕鬆管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，藉此瞭解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。

Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕鬆地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。

目前Flink最大的侷限之一在於這依然是一個非常“年幼”的項目。現實環境中該項目的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的侷限目前也沒有較為深入的研究。隨著快速開發週期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署。

總結

Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。其快速開發的工作效率，引起人們的關注。

八、大數據處理框架的選擇

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存在一定風險。

全文總結：

通常，我們需要解決一件事情，首先應該明確事件基本情況、時間、結果。所以對於大數據如何選取適合的解決方案，主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。同時還需注意這個大數據項目的側重點，瞭解這些，從自身實際經濟情況出發，選擇適合企業/個人的解決方案。

閱讀更多 數據先行者 的文章

關鍵字: Hadoop 解析 數據處理