【轉】分佈式數據流的輕量級異步快照

時間 2019-11-13

原文原文鏈接

本篇翻譯自論文：Lightweight Asynchronous Snapshots for Distributed Dataflows，Flink的容錯快照模型即來源於該論文。原文地址：https://arxiv.org/pdf/1506.08603.pdfnode

分佈式數據流的輕量級異步快照

摘要

分佈式有狀態的流處理使得大規模持續計算可以部署在雲端，它的目標是低延遲和高吞吐。其最基本的挑戰之一是提供潛在失敗可能性下對處理的保證。現有的方法都依賴用於故障恢復的週期性全局狀態快照。這些方法有兩個主要缺點。首先，它們常常中止（拖延）所有的計算，這會影響攝取。其次，它們熱衷於保持運行過程當中的全部狀態，致使快照比所需的要大。在咱們這項工做中，咱們提出了異步屏障快照Asynchronous Barrier Snapshotting (ABS)，這是一個的、適用於現代數據流執行引擎的、將空間佔用最小化的輕量級算法。ABS僅僅在非循環執行拓撲上保留Operator的狀態，同時在循環的數據流上保留最小化的record日誌。咱們在Apache Flink（一個支持有狀態的分佈式流處理分析引擎）中實現了ABS。咱們的評估表名，咱們的算法對執行沒有很重的影響，而且保持了線性的擴展以及在頻繁快照的狀況下表現良好。算法

關鍵詞 容錯, 分佈式計算, 流處理, 數據流, 雲計算, 狀態管理apache

1. 介紹

分佈式數據流處理是一種新出現的容許持續計算的數據密集型計算範例，目標是端到端的低延遲同時保證高吞吐量。一些對時間要求嚴格的應用能夠從諸如Apache Flink和Naiad這樣的數據流處理系統受益，尤爲是實時分析領域（eg. 預測分析和復瑣事件處理）。容錯在這類系統中相當重要，由於絕大多數真實世界的用例是不能提供錯誤的。目前已知的，在有狀態的處理系統上可以保證exactly-once語義的方法，依賴於執行狀態的全局一致快照。然而，這裏有兩個主要缺點會使得它們的應用對於實時流處理而言效率低下。同步快照技術會中止分佈式計算的總體執行來得到總體狀態的一致視圖。此外，據咱們所知，已知的全部分佈式快照算法會包含正在通道中傳輸的記錄或者未處理的信息做爲快照的一部分，大多數狀況下，包含的狀態會比須要的大。編程

在這項工做中，咱們專一於提供輕量級的快照，專門針對分佈式有狀態的數據流系統，在性能上影響很小。咱們的解決方案提供異步的低空間成本狀態快照，它僅僅包含了Operator在非循環執行拓撲上的狀態。另外，咱們經過在拓撲的選中部分應用下游備份，同時保持快照狀態在最小值，來覆蓋循環執行圖的case。咱們的技術不會中止流操做，它只會引入很小的運行開銷。這篇論文的主要貢獻能夠概括以下：後端

咱們提出而且實現了一個異步快照算法，它在非循環執行圖上實現了最小化的快照。
咱們描述並實現了用於循環執行圖上的算法的概論。
咱們展現了咱們的方法相比於使用Apache Flink Streaming做爲基礎系統的最新技術的優點。

論文的剩餘篇幅組織以下：第2部分概述了有狀態數據流系統中分佈式全局快照的現有方法；第3部分提供了Apache Flink的處理處理和執行模型，接着第4部分咱們詳細描述了全局快照的主要方法。咱們的恢復方案會在第5部分有個簡要介紹。第6部分總結了咱們的實現，第7部分是咱們的測試評估，將來工做和結論在第8部分。緩存

2. 相關工做

