前言
說起大數(shù)據(jù)處理，一切都起源于Google公司的經(jīng)典論文：《MapReduce:Simplied Data Processing on Large Clusters》。在當時（2000年左右），由于網(wǎng)頁數(shù)量急劇增加，Google公司內(nèi)部平時要編寫很多的程序來處理大量的原始數(shù)據(jù)：爬蟲爬到的網(wǎng)頁、網(wǎng)頁請求日志；計算各種類型的派生數(shù)據(jù)：倒排索引、網(wǎng)頁的各種圖結(jié)構(gòu)等等。這些計算在概念上很容易理解，但由于輸入數(shù)據(jù)量很大，單機難以處理。所以需要利用分布式的方式完成計算，并且需要考慮如何進行并行計算、分配數(shù)據(jù)和處理失敗等等問題。
針對這些復(fù)雜的問題，Google決定設(shè)計一套抽象模型來執(zhí)行這些簡單計算，并隱藏并發(fā)、容錯、數(shù)據(jù)分布和均衡負載等方面的細節(jié)。受到Lisp和其它函數(shù)式編程語言map、reduce思想的啟發(fā)，論文的作者意識到許多計算都涉及對每條數(shù)據(jù)執(zhí)行map操作，得到一批中間key/value對，然后利用reduce操作合并那些key值相同的k-v對。這種模型能很容易實現(xiàn)大規(guī)模并行計算。
事實上，與很多人理解不同的是，MapReduce對大數(shù)據(jù)計算的最大貢獻，其實并不是它名字直觀顯示的Map和Reduce思想（正如上文提到的，Map和Reduce思想在Lisp等函數(shù)式編程語言中很早就存在了），而是這個計算框架可以運行在一群廉價的PC機上。MapReduce的偉大之處在于給大眾們普及了工業(yè)界對于大數(shù)據(jù)計算的理解：它提供了良好的橫向擴展性和容錯處理機制，至此大數(shù)據(jù)計算由集中式過渡至分布式。以前，想對更多的數(shù)據(jù)進行計算就要造更快的計算機，而現(xiàn)在只需要添加計算節(jié)點。
話說當年的Google有三寶：MapReduce、GFS和BigTable。但Google三寶雖好，尋常百姓想用卻用不上，原因很簡單：它們都不開源。于是Hadoop應(yīng)運而生，初代Hadoop的MapReduce和HDFS即為Google的MapReduce和GFS的開源實現(xiàn)（另一寶BigTable的開源實現(xiàn)是同樣大名鼎鼎的HBase）。自此，大數(shù)據(jù)處理框架的歷史大幕正式的緩緩拉開。
一、基礎(chǔ)
1.大數(shù)據(jù)的定義
“大數(shù)據(jù)”一詞的確切定義其實是很難給出的，因為不同的人（供應(yīng)商、從業(yè)者、商業(yè)公司等）對它的理解也并不完全一致。通常來講，大數(shù)據(jù)是：
大數(shù)據(jù)集
用于處理大數(shù)據(jù)集的某類技術(shù)
此處的“大數(shù)據(jù)集”是指一個數(shù)據(jù)集的數(shù)據(jù)量太大以至于無法使用傳統(tǒng)工具或單機方式來處理和存儲，而處理技術(shù)包括數(shù)據(jù)接入、數(shù)據(jù)持久化存儲、數(shù)據(jù)計算和分析、數(shù)據(jù)展示（可視化）等等。
2.大數(shù)據(jù)的特征
大數(shù)據(jù)系統(tǒng)的基本需求與傳統(tǒng)系統(tǒng)并沒有本質(zhì)上的不同。但大數(shù)據(jù)系統(tǒng)雖然具有海量的數(shù)據(jù)規(guī)模，但是對數(shù)據(jù)的接入和處理速度上也有較高的要求，而且在每個階段都要對數(shù)據(jù)進行處理。這些特點還是為設(shè)計解決方案時提供了新的挑戰(zhàn)。
在2001年，美國Gartner公司的Doug Laney首先提出了“3V”模型來描述大數(shù)據(jù)處理系統(tǒng)與傳統(tǒng)數(shù)據(jù)處理系統(tǒng)的不同：
Volume
待處理數(shù)據(jù)的規(guī)模在很大程度決定了系統(tǒng)是否為大數(shù)據(jù)系統(tǒng)。大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)規(guī)?？赡鼙葌鹘y(tǒng)處理系統(tǒng)中的數(shù)據(jù)集大幾個數(shù)量級，這也為數(shù)據(jù)處理和存儲帶來了更多的挑戰(zhàn)。由于數(shù)據(jù)處理和存儲等工作超出了單臺計算機所能達到的性能極限，所以大數(shù)據(jù)系統(tǒng)通常采用集群方式。集群方式更加考驗資源的分配和協(xié)調(diào)，集群管理和任務(wù)分配算法變得越來越重要。
Velocity
大數(shù)據(jù)與其他數(shù)據(jù)系統(tǒng)另一個顯著的差異體現(xiàn)在數(shù)據(jù)的“流動”速度。在大數(shù)據(jù)系統(tǒng)中，數(shù)據(jù)經(jīng)常從多種數(shù)據(jù)源流入系統(tǒng)，并且以一種近實時的方式進行處理。數(shù)據(jù)被持續(xù)不斷的接入、修改、處理和分析以便能夠跟得上新數(shù)據(jù)的接入速度。由于近實時處理可以盡早的提供有價值的信息，目前很多商業(yè)公司更加青睞于實時處理系統(tǒng)而不是傳統(tǒng)的批處理系統(tǒng)。
Variety
大數(shù)據(jù)系統(tǒng)的問題通常是其他系統(tǒng)所不具備的，因為它所處理的數(shù)據(jù)來源廣泛。數(shù)據(jù)源可以是應(yīng)用程序的日志信息，也可以是社交媒體的用戶信息，甚至是物理設(shè)備傳感器的采集數(shù)據(jù)。不論何種數(shù)據(jù)，大數(shù)據(jù)系統(tǒng)的目標都是在海量數(shù)據(jù)中尋找有用的數(shù)據(jù)。
3.大數(shù)據(jù)處理流程
那么大數(shù)據(jù)系統(tǒng)實際上是如何處理數(shù)據(jù)的呢？雖然不同公司的架構(gòu)設(shè)計不盡相同，但我們可以總結(jié)出一個基本的流程。下面介紹的流程雖然不是適用于所有情況，但它們確實被廣泛使用。大數(shù)據(jù)處理的基本流程是：
接入數(shù)據(jù)到系統(tǒng)中
將數(shù)據(jù)持久化到存儲系統(tǒng)
計算和分析數(shù)據(jù)
展示結(jié)果（可視化）
4.大數(shù)據(jù)處理框架的定義
說完了大數(shù)據(jù)，我們來說說本文的重點——大數(shù)據(jù)處理框架。大數(shù)據(jù)處理框架負責對大數(shù)據(jù)系統(tǒng)中的數(shù)據(jù)進行計算。數(shù)據(jù)包括從持久存儲中讀取的數(shù)據(jù)或通過消息隊列等方式接入到系統(tǒng)中的數(shù)據(jù)，而計算則是從數(shù)據(jù)中提取信息的過程。除了大數(shù)據(jù)處理框架，有些同學(xué)可能還聽到過“大數(shù)據(jù)計算框架”、“大數(shù)據(jù)框架”，這些術(shù)語沒有嚴格的區(qū)分，但基本可以理解為是一種東西，只不過是對“big data processing framework”不同的翻譯（大數(shù)據(jù)框架是“big data framework”的翻譯）。
還有一個名詞是“大數(shù)據(jù)處理引擎”，那么這個“引擎”和我們說的“框架”又有什么關(guān)系呢？其實并沒有區(qū)分他們的權(quán)威的定義，但一般來說，前者是實際負責處理操作的組件，而后者可以理解為用來完成同樣工作的一系列組件。比如Apache Hadoop可以看做是以MapReduce為默認處理引擎的處理框架。
二、數(shù)據(jù)處理框架分類
不論是系統(tǒng)中存在的歷史數(shù)據(jù)，還是持續(xù)不斷接入系統(tǒng)中的實時數(shù)據(jù)，只要數(shù)據(jù)是可訪問的，我們就可以對數(shù)據(jù)進行處理。按照對所處理的數(shù)據(jù)形式和得到結(jié)果的時效性分類，數(shù)據(jù)處理框架可以分為兩類：
批處理系統(tǒng)
流處理系統(tǒng)
批處理是一種用來計算大規(guī)模數(shù)據(jù)集的方法。批處理的過程包括將任務(wù)分解為較小的任務(wù)，分別在集群中的每個計算機上進行計算，根據(jù)中間結(jié)果重新組合數(shù)據(jù)，然后計算和組合最終結(jié)果。當處理非常巨大的數(shù)據(jù)集時，批處理系統(tǒng)是最有效的。
典型的批處理系統(tǒng)就是Apache Hadoop。而流處理則對由連續(xù)不斷的單條數(shù)據(jù)項組成的數(shù)據(jù)流進行操作，注重數(shù)據(jù)處理結(jié)果的時效性。典型的流處理系統(tǒng)有Apache Storm，Apache Samza。還有一種系統(tǒng)，同時具備批處理與流處理的能力，這種稱為混合處理系統(tǒng)，比如Apache Spark，Apache Flink。接下來我們來詳細介紹這三種處理系統(tǒng)。
三、批處理系統(tǒng)
批處理系統(tǒng)在大數(shù)據(jù)世界中有著悠久的歷史。批處理系統(tǒng)主要操作大量的、靜態(tài)的數(shù)據(jù)，并且等到全部處理完成后才能得到返回的結(jié)果。批處理系統(tǒng)中的數(shù)據(jù)集一般符合以下特征：
有限：數(shù)據(jù)集中的數(shù)據(jù)必須是有限的（無限的數(shù)據(jù)一批就處理不完了啊。連續(xù)不斷的數(shù)據(jù)一般會使用流處理系統(tǒng)來進行處理，我們后面會講到）
持久：批處理系統(tǒng)處理的數(shù)據(jù)一般存儲在持久存儲系統(tǒng)上（比如硬盤上、數(shù)據(jù)庫中）
海量：極海量的數(shù)據(jù)通常只能使用批處理系統(tǒng)來處理。批處理系統(tǒng)在設(shè)計之初就充分的考慮了數(shù)據(jù)量巨大的問題，實際上批處理系統(tǒng)也是為此而生的。
由于批處理系統(tǒng)在處理海量的持久數(shù)據(jù)方面表現(xiàn)出色，所以它通常被用來處理歷史數(shù)據(jù)，很多OLAP（在線分析處理）系統(tǒng)的底層計算框架就是使用的批處理系統(tǒng)。但是由于海量數(shù)據(jù)的處理需要耗費很多時間，所以批處理系統(tǒng)一般不適合用于對延時要求較高的場景。
Apache Hadoop
說起大數(shù)據(jù)處理框架，永遠也繞不開Hadoop。Hadoop是首個在開源社區(qū)獲得極大關(guān)注的大數(shù)據(jù)處理框架，在很長一段時間內(nèi)，它幾乎可以作為大數(shù)據(jù)技術(shù)的代名詞。在2.0版本以后，Hadoop由以下組件組成：
Hadoop分布式文件系統(tǒng)HDFS：HDFS是一種分布式文件系統(tǒng)，它具有很高的容錯性，適合部署在廉價的機器集群上。HDFS能提供高吞吐量的數(shù)據(jù)訪問，非常適合在大規(guī)模數(shù)據(jù)集上使用。它可以用于存儲數(shù)據(jù)源，也可以存儲計算的最終結(jié)果。
資源管理器YARN：YARN可以為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它可以管理服務(wù)器的資源（主要是CPU和內(nèi)存），并負責調(diào)度作業(yè)的運行。在Hadoop中，它被設(shè)計用來管理MapReduce的計算服務(wù)。但現(xiàn)在很多其他的大數(shù)據(jù)處理框架也可以將YARN作為資源管理器，比如Spark。
MapReduce：即為Hadoop中默認的數(shù)據(jù)處理引擎，也是Google的MapReduce論文思想的開源實現(xiàn)。使用HDFS作為數(shù)據(jù)源，使用YARN進行資源管理。
從今天的眼光來看，MapReduce作為Hadoop默認的數(shù)據(jù)處理引擎，存在著很多的不足。比如：編程模型抽象程度較低，僅支持Map和Reduce兩種操作，需要手工編寫大量的代碼；Map的中間結(jié)果需要寫入磁盤，多個MR之間需要使用HDFS交換數(shù)據(jù)，因此不適合迭代計算（機器學(xué)習、圖計算）；任務(wù)的啟動和調(diào)度開銷較大等。隨著更多高性能處理引擎的發(fā)展，目前在企業(yè)中使用MapReduce進行計算的應(yīng)用已經(jīng)呈下降趨勢（HDFS及YARN仍然被廣泛使用），但雖然如此，MapReduce作為最早的大數(shù)據(jù)處理引擎，仍然值得被我們銘記。
四、流處理系統(tǒng)
批處理系統(tǒng)好理解，那什么是流處理系統(tǒng)呢？小學(xué)的時候我們都做過這么一道數(shù)學(xué)題：一個水池有一個進水管和一個出水管，只打開進水管8個小時充滿水，只打開出水管6個小時流光水，那么同時打開進水管和出水管，水池多長時間充滿水？
好吧，這道題的答案是永遠也充不滿……因為出水管出水比較快嘛。流處理系統(tǒng)就相當于這個水池，把流進來的水（數(shù)據(jù)）進行加工，比如加鹽讓它變成鹽水，然后再把加工過的水（數(shù)據(jù)）從出水管放出去。這樣，數(shù)據(jù)就像水流一樣永不停止，而且在水池中就被處理過了。所以，這種處理永不停止的接入數(shù)據(jù)的系統(tǒng)就叫做流處理系統(tǒng)。
流處理系統(tǒng)與批處理系統(tǒng)所處理的數(shù)據(jù)不同之處在于，流處理系統(tǒng)并不對已經(jīng)存在的數(shù)據(jù)集進行操作，而是對從外部系統(tǒng)接入的的數(shù)據(jù)進行處理。流處理系統(tǒng)可以分為兩種：
逐項處理：每次處理一條數(shù)據(jù)，是真正意義上的流處理。
微批處理：這種處理方式把一小段時間內(nèi)的數(shù)據(jù)當作一個微批次，對這個微批次內(nèi)的數(shù)據(jù)進行處理。
不論是哪種處理方式，其實時性都要遠遠好于批處理系統(tǒng)。因此，流處理系統(tǒng)非常適合應(yīng)用于對實時性要求較高的場景，比如日志分析，設(shè)備監(jiān)控、網(wǎng)站實時流量變化等等。由于很多情況下，我們想要盡快看到計算結(jié)果，所以近些年流處理系統(tǒng)的應(yīng)用越來越廣泛。下面我們來了解兩種流處理系統(tǒng)。
Apache Storm
Apache Storm是一種側(cè)重于低延遲的流處理框架，它可以處理海量的接入數(shù)據(jù)，以近實時方式處理數(shù)據(jù)。Storm延時可以達到亞秒級。Storm含有如下關(guān)鍵概念：
Topology：Storm topology中封裝了實時應(yīng)用程序的邏輯。Storm topology類似于MapReduce作業(yè)，但區(qū)別是MapReduce最終會完成，而topology則會一直運行（除非被強制停止）。Topology是由spouts和bolts組成的DAG（有向無環(huán)圖）。
Stream：Stream是一種不斷被接入Storm中的無界的數(shù)據(jù)序列。
Spout：Spout是topology中Stream的源。Spout從外部數(shù)據(jù)源讀取數(shù)據(jù)并接入到Strom系統(tǒng)中
Bolt：Bolt用于Storm中的數(shù)據(jù)處理，它可以進行過濾、聚合、連接等操作。將不同的bolt連接組成完整的數(shù)據(jù)處理鏈條，最后一個bolt用來輸出（到文件系統(tǒng)或數(shù)據(jù)庫等）。
Storm的基本思想是使用spout拉取stream（數(shù)據(jù)），并使用bolt進行處理和輸出。默認情況下Storm提供了“at least once”的保證，即每條數(shù)據(jù)被至少消費一次。當一些特殊情況（比如服務(wù)器故障等）發(fā)生時，可能會導(dǎo)致重復(fù)消費。為了實現(xiàn)“exactly once”（即有且僅有一次消費），Storm引入了Trident。Trident可以將Storm的單條處理方式改變?yōu)槲⑴幚矸绞?，但同時也會對Storm的處理能力產(chǎn)生一定的影響。
值得一提的是，一些國內(nèi)的公司在Storm的基礎(chǔ)上進行了改進，為推動流處理系統(tǒng)的發(fā)展做出了很大貢獻。阿里巴巴的JStorm參考了Storm，并在網(wǎng)絡(luò)IO、線程模型、資源調(diào)度及穩(wěn)定性上做了改進。而華為的StreamCQL則為Storm提供了SQL查詢語義。
Apache Samza
提到Apache Samza，就不得不提到當前最流行的大數(shù)據(jù)消息中間件：Apache Kafka。Apache Kafka是一個分布式的消息中間件系統(tǒng)，具有高吞吐、低延時等特點，并且自帶了容錯機制。以下是Kafka的關(guān)鍵概念：
Broker：由于Kafka是分布式消息中間件，所以需要多個節(jié)點來存儲數(shù)據(jù)。Broker即為Kafka集群中的單個節(jié)點。
Topic：用于存儲寫入Kafka的數(shù)據(jù)流。如同它的字面含義——主題，不同主題的數(shù)據(jù)流最好寫入不同的topic，方便后續(xù)的處理。
Partition：每個topic都有1到多個partition，便于分散到不同的borker中。多個partition的數(shù)據(jù)合并在一起組成了topic完整的數(shù)據(jù)。
Producer：消息的生產(chǎn)者，用來將消息寫入到Kafka集群。
Consumer：消息的消費者，用來讀取Kafka中的消息并進行處理。
雖然Kafka被廣泛應(yīng)用于各種流處理系統(tǒng)做數(shù)據(jù)源，但Samza可以更好的發(fā)揮Kafka架構(gòu)的優(yōu)勢。根據(jù)官網(wǎng)的解釋，Samza由三個層次組成：
數(shù)據(jù)流層
執(zhí)行層
處理層
支持三個層次的組件分別為：
Kafka
YARN
Samza API
也就是說，Samza使用Kafka提供了數(shù)據(jù)流，使用YARN進行資源管理，自身僅提供了操作數(shù)據(jù)流的API。Samza對Kafka和YARN的依賴在很多方面上與MapReduce對HDFS和YARN的依賴相似。
如果已經(jīng)擁有Hadoop集群和Kafka集群環(huán)境，那么使用Samza作為流處理系統(tǒng)無疑是一個非常好的選擇。由于可以很方便的將處理過的數(shù)據(jù)再次寫入Kafka，Samza尤其適合不同團隊之間合作開發(fā)，處理不同階段的多個數(shù)據(jù)流。
五、混合處理系統(tǒng)：批處理和流處理
一些處理框架既可以進行批處理，也可以進行流處理。這些框架可以使用相同或相關(guān)的API處理歷史和實時數(shù)據(jù)。當前主流的混合處理框架主要為Spark和Flink。
雖然專注于一種處理方式可能非常適合特定場景，但是混合框架為數(shù)據(jù)處理提供了通用的解決方案。
Apache Spark
如果說如今大數(shù)據(jù)處理框架處于一個群星閃耀的年代，那Spark無疑就是所有星星中最閃亮的那一顆。Spark由加州大學(xué)伯克利分校AMP實驗室開發(fā)，最初的設(shè)計受到了MapReduce思想的啟發(fā)，但不同于MapReduce的是，Spark通過內(nèi)存計算模型和執(zhí)行優(yōu)化大幅提高了對數(shù)據(jù)的處理能力（在不同情況下，速度可以達到MR的10-100倍，甚至更高）。相比于MapReduce，Spark具有如下優(yōu)點：
提供了內(nèi)存計算模型RDD（Resilient Distributed Dataset，彈性分布式數(shù)據(jù)集），將數(shù)據(jù)讀入內(nèi)存中生成一個RDD，再對RDD進行計算。并且每次計算結(jié)果可以緩存在內(nèi)存中，減少了磁盤IO。因此很適用于迭代計算。
不同于MapReduce的MR模型，Spark采用了DAG編程模型，將不同步驟的操作串聯(lián)成一個有向無環(huán)圖，可以有效減少任務(wù)間的數(shù)據(jù)傳遞，提高了性能。
提供了豐富的編程模型，可以輕松實現(xiàn)過濾、連接、聚合等操作，代碼量相比MapReduce少到令人發(fā)指，因此可以提高開發(fā)人員的生產(chǎn)力。
支持Java、Scala、Python和R四種編程語言，為不同語言的使用者降低了學(xué)習成本。
而Spark的流處理能力，則是由Spark Streaming模塊提供的。Spark在設(shè)計之初與MapReduce一樣是用于批處理系統(tǒng)，為了適應(yīng)于流處理模式，Spark提出了微批次（Micro-Batch）的概念，即把一小段時間內(nèi)的接入數(shù)據(jù)作為一個微批次來處理。這樣做的優(yōu)點是在設(shè)計Spark Streaming時可以很大程度上重用批處理模塊（Spark Core）的代碼，開發(fā)人員也不必學(xué)習兩套編程模型。但缺點就是，與Storm等原生的流處理系統(tǒng)相比，Spark Streaming的延時會相對高一些。
除了最初開發(fā)用于批處理的Spark Core和用于流處理的Spark Streaming，Spark還提供了其他編程模型用于支持圖計算（GraphX）、交互式查詢（Spark SQL）和機器學(xué)習（MLlib）。
但Spark也不是沒有缺點。在批處理領(lǐng)域，由于內(nèi)存是比硬盤更昂貴的資源，所以Spark集群的成本比MapReduce集群更高。而在流處理領(lǐng)域，微批次的架構(gòu)使得它的延時要比Storm等流處理系統(tǒng)略高。不過瑕不掩瑜，Spark依然是如今最炙手可熱的數(shù)據(jù)處理框架。
Apache Flink
有趣的是，同樣作為混合處理框架，F(xiàn)link的思想與Spark是完全相反的：Spark把流拆分成若干個小批次來處理，而Flink把批處理任務(wù)當作有界的流來處理。其本質(zhì)原因是，Spark最初是被設(shè)計用來進行批處理的，而Flink最初是被設(shè)計用來進行流處理的。這種流處理優(yōu)先的方式叫做Kappa架構(gòu)，與之相對的使用批處理優(yōu)先的架構(gòu)叫做Lambda架構(gòu)。Kappa架構(gòu)會使用處理流的方式處理一切，以此來簡化編程模型。這一切是在最近流處理引擎逐漸成熟起來才有可能實現(xiàn)的。
Flink的流處理模型將逐項輸入的數(shù)據(jù)作為真實的流處理。Flink提供了DataStream API用于處理無盡的數(shù)據(jù)流。Flink的基本組件包括：
Stream：Stream是流過系統(tǒng)的不可變的、無界的數(shù)據(jù)集
Operator：Operator用來操作數(shù)據(jù)流以產(chǎn)生新的數(shù)據(jù)流（stream）
Source：Source是數(shù)據(jù)流（stream）進入系統(tǒng)的入口
Sink：Sink是數(shù)據(jù)流（stream）流出Flink系統(tǒng)后的位置。它可能是數(shù)據(jù)庫或到其他系統(tǒng)的連接器
Flink的流處理思想與Storm類似，以source接入數(shù)據(jù)，通過不同的operator進行transformation，最后輸出到sink。
Flink的提供了DataSet API用于批處理。Flink的批處理在很大程度上可以看作是流處理的一種擴展，它讀取在持久存儲系統(tǒng)上的數(shù)據(jù)，并把去除的數(shù)據(jù)集當成一個有邊界的流來處理。
與Spark相同，F(xiàn)link也提供了較為完整的數(shù)據(jù)處理方式。除了上面介紹的流處理（DataStream API）和批處理（DataSet API）之外，F(xiàn)link還提供了類SQL查詢（Table API）、圖計算（Gelly）和機器學(xué)習庫（Flink ML）。而令人驚訝的是，在很多性能測試中，F(xiàn)link甚至略優(yōu)于Spark。
在目前的數(shù)據(jù)處理框架領(lǐng)域，F(xiàn)link可謂獨樹一幟。雖然Spark同樣也提供了批處理和流處理的能力，但Spark流處理的微批次架構(gòu)使其響應(yīng)時間略長。Flink流處理優(yōu)先的方式實現(xiàn)了低延遲、高吞吐和真正逐條處理。
同樣，F(xiàn)link也并不是完美的。Flink目前最大的缺點就是缺乏在大型公司實際生產(chǎn)項目中的成功應(yīng)用案例。相對于Spark來講，它還不夠成熟，社區(qū)活躍度也沒有Spark那么高。但假以時日，F(xiàn)link必然會改變數(shù)據(jù)處理框架的格局。
六、大數(shù)據(jù)處理框架的選擇
1.對于初學(xué)者
由于Apache Hadoop在大數(shù)據(jù)領(lǐng)域的廣泛使用，因此仍推薦作為初學(xué)者學(xué)習數(shù)據(jù)處理框架的首選。雖然MapReduce因為性能原因以后的應(yīng)用會越來越少，但是YARN和HDFS依然作為其他框架的基礎(chǔ)組件被大量使用（比如HBase依賴于HDFS，YARN可以為Spark、Samza等框架提供資源管理）。學(xué)習Hadoop可以為以后的進階打下基礎(chǔ)。
Apache Spark在目前的企業(yè)應(yīng)用中應(yīng)該是當之無愧的王者。在批處理領(lǐng)域，雖然Spark與MapReduce的市場占有率不相上下，但Spark穩(wěn)定上升，而MapReduce卻穩(wěn)定下降。而在流處理領(lǐng)域，Spark Streaming與另一大流處理系統(tǒng)Apache Storm共同占據(jù)了大部分市場（當然很多公司會使用內(nèi)部研發(fā)的數(shù)據(jù)處理框架，但它們多數(shù)并不開源）。伯克利的正統(tǒng)出身、活躍的社區(qū)以及大量的商用案例都是Spark的優(yōu)勢。除了可用于批處理和流處理系統(tǒng)，Spark還支持交互式查詢、圖計算和機器學(xué)習。Spark在未來幾年內(nèi)仍然會是大數(shù)據(jù)處理的主流框架，推薦同學(xué)們認真學(xué)習。
另一個作為混合處理框架的Apache Flink則潛力無限，被稱作“下一代數(shù)據(jù)處理框架”。雖然目前存在社區(qū)活躍度不夠高、商用案例較少等情況，不過“是金子總會發(fā)光”，如果Flink能在商業(yè)應(yīng)用上有突出表現(xiàn)，則可能挑戰(zhàn)Spark的地位。
2.對于企業(yè)應(yīng)用
如果企業(yè)中只需要批處理工作，并且對時間并不敏感，那么可以使用成本較其他解決方案更低的Hadoop集群。
如果企業(yè)僅進行流處理，并且對低延遲有著較高要求，Storm更加適合，如果對延遲不非常敏感，可以使用Spark Streaming。而如果企業(yè)內(nèi)部已經(jīng)存在Kafka和Hadoop集群，并且需要多團隊合作開發(fā)（下游團隊會使用上游團隊處理過的數(shù)據(jù)作為數(shù)據(jù)源），那么Samza是一個很好的選擇。
如果需要同時兼顧批處理與流處理任務(wù)，那么Spark是一個很好的選擇。混合處理框架的另一個好處是，降低了開發(fā)人員的學(xué)習成本，從而為企業(yè)節(jié)約人力成本。Flink提供了真正的流處理能力并且同樣具備批處理能力，但商用案例較少，對于初次嘗試數(shù)據(jù)處理的企業(yè)來說，大規(guī)模使用Flink存在一定風險。
