我們在思考流處理問題上花了很多時間，更酷的是，我們也花了很多時間幫助其他人認識流處理，以及如何在他們的組織里應(yīng)用流處理來解決數(shù)據(jù)問題。

[[178179]]

我們首先要做的是糾正人們對流處理(作為一個快速變化的領(lǐng)域，這里有很多誤見值得我們思考)的錯誤認識。

在這篇文章里，我們選出了其中的六個作為例子。因為我們對Apache Flink比較熟悉，所以我們會基于Flink來講解這些例子。

謬見1：沒有不使用批處理的流(Lambda架構(gòu))

謬見2：延遲和吞吐量：只能選擇一個

謬見3：微批次意味著更好的吞吐量

謬見4：Exactly once?完全不可能

謬見5：流只能被應(yīng)用在“實時”場景里

謬見6：不管怎么樣，流仍然很復(fù)雜

謬見1：沒有不使用批處理的流(Lambda架構(gòu))

“Lambda架構(gòu)”在Apache Storm的早期階段和其它流處理項目里是一個很有用的設(shè)計模式。這個架構(gòu)包含了一個“快速流層”和一個“批次層”。  

之所以使用兩個單獨的層，是因為Lambda架構(gòu)里的流處理只能計算出大致的結(jié)果(也就是說，如果中間出現(xiàn)了錯誤，那么計算結(jié)果就不可信)，而且只能處理相對少量的事件。

算Storm的早期版本存在這樣的問題，但現(xiàn)今的很多開源流處理框架都具有容錯能力，它們可以在出現(xiàn)故障的前提下生成準(zhǔn)確的計算結(jié)果，而且具有高吞吐的計算能力。所以沒有必要再為了分別得到“快”和“準(zhǔn)確”的結(jié)果而維護多層架構(gòu)。現(xiàn)今的流處理器(比如Flink)可以同時幫你得到兩種結(jié)果。

好在人們不再更多地討論Lambda架構(gòu)，說明流處理正在走向成熟。

謬見2：延遲和吞吐量：只能選擇一個

早期的開源流處理框架要么是“高吞吐”的，要么是“低延遲”的，而“海量且快速”一直未能成為開源流處理框架的代名詞。

不過Flink(可能還有其它的框架)就同時提供了高吞吐和低延遲。這里有一個基準(zhǔn)測試結(jié)果的樣例。

讓我們從底層來剖析這個例子，特別是從硬件層，并結(jié)合具有網(wǎng)絡(luò)瓶頸的流處理管道(很多使用Flink的管道都有這個瓶頸)。在硬件層不應(yīng)該存在需要作出權(quán)衡的條件，所以網(wǎng)絡(luò)才是影響吞吐量和延遲的主要因素。

一個設(shè)計良好的軟件系統(tǒng)應(yīng)該會充分利用網(wǎng)絡(luò)的上限而不會引入瓶頸問題。不過對Flink來說，總是有可優(yōu)化的空間，可以讓它更接近硬件所能提供的效能。使用一個包含10個節(jié)點的集群，F(xiàn)link現(xiàn)在每秒可以處理***別的事件量，如果擴展到1000個節(jié)點，它的延遲可以降低到幾十毫秒。在我們看來，這種水平已經(jīng)比很多現(xiàn)有的方案高出很多。

謬見3：微批次意味著更好的吞吐量

我們可以從另一個角度來討論性能，不過先讓我們來澄清兩個容易混淆的概念：

微批次

微批次建立在傳統(tǒng)批次之上，是處理數(shù)據(jù)的一個執(zhí)行或編程模型。“通過這項技術(shù)，進程或任務(wù)可以把一個流當(dāng)作一系列小型的批次或數(shù)據(jù)塊”。

緩沖

緩沖技術(shù)用于對網(wǎng)絡(luò)、磁盤、緩存的訪問進行優(yōu)化。Wikipedia***地把它定義為“物理內(nèi)存里的一塊用于臨時儲存移動數(shù)據(jù)的區(qū)域“。

那么第3個繆見就是說，使用微批次的數(shù)據(jù)處理框架能夠比每次處理一個事件的框架達到更高的吞吐量，因為微批次在網(wǎng)絡(luò)上傳輸?shù)男矢摺?/p>

