搞大數據必知的處理框架技術，你的項目應該使用哪一種？

大數據是收集、整理、處理大容量數據集，並從中得到看法所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一臺計算機的上限，但這種計算類型的廣泛性、規模，以及價值在最近幾年才經歷了大規模擴展。

 

這裏將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和看法的過程。

下文將介紹這些框架：

僅批處理框架：

Apache Hadoop

僅流處理框架：

Apache Storm

Apache Samza

混合框架：

Apache Spark

Apache Flink

大數據處理框架是什麼?

處理框架和處理引擎負責對數據系統中的數據進行計算。雖然「引擎」和「框架」之間的區別沒有什麼權威的定義，但大部分時候能夠將前者定義爲實際負責處理數據操做的組件，後者則可定義爲承擔相似做用的一系列組件。

例如Apache Hadoop能夠看做一種以MapReduce做爲默認處理引擎的處理框架。引擎和框架一般能夠相互替換或同時使用。例如另外一個框架Apache Spark能夠歸入Hadoop並取代MapReduce。組件之間的這種互操做性是大數據系統靈活性如此之高的緣由之一。

雖然負責處理生命週期內這一階段數據的系統一般都很複雜，但從廣義層面來看它們的目標是很是一致的：經過對數據執行操做提升理解能力，揭示出數據蘊含的模式，並針對複雜互動得到看法。

爲了簡化這些組件的討論，咱們會經過不一樣處理框架的設計意圖，按照所處理的數據狀態對其進行分類。一些系統能夠用批處理方式處理數據，一些系統能夠用流方式處理接二連三流入系統的數據。此外還有一些系統能夠同時處理這兩類數據。

在深刻介紹不一樣實現的指標和結論以前，首先須要對不一樣處理類型的概念進行一個簡單的介紹。

批處理系統

批處理在大數據世界有着悠久的歷史。批處理主要操做大容量靜態數據集，並在計算過程完成後返回結果。

批處理模式中使用的數據集一般符合下列特徵...

有界：批處理數據集表明數據的有限集合

持久：數據一般始終存儲在某種類型的持久存儲位置中

大量：批處理操做一般是處理極爲海量數據集的惟一方法

批處理很是適合須要訪問全套記錄才能完成的計算工做。例如在計算總數和平均數時，必須將數據集做爲一個總體加以處理，而不能將其視做多條記錄的集合。這些操做要求在計算進行過程當中數據維持本身的狀態。

須要處理大量數據的任務一般最適合用批處理操做進行處理。不管直接從持久存儲設備處理數據集，或首先將數據集載入內存，批處理系統在設計過程當中就充分考慮了數據的量，可提供充足的處理資源。因爲批處理在應對大量持久數據方面的表現極爲出色，所以常常被用於對歷史數據進行分析。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

大量數據的處理須要付出大量時間，所以批處理不適合對處理時間要求較高的場合。

Apache Hadoop

Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社區得到極大關注的大數據框架。基於谷歌有關海量數據處理所發表的多篇論文與經驗的Hadoop從新實現了相關算法和組件堆棧，讓大規模批處理技術變得更易用。

新版Hadoop包含多個組件，即多個層，經過配合使用可處理批數據：

HDFS：HDFS是一種分佈式文件系統層，可對集羣節點間的存儲和複製進行協調。HDFS確保了沒法避免的節點故障發生後數據依然可用，可將其用做數據來源，可用於存儲中間態的處理結果，並可存儲計算的最終結果。

YARN：YARN是Yet Another Resource Negotiator(另外一個資源管理器)的縮寫，可充當Hadoop堆棧的集羣協調組件。該組件負責協調並管理底層資源和調度做業的運行。經過充當集羣資源的接口，YARN使得用戶能在Hadoop集羣中使用比以往的迭代方式運行更多類型的工做負載。

MapReduce：MapReduce是Hadoop的原生批處理引擎。

批處理模式

Hadoop的處理功能來自MapReduce引擎。MapReduce的處理技術符合使用鍵值對的map、shuffle、reduce算法要求。基本處理過程包括：

從HDFS文件系統讀取數據集

將數據集拆分紅小塊並分配給全部可用節點

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

從新分配中間態結果並按照鍵進行分組

經過對每一個節點計算的結果進行彙總和組合對每一個鍵的值進行「Reducing」

將計算而來的最終結果從新寫入 HDFS

優點和侷限

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

MapReduce的學習曲線較爲陡峭，雖然Hadoop生態系統的其餘周邊技術能夠大幅下降這一問題的影響，但經過Hadoop集羣快速實現某些應用時依然須要注意這個問題。

