精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

優(yōu)勢和局限

目前來說Storm可能是近實(shí)時(shí)處理領(lǐng)域的最佳解決方案。該技術(shù)可以用極低延遲處理數(shù)據(jù)，可用于希望獲得最低延遲的工作負(fù)載。如果處理速度直接影響用戶體驗(yàn)，例如需要將處理結(jié)果直接提供給訪客打開的網(wǎng)站頁面，此時(shí)Storm將會(huì)是一個(gè)很好的選擇。

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

Core Storm無法保證消息的處理順序。Core Storm為消息提供了“至少一次”的處理保證，這意味著可以保證每條消息都能被處理，但也可能發(fā)生重復(fù)。Trident提供了嚴(yán)格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個(gè)批內(nèi)部實(shí)現(xiàn)順序處理。

在互操作性方面，Storm可與Hadoop的YARN資源管理器進(jìn)行集成，因此可以很方便地融入現(xiàn)有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓?fù)涠x提供了更多選擇。

總結(jié)

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

Apache Samza

Apache Samza是一種與Apache Kafka消息系統(tǒng)緊密綁定的流處理框架。雖然Kafka可用于很多流處理系統(tǒng)，但按照設(shè)計(jì)，Samza可以更好地發(fā)揮Kafka獨(dú)特的架構(gòu)優(yōu)勢和保障。該技術(shù)可通過Kafka提供容錯(cuò)、緩沖，以及狀態(tài)存儲(chǔ)。

Samza可使用YARN作為資源管理器。這意味著默認(rèn)情況下需要具備Hadoop集群(至少具備HDFS和YARN)，但同時(shí)也意味著Samza可以直接使用YARN豐富的內(nèi)建功能。

流處理模式

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

由于Kafka相當(dāng)于永恒不變的日志，Samza也需要處理永恒不變的數(shù)據(jù)流。這意味著任何轉(zhuǎn)換創(chuàng)建的新數(shù)據(jù)流都可被其他組件所使用，而不會(huì)對(duì)最初的數(shù)據(jù)流產(chǎn)生影響。

優(yōu)勢和局限

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

例如Kafka已經(jīng)提供了可以通過低延遲方式訪問的數(shù)據(jù)存儲(chǔ)副本，此外還可以為每個(gè)數(shù)據(jù)分區(qū)提供非常易用且低成本的多訂閱者模型。所有輸出內(nèi)容，包括中間態(tài)的結(jié)果都可寫入到Kafka，并可被下游步驟獨(dú)立使用。

這種對(duì)Kafka的緊密依賴在很多方面類似于MapReduce引擎對(duì)HDFS的依賴。雖然在批處理的每個(gè)計(jì)算之間對(duì)HDFS的依賴導(dǎo)致了一些嚴(yán)重的性能問題，但也避免了流處理遇到的很多其他問題。

Samza與Kafka之間緊密的關(guān)系使得處理步驟本身可以非常松散地耦合在一起。無需事先協(xié)調(diào)，即可在輸出的任何步驟中增加任意數(shù)量的訂閱者，對(duì)于有多個(gè)團(tuán)隊(duì)需要訪問類似數(shù)據(jù)的組織，這一特性非常有用。多個(gè)團(tuán)隊(duì)可以全部訂閱進(jìn)入系統(tǒng)的數(shù)據(jù)話題，或任意訂閱其他團(tuán)隊(duì)對(duì)數(shù)據(jù)進(jìn)行過某些處理后創(chuàng)建的話題。這一切并不會(huì)對(duì)數(shù)據(jù)庫等負(fù)載密集型基礎(chǔ)架構(gòu)造成額外的壓力。

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

Samza可以使用以本地鍵值存儲(chǔ)方式實(shí)現(xiàn)的容錯(cuò)檢查點(diǎn)系統(tǒng)存儲(chǔ)數(shù)據(jù)。這樣Samza即可獲得“至少一次”的交付保障，但面對(duì)由于數(shù)據(jù)可能多次交付造成的失敗，該技術(shù)無法對(duì)匯總后狀態(tài)(例如計(jì)數(shù))提供精確恢復(fù)。

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

