文 | Petr Zapletal ，譯者 俠天

在上篇文章中，我們過了下基本的理論，也介紹了主流的流處理框架：Storm，Trident，Spark Streaming，Samza和Flink。今天咱們來點有深度的topic，比如，容錯，狀態管理或者性能。除此之外，我們也將討論開發分布式流處理應用的指南，并給出推薦的流處理框架。

容錯性流處理系統的容錯性與生俱來的比批處理系統難實現。當批處理系統中出現錯誤時，我們只需要把失敗的部分簡單重啟即可;但對于流處理系統，出現錯誤就很難恢復。因為線上許多作業都是7 x 24小時運行，不斷有輸入的數據。流處理系統面臨的另外一個挑戰是狀態一致性，因為重啟后會出現重復數據，并且不是所有的狀態操作是冪等的。容錯性這么難實現，那下面我們看看各大主流流處理框架是如何處理這一問題。

Apache Storm：Storm使用上游數據備份和消息確認的機制來保障消息在失敗之后會重新處理。消息確認原理：每個操作都會把前一次的操作處理消息的確認信息返回。

Topology的數據源備份它生成的所有數據記錄。當所有數據記錄的處理確認信息收到，備份即會被安全拆除。失敗后，如果不是所有的消息處理確認信息收到，那數據記錄會被數據源數據替換。這保障了沒有數據丟失，但數據結果會有重復，這就是at-least once傳輸機制。

Storm采用取巧的辦法完成了容錯性，對每個源數據記錄僅僅要求幾個字節存儲空間來跟蹤確認消息。純數據記錄消息確認架構，盡管性能不錯，但不能保證exactly once消息傳輸機制，所有應用開發者需要處理重復數據。Storm存在低吞吐量和流控問題，因為消息確認機制在反壓下經常誤認為失敗。

Spark Streaming：Spark Streaming實現微批處理，容錯機制的實現跟Storm不一樣的方法。微批處理的想法相當簡單。Spark在集群各worker節點上處理micro-batches。每個micro-batches一旦失敗，重新計算就行。因為micro-batches本身的不可變性，并且每個micro-batches也會持久化，所以exactly once傳輸機制很容易實現。

Samza：Samza的實現方法跟前面兩種流處理框架完全不一樣。Samza利用消息系統Kafka的持久化和偏移量。Samza監控任務的偏移量，當任務處理完消息，相應的偏移量被移除。消息的偏移量會被checkpoint到持久化存儲中，并在失敗時恢復。但是問題在于：從上次checkpoint中修復偏移量時并不知道上游消息已經被處理過，這就會造成重復。這就是at least once傳輸機制。

Apache Flink：Flink的容錯機制是基于分布式快照實現的，這些快照會保存流處理作業的狀態(本文對Flink的檢查點和快照不進行區分，因為兩者實際是同一個事物的兩種不同叫法。Flink構建這些快照的機制可以被描述成分布式數據流的輕量級異步快照，它采用Chandy-Lamport算法實現。)。

如果發生失敗的情況，系統可以從這些檢查點進行恢復。Flink發送checkpoint的柵欄(barrier)到數據流中(柵欄是Flink的分布式快照機制中一個核心的元素)，當checkpoint的柵欄到達其中一個operator，operator會接所有收輸入流中對應的柵欄(比如，圖中checkpoint n對應柵欄n到n-1的所有輸入流，其僅僅是整個輸入流的一部分)。所以相對于Storm，Flink的容錯機制更高效，因為Flink的操作是對小批量數據而不是每條數據記錄。但也不要讓自己糊涂了，Flink仍然是原生流處理框架，它與Spark Streaming在概念上就完全不同。Flink也提供exactly once消息傳輸機制。