圍繞Hadoop已經造成了遼闊的生態系統，Hadoop集羣自己也常常被用做其餘軟件的組成部件。不少其餘處理框架和引擎經過與Hadoop集成也可使用HDFS和YARN資源管理器。

總結

Apache Hadoop及其MapReduce處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的很是大規模數據集。經過很是低成本的組件便可搭建完整功能的Hadoop集羣，使得這一廉價且高效的處理技術能夠靈活應用在不少案例中。與其餘框架和引擎的兼容與集成能力使得Hadoop能夠成爲使用不一樣技術的多種工做負載處理平臺的底層基礎。

流處理系統

流處理系統會對隨時進入系統的數據進行計算。相比批處理模式，這是一種大相徑庭的處理方式。流處理方式無需針對整個數據集執行操做，而是對經過系統傳輸的每一個數據項執行操做。

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

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

工做數據集也許更相關，在特定時間只能表明某個單一數據項。

處理工做是基於事件的，除非明確中止不然沒有「盡頭」。處理結果馬上可用，並會隨着新數據的抵達繼續更新。

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

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

此類處理很是適合某些類型的工做負載。有近實時處理需求的任務很適合使用流處理模式。分析、服務器或應用程序錯誤日誌，以及其餘基於時間的衡量指標是最適合的類型，由於對這些領域的數據變化作出響應對於業務職能來講是極爲關鍵的。流處理很適合用來處理必須對變更或峯值作出響應，而且關注一段時間內變化趨勢的數據。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

Apache Storm

Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工做負載的最佳選擇。該技術可處理很是大量的數據，經過比其餘解決方案更低的延遲提供結果。

流處理模式

Storm的流處理可對框架中名爲Topology(拓撲)的DAG(Directed Acyclic Graph，有向無環圖)進行編排。這些拓撲描述了當數據片斷進入系統後，須要對每一個傳入的片斷執行的不一樣轉換或步驟。

拓撲包含：

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

Spout：位於拓撲邊緣的數據流來源，例如能夠是API或查詢等，從這裏能夠產生待處理的數據。

Bolt：Bolt表明須要消耗流數據，對其應用操做，並將結果以流的形式進行輸出的處理步驟。Bolt須要與每一個Spout創建鏈接，隨後相互鏈接以組成全部必要的處理。在拓撲的尾部，可使用最終的Bolt輸出做爲相互鏈接的其餘系統的輸入。

Storm背後的想法是使用上述組件定義大量小型的離散操做，隨後將多個組件組成所需拓撲。默認狀況下Storm提供了「至少一次」的處理保證，這意味着能夠確保每條消息至少能夠被處理一次，但某些狀況下若是遇到失敗可能會處理屢次。Storm沒法確保能夠按照特定順序處理消息。

爲了實現嚴格的一次處理，即有狀態處理，可使用一種名爲Trident的抽象。嚴格來講不使用Trident的Storm一般可稱之爲Core Storm。Trident會對Storm的處理能力產生極大影響，會增長延遲，爲處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。

爲避免這些問題，一般建議Storm用戶儘量使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些狀況下也比較有用，例如系統沒法智能地處理重複消息時。若是須要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個連接，此時Trident將是你惟一的選擇。儘管不能充分發揮框架與生俱來的優點，但Trident提升了Storm的靈活性。

Trident拓撲包含：

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

操做(Operation)：是指能夠對數據執行的批處理過程。

優點和侷限

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

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

Core Storm沒法保證消息的處理順序。Core Storm爲消息提供了「至少一次」的處理保證，這意味着能夠保證每條消息都能被處理，但也可能發生重複。Trident提供了嚴格的一次處理保證，能夠在不一樣批之間提供順序處理，但沒法在一個批內部實現順序處理。

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

總結

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

Apache Samza

Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用於不少流處理系統，但按照設計，Samza能夠更好地發揮Kafka獨特的架構優點和保障。該技術可經過Kafka提供容錯、緩衝，以及狀態存儲。

Samza可以使用YARN做爲資源管理器。這意味着默認狀況下須要具有Hadoop集羣(至少具有HDFS和YARN)，但同時也意味着Samza能夠直接使用YARN豐富的內建功能。

流處理模式

Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：

Topic(話題)：進入Kafka系統的每一個數據流可稱之爲一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。

Partition(分區)：爲了將一個話題分散至多個節點，Kafka會將傳入的消息劃分爲多個分區。分區的劃分將基於鍵(Key)進行，這樣能夠保證包含同一個鍵的每條消息能夠劃分至同一個分區。分區的順序可得到保證。

Broker(代理)：組成Kafka集羣的每一個節點也叫作代理。

Producer(生成方)：任何向Kafka話題寫入數據的組件能夠叫作生成方。生成方可提供將話題劃分爲分區所需的鍵。