在過去十年間，（業界）爲作持續處理的系統提出過幾種恢復機制[4,11][4,11]。將持續處理模擬爲無狀態分佈式批處理計算（如離散化流和Comet[6，15][6，15]）的系統依賴於狀態從新計算。另外一方面，有狀態的數據流系統，如Naiad、SDGs、Piccolo和SEEP[三、五、十一、12][三、五、十一、12]（它們也是咱們在這項工做中的主要關注點），使用checkpoint檢查點獲取故障恢復的全局執行的一致快照。Chandy和Lamport[4][4]提出的分佈式環境中的一致全局快照問題在過去幾十年中獲得了普遍的研究[4,7,8][4,7,8]。全局快照理論上反映了執行的總體狀態，或者在其操做的特定實例上可能的狀態。Naiad [11][11]採用的一種簡單但成本高昂的方法是分三步同步快照：第一步是暫停執行圖的總體計算，第二步是執行快照，最後一步是指示每一個task在全局快照完成後繼續其操做。這個方法對吞吐量和空間使用都有着很大的影響，由於須要阻塞整個計算，同時還依賴上游備份，該備份記錄生產者端發送的records。另一種流行的方法，最初由Chandy和Lamport提出，如今已經部署在不少系統中，是在作上游備份的時候異步執行快照[4,5,10][4,5,10]。這是經過在整個執行圖中分佈標記來實現的，這些標記會觸發Operator和通道狀態的持久性。可是，因爲須要上游備份，而且因爲對備份記錄的從新處理致使恢復時間延長，這種方法仍然存在額外的空間需求。咱們的方法擴展了Chandy和Lamport最初的異步快照思想，可是，它不考慮非循環圖記錄的備份日誌記錄，同時在循環執行圖上保留很是有選擇性的備份記錄。安全

3. Apache Flink

咱們當前的工做以Apache Flink Streaming的容錯需求爲指導，Apache Flink Streaming是一個分佈式流分析系統，是Apache Flink Stack（前身Stratosphere [2][2]）的一部分。 Apache Flink圍繞通用的Runtime引擎進行架構，統一處理有狀態而且互連的task組成的批處理和流工做。 Flink中的分析做業被編譯爲任務的有向圖。數據元素從外部源獲取，並以管道方式經過任務圖進行路由。 task根據收到的輸入持續操縱其內部狀態，併產生新的輸出。網絡

3.1 流式編程模型

Apache Flink的流式處理API容許經過暴露無界有分區的數據流（部分排序的record序列）做爲其核心的數據抽象（稱爲DataStream）來組合複雜的流分析job。DataStream能夠從外部數據源創立（如消息隊列，Socket流，自定義Generator）或者經過在其餘DataStream上調用操做。DataStream以高階函數的形式支持多種operator如map、filter、reduce，這些函數在每條記錄上都應用，生成新的DataStream。下面代碼示例1展現瞭如何在Apache Flink實現一個增量的WordCount。在這個程序裏，單詞從文本讀入，每一個單詞的count打印到標準輸出。這是一個有狀態的流程序，由於數據源須要留意當前單詞在文件的偏移量，計數器葉鏊維持當前的每一個單詞的計數做爲它們的內部狀態。架構

圖1：增量的WordCount執行圖異步

val env : StreamExecutionEnvironment = ...
env.setParallelism(2)

val wordStream = env.readTextFile(path)
val countStream = wordStream.groupBy(_).count
countStream.print

示例1：增量的WordCount程序

3.2 分佈式數據流執行

當用戶執行一個應用，全部的DataStream operator會編譯成一個執行圖，原則上是一個有向圖G = (T, E)，頂點T表明Task，邊E表明task之間的數據通道，這和Naiad類似。上圖1描繪了一個增量WordCount示例程序的執行圖。如圖所示，每一個operator實例都被封裝到相關task上。當沒有輸入通道時，task能夠更進一步被分類爲數據源，沒有輸出通道時，task能夠下沉。此外，M表示在並行執行期間全部經過task傳輸的record的集合，每一個task t∈Tt∈T 封裝了一個獨立執行的operator實例，而且由如下部分組成：（1）輸入輸出通道的集合：It,Ot⊆EIt,Ot⊆E；（2）一個operator的狀態stst和（3）用戶自定義函數（UDF）ftft。數據接收是基於拉取（pull-based）的：在執行期間，每一個task消耗其input records，更新其operator狀態並根據其用戶自定義函數生成新記錄。更具體地說，對於一個task t∈Tt∈T接收的每一個record r∈Mr∈M，一個新的狀態s、tst、會隨着根據UDF ft:st,r−>[s、t,D]ft:st,r−>[st、,D] 獲得的輸出records集合 D⊆MD⊆M產生。