狀態管理大部分大型流處理應用都涉及到狀態。相對于無狀態的操作(其只有一個輸入數據，處理過程和輸出結果)，有狀態的應用會有一個輸入數據和一個狀態信息，然后處理過程，接著輸出結果和修改狀態信息。因此，我們不得不管理狀態信息，并持久化。我們期望一旦因某種原因失敗，狀態能夠修復。狀態修復有可能會出現小問題，它并不總是保證exactly once，有時也會出現消費多次，但這并不是我們想要的。

據我們所知，Storm提供at-least once的消息傳輸保障。那我們又該如何使用Trident做到exactly once的語義。概念上貌似挺簡單，你只需要提交每條數據記錄，但這顯然不是那么高效。所以你會想到小批量的數據記錄一起提交會優化。Trident定義了幾個抽象來達到exactly once的語義，見下圖，其中也會有些局限。

Spark Streaming是微批處理系統，它把狀態信息也看做是一種微批量數據流。在處理每個微批量數據時，Spark加載當前的狀態信息，接著通過函數操作獲得處理后的微批量數據結果并修改加載過的狀態信息。

1Samza實現狀態管理是通過Kafka來處理的。Samza有真實的狀態操作，所以其任務會持有一個狀態信息，并把狀態改變的日志推送到Kafka。如果需要狀態重建，可以很容易的從Kafka的topic重建。為了達到更快的狀態管理，Samza也支持把狀態信息放入本地key-value存儲中，所以狀態信息不必一直在Kafka中管理，見下圖。不幸的是，Samza只提供at-least once語義，exactly once的支持也在計劃中。

Flink提供狀態操作，和Samza類似。Flink提供兩種類型的狀態：一種是用戶自定義狀態;另外一種是窗口狀態。如圖，第一個狀態是自定義狀態，它和其它的的狀態不相互作用。這些狀態可以分區或者使用嵌入式Key-Value存儲狀態[文檔一和二]。當然Flink提供exactly-once語義。下圖展示Flink長期運行的三個狀態。

單詞計數例子中的狀態管理單詞計數的詳細代碼見上篇文章，這里僅關注狀態管理部分。讓我們先看Trident：

在第九行代碼中，我們通過調用persistentAggregate創建一個狀態。其中參數Count存儲單詞數，如果你想從狀態中處理數據，你必須創建一個數據流。從代碼中也可以看出實現起來不方便。Spark Streaming聲明式的方法稍微好點：

首先我們需要創建一個RDD來初始化狀態(第二行代碼)，然后進行transformations(第五行和六行代碼)。接著在第八行到十四行代碼，我們定義函數來處理單詞數狀態。函數計算并更新狀態，最后返回結果。第十六行和十七行代碼，我們得到一個狀態信息流，其中包含單詞數。接著我們看下Samza，

?

首先在第三行代碼定義狀態，進行Key-Value存儲，在第五行到八行代碼初始化狀態。接著在計算中使用，上面的代碼已經很直白。最后，講下Flink使用簡潔的API實現狀態管理：

?

我們僅僅需要在第六行代碼中調用mapwithstate函數，它有一個函數參數(函數有兩個變量，第一個是單詞，第二個是狀態。然后返回處理的結果和新的狀態)。流處理框架性能這里所講的性能主要涉及到的是延遲性和吞吐量。對于延遲性來說，微批處理一般在秒級別，大部分原生流處理在百毫秒以下，調優的情況下Storm可以很輕松的達到十毫秒。

同時也要記住，消息傳輸機制保障，容錯性和狀態恢復都會占用機器資源。例如，打開容錯恢復可能會降低10%到15%的性能，Storm可能降低70%的吞吐量。

總之，天下沒有免費的午餐。對于有狀態管理，Flink會降低25%的性能，Spark Streaming降低50%的性能。也要記住，各大流處理框架的所有操作都是分布式的，通過網絡發送數據是相當耗時的，所以進了利用數據本地性，也盡量優化你的應用的序列化。項目成熟度

當你為應用選型時一定會考慮項目的成熟度。下面來快速瀏覽一下：