這個繆見忽略了一個事實，流框架不會依賴任何編程模型層面的批次，它們只會在物理層面使用緩沖。

Flink確實也會對數(shù)據(jù)進行緩沖，也就是說它會通過網(wǎng)絡(luò)發(fā)送一組處理過的記錄，而不是每次發(fā)送一條記錄。從性能方面說，不對數(shù)據(jù)進行緩沖是不可取的，因為通過網(wǎng)絡(luò)逐個發(fā)送記錄不會帶來任何性能上的好處。所以我們得承認在物理層面根本不存在類似一次一條記錄這樣的情況。

不過緩沖只能作為對性能的優(yōu)化，所以緩沖：

• 對用戶是不可見的
• 不應(yīng)該對系統(tǒng)造成任何影響
• 不應(yīng)該出現(xiàn)人為的邊界
• 不應(yīng)該限制系統(tǒng)功能

所以對Flink的用戶來說，他們開發(fā)的程序能夠單獨地處理每個記錄，那是因為Flink為了提升性能隱藏了使用緩沖的細節(jié)。

事實上，在任務(wù)調(diào)度里使用微批次會帶來額外的開銷，而如果這樣做是為了降低延遲，那么這種開銷會只增不減!流處理器知道該如何利用緩沖的優(yōu)勢而不會帶來任務(wù)調(diào)度方面的開銷。

謬見4：Exactly once?完全不可能

這個繆見包含了幾個方面的內(nèi)容：

• 從根本上說，Exactly once是不可能的
• 從端到端的Exactly once是不可能的
• Exactly once從來都不是真實世界的需求
• Exactly once以犧牲性能為代價

讓我們退一步講，我們并不介意“Exactly once”這種觀點的存在。“Exactly once”原先指的是“一次性傳遞”，而現(xiàn)在這個詞被隨意用在流處理里，讓這個詞變得令人困惑，失去了它原本的意義。不過相關(guān)的概念還是很重要的，我們不打算跳過去。

為了盡量準(zhǔn)確，我們把“一次性狀態(tài)”和“一次性傳遞”視為兩種不同的概念。因為之前人們對這兩個詞的使用方式導(dǎo)致了它們的混淆。Apache Storm使用“at least once”來描述傳遞(Storm不支持狀態(tài))，而Apache Samza使用“at least once”來描述應(yīng)用狀態(tài)。

一次性狀態(tài)是指應(yīng)用程序在經(jīng)歷了故障以后恍如沒有發(fā)生過故障一樣。例如，假設(shè)我們在維護一個計數(shù)器應(yīng)用程序，在發(fā)生了一次故障之后，它既不能多計數(shù)也不能少計數(shù)。在這里使用“Exactly once”這個詞是因為應(yīng)用程序狀態(tài)認為每個消息只被處理了一次。

一次性傳遞是指接收端(應(yīng)用程序之外的系統(tǒng))在故障發(fā)生后會收到處理過的事件，恍如沒有發(fā)生過故障一樣。

流處理框在任何情況下都不保證一次性傳遞，但可以做到一次性狀態(tài)。Flink可以做到一次性狀態(tài)，而且不會對性能造成顯著影響。Flink還能在與Flink檢查點相關(guān)的數(shù)據(jù)槽上做到一次性傳遞。

Flink檢查點就是應(yīng)用程序狀態(tài)的快照，F(xiàn)link會為應(yīng)用程序定時異步地生成快照。這就是Flink在發(fā)生故障時仍然能保證一次性狀態(tài)的原因：Flink定時記錄(快照)輸入流的讀取位置和每個操作數(shù)的相關(guān)狀態(tài)。如果發(fā)生故障，F(xiàn)link會回滾到之前的狀態(tài)，并重新開始計算。所以說，盡管記錄被重新處理，但從結(jié)果來看，記錄好像只被處理過一次。

那么端到端的一次性處理呢?通過恰當(dāng)?shù)姆绞阶寵z查點兼具事務(wù)協(xié)調(diào)機制是可能的，換句話說，就是讓源操作和目標(biāo)操作參與到檢查點里來。在框架內(nèi)部，結(jié)果是一次性的，從端到端來看，也是一次性的，或者說“接近一次性”。例如，在使用Flink和Kafka作為數(shù)據(jù)源并發(fā)生數(shù)據(jù)槽(HDFS)滾動時，從Kafka到HDFS就是端到端的一次性處理。類似地，在把Kafka作為Flink的源并且把Cassandra作為Flink的槽時，如果針對Cassandra的更新是冪等時，那么就可以實現(xiàn)端到端的一次性處理。 