4. 異步屏障快照（Asynchronous Barrier Snapshotting， ABS）

爲了提供持續的輸入，分佈式處理系統須要對故障task有彈性（容忍）。一個提供彈性的方式是週期性地抓取執行圖的快照，這樣就能夠用來稍後從故障中恢復。一個快照是一個執行圖的全局狀態，抓取全部必須的信息來從特定的執行狀態重啓計算。

4.1 問題定義

咱們定義了一個執行圖G=(T,E)G=(T,E)的全局快照Gx=(Tx,Ex)Gx=(Tx,Ex)做爲一個全部task和edge的狀態集合，TxTx和ExEx分別地。更詳細地說，TxTx由全部operator的狀態sxt∈Tx,∀t∈Tstx∈Tx,∀t∈T組成，ExEx是通道狀態的集合ex∈Exex∈Ex，而exex由在e中傳輸的records組成。

咱們須要爲每一個快照G∗G∗保留某些屬性，爲了保證恢復的正確結果如Tel所描述的終止（Termination）和可行性（Feasibility）[14][14]。

終止（Termination）保證了一個快照算法在全部進程alive的狀況下最終能在有限的時間內完成。可行性（Feasibility）表示快照是有意義的的，即在快照過程當中沒有丟失有關計算的信息。從形式上講，這意味着快照中維護了因果順序，這樣task中傳遞的records也是從快照的角度發送的。

4.2 非循環數據流的ABS

執行被拆分紅stages的狀況下，不保存通道狀態就作快照是可行的。Stages將注入的數據流和全部相關的計算拆分爲一系列可能的執行（executions），在這些執行中，全部先前的輸入和生成的輸出都已經被安全處理。一個stage結束時的operator狀態的集合反映了整個執行的歷史。所以，它能夠單獨用於快照。咱們算法的核心思想是在保持持續數據流入的同時，使用階段性（分階段）快照建立相同的快照。

在咱們的方法中，stage在持續數據流執行中被特殊的屏障標記所模擬，這些屏障標記被數據流週期性地注入，也在整個執行圖中被推送到下游接收。隨着每一個task接收指示執行階段的屏障，逐步構建全局快照。咱們進一步對咱們的算法作出如下假設：

圖2：非循環圖的異步屏障快照（ABS）

算法1：非循環執行圖的異步屏障快照

1: upon event do
2: state := init_state; blocked_inputs := ϕϕ;
3: inputs := input_channels;
4: outputs := output_channels; udf := fun;
5:
6: upon event > do
7: if input ≠≠ Nil then
8: blocked_inputs := blocked_inputs ∪∪ {input};
9: trigger ;
10: if blocked_inputs = inputs then
11: blocked_inputs := ϕϕ;
12: broadcast >;
13: trigger ;
14: for each inputs as input
15: trigger ;
16:
17:
18: upon event do
19: {state ‘‘, out_records}:=udf(msg,state);
20: state:=state‘‘;
21: for each out_records as {out_put,out_record}
22: *trigger ;
23:

網絡信道是準可靠的，遵照FIFO傳送次序，能夠被阻止（blocked）和解除阻止（unblock）。
當通道被阻止（blocked）時，全部消息（msg）都被緩衝但在解除阻塞（unblock）以前不會繼續傳遞。
Task能夠在它們的通道（channel）組件觸發（trigger）操做如阻止（blocked）、解除阻止（unblock）和發送（send）消息。廣播（broadcast）消息也是在輸出通道（output_channel）上支持的。
在源頭task上注入的消息（msg），即消息屏障，被解析爲「Nil」輸入通道（input_channel）。

譯者注：這段確實有點晦澀難懂，我來解釋一下。