Consumer(消耗方)：任何從Kafka讀取話題的組件可叫作消耗方。消耗方須要負責維持有關本身分支的信息，這樣便可在失敗後知道哪些記錄已經被處理過了。

因爲Kafka至關於永恆不變的日誌，Samza也須要處理永恆不變的數據流。這意味着任何轉換建立的新數據流均可被其餘組件所使用，而不會對最初的數據流產生影響。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

優點和侷限

乍看之下，Samza對Kafka類查詢系統的依賴彷佛是一種限制，然而這也能夠爲系統提供一些獨特的保證和功能，這些內容也是其餘流處理系統不具有的。

例如Kafka已經提供了能夠經過低延遲方式訪問的數據存儲副本，此外還能夠爲每一個數據分區提供很是易用且低成本的多訂閱者模型。全部輸出內容，包括中間態的結果均可寫入到Kafka，並可被下游步驟獨立使用。

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

Samza與Kafka之間緊密的關係使得處理步驟自己能夠很是鬆散地耦合在一塊兒。無需事先協調，便可在輸出的任何步驟中增長任意數量的訂閱者，對於有多個團隊須要訪問相似數據的組織，這一特性很是有用。多個團隊能夠所有訂閱進入系統的數據話題，或任意訂閱其餘團隊對數據進行過某些處理後建立的話題。這一切並不會對數據庫等負載密集型基礎架構形成額外的壓力。

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

Samza可使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza便可得到「至少一次」的交付保障，但面對因爲數據可能屢次交付形成的失敗，該技術沒法對彙總後狀態(例如計數)提供精確恢復。

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

總結

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

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

一些處理框架可同時處理批處理和流處理工做負載。這些框架能夠用相同或相關的組件和API處理兩種類型的數據，藉此讓不一樣的處理需求得以簡化。

如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不一樣處理模式如何進行統一，以及要對固定和不固定數據集之間的關係進行何種假設。

雖然側重於某一種處理類型的項目會更好地知足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不只能夠提供處理數據所需的方法，並且提供了本身的集成項、庫、工具，可勝任圖形分析、機器學習、交互式查詢等多種任務。

Apache Spark

Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapReduce引擎基於各類相同原則開發而來的Spark主要側重於經過完善的內存計算和處理優化機制加快批處理工做負載的運行速度。

Spark可做爲獨立集羣部署(須要相應存儲層的配合)，或可與Hadoop集成並取代MapReduce引擎。

批處理模式

與MapReduce不一樣，Spark的數據處理工做所有在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時須要與存儲層交互。全部中間態的處理結果均存儲在內存中。

雖然內存中處理方式可大幅改善性能，Spark在處理與磁盤有關的任務時速度也有很大提高，由於經過提早對整個任務集進行分析能夠實現更完善的總體式優化。爲此Spark可建立表明所需執行的所有操做，須要操做的數據，以及操做和數據之間關係的Directed Acyclic Graph(有向無環圖)，即DAG，藉此處理器能夠對任務進行更智能的協調。

爲了實現內存中批計算，Spark會使用一種名爲Resilient Distributed Dataset(彈性分佈式數據集)，即RDD的模型來處理數據。這是一種表明數據集，只位於內存中，永恆不變的結構。針對RDD執行的操做可生成新的RDD。每一個RDD可經過世系(Lineage)回溯至父級RDD，並最終回溯至磁盤上的數據。Spark可經過RDD在無需將每一個操做的結果寫回磁盤的前提下實現容錯。

流處理模式

流處理能力是由Spark Streaming實現的。Spark自己在設計上主要面向批處理工做負載，爲了彌補引擎設計和流處理工做負載特徵方面的差別，Spark實現了一種叫作微批(Micro-batch)*的概念。在具體策略方面該技術能夠將數據流視做一系列很是小的「批」，藉此便可經過批處理引擎的原生語義進行處理。

Spark Streaming會以亞秒級增量對流進行緩衝，隨後這些緩衝會做爲小規模的固定數據集進行批處理。這種方式的實際效果很是好，但相比真正的流處理框架在性能方面依然存在不足。

優點和侷限

使用Spark而非Hadoop MapReduce的主要緣由是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark能夠用更快速度處理相同的數據集。

Spark的另外一個重要優點在於多樣性。該產品可做爲獨立集羣部署，或與現有Hadoop集羣集成。該產品可運行批處理和流處理，運行一個集羣便可處理不一樣類型的任務。

除了引擎自身的能力外，圍繞Spark還創建了包含各類庫的生態系統，可爲機器學習、交互式查詢等任務提供更好的支持。相比MapReduce，Spark任務更是「衆所周知」地易於編寫，所以可大幅提升生產力。

