免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

文章內(nèi)容由K2研究院原創(chuàng)，轉(zhuǎn)載請(qǐng)注明來(lái)源。

   上篇鏈接：流計(jì)算簡(jiǎn)介（上篇）

本節(jié)將先后介紹Structured Streaming、Flink和Kafka，并從架構(gòu)的角度討論其異同。在討論各個(gè)框架的時(shí)候，不會(huì)談如何構(gòu)建一個(gè)具體的應(yīng)用，大家閱讀對(duì)應(yīng)的用戶文檔可以很快編寫一些簡(jiǎn)單實(shí)用的流計(jì)算應(yīng)用?；谇懊娴牧饔?jì)算關(guān)鍵概念介紹，本節(jié)將從架構(gòu)上討論各個(gè)框架的異同，以期大家能對(duì)各個(gè)技術(shù)的來(lái)龍去脈、適用場(chǎng)景和未來(lái)發(fā)展趨勢(shì)有更深入的了解。因?yàn)镾park流行甚廣，下面先從Spark的Structured Streaming開(kāi)始。

Spark是由UC Berkeley AMPLab在2010年開(kāi)源的項(xiàng)目，其核心思想來(lái)自一系列論文。Spark中最重要的概念之一是RDD（resilient distributed datasets），與Mapreduce相比，Spark利用RDD把數(shù)據(jù)與計(jì)算解耦開(kāi)來(lái)。在Spark的框架下，計(jì)算是無(wú)狀態(tài)的，所有的狀態(tài)信息都在RDD里。每個(gè)Spark任務(wù)都是一個(gè)計(jì)算工作流，每個(gè)步驟的輸入和輸出都是RDD，中間的計(jì)算過(guò)程無(wú)狀態(tài)。所以，在工作流執(zhí)行過(guò)程中，集群如果出現(xiàn)故障導(dǎo)致計(jì)算失敗，只需要從最近一個(gè)持久化的RDD重新計(jì)算。

早期的Spark并沒(méi)有流計(jì)算的概念。直到Spark Streaming加入項(xiàng)目，Spark才從批計(jì)算的模式向批流結(jié)合的統(tǒng)一框架演進(jìn)。但Spark Streaming更像是批計(jì)算的衍生，所以在API上并不適合流計(jì)算場(chǎng)景，所以項(xiàng)目最終提出Structured Streaming正式作為Spark引擎對(duì)外提供的批流結(jié)合的API形式。其處理模式上仍然沿用基于RDD的批計(jì)算模式——源源不斷的數(shù)據(jù)被劃分為連續(xù)小批（micro batch），每個(gè)小批看做一個(gè)RDD，在處理小批的模式上仍然與原始的Spark是完全一樣的。

要支持流計(jì)算就必須支持時(shí)間窗口定義。前面討論過(guò)，窗口實(shí)際上對(duì)應(yīng)一系列需要緩存的計(jì)算中間結(jié)果。在Structured Streaming里，與原始的Spark一樣，這些結(jié)果仍然是以RDD的形式存在的。考慮一個(gè)具體的實(shí)例來(lái)理解基于小批的計(jì)算模式是如何支持時(shí)間窗口的。我們?nèi)匀谎赜们懊嫣岬降挠?jì)算窗口內(nèi)平均溫度的例子：以發(fā)生時(shí)間每5分鐘統(tǒng)計(jì)一次平均溫度，即計(jì)算8:00~8:05時(shí)間范圍內(nèi)的平均溫度。假設(shè)在9:00時(shí)刻系統(tǒng)接收到第一批數(shù)據(jù)中存在8:00~8:05內(nèi)的溫度讀數(shù)，那么處理完之后緩存的中間結(jié)果為（我們暫且忽略其它窗口內(nèi)的中間結(jié)果）：