首先說圖，能夠看到圖上黑色加粗的線標記的是barrier屏障，屏障存在於每一個通道上，能夠看作一個特殊的record，在其前面的record叫preshot records，在其後面的record叫postshot records，當preshot records都被傳遞到途中的count算子後，src->count的通道上只剩postshot records，這時候通道會block，按照前文的說法，block的channel上的record都會在緩存裏。當鏈接至某個算子的所有輸入信道（如圖中b所示的count-1 task的兩條輸入通道src-1->count-1和src-2->count-1通道）都已經block之後，對該task作快照，同理圖中c所示的count-2 task也同樣。
而後說算法，首先要明確一下，算法中的input和output其實都是指通道。
- 第一個方法很好理解，一個初始化方法，此時block的輸入通道是空集，也就是沒有被block的通道。
- 第二個和第三個方法其實都是receive的方法，上面我在解釋圖的時候說過，能夠把barrier看成一個特殊的record來考慮。因此，第二個方法是接收到barrier，第三個方法是接收到正常的有msg的record。那咱們先來講第二個，當task接收到barrier屏障時，首先是個常規的空值判斷，若是input不爲空，那麼就把觸發該input通道的block。而且該task的block的input通道的集合爲當前已經block的通道和參數input通道的並集。若是block的input通道等於全部input通道，也就是全部input通道都已經被block了，此時觸發該task的快照操做，而且把屏障日後廣播（即對全部output通道加上這個屏障），而後對全部input通道解除block。
- 第三個方法，傳入msg，經過UDF計算出結果record和結果狀態，而且把結果狀態賦值給當前狀態，而且把全部結果record日後發送（結果集的每一個record對應的output通道不必定是同一個，只逐個往對應的output通道發送）。

下文也會有官方解釋，更進一步瞭解該算法。↓↓↓↓

ABS算法也如圖2所示：一箇中心協調器會週期性地給全部source注入stage屏障。當一個source收到了屏障，它就會給當前狀態作一個快照，而後廣播屏障到全部輸出通道（如圖2的a）。當一個非source的task收到了其input通道里的某個發送過來的屏障，它會block該input通道直到它收到了全部input通道的屏障（算法第9行，圖2的b），而後該task就會生成其當前狀態的快照而且廣播屏障給全部output通道（算法第12-13行，圖2的c）。接下來，該task會解除全部input通道的block繼續計算（算法第15行，圖2的d）。最終的全局快照Gx=(Tx,Ex)Gx=(Tx,Ex)是徹底由全部Ex=ϕEx=ϕ的operator的狀態T∗T∗組成的。

證實簡述：正如以前提到的，一個快照算法須要保證終止（Termination）和可行性（Feasibility）。
終止（Termination）是由通道和非循環執行圖的屬性保證的。通道的可靠性保證了只要task存活，最終將收到以前發送的每一個屏障。此外，因爲始終存在來自源的路徑，所以有向無環圖（DAG）拓撲中的每一個任務task都會從其全部輸入通道接收到屏障並生成快照。
至於可行性（Feasibility），它足以代表全局快照中的operator的狀態只反映到最後一個stage處理的records的歷史。這是由先入先出順序（FIFO）和屏障上input通道的block來保證的，它確保在快照生成以前沒有post-shot記錄會被處理。

4.3 循環數據流的ABS

在執行圖存在有向循環的狀況下，前面提出的ABS算法不會終止，這就會致使死鎖，由於循環中的task將無限等待接收來自其全部輸入的屏障。此外，在循環內任意傳輸的records不會包含在快照中，違反了可行性。所以，須要一致地將一個週期內生成的全部記錄包括在快照中，以便於可行性，並在恢復時將這些記錄放回傳輸中。咱們處理循環圖的方法擴展了基本算法，而不會引入任何額外的通道阻塞，以下算法2所示。首先，咱們經過靜態分析，在執行圖的循環中定義back-edges L。根據控制流圖理論，在一個有向圖中，一個back-edge是一個指向已經在深度優先搜索（depth-first search）中被訪問過的頂點（vertex）的邊（edge）。定義執行圖 G(T, E \ L) 是一個包含拓撲中全部task的有向無環圖（DAG）。從這個DAG的角度來看，該算法和之前同樣工做，不過，咱們在快照期間還使用從已定義的back-edges接收的記錄的下游備份。這是由每一個task t 實現的，back-edges的一個消費者Lt⊆It,LtLt⊆It,Lt產生一個從LtLt轉發屏障到接收屏障們回LtLt的備份日誌。屏障會push全部在循環中的records進入下游的日誌，因此它們在接二連三的快照中只會存在一次。

