前言

說起大數據處理，一切都起源于Google公司的經典論文：《MapReduce:Simplied Data Processing on Large Clusters》。在當時(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. 大數據的定義

“大數據”一詞的確切定義其實是很難給出的，因為不同的人(供應商、從業者、商業公司等)對它的理解也并不完全一致。通常來講，大數據是：

1) 大數據集

2) 用于處理大數據集的某類技術

此處的“大數據集”是指一個數據集的數據量太大以至于無法使用傳統工具或單機方式來處理和存儲，而處理技術包括數據接入、數據持久化存儲、數據計算和分析、數據展示(可視化)等等。

2. 大數據的特征

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

在2001年，美國Gartner公司的Doug Laney首先提出了“3V”模型來描述大數據處理系統與傳統數據處理系統的不同：

Volume

待處理數據的規模在很大程度決定了系統是否為大數據系統。大數據系統中的數據規?？赡鼙葌鹘y處理系統中的數據集大幾個數量級，這也為數據處理和存儲帶來了更多的挑戰。由于數據處理和存儲等工作超出了單臺計算機所能達到的性能極限，所以大數據系統通常采用集群方式。集群方式更加考驗資源的分配和協調，集群管理和任務分配算法變得越來越重要。

Velocity

大數據與其他數據系統另一個顯著的差異體現在數據的“流動”速度。在大數據系統中，數據經常從多種數據源流入系統，并且以一種近實時的方式進行處理。數據被持續不斷的接入、修改、處理和分析以便能夠跟得上新數據的接入速度。由于近實時處理可以盡早的提供有價值的信息，目前很多商業公司更加青睞于實時處理系統而不是傳統的批處理系統。

Variety

大數據系統的問題通常是其他系統所不具備的，因為它所處理的數據來源廣泛。數據源可以是應用程序的日志信息，也可以是社交媒體的用戶信息，甚至是物理設備傳感器的采集數據。不論何種數據，大數據系統的目標都是在海量數據中尋找有用的數據。

3. 大數據處理流程

那么大數據系統實際上是如何處理數據的呢?雖然不同公司的架構設計不盡相同，但我們可以總結出一個基本的流程。下面介紹的流程雖然不是適用于所有情況，但它們確實被廣泛使用。大數據處理的基本流程是：

• 接入數據到系統中
• 將數據持久化到存儲系統
• 計算和分析數據
• 展示結果(可視化)

4. 大數據處理框架的定義

說完了大數據，我們來說說本文的重點——大數據處理框架。大數據處理框架負責對大數據系統中的數據進行計算。數據包括從持久存儲中讀取的數據或通過消息隊列等方式接入到系統中的數據，而計算則是從數據中提取信息的過程。除了大數據處理框架，有些同學可能還聽到過“大數據計算框架”、“大數據框架”，這些術語沒有嚴格的區分，但基本可以理解為是一種東西，只不過是對“big data processing framework”不同的翻譯(大數據框架是“big data framework”的翻譯)。

還有一個名詞是“大數據處理引擎”，那么這個“引擎”和我們說的“框架”又有什么關系呢?其實并沒有區分他們的權威的定義，但一般來說，前者是實際負責處理操作的組件，而后者可以理解為用來完成同樣工作的一系列組件。比如Apache Hadoop可以看做是以MapReduce為默認處理引擎的處理框架。

二、數據處理框架分類

不論是系統中存在的歷史數據，還是持續不斷接入系統中的實時數據，只要數據是可訪問的，我們就可以對數據進行處理。按照對所處理的數據形式和得到結果的時效性分類，數據處理框架可以分為兩類：

1、批處理系統

2、流處理系統

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

典型的批處理系統就是Apache Hadoop。而流處理則對由連續不斷的單條數據項組成的數據流進行操作，注重數據處理結果的時效性。典型的流處理系統有Apache Storm，Apache Samza。還有一種系統，同時具備批處理與流處理的能力，這種稱為混合處理系統，比如Apache Spark，Apache Flink。接下來我們來詳細介紹這三種處理系統。

三、批處理系統