每次更新中間結(jié)果需要同時(shí)使用新的數(shù)據(jù)和前一次的輸出，按照這樣的形式隨著數(shù)據(jù)不斷到來(lái)，中間結(jié)果也在不斷更新，直到水位線超過(guò)時(shí)間窗口后得到最終的計(jì)算結(jié)果。所以從處理模式來(lái)看，Structured Streaming與Spark的批計(jì)算并沒(méi)有本質(zhì)不同，只是在開(kāi)始計(jì)算前系統(tǒng)并沒(méi)有得到全部數(shù)據(jù)，一些輸入的RDD是在計(jì)算開(kāi)始之后才源源不斷到來(lái)的，如上圖所示。同樣，如果在計(jì)算過(guò)程中系統(tǒng)發(fā)生故障，可以從發(fā)生失敗之前最后一次持久化的應(yīng)用狀態(tài)開(kāi)始往后計(jì)算；在數(shù)據(jù)源和輸出支持的情況下，Structured Streaming支持Exactly-once的計(jì)算語(yǔ)義。

由于Structured Streaming的計(jì)算過(guò)程是無(wú)狀態(tài)的，所以一些計(jì)算的并行化程度可以隨著數(shù)據(jù)負(fù)載的變化而變化。例如，如果我們想監(jiān)控某社交網(wǎng)站的聊天記錄，根據(jù)其中包含的關(guān)鍵詞進(jìn)行報(bào)警，那么在一天中不同時(shí)間段產(chǎn)生的日志量是有較大波動(dòng)的。在日志負(fù)載較高的時(shí)候，我們希望流計(jì)算引擎能自動(dòng)擴(kuò)容，占用更多的資源來(lái)處理日志；反之，我們則希望流計(jì)算占用的資源縮小。Structured Streaming在這時(shí)候可以根據(jù)每批數(shù)據(jù)的多少來(lái)自動(dòng)伸縮。

由于數(shù)據(jù)到來(lái)后總是需要等待一段時(shí)間才會(huì)被處理，這自然增大了數(shù)據(jù)處理延遲。對(duì)于一些對(duì)實(shí)時(shí)性要求很高的應(yīng)用Structured Streaming可能無(wú)法滿足要求。為了彌補(bǔ)這種短板，從Spark 2.3之后加入了稱為Continuous Processing的處理模式。其實(shí)現(xiàn)原理上不再有小批的概念，而是在原始的數(shù)據(jù)流中插入一些標(biāo)記符（marker）來(lái)將數(shù)據(jù)分段，這與Flink的實(shí)現(xiàn)非常類似。目前Continuous Processing截止到最新的2.4版本仍處于實(shí)驗(yàn)狀態(tài)，并且只能夠支持映射類的算子，例如map、filter等等，這樣設(shè)計(jì)是考慮這些算子本身不需要記錄狀態(tài)，實(shí)現(xiàn)上相對(duì)容易。當(dāng)然，Continuous Processing模式下的算子不再具備自動(dòng)伸縮的能力。

Flink是一個(gè)開(kāi)源的支持批流結(jié)合的分布式計(jì)算框架。2014年之后，F(xiàn)link的創(chuàng)建者成立了Data Artisans（后更名為Ververica）公司與開(kāi)源社區(qū)一同完善Flink的開(kāi)發(fā)工作。從Structured Streaming的發(fā)展過(guò)程中，我們可以清晰的看到Spark是由批計(jì)算逐步支持流計(jì)算的，而對(duì)比來(lái)看Flink則是在一開(kāi)始更多考慮的是流計(jì)算。