Storm是第一個主流的流處理框架，后期已經成為長期的工業級的標準，并在像Twitter，Yahoo，Spotify等大公司使用。Spark Streaming是最近最流行的Scala代碼實現的流處理框架。現在Spark Streaming被公司(Netflix, Cisco, DataStax, Intel, IBM等)日漸接受。Samza主要在LinkedIn公司使用。Flink是一個新興的項目，很有前景。

你可能對項目的貢獻者數量也感興趣。Storm和Trident大概有180個代碼貢獻者;整個Spark有720多個;根據github顯示，Samza有40個;Flink有超過130個代碼貢獻者。小結在進行流處理框架推薦之前，先來整體看下總結表：

流處理框架推薦應用選型是大家都會遇到的問題，一般是根據應用具體的場景來選擇特定的流處理框架。下面給出幾個作者認為優先考慮的點：

1. High level API：具有high level API的流處理框架會更簡潔和高效;
2. 狀態管理：大部分流處理應用都涉及到狀態管理，因此你得把狀態管理作為評價指標之一;
3. exactly once語義：exactly once會使得應用開發變得簡單，但也要看具體需求，可能at least once 或者at most once語義就滿足你得要求;
4. 自動恢復：確保流處理系統能夠快速恢復，你可以使用Chaos Monkey或者類似的工具進行測試。快速的恢復是流處理重要的部分。

Storm： Storm非常適合任務量小但速度要求高的應用。如果你主要在意流處理框架的延遲性，Storm將可能是你的首先。但同時也要記住，Storm的容錯恢復或者Trident的狀態管理都會降低整體的性能水平。也有一個潛在的Storm更新項目-Twitter的Heron，Heron設計的初衷是為了替代Storm，并在每個單任務上做了優化但同時保留了API。

Spark Streaming： 如果你得基礎架構中已經設計到Spark，那Spark Streaming無疑是值得你嘗試的。因為你可以很好的利用Spark各種library。如果你需要使用Lambda架構，Spark Streaming也是一個不錯的選擇。但你要時刻記住微批處理的局限性，以及它的延遲性問題。

Samza： 如果你想使用Samza，那Kafka應該是你基礎架構中的基石，好在現在Kafka已經成為家喻戶曉的組件。像前面提到的，Samza一般會搭配強大的本地存儲一起，這對管理大數據量的狀態非常有益。它可以輕松處理上萬千兆字節的狀態信息，但要記住Samza只支持at least once語義。

Flink： Flink流處理系統的概念非常不錯，并且滿足絕大多數流處理場景，也經常提供前沿的功能函數，比如，高級窗口函數或者時間處理功能，這些在其它流處理框架中是沒有的。同時Flink也有API提供給通用的批處理場景。但你需要足夠的勇氣去上線一個新興的項目，并且你也不能忘了看下Flink的roadmap。

Dataflow和開源

最后，我們來聊下Dataflow和它的開源。Dataflow是Google云平臺的一部分，Google云平臺包含很多組件：大數據存儲，BigQuery，Cloud PubSub，數據分析工具和前面提到的Dataflow。

Dataflow是Google管理批處理和流處理的統一API。它是建立在MapReduce(批處理)，FlumeJava(編程模型)和MillWheel(流處理)之上。Google最近決定開源Dataflow SDK，并完成Spark和Flink的runner。現在可以通過Dataflow的API來定義Google云平臺作業、Flink作業或者Spark作業，后續會增加對其它引擎的支持。Google為Dataflow提供Java、Python的API，社區已經完成Scalable的DSL支持。除此之外，Google及其合作者提交Apache Beam到Apache。

結論本系列文章粗略的講述各大流行的流處理框架，并討論了它們的相似性、區別、折衷權衡和使用的場景。希望這些將會給你設計流處理方案有幫助。

同系列文章之? Storm，Trident，Spark Streaming，Samza和Flink主流流處理框架比較 | 上

End.