圖3：循環圖的異步屏障快照（ABS）

算法2：非循環執行圖的異步屏障快照

1: upon event do
2: state := init_state; marked := ϕϕ;
3: inputs := input_channels; logging := False
4: outputs := output_channels; udf := fun;
5: loop_inputs := backedge_channels;
6: state_copy := Nil; backup_log := [];
7:
8: upon event > do
9: marked := marked ∪∪ {input}
10: regular := inputs \ loop_inputs;
11: if input ≠≠ Nil AND input ∉∉ loop_inputs then
12: trigger ;
13: if !logging AND marked = regular then
14: state_copy := state; logging := True;
15: broadcast >;
16: for each inputs as input
17: trigger ;
18:
19: if marked = input_channels then
20: trigger ;
21: marked := ϕϕ; logging := False;
22: state_copy := Nil; backup_log := [];
23:
24: upon event do
25: if logging AND node ∈∈ loop_inputs then
26: backup_log := backup_log :: [input];
27: {state ‘‘, out_records}:=udf(msg,state);
28: state:=state‘‘;
29: for each out_records as {out_put,out_record}
30: *trigger ;
31:

譯者注：這個算法跟上一個算法不同的地方在於，把循環過的input邊看成back-edge，其他邊看成regular，除掉循環的DAG依然仍是按以前的作法處理，而後有back-edge的邊的task，在接收到屏障的時候須要把其state作一個備份，而且接受它的back-edge中在屏障以前的pre-shot record做爲log。

更詳細解釋下ABS算法2（圖3所示）：有着back-edge做爲輸入通道的task，一旦它們的常規通道（e∉Le∉L）都接收到了屏障，該task就會產生了一個其狀態的本地備份（算法的14行，圖3的b）。接下來，從這一點開始，它們記錄從back-edges收到的全部record，直到它們收到來自它們的stage屏障（算法第26行）。這就容許，像圖3（c）中看到的，全部在循環中的pre-shot record，都會包含在當前快照中。注意，最後的全局快照Gx=(Tx,Lx)Gx=(Tx,Lx) 包含了全部task的狀態TxTx和在傳輸中Lx⊂ExLx⊂Ex僅僅back-edge中的記錄。

證實簡述：再次地，咱們須要證實終止（Termination）和可行性（Feasibility）。與4.2中終止（Termination）被保證同樣，由於每一個task最終都會接收到全部輸入通道（包括後端）的屏障。經過從全部常規輸入接收屏障後當即廣播屏障，咱們避免了前面提到的死鎖條件。

FIFO的屬性仍適用於back-edge，如下屬性證實了可行性。（1）快照中包含的每一個task狀態，是在處理常規輸入接收的post-shot record以前所執行的各自task的狀態副本。（2）快照中包含的下游日誌是完整的，因爲FIFO保證，包含back-edge接收的全部屏障以前的全部pending的post-shot record。

5. 故障恢復

雖然不是這項工做的主要焦點，但故障恢復方案是咱們應用快照方法的動機。所以，咱們在這裏簡要說明了它的操做。有幾種故障恢復方案可使用這種持續快照。在最簡單的形式中，整個執行圖能夠從上一個全局快照從新啓動，以下所示：每一個任務t（1）從持久化存儲中檢索其快照stst的關聯狀態並將其設置爲其初始狀態，（2）恢復其備份日誌並處理全部其中包含的records，（3）開始從其輸入通道中攝取records。相似於TimeStream [13]，部分圖恢復方案也是可行的，經過僅從新安排上游依賴task（輸出通道鏈接失敗task的task）以及它們各自的上游任務直到源。示例恢復計劃如圖4所示。爲了提供exactly-once語義，應在全部下游節點中忽略重複記錄以免從新計算。爲了實現這一目標，咱們能夠遵循與SDG相似的方案[5]，使用來自源的序列號標記記錄，所以，每一個下游節點均可以丟棄序列號小於已處理的記錄的記錄。