對(duì)比Structured Streaming，F(xiàn)link最顯著的區(qū)別在處理模式。在Flink里不再有小批的概念，數(shù)據(jù)一旦抵達(dá)流計(jì)算引擎即可以被處理，而不需要等待。所以Flink比起Structured Streaming更加適合那些對(duì)實(shí)時(shí)性要求高的應(yīng)用場(chǎng)景。前面提到過(guò)Structured Streaming在2.3版本引入了Continuous Processing的概念，通過(guò)在原始數(shù)據(jù)流里插入一些標(biāo)記來(lái)將數(shù)據(jù)分段。而這種標(biāo)記的概念在Flink里早就存在，稱為Barrier，這種設(shè)計(jì)來(lái)源于Chandy-Lamport 算法。Flink定期將數(shù)據(jù)段計(jì)算的中間結(jié)果持久化以便故障后可以及時(shí)恢復(fù)。在實(shí)現(xiàn)Exactly-once語(yǔ)義時(shí)，F(xiàn)link采用Two-phase commit來(lái)完成。

Flink與Structured Streaming另一個(gè)重要的區(qū)別來(lái)自狀態(tài)的維護(hù)上。在Spark里，算子并沒(méi)有狀態(tài)，而狀態(tài)都是以RDD的形式保存的；但在Flink里，算子是可以有狀態(tài)的，如下圖所示。

前面我們提到過(guò)算子的狀態(tài)一般是計(jì)算的中間結(jié)果，除此以外對(duì)于數(shù)據(jù)源算子還需要記錄數(shù)據(jù)的消費(fèi)情況。例如在Flink里的Kafka數(shù)據(jù)源算子就需要記錄被消費(fèi)的topic里各個(gè)partition的offset情況。借用Flink文檔里的一句話來(lái)概括算子的狀態(tài)：

所以在Flink里不僅僅有算子和流的概念，還有狀態(tài)概念；而在Structured Streaming里，雖然也有狀態(tài)的概念，但狀態(tài)和流在實(shí)現(xiàn)上并沒(méi)有區(qū)分開(kāi)。

前面在討論Structured Streaming時(shí)，我們提到一些算子（主要是映射類算子）可以根據(jù)負(fù)載動(dòng)態(tài)調(diào)整并行度。對(duì)于并行度變化，我們可以再展開(kāi)一些討論。

為了理解最后一種情況，我們可以舉個(gè)例子：假設(shè)我們希望建立一套流計(jì)算應(yīng)用來(lái)統(tǒng)計(jì)某網(wǎng)站用戶每5分鐘的操作次數(shù)。每個(gè)用戶有唯一的userId，那么在構(gòu)建Flink處理項(xiàng)目時(shí)，我們可以編寫如下Java代碼：

上面的代碼片段里，數(shù)據(jù)流通過(guò)keyBy方法將原始數(shù)據(jù)分流到5個(gè)邏輯節(jié)點(diǎn)來(lái)處理。假設(shè)網(wǎng)站一共有100個(gè)用戶，那么理想情況下每個(gè)節(jié)點(diǎn)需要處理來(lái)自20個(gè)用戶的數(shù)據(jù)。如果我們希望改變節(jié)點(diǎn)的并行度，比如改成10，那么意味著我們用10個(gè)節(jié)點(diǎn)計(jì)算，每個(gè)節(jié)點(diǎn)處理10個(gè)用戶。如果流計(jì)算應(yīng)用已經(jīng)運(yùn)行了一段時(shí)間，我們?nèi)绻霃牟⑿卸?改成并行度10，不僅需要額外的5個(gè)邏輯節(jié)點(diǎn)，還需要把原來(lái)5個(gè)邏輯節(jié)點(diǎn)上緩存的中間狀態(tài)分發(fā)到新的節(jié)點(diǎn)上。目前Flink允許修改有狀態(tài)算子的并行度，但必須先停止正在運(yùn)行的項(xiàng)目，修改后再重新啟動(dòng)。