總結(jié)

對(duì)于已經(jīng)具備或易于實(shí)現(xiàn)Hadoop和Kafka的環(huán)境，Apache Samza是流處理工作負(fù)載一個(gè)很好的選擇。Samza本身很適合有多個(gè)團(tuán)隊(duì)需要使用(但相互之間并不一定緊密協(xié)調(diào))不同處理階段的多個(gè)數(shù)據(jù)流的組織。Samza可大幅簡化很多流處理工作，可實(shí)現(xiàn)低延遲的性能。如果部署需求與當(dāng)前系統(tǒng)不兼容，也許并不適合使用，但如果需要極低延遲的處理，或?qū)?yán)格的一次處理語義有較高需求，此時(shí)依然適合考慮。

混合處理系統(tǒng)：批處理和流處理

一些處理框架可同時(shí)處理批處理和流處理工作負(fù)載。這些框架可以用相同或相關(guān)的組件和API處理兩種類型的數(shù)據(jù)，借此讓不同的處理需求得以簡化。

如你所見，這一特性主要是由Spark和Flink實(shí)現(xiàn)的，下文將介紹這兩種框架。實(shí)現(xiàn)這樣的功能重點(diǎn)在于兩種不同處理模式如何進(jìn)行統(tǒng)一，以及要對(duì)固定和不固定數(shù)據(jù)集之間的關(guān)系進(jìn)行何種假設(shè)。

雖然側(cè)重于某一種處理類型的項(xiàng)目會(huì)更好地滿足具體用例的要求，但混合框架意在提供一種數(shù)據(jù)處理的通用解決方案。這種框架不僅可以提供處理數(shù)據(jù)所需的方法，而且提供了自己的集成項(xiàng)、庫、工具，可勝任圖形分析、機(jī)器學(xué)習(xí)、交互式查詢等多種任務(wù)。

Apache Spark

Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapReduce引擎基于各種相同原則開發(fā)而來的Spark主要側(cè)重于通過完善的內(nèi)存計(jì)算和處理優(yōu)化機(jī)制加快批處理工作負(fù)載的運(yùn)行速度。

Spark可作為獨(dú)立集群部署(需要相應(yīng)存儲(chǔ)層的配合)，或可與Hadoop集成并取代MapReduce引擎。

批處理模式

與MapReduce不同，Spark的數(shù)據(jù)處理工作全部在內(nèi)存中進(jìn)行，只在一開始將數(shù)據(jù)讀入內(nèi)存，以及將最終結(jié)果持久存儲(chǔ)時(shí)需要與存儲(chǔ)層交互。所有中間態(tài)的處理結(jié)果均存儲(chǔ)在內(nèi)存中。

雖然內(nèi)存中處理方式可大幅改善性能，Spark在處理與磁盤有關(guān)的任務(wù)時(shí)速度也有很大提升，因?yàn)橥ㄟ^提前對(duì)整個(gè)任務(wù)集進(jìn)行分析可以實(shí)現(xiàn)更完善的整體式優(yōu)化。為此Spark可創(chuàng)建代表所需執(zhí)行的全部操作，需要操作的數(shù)據(jù)，以及操作和數(shù)據(jù)之間關(guān)系的Directed Acyclic Graph(有向無環(huán)圖)，即DAG，借此處理器可以對(duì)任務(wù)進(jìn)行更智能的協(xié)調(diào)。