值得一提的是，利用Flink的保存點，檢查點可以兼具狀態(tài)版本機制。使用保存點，在保持狀態(tài)一致性的同時還可以“隨著時間移動”。這樣可以讓代碼的更新、維護、遷移、調(diào)試和各種模擬測試變得簡單。 

謬見5：流只能被應(yīng)用在“實時”場景里

這個謬見包括幾點內(nèi)容：

• “我沒有低延遲的應(yīng)用，所以我不需要流處理器”
• “流處理只跟那些持久化之前的過渡數(shù)據(jù)有關(guān)系”
• “我們需要批處理器來完成笨重的離線計算”

現(xiàn)在是時候思考一下數(shù)據(jù)集的類型和處理模型之間的關(guān)系了。

首先，有兩種數(shù)據(jù)集：

• 沒有邊界的：從非預(yù)定義的端點持續(xù)產(chǎn)生的數(shù)據(jù)
• 有邊界的：有限且完整的數(shù)據(jù)

很多真實的數(shù)據(jù)集是沒有邊界的，不管這些數(shù)據(jù)時存儲在文件里，還是在HDFS的目錄里，還是在像Kafka這樣的系統(tǒng)里。舉一些例子：

• 移動設(shè)備或網(wǎng)站用戶的交互信息
• 物理傳感器提供的度量指標(biāo)
• 金融市場數(shù)據(jù)
• 機器日志數(shù)據(jù)

實際上，在現(xiàn)實世界中很難找到有邊界的數(shù)據(jù)集，不過一個公司所有大樓的位置信息倒是有邊界的(不過它也會隨著公司業(yè)務(wù)的增長而變化)。

其次，有兩種處理模型：

• 流：只要有數(shù)據(jù)生成就會一直處理
• 批次：在有限的時間內(nèi)結(jié)束處理，并釋放資源

讓我們再深入一點，來區(qū)分兩種沒有邊界的數(shù)據(jù)集：連續(xù)性流和間歇性流。 

使用任意一種模型來處理任意一種數(shù)據(jù)集是完全可能的，雖然這不是***的做法。例如，批次處理模型被長時間地應(yīng)用在無邊界的數(shù)據(jù)集上，特別是間歇性的無邊界數(shù)據(jù)集?，F(xiàn)實情況是，大多數(shù)“批處理”任務(wù)是通過調(diào)度來執(zhí)行的，每次只處理無邊界數(shù)據(jù)集的一小部分。這意味著流的無邊界特質(zhì)會給某些人帶來麻煩(那些工作在流入管道上的人)。

批處理是無狀態(tài)的，輸出只取決于輸入?，F(xiàn)實情況是，批處理任務(wù)會在內(nèi)部保留狀態(tài)(比如reducer經(jīng)常會保留狀態(tài))，但這些狀態(tài)只限在批次的邊界內(nèi)，而且它們不會在批次間流竄。

當(dāng)有人嘗試實現(xiàn)類似帶有“事件時間戳”的時間窗，那么“批次的邊界內(nèi)狀態(tài)”就會變得很有用，這在處理無邊界數(shù)據(jù)集時是個很常用的手段。

處理無邊界數(shù)據(jù)集的批處理器將不可避免地遇到遲到事件(因為上游的延遲)，批次內(nèi)的數(shù)據(jù)有可能因此變得不完整。要注意，這里假設(shè)我們是基于事件時間戳來移動時間窗的，因為事件時間戳是現(xiàn)實當(dāng)中最為準(zhǔn)確的模型。在執(zhí)行批處理的時候，遲到的數(shù)據(jù)會成為問題，即使通過簡單的時間窗修復(fù)(比如翻轉(zhuǎn)或滑動時間窗)也解決不了這個問題，特別是如果使用會話時間窗，就更難以處理了。

因為完成一個計算所需要的數(shù)據(jù)不會都在一個批次里，所以在使用批次處理無邊界數(shù)據(jù)集時，很難保證結(jié)果的正確性。最起碼，它需要額外的開銷來處理遲到的數(shù)據(jù)，還要維護批次之間的狀態(tài)(要等到所有數(shù)據(jù)達到后才開始處理，或者重新處理批次)。