Kafka Streams是基于Kafka的一套用于開(kāi)發(fā)流計(jì)算應(yīng)用的庫(kù)。所以，從應(yīng)用開(kāi)發(fā)上看，Kafka Streams比起Flink和Structured Streaming顯得更輕量級(jí)。后兩者一般借助其它的資源管理服務(wù)，如Yarn、Mesos或Kubernetes來(lái)管理集群的計(jì)算和內(nèi)存資源（它們自身也有簡(jiǎn)單的獨(dú)立管理資源能力）。如果基于Kafka Streams開(kāi)發(fā)一個(gè)流計(jì)算應(yīng)用，那么應(yīng)用運(yùn)行起來(lái)只是本地的一個(gè)進(jìn)程，而不是運(yùn)行在某種資源管理服務(wù)上。所以如果希望增加應(yīng)用的并行度，在資源充足的前提下，可以在一個(gè)節(jié)點(diǎn)上運(yùn)行多個(gè)進(jìn)程，或者在其它機(jī)器上運(yùn)行更多的進(jìn)程，這些進(jìn)程（包括進(jìn)程內(nèi)的多個(gè)線程）會(huì)由Kafka Streams庫(kù)統(tǒng)一調(diào)度。如果希望做資源隔離，則可以將進(jìn)程運(yùn)行在容器里（比如Docker），利用Kubernetes這樣的框架來(lái)管理容器的生命周期和服務(wù)的伸縮。

從處理模式來(lái)看，Kafka Streams更加接近Flink，而不是類似Structured Streaming的基于小批的處理。所以，Kafka Streams也能達(dá)到較好的實(shí)時(shí)性。由于Kafka Streams依賴用戶啟動(dòng)更多的進(jìn)程來(lái)增加處理的吞吐量，所以同F(xiàn)link一樣，它也不具備自動(dòng)隨著輸入負(fù)載自動(dòng)伸縮的能力。但結(jié)合容器和Kubernetes，通過(guò)外部的一些策略可以比較簡(jiǎn)單的實(shí)現(xiàn)自動(dòng)伸縮。這方面比起Flink來(lái)要相對(duì)靈活。

Kafka Streams需要依托在Kafka集群上，其中間結(jié)果的存儲(chǔ)需要保存在Kafka。這些中間結(jié)果，既包括算子的狀態(tài)（類似Flink里的狀態(tài)），也包括一些聚合操作所需要的數(shù)據(jù)存儲(chǔ)。例如在下面的處理邏輯上：

從map到groupById之間需要將數(shù)據(jù)shuffle一次。在Flink或Structured Streaming里，這些中間數(shù)據(jù)會(huì)緩存在計(jì)算節(jié)點(diǎn)的本地存儲(chǔ)上。但在Kafka Streams中，這些數(shù)據(jù)會(huì)存儲(chǔ)在Kafka里臨時(shí)的topic里。這意味著Kafka Streams的流計(jì)算應(yīng)用需要占用Kafka集群的一些資源。所以，在使用Kafka Streams之前需要對(duì)集群資源做詳細(xì)的測(cè)試。

面對(duì)具體的應(yīng)用場(chǎng)景，可以通過(guò)對(duì)比來(lái)選擇適合的流計(jì)算框架。例如，如果已經(jīng)有Hadoop環(huán)境，可以選擇Flink或Structured Streaming；如果沒(méi)有，而是有Kafka集群，則可以考慮使用Kafka Streams（當(dāng)然也可以使用Flink的獨(dú)立集群模式）。如果應(yīng)用更加偏批計(jì)算，例如希望每天分析前一天的所有數(shù)據(jù)，那么使用Structured Streaming可以享受到自動(dòng)資源伸縮的好處；如果應(yīng)用更加偏流計(jì)算，比如希望根據(jù)數(shù)據(jù)里的特定模式報(bào)警，則Flink要更勝一籌。此外，從開(kāi)發(fā)的歷程上看，F(xiàn)link比起另外兩者在成熟度上更有優(yōu)勢(shì)，無(wú)論是UI交互、觀測(cè)metrics還是API的靈活性都要更加豐富和完善。

本文介紹了流計(jì)算的演進(jìn)和核心概念，在此基礎(chǔ)上介紹了一些流計(jì)算框架。希望給讀者從概念理解和應(yīng)用選型上提供一些參考。