獨家 | 一文讀懂大資料處理架構

前言

說起大資料處理，一切都起源于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.大資料的定義 

“大資料”一詞的确切定義其實是很難給出的，因為不同的人（供應商、從業者、商業公司等）對它的了解也并不完全一緻。通常來講，大資料是：

大資料集

用于處理大資料集的某類技術

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

2.大資料的特征

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

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

Volume

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

Velocity

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

Variety

大資料系統的問題通常是其他系統所不具備的，因為它所處理的資料來源廣泛。資料源可以是應用程式的日志資訊，也可以是社交媒體的使用者資訊，甚至是實體裝置傳感器的采集資料。不論何種資料，大資料系統的目标都是在海量資料中尋找有用的資料。

3.大資料處理流程

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

接入資料到系統中

将資料持久化到存儲系統

計算和分析資料

展示結果（可視化）

4.大資料處理架構的定義

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

還有一個名詞是“大資料處理引擎”，那麼這個“引擎”和我們說的“架構”又有什麼關系呢？其實并沒有區分他們的權威的定義，但一般來說，前者是實際負責處理操作的元件，而後者可以了解為用來完成同樣工作的一系列元件。比如Apache Hadoop可以看做是以MapReduce為預設處理引擎的處理架構。

二、資料處理架構分類

不論是系統中存在的曆史資料，還是持續不斷接入系統中的實時資料，隻要資料是可通路的，我們就可以對資料進行處理。按照對所處理的資料形式和得到結果的時效性分類，資料處理架構可以分為兩類：

批處理系統

流處理系統

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

典型的批處理系統就是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存在一定風險。

七、學習資源

首先，任何開源項目最好的學習資源，就是官方文檔。一般來講，官方文檔都會給出從下載下傳到安裝再到基礎開發的一系列教程。推薦英語不算太差的同學盡量去撸官方文檔。

其次，一些比較好的書也會對學習有很大幫助。相對于網絡資源，書的優點是系統的列出了需要掌握的技能，缺點是時效性不高，尤其是中文版的書。不過下面還是列出了一些在資料處理方面經典的書籍，供同學們參考。

Hadoop：

《Hadoop權威指南》

連結位址：

https://book.douban.com/subject/26206050/

這本書被戲稱為大象書，包含了Hadoop核心的MapReduce、YARN和HDFS，及Hadoop生态圈中常用的HBase、Hive等技術，初學者可以通過此書對Hadoop生态有一個較為全面的認識。

《YARN權威指南》

https://book.douban.com/subject/26377893/

雖然YARN是資料總管，但是很多資料處理架構都用它來管理資源。想要深入了解YARN的同學們可以參考一下這本書。話說這本權威指南真的很權威，因為作者就是YARN的建立和開發團隊。

Spark

《Spark快速大資料分析》

https://book.douban.com/subject/26616244/

這本書也算是Spark最經典的入門書了，把Spark的基本概念和各個方面介紹的比較全面。缺點就是Spark發展比較快，是以這本書有點老了（2015年10月出版），有一小部分東西跟目前版本不太對應的上。

《Spark進階資料分析》

https://book.douban.com/subject/26647951/

這本書适合有一些Spark基礎的同學（比如讀完上一本書之後再讀），主要介紹了利用Spark進行資料分析和機器學習。缺點和上一本一樣，就是也有點老了。

《Spark GraphX》實戰

https://book.douban.com/subject/27004653/

這是一本專門介紹Spark的圖計算庫Spark GraphX的書。優點是比較新（2017年3月出版），應該可以緊跟目前版本。缺點也是比較新，還沒有太多人看過，是以不好評價。想嘗鮮的同學們不妨試試。

其他

由于Samza技術比較新，相對也沒那麼熱門，是以并沒有什麼靠譜的書可以推薦。Flink同樣也沒有出版的中文書，倒是已經出版了幾本英文書，不過英文原版書的價格大家懂的，土豪同學可以去電商網站上選購。Storm作為成熟的技術，世面上的中文書籍很多，但卻沒有一本書能獲得衆口一詞的好評，是以這裡也沒有推薦。 

原文釋出時間為：2017-06-23

本文作者：柴詩雨

本文來自雲栖社群合作夥伴“資料派THU”，了解相關資訊可以關注“資料派THU”微信公衆号