圖4：示例恢復計劃

6. 實現

咱們爲Apache Flink貢獻了ABS算法的實現，以便爲流運行時提供精確的一次處理語義。在咱們當前的實現中，阻塞通道將全部傳入記錄存儲在磁盤上，而不是將它們保留在內存中以提升可伸縮性。雖然這種技術確保了魯棒性，但它增長了ABS算法的運行時間影響。

爲了從數據中區分operator狀態，咱們引入了一個顯式的OperatorState接口，該接口包含更新和檢查狀態的方法。咱們爲Apache Flink支持的有狀態的運行時operator提供了OperatorState實現，例如基於偏移量的源或聚合。

快照協調是做爲JobManager上的參與者進程實現的，它爲單個job的執行圖保留全局狀態。協調器按期向執行圖的全部源注入階段屏障。從新配置後，最後一個全局快照狀態將從分佈式in-memory的持久化存儲中恢復到operator上。

7. 評估

咱們評估的目標是將ABS的運行時開銷與Naiad [11]中採用的全局同步快照算法進行比較，並測試該算法在大量節點上的可擴展性。

7.1 Setup

用於評估的執行拓撲（圖5）由6個不一樣的運算符組成，並行度等於集羣節點的數量，Task點的數量是6倍的集羣節點數量。該執行包含了3個shuffle，以強調ABS中通道阻塞的可能影響。源生成總共10億條記錄，這些記錄統一分佈在源實例之間。拓撲中的operator的狀態是每一個key的聚合和源偏移。實驗在Amazon EC2集羣上運行，使用多達40臺 m3.medium實例。

圖5：用於評估的執行拓撲

咱們測量了在不一樣快照方案下運行的評估做業的運行時開銷，即ABS和具備不一樣快照間隔的同步快照[11]。咱們在Apache Flink上實現了Naiad [11]中使用的同步快照算法，以便爲比較提供相同的執行後端。該實驗使用10節點集羣運行。爲了評估算法的可擴展性，咱們處理了固定數量的輸入記錄（10億），同時將拓撲的並行性從5個增長到40個節點。

7.2 結論

在圖6中，咱們描述了兩種算法對基線的運行時影響（沒有容錯）。當快照間隔很小時，同步快照的巨大性能影響尤其明顯。這是由於系統花費更多時間不處理任何數據，以得到全局快照。 ABS對運行時的影響要小得多，由於它在不阻塞總體執行的狀況下連續運行，同時保持至關穩定的吞吐率。對於較大的快照間隔，同步算法的影響不過重要，由於它是忽然執行的（在咱們的實驗中爲1-2秒），同時讓系統在其他執行期間以其正常吞吐量運行。然而，就許多臨界環境應用（如入侵檢測管道）的實時保證而言，突發事件一般會違反SLA。所以，這些應用將經過ABS的性能進一步受益。在圖7中，咱們將運行ABS的拓撲的可擴展性與基線的3秒快照間隔進行比較（沒有容錯）。很明顯，基線工做和ABS都實現了線性可擴展性。

圖6：兩種算法對基線的運行時影響（沒有容錯）

圖7：與基線的3秒快照間隔進行比較（沒有容錯）

8. 將來的工做和結論

在將來的工做中，咱們計劃經過解耦快照狀態和運行狀態來探索進一步下降ABS影響的可能性。這容許純粹的異步狀態管理，由於任務能夠在持久化快照的同時連續處理記錄。在這種方案中，還須要將pre-shot和post-shot記錄與相應的狀態同步，這能夠經過根據它們所屬的快照標記記錄來解決。因爲這種方法會增長算法的計算，空間和網絡I/O要求，咱們計劃將其性能與咱們當前的ABS實現進行比較。最後，咱們計劃研究不一樣的恢復技術，這些技術只維護exactly-once語義，同時經過在每一個任務粒度上操做來最小化從新配置的須要。