批處理系統在大數據世界中有著悠久的歷史。批處理系統主要操作大量的、靜態的數據，并且等到全部處理完成后才能得到返回的結果。批處理系統中的數據集一般符合以下特征：

有限： 數據集中的數據必須是有限的(無限的數據一批就處理不完了啊。連續不斷的數據一般會使用流處理系統來進行處理，我們后面會講到)

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

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

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

Apache Hadoop

說起大數據處理框架，永遠也繞不開Hadoop。Hadoop是首個在開源社區獲得極大關注的大數據處理框架，在很長一段時間內，它幾乎可以作為大數據技術的代名詞。在2.0版本以后，Hadoop由以下組件組成：

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

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

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

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

四、流處理系統

批處理系統好理解，那什么是流處理系統呢?小學的時候我們都做過這么一道數學題：一個水池有一個進水管和一個出水管，只打開進水管8個小時充滿水，只打開出水管6個小時流光水，那么同時打開進水管和出水管，水池多長時間充滿水?

好吧，這道題的答案是永遠也充不滿……因為出水管出水比較快嘛。流處理系統就相當于這個水池，把流進來的水(數據)進行加工，比如加鹽讓它變成鹽水，然后再把加工過的水(數據)從出水管放出去。這樣，數據就像水流一樣永不停止，而且在水池中就被處理過了。所以，這種處理永不停止的接入數據的系統就叫做流處理系統。

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

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

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

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

Apache Storm

Apache Storm是一種側重于低延遲的流處理框架，它可以處理海量的接入數據，以近實時方式處理數據。Storm延時可以達到亞秒級。Storm含有如下關鍵概念：

Topology：Storm topology中封裝了實時應用程序的邏輯。Storm topology類似于MapReduce作業，但區別是MapReduce最終會完成，而topology則會一直運行(除非被強制停止)。Topology是由spouts和bolts組成的DAG(有向無環圖)。

Stream:Stream是一種不斷被接入Storm中的無界的數據序列。

Spout：Spout是topology中Stream的源。Spout從外部數據源讀取數據并接入到Strom系統中

Bolt：Bolt用于Storm中的數據處理，它可以進行過濾、聚合、連接等操作。將不同的bolt連接組成完整的數據處理鏈條，最后一個bolt用來輸出(到文件系統或數據庫等)。

Storm的基本思想是使用spout拉取stream(數據)，并使用bolt進行處理和輸出。默認情況下Storm提供了“at least once”的保證，即每條數據被至少消費一次。當一些特殊情況(比如服務器故障等)發生時，可能會導致重復消費。為了實現“exactly once”(即有且僅有一次消費)，Storm引入了Trident。Trident可以將Storm的單條處理方式改變為微批處理方式，但同時也會對Storm的處理能力產生一定的影響。

值得一提的是，一些國內的公司在Storm的基礎上進行了改進，為推動流處理系統的發展做出了很大貢獻。阿里巴巴的JStorm參考了Storm，并在網絡IO、線程模型、資源調度及穩定性上做了改進。而華為的StreamCQL則為Storm提供了SQL查詢語義。

Apache Samza

提到Apache Samza，就不得不提到當前最流行的大數據消息中間件：Apache Kafka。Apache 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

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

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

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

一些處理框架既可以進行批處理，也可以進行流處理。這些框架可以使用相同或相關的API處理歷史和實時數據。當前主流的混合處理框架主要為Spark和Flink。

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

Apache Spark

如果說如今大數據處理框架處于一個群星閃耀的年代，那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)。

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

Apache Flink

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

Flink的流處理模型將逐項輸入的數據作為真實的流處理。Flink提供了DataStream API用于處理無盡的數據流。Flink的基本組件包括：

Stream：Stream是流過系統的不可變的、無界的數據集

Operator：Operator用來操作數據流以產生新的數據流(stream)

Source：Source是數據流(stream)進入系統的入口

Sink：Sink是數據流(stream)流出Flink系統后的位置。

它可能是數據庫或到其他系統的連接器

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

Flink的提供了DataSet API用于批處理。Flink的批處理在很大程度上可以看作是流處理的一種擴展，它讀取在持久存儲系統上的數據，并把去除的數據集當成一個有邊界的流來處理。

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

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

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

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

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