為了實(shí)現(xiàn)內(nèi)存中批計(jì)算，Spark會(huì)使用一種名為Resilient Distributed Dataset(彈性分布式數(shù)據(jù)集)，即RDD的模型來處理數(shù)據(jù)。這是一種代表數(shù)據(jù)集，只位于內(nèi)存中，永恒不變的結(jié)構(gòu)。針對(duì)RDD執(zhí)行的操作可生成新的RDD。每個(gè)RDD可通過世系(Lineage)回溯至父級(jí)RDD，并最終回溯至磁盤上的數(shù)據(jù)。Spark可通過RDD在無需將每個(gè)操作的結(jié)果寫回磁盤的前提下實(shí)現(xiàn)容錯(cuò)。

流處理模式

流處理能力是由Spark Streaming實(shí)現(xiàn)的。Spark本身在設(shè)計(jì)上主要面向批處理工作負(fù)載，為了彌補(bǔ)引擎設(shè)計(jì)和流處理工作負(fù)載特征方面的差異，Spark實(shí)現(xiàn)了一種叫做微批(Micro-batch)*的概念。在具體策略方面該技術(shù)可以將數(shù)據(jù)流視作一系列非常小的“批”，借此即可通過批處理引擎的原生語義進(jìn)行處理。

Spark Streaming會(huì)以亞秒級(jí)增量對(duì)流進(jìn)行緩沖，隨后這些緩沖會(huì)作為小規(guī)模的固定數(shù)據(jù)集進(jìn)行批處理。這種方式的實(shí)際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。

優(yōu)勢和局限

使用Spark而非Hadoop MapReduce的主要原因是速度。在內(nèi)存計(jì)算策略和先進(jìn)的DAG調(diào)度等機(jī)制的幫助下，Spark可以用更快速度處理相同的數(shù)據(jù)集。

Spark的另一個(gè)重要優(yōu)勢在于多樣性。該產(chǎn)品可作為獨(dú)立集群部署，或與現(xiàn)有Hadoop集群集成。該產(chǎn)品可運(yùn)行批處理和流處理，運(yùn)行一個(gè)集群即可處理不同類型的任務(wù)。

除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態(tài)系統(tǒng)，可為機(jī)器學(xué)習(xí)、交互式查詢等任務(wù)提供更好的支持。相比MapReduce，Spark任務(wù)更是“眾所周知”地易于編寫，因此可大幅提高生產(chǎn)力。

為流處理系統(tǒng)采用批處理的方法，需要對(duì)進(jìn)入系統(tǒng)的數(shù)據(jù)進(jìn)行緩沖。緩沖機(jī)制使得該技術(shù)可以處理非常大量的傳入數(shù)據(jù)，提高整體吞吐率，但等待緩沖區(qū)清空也會(huì)導(dǎo)致延遲增高。這意味著Spark Streaming可能不適合處理對(duì)延遲有較高要求的工作負(fù)載。

由于內(nèi)存通常比磁盤空間更貴，因此相比基于磁盤的系統(tǒng)，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務(wù)，在需要按照小時(shí)數(shù)為資源付費(fèi)的環(huán)境中，這一特性通常可以抵消增加的成本。

Spark內(nèi)存計(jì)算這一設(shè)計(jì)的另一個(gè)后果是，如果部署在共享的集群中可能會(huì)遇到資源不足的問題。相比Hadoop MapReduce，Spark的資源消耗更大，可能會(huì)對(duì)需要在同一時(shí)間使用集群的其他任務(wù)產(chǎn)生影響。從本質(zhì)來看，Spark更不適合與Hadoop堆棧的其他組件共存一處。

總結(jié)

Spark是多樣化工作負(fù)載處理任務(wù)的最佳選擇。Spark批處理能力以更高內(nèi)存占用為代價(jià)提供了無與倫比的速度優(yōu)勢。對(duì)于重視吞吐率而非延遲的工作負(fù)載，則比較適合使用Spark Streaming作為流處理解決方案。

Apache Flink

Apache Flink是一種可以處理批處理任務(wù)的流處理框架。該技術(shù)可將批處理數(shù)據(jù)視作具備有限邊界的數(shù)據(jù)流，借此將批處理任務(wù)作為流處理的子集加以處理。為所有處理任務(wù)采取流處理為先的方法會(huì)產(chǎn)生一系列有趣的副作用。