綜上所述，咱們重點研究了分佈式數據流系統中週期性全局快照的問題，介紹了一種新的快照技術ABS，它能夠得到良好的吞吐量。ABS是第一個考慮非循環執行拓撲可能的最小化的狀態的算法。此外，咱們還擴展了ABS來處理循環執行圖，只存儲恢復時須要從新處理的記錄。咱們在ApacheFlink上實現了ABS，並跟同步快照做對比，測試評估了咱們的方法。在此早期階段，ABS顯示出良好的效果，對總體執行吞吐量的影響很小，具備線性可擴展性。

參考文獻

[1] Apache flink. https://flink.apache.org/.

[2] A. Alexandrov, R. Bergmann, S. Ewen, J.-C. Freytag, F. Hueske, A. Heise, O. Kao, M. Leich, U. Leser, V. Markl, et al. The stratosphere platform for big data analytics. The VLDB JournalThe International Journal on Very Large Data Bases, 23(6):939–964, 2014.

[3] R. Castro Fernandez, M. Migliavacca, E. Kalyvianaki, and P. Pietzuch. Integrating scale out and fault tolerance in stream processing using operator state management. In Proceedings of the 2013 ACM SIGMOD international conference on Management of data, pages 725–736. ACM, 2013.

[4] K. M. Chandy and L. Lamport. Distributed snapshots: determining global states of distributed systems. ACM Transactions on Computer Systems (TOCS), 3(1):63–75, 1985.

[5] R. C. Fernandez, M. Migliavacca, E. Kalyvianaki, and P. Pietzuch. Making state explicit for imperative big data processing. In USENIX ATC, 2014.

[6] B. He, M. Yang, Z. Guo, R. Chen, B. Su, W. Lin, and L. Zhou. Comet: batched stream processing for data intensive distributed computing. In Proceedings of the 1st ACM symposium on Cloud computing, pages 63–74. ACM, 2010.

[7] A. D. Kshemkalyani, M. Raynal, and M. Singhal. An introduction to snapshot algorithms in distributed computing. Distributed systems engineering, 2(4):224, 1995.

[8] T. H. Lai and T. H. Yang. On distributed snapshots. Information Processing Letters, 25(3):153–158, 1987.

[9] L. Lamport. Time, clocks, and the ordering of events in a distributed system. Communications of the ACM, 21(7):558–565, 1978.

[10] Y. Low, D. Bickson, J. Gonzalez, C. Guestrin, A. Kyrola, and J. M. Hellerstein. Distributed graphlab: a framework for machine learning and data mining in the cloud. Proceedings of the VLDB Endowment, 5(8):716–727, 2012.

[11] D. G. Murray, F. McSherry, R. Isaacs, M. Isard, P. Barham, and M. Abadi. Naiad: a timely dataflow system. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, pages 439–455. ACM, 2013.

[12] R. Power and J. Li. Piccolo: Building fast, distributed programs with partitioned tables. In OSDI, volume 10, pages 1–14, 2010.

[13] Z. Qian, Y. He, C. Su, Z. Wu, H. Zhu, T. Zhang, L. Zhou, Y. Yu, and Z. Zhang. Timestream: Reliable stream computation in the cloud. In Proceedings of the 8th ACM European Conference on Computer Systems, pages 1–14. ACM, 2013.

[14] G. Tel. Introduction to distributed algorithms. Cambridge university press, 2000.

[15] M. Zaharia, T. Das, H. Li, S. Shenker, and I. Stoica. Discretized streams: an efficient and fault-tolerant model for stream processing on large clusters. In Proceedings of the 4th USENIX conference on Hot Topics in Cloud Ccomputing, pages 10–10. USENIX Association, 2012.

【原文】http://blog.orisonchan.cc/2019/04/04/51/