Flink內(nèi)建了處理遲到數(shù)據(jù)的機制，遲到數(shù)據(jù)被視為真實世界無邊界數(shù)據(jù)的正?，F(xiàn)象，所以Flink設(shè)計了一個流處理器專門處理遲到數(shù)據(jù)。

有狀態(tài)的流處理器更適合用來處理無邊界數(shù)據(jù)集，不管數(shù)據(jù)集是持續(xù)生成的還是間歇生成的。使用流處理器只是個錦上添花的事情。

繆見6：不管怎么樣，流仍然很復(fù)雜

這是***一個繆見。你也許會想：“理論雖好，但我仍然不會采用流技術(shù)，因為……”：

• 流框架難以掌握
• 流難以解決時間窗、事件時間戳、觸發(fā)器的問題
• 流需要結(jié)合批次，而我已經(jīng)知道如何使用批次，那為什么還要使用流?

我們從來沒有打算慫恿你使用流，雖然我們覺得流是個很酷的東西。我們相信，是否使用流完全取決于數(shù)據(jù)和代碼的特點。

在做決定之前問問自己：“我正在跟什么樣類型的數(shù)據(jù)集打交道?”

• 無邊界的(用戶活動數(shù)據(jù)、日志、傳感器數(shù)據(jù))
• 有邊界的

然后再問另一個問題：“哪部分變化最頻繁?”

• 代碼比數(shù)據(jù)變化更頻繁
• 數(shù)據(jù)比代碼變化更頻繁

對于數(shù)據(jù)比代碼變化更頻繁的情況，例如在經(jīng)常變化的數(shù)據(jù)集上執(zhí)行一個相對固定的查詢操作，這樣會出現(xiàn)流方面的問題。

所以，在認定流是一個“復(fù)雜”的東西之前，你可能在不知不覺中已經(jīng)解決過流方面的問題!你可能使用過基于小時的批次任務(wù)調(diào)度，團隊里的其他人可以創(chuàng)建和管理這些批次(在這種情況下，你得到的結(jié)果可能是不準(zhǔn)確的，而你意識不到這樣的結(jié)果是批次的時間問題和之前提過的狀態(tài)問題造成的)。

為了能夠提供一組封裝了這些時間和狀態(tài)復(fù)雜性的API，F(xiàn)link社區(qū)為此工作了很長時間。在Flink里可以很簡單地處理事件時間戳，只要定義一個時間窗口和一個能夠抽取時間戳和水印的函數(shù)(只在每個流上調(diào)用一次)。處理狀態(tài)也很簡單，類似于定義Java變量，再把這些變量注冊到Flink。使用Flink的StreamSQL可以在源源不斷的流上面運行SQL查詢。

***一點：對代碼比數(shù)據(jù)變化更頻繁的情況該怎么辦?對于這種情況，我們認為你遇到了探索性問題。使用筆記本或其它類似的工具進行迭代可能適合用來解決探索性問題。

在代碼穩(wěn)定了之后，你仍然會碰到流方面的問題。我們建議從一開始就使用長遠的方案來解決流方面的問題。

流處理的未來

隨著流處理的日漸成熟和這些繆見的逐步淡去，我們發(fā)現(xiàn)流正朝著除分析應(yīng)用之外的領(lǐng)域發(fā)展。正如我們所討論的那樣，真實世界正連續(xù)不斷地生成數(shù)據(jù)。

傳統(tǒng)的做法會中斷這些連續(xù)的數(shù)據(jù)，因為這些數(shù)據(jù)必須被聚合到一個集中的位置，或者被切分成批次，方便應(yīng)用程序使用。

像CQRS這樣的流處理模式越來越流行，應(yīng)用程序可以直接基于持續(xù)的數(shù)據(jù)流進行開發(fā)，這樣可以在本地保留狀態(tài)，可以更好地隔離應(yīng)用和團隊，可以更好地處理基于時間的數(shù)據(jù)。

隨著Flink不斷地演化改進，并被越來越多的企業(yè)所采用，我們相信它不僅僅能夠用來簡化分析管道，還能夠為我們帶來更強大的計算模型。

本文作者：Kostas Tzoumas。原文：Stream Processing Myths Debunked。