這種流處理為先的方法也叫做Kappa架構(gòu)，與之相對(duì)的是更加被廣為人知的Lambda架構(gòu)(該架構(gòu)中使用批處理作為主要處理方法，使用流作為補(bǔ)充并提供早期未經(jīng)提煉的結(jié)果)。Kappa架構(gòu)中會(huì)對(duì)一切進(jìn)行流處理，借此對(duì)模型進(jìn)行簡化，而這一切是在最近流處理引擎逐漸成熟后才可行的。

流處理模型

Flink的流處理模型在處理傳入數(shù)據(jù)時(shí)會(huì)將每一項(xiàng)視作真正的數(shù)據(jù)流。Flink提供的DataStream API可用于處理無盡的數(shù)據(jù)流。Flink可配合使用的基本組件包括：

為了在計(jì)算過程中遇到問題后能夠恢復(fù)，流處理任務(wù)會(huì)在預(yù)定時(shí)間點(diǎn)創(chuàng)建快照。為了實(shí)現(xiàn)狀態(tài)存儲(chǔ)，F(xiàn)link可配合多種狀態(tài)后端系統(tǒng)使用，具體取決于所需實(shí)現(xiàn)的復(fù)雜度和持久性級(jí)別。

此外Flink的流處理能力還可以理解“事件時(shí)間”這一概念，這是指事件實(shí)際發(fā)生的時(shí)間，此外該功能還可以處理會(huì)話。這意味著可以通過某種有趣的方式確保執(zhí)行順序和分組。

批處理模型

Flink的批處理模型在很大程度上僅僅是對(duì)流處理模型的擴(kuò)展。此時(shí)模型不再從持續(xù)流中讀取數(shù)據(jù)，而是從持久存儲(chǔ)中以流的形式讀取有邊界的數(shù)據(jù)集。Flink會(huì)對(duì)這些處理模型使用完全相同的運(yùn)行時(shí)。

Flink可以對(duì)批處理工作負(fù)載實(shí)現(xiàn)一定的優(yōu)化。例如由于批處理操作可通過持久存儲(chǔ)加以支持，F(xiàn)link可以不對(duì)批處理工作負(fù)載創(chuàng)建快照。數(shù)據(jù)依然可以恢復(fù)，但常規(guī)處理操作可以執(zhí)行得更快。

另一個(gè)優(yōu)化是對(duì)批處理任務(wù)進(jìn)行分解，這樣即可在需要的時(shí)候調(diào)用不同階段和組件。借此Flink可以與集群的其他用戶更好地共存。對(duì)任務(wù)提前進(jìn)行分析使得Flink可以查看需要執(zhí)行的所有操作、數(shù)據(jù)集的大小，以及下游需要執(zhí)行的操作步驟，借此實(shí)現(xiàn)進(jìn)一步的優(yōu)化。

優(yōu)勢和局限

Flink目前是處理框架領(lǐng)域一個(gè)獨(dú)特的技術(shù)。雖然Spark也可以執(zhí)行批處理和流處理，但Spark的流處理采取的微批架構(gòu)使其無法適用于很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項(xiàng)處理的能力。

Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出于性能方面的原因，該技術(shù)可自行管理內(nèi)存，無需依賴原生的Java垃圾回收機(jī)制。與Spark不同，待處理數(shù)據(jù)的特征發(fā)生變化后Flink無需手工優(yōu)化和調(diào)整，并且該技術(shù)也可以自行處理數(shù)據(jù)分區(qū)和自動(dòng)緩存等操作。