爲流處理系統採用批處理的方法，須要對進入系統的數據進行緩衝。緩衝機制使得該技術能夠處理很是大量的傳入數據，提升總體吞吐率，但等待緩衝區清空也會致使延遲增高。這意味着Spark Streaming可能不適合處理對延遲有較高要求的工做負載。

因爲內存一般比磁盤空間更貴，所以相比基於磁盤的系統，Spark成本更高。然而處理速度的提高意味着能夠更快速完成任務，在須要按照小時數爲資源付費的環境中，這一特性一般能夠抵消增長的成本。

Spark內存計算這一設計的另外一個後果是，若是部署在共享的集羣中可能會遇到資源不足的問題。相比Hadoop MapReduce，Spark的資源消耗更大，可能會對須要在同一時間使用集羣的其餘任務產生影響。從本質來看，Spark更不適合與Hadoop堆棧的其餘組件共存一處。

總結

Spark是多樣化工做負載處理任務的最佳選擇。Spark批處理能力以更高內存佔用爲代價提供了無與倫比的速度優點。對於重視吞吐率而非延遲的工做負載，則比較適合使用Spark Streaming做爲流處理解決方案。

Apache Flink

Apache Flink是一種能夠處理批處理任務的流處理框架。該技術可將批處理數據視做具有有限邊界的數據流，藉此將批處理任務做爲流處理的子集加以處理。爲全部處理任務採起流處理爲先的方法會產生一系列有趣的反作用。

這種流處理爲先的方法也叫作Kappa架構，與之相對的是更加被廣爲人知的Lambda架構(該架構中使用批處理做爲主要處理方法，使用流做爲補充並提供早期未經提煉的結果)。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後纔可行的。

流處理模型

Flink的流處理模型在處理傳入數據時會將每一項視做真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：

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

Operator(操做方)是指針對數據流執行操做以產生其餘數據流的功能

Source(源)是指數據流進入系統的入口點

Sink(槽)是指數據流離開Flink系統後進入到的位置，槽能夠是數據庫或到其餘系統的鏈接器

爲了在計算過程當中遇到問題後可以恢復，流處理任務會在預約時間點建立快照。爲了實現狀態存儲，Flink可配合多種狀態後端系統使用，具體取決於所需實現的複雜度和持久性級別。

此外Flink的流處理能力還能夠理解「事件時間」這一律念，這是指事件實際發生的時間，此外該功能還能夠處理會話。這意味着能夠經過某種有趣的方式確保執行順序和分組。歡迎加入大數據學習交流分享羣： 658558542   一塊兒吹水交流學習（☛點擊便可加入羣聊）

批處理模型

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

Flink能夠對批處理工做負載實現必定的優化。例如因爲批處理操做可經過持久存儲加以支持，Flink能夠不對批處理工做負載建立快照。數據依然能夠恢復，但常規處理操做能夠執行得更快。

另外一個優化是對批處理任務進行分解，這樣便可在須要的時候調用不一樣階段和組件。藉此Flink能夠與集羣的其餘用戶更好地共存。對任務提早進行分析使得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管理的集羣上運行，所以能夠很方便地進行評估。快速進展的開發工做使其值得被你們關注。

結論

大數據系統可以使用多種處理技術。

對於僅須要批處理的工做負載，若是對時間不敏感，比其餘解決方案實現成本更低的Hadoop將會是一個好選擇。

對於僅須要流處理的工做負載，Storm可支持更普遍的語言並實現極低延遲的處理，但默認配置可能產生重複結果而且沒法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團隊使用，以及更簡單的複製和狀態管理。

對於混合型工做負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支持更完善，具有各類集成庫和工具，可實現靈活的集成。Flink提供了真正的流處理並具有批處理能力，經過深度優化可運行鍼對其餘平臺編寫的任務，提供低延遲的處理，但實際應用方面還爲時過早。

最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及但願獲得的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題須要慎重權衡。隨着逐漸成熟並被普遍接受，在評估任何新出現的創新型解決方案時都須要考慮相似的問題。

結語

感謝您的觀看，若有不足之處，歡迎批評指正。

若是有對大數據感興趣的小夥伴或者是從事大數據的老司機能夠加羣：

658558542    （☛點擊便可加入羣聊）

裏面整理了一大份學習資料，全都是些乾貨，包括大數據技術入門，海量數據高級分析語言，海量數據存儲分佈式存儲，以及海量數據分析分佈式計算等部分，送給每一位大數據小夥伴，這裏不止是小白彙集地，還有大牛在線解答！歡迎初學和進階中的小夥伴一塊兒進羣學習交流，共同進步！

最後祝福全部遇到瓶頸的大數據程序員們突破本身，祝福你們在日後的工做與面試中一切順利。