Flink會(huì)通過多種方式對(duì)工作進(jìn)行分許進(jìn)而優(yōu)化任務(wù)。這種分析在部分程度上類似于SQL查詢規(guī)劃器對(duì)關(guān)系型數(shù)據(jù)庫所做的優(yōu)化，可針對(duì)特定任務(wù)確定最高效的實(shí)現(xiàn)方法。該技術(shù)還支持多階段并行執(zhí)行，同時(shí)可將受阻任務(wù)的數(shù)據(jù)集合在一起。對(duì)于迭代式任務(wù)，出于性能方面的考慮，F(xiàn)link會(huì)嘗試在存儲(chǔ)數(shù)據(jù)的節(jié)點(diǎn)上執(zhí)行相應(yīng)的計(jì)算任務(wù)。此外還可進(jìn)行“增量迭代”，或僅對(duì)數(shù)據(jù)中有改動(dòng)的部分進(jìn)行迭代。

在用戶工具方面，F(xiàn)link提供了基于Web的調(diào)度視圖，借此可輕松管理任務(wù)并查看系統(tǒng)狀態(tài)。用戶也可以查看已提交任務(wù)的優(yōu)化方案，借此了解任務(wù)最終是如何在集群中實(shí)現(xiàn)的。對(duì)于分析類任務(wù)，F(xiàn)link提供了類似SQL的查詢，圖形化處理，以及機(jī)器學(xué)習(xí)庫，此外還支持內(nèi)存計(jì)算。

Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術(shù)可以很好地融入整個(gè)環(huán)境，在任何時(shí)候都只占用必要的資源。該技術(shù)可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，F(xiàn)link還可以運(yùn)行為其他處理框架，例如Hadoop和Storm編寫的任務(wù)。

目前Flink最大的局限之一在于這依然是一個(gè)非常“年幼”的項(xiàng)目。現(xiàn)實(shí)環(huán)境中該項(xiàng)目的大規(guī)模部署尚不如其他處理框架那么常見，對(duì)于Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨著快速開發(fā)周期的推進(jìn)和兼容包等功能的完善，當(dāng)越來越多的組織開始嘗試時(shí)，可能會(huì)出現(xiàn)越來越多的Flink部署。

總結(jié)

Flink提供了低延遲流處理，同時(shí)可支持傳統(tǒng)的批處理任務(wù)。Flink也許最適合有極高流處理需求，并有少量批處理任務(wù)的組織。該技術(shù)可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運(yùn)行，因此可以很方便地進(jìn)行評(píng)估。快速進(jìn)展的開發(fā)工作使其值得被大家關(guān)注。

結(jié)論

大數(shù)據(jù)系統(tǒng)可使用多種處理技術(shù)。

對(duì)于僅需要批處理的工作負(fù)載，如果對(duì)時(shí)間不敏感，比其他解決方案實(shí)現(xiàn)成本更低的Hadoop將會(huì)是一個(gè)好選擇。

對(duì)于僅需要流處理的工作負(fù)載，Storm可支持更廣泛的語言并實(shí)現(xiàn)極低延遲的處理，但默認(rèn)配置可能產(chǎn)生重復(fù)結(jié)果并且無法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團(tuán)隊(duì)使用，以及更簡單的復(fù)制和狀態(tài)管理。

對(duì)于混合型工作負(fù)載，Spark可提供高速批處理和微批處理模式的流處理。該技術(shù)的支持更完善，具備各種集成庫和工具，可實(shí)現(xiàn)靈活的集成。Flink提供了真正的流處理并具備批處理能力，通過深度優(yōu)化可運(yùn)行針對(duì)其他平臺(tái)編寫的任務(wù)，提供低延遲的處理，但實(shí)際應(yīng)用方面還為時(shí)過早。

最適合的解決方案主要取決于待處理數(shù)據(jù)的狀態(tài)，對(duì)處理所需時(shí)間的需求，以及希望得到的結(jié)果。具體是使用全功能解決方案或主要側(cè)重于某種項(xiàng)目的解決方案，這個(gè)問題需要慎重權(quán)衡。隨著逐漸成熟并被廣泛接受，在評(píng)估任何新出現(xiàn)的創(chuàng)新型解決方案時(shí)都需要考慮類似的問題。