點擊上方藍字關注我們

數據流計算模型及其在大數據處理中的應用

畢倪飛,?丁光耀,?陳啟航,?徐辰,?周傲英

華東師范大學數據科學與工程學院，上海 200062

論文引用格式：

畢倪飛,?丁光耀,?陳啟航,?徐辰,?周傲英.數據流計算模型及其在大數據處理中的應用.?大數據[J], 2020, 6(3):73-86

BI N F, DING G Y, CHEN Q H, XU C, ZHOU A?Y.Dataflow model and its applications in big data processing.?Big Data Research[J], 2020, 6(3): 73-86

1 引言

計算機體系結構的計算模型可以分為控制流和數據流兩大類。控制流計算機也被稱為馮·諾伊曼型計算機，它是主流計算機一直采用的體系結構。控制流計算模型按指令的順序來驅動操作，數據是否參加運算取決于當時所執行的指令是否需要。數據流計算模型采用數據驅動方式，只有當一條或一組指令所需的操作數全部準備好時，才能激發相應指令的執行，執行結果又流向等待這一數據的下一條或一組指令，以驅動該條或該組指令的執行。大數據處理中也存在數據流計算模型的概念，但是大數據處理中的數據流計算模型用于完成復雜的數據處理工作，與計算機體系結構中的數據流計算模型位于不同層面，并非同一個概念。此外，Murray和McSherry等人提出增量數據流計算模型，主要用于解決迭代算法中增量計算的問題，TensorFlow的數據流模型主要用于抽象描述機器學習算法中的狀態和計算，Bonna和Loubach等人提出的場景感知數據流模型主要對動態應用程序進行建模和仿真，而本文大數據處理中的數據流計算模型用于低時延、正確地處理大規模、無界、亂序的數據，因此這些數據流計算模型與本文大數據處理中的數據流計算模型不是同一個概念。

現有的大數據處理系統按照執行引擎可以分為兩大類。一類是基于批處理引擎的大數據處理系統，如MapReduce 、Spar k、Spark Streaming、Structured Streami ng和Dr yad等；另一類是基于流計算引擎的大數據處理系統，如S torm、Mill wheel、Samza和Flink等。在執行引擎層面 ，大數據處理中的數據流計算模型體現為數據流圖。大數據處理系統通常使用數據流圖來直觀地表達復雜的數據處理邏輯，用戶編寫的數據處理流程在系統中先被轉換為邏輯數據流圖，該圖是由一組頂點和邊構成的有向無環圖，該有向無環圖在被交給底層執行引擎之前，根據特定的并發度又被進一步轉換為物理數據流圖。在統一編程層面，大數據處理中的數據流計算模型體現為 數據流編程模型。數據流編程模型將批處理和流計算引擎的編程方式進行抽象統一，引入了事件時間、窗口和水位線等重要概念，旨在滿足數據消費者對窗口、時間語義以及處理時延等的需求。

本文結合Spark批處理引擎和Flink流計算引擎等多個執行引擎，對比分析了數據流圖和數據流編程模型在兩者中的具體實現。

2 數據流圖

本節首先介紹大數據處理中的邏輯數據流圖，其次介紹物理數據流圖，最后結合Spark批處理引擎和Flink流計算引擎分析物理數據流圖在兩者中的具體體現。

2.1 邏輯數據流圖

大數據處理系統通常使用邏輯數據流圖來抽象描述整個數據處理的邏輯流程，邏輯數據流圖是一個由一組頂點和邊構成的有向無環圖。有向無環圖中的每個頂點代表了整個數據處理流程中一個特定的數據處理步驟，封裝了用戶定義的數據轉換操作，如選擇、過濾、聚合、連接等，對接收到的輸入數據執行轉換操作后產生輸出數據。頂點和頂點之間通過有向邊連接，每條有向邊代表了數據的流動和數據的依賴。與有向邊起點相連的頂點表示數據的生產者，與有向邊終點相連的頂點表示數據的消費者，數據由生產者流向消費者，消費者對數據的處理依賴于生產者的處理結果。如圖1所示，該邏輯數據流圖由5個表示計算邏輯的頂點和4條表示數據流動和數據依賴的有向邊組成，表達了數據從讀取頂點被讀取后，依次流經映射、按鍵值分組和過濾3個頂點，并在這3個頂點中進行轉換處理，最終通過保存頂點將處理結果存儲下來的整個數據處理流程。

2.2 物理數據流圖

大數據處理系統通常采用并行化的策略進行數據處理，將數據按照特定的分區策略進行分區，并為每個數據處理頂點設定并行度，讓不同的數據分區流入各自相應的數據處理頂點實例，以達到并行處理的目的。但是邏輯數據流圖中的頂點和邊僅僅是對處理過程的邏輯抽象，即每個頂點是一個邏輯的處理步驟，不包含系統實際處理數據時并行化的概念，每條邊也只描述了邏輯頂點之間的數據流動。因此，邏輯數據流圖不能被直接應用到底層執行引擎，而需要先在邏輯數據流圖中引入并行度，將其轉換為物理數據流圖后才能交給底層執行引擎。圖2展示了圖1中描述的邏輯數據流圖根據特定的并行度轉換后得到的物理數據流圖，該物理數據流圖中讀取和映射2個數據處理頂點的并行度為3，按鍵值分組、過濾和保存3個數據處理頂點的并行度為2。由于批處理引擎和流計算引擎2種執行引擎的數據交換機制不同，物理數據流圖在這2種執行引擎中的具體體現也有所不同。

圖1???邏輯數據流圖

圖2???物理數據流圖

2.2.1 批處理引擎中的物理數據流圖

在批處理引擎中，一個物理數據流圖通常被劃分為多個階段，階段之間根據依賴關系按序執行，一個階段只有等其依賴的所有階段都執行結束后才能開始執行。每個階段由與分區數相同個數的任務組成，一個任務負責一個分區，各個任務之間相互獨立執行，不會發生數據交換。當某個任務中的一條數據被處理完成后，并不會立刻通過網絡將其傳輸到下一個階段的任務中，而是先將其放在緩存中，當緩存達到一定的閾值時，再將緩存中的數據溢寫到本地磁盤上。只有當一個階段中所有的任務都完成數據處理，并將處理結果寫入磁盤后，才開始將這個階段處理后的中間結果通過網絡傳輸到下一個階段進行后續處理。

例如，在基于批處理引擎的Spark系統中，將每個邏輯數據流圖根據給定的并行度轉換為物理數據流圖后，系統會根據數據交換將該物理數據流圖劃分為多個階段按序執行。如圖3所示，因為在按鍵值分組頂點處發生數據交換，所以整個物理數據流圖在此處被切分，形成階段0和階段1這2個階段。其中，階段1中的數據處理依賴于階段0處理后的中間結果，即2個階段的執行存在先后順序，階段1只有在階段0的處理全部完成后才能開始執行。在階段0中，系統啟動3個線程分別處理相互獨立的3個分區中的數據，并將得到的中間結果存儲在3個線程各自的本地磁盤上。等到階段0中的3個線程都完成處理后，系統開始進行階段1的處理，階段1中啟動2個線程分別負責2個分區的數據，每個線程通過網絡從階段0的中間結果處獲取屬于自己的數據進行后續處理。

2.2.2 流計算引擎中的物理數據流圖

在流計算引擎中，物理數據流圖不會被劃分為多個階段，數據流圖中的所有處理任務同時啟動并且長時間運行，直到整個作業完成或終止。任務之間的數據交換不需要阻塞式地將中間結果數據先寫入磁盤再發送給下游任務，而是采用流水線的方式，即在處理完一條數據后立即將其發送給下游任務。這種方式有效地降低了數據處理的時延，但會導致過多的網絡輸入/輸出（input/output，I/O）次數，從而造成系統吞吐量的下降。為了減少發送數據的網絡I/O次數對吞吐量性能的影響，流計算引擎通常會設置內存緩沖區收集結果數據，當緩沖區內的數據量積累到一定大小（例如32 KB）后再一并發送給下游任務。

圖3???批處理引擎中的物理數據流圖

在基于流計算引擎的Flink系統中，物理數據流圖中的每個任務在處理一條數據后將結果放入內存緩沖區中，緩沖區不斷接收任務產生的結果數據，當緩沖區數據大小達到閾值（默認32 KB）或緩沖區保存數據的時間超過設定的閾值（默認100 ms）時，系統就將緩沖區內的數據通過網絡傳輸給下游任務。Flink通過設置內存緩沖區一次發送小批數據來避免過多的網絡I/O次數，以犧牲部分時延性能為代價提升了系統的吞吐量，用戶可以根據應用需求設置超時閾值，以在系統的吞吐量和時延之間進行權衡。如圖4所示，每個物理任務都維護一個本地緩沖池，緩沖池中含有多個用于網絡傳輸的緩沖區。最右側已經填滿數據的緩沖區將被發送到下游算子，中間還未填滿數據的緩沖區直到填滿數據或觸發超時機制后才會被發送到下游任務，最左側還未填充任何數據的緩沖區只有在先驅緩沖區被填滿或者觸發超時機制后才開始接收本地任務的輸出數據。

圖4???流計算引擎中的物理數據流圖

3 數據流編程模型

本節介紹Google公司提出的數據流編程模型，首先闡明有界數據和無界數據的概念，其次介紹數據 流編程模型中的時間語義和水位線2個重要概念，在此基礎上依次在原語算子中介紹計算結果的方式，在窗口操作中介紹數據按事件時間被分到哪個窗口中計算結果，在觸發器中介紹被分配到窗口內的數據按處理時間何時被處理，并展示給用戶，在修正策略中介紹同一窗口的多個結果之間如何相互關聯。

3.1 有界數據和無界數據

當談到有限/無限數據時，有些地方可能會將其描述為批/流數據。但是批/流數據容易讓人產生誤解，即批處理系統用于處理批數據，流計算系統用于處理流數據。而事實上，批處理系統也可以用于處理流數據，如Structured Streaming常被用于處理流數據，而其底層是Spark批處理系統。類似地，也可以用流計算系統Flink來處理批數據。因此，使用批/流數據概念容易造成誤解，故本文統一使用有界/無界數據來表示有限/無限數據，將批和流用于描述批處理引擎和流計算引擎。

3.2 時間語義和水位線

考慮到系統處理記錄的順序和它們的原始順序可能存在不一致性，在處理數據時，需要考慮2個時間域。

● 事件時間：事件實際發生的時間，即當該事件發生時，其所在系統的當前時間。

● 處理時間：系統執行數據處理的過程中，一個事件被數據處理系統觀察到的時間。也就是，該事件被系統處理時，其所在系統的當前時間。

比如在傳感器采集事件時，對應的系統時間就是事件時間，然后將事件發送到相應的數據處理系統進行處理時對應的系統時間就是處理時間。一個事件的事件時間是永遠不變的，但是一個事件的處理時間會隨著它在數據管道中一步步被處理而持續變化。很多時候需要根據事件時間進行數據分析，而不是處理時間。例如，收到傳感器采集到的數據后，希望統計某一時間段內所監控事物的變化情況，那么依據事件時間統計更為合理（而不是處理時間）。

3.3 原語算子

從有界數據集的角度來看，數據流編程模型把所有的數據抽象為鍵值對，基于鍵值對有2個核心的原語算子。

● ParDo：對數據進行并行化處理，相當于MapReduce中的map原語，將輸入的鍵值對進行一次變換，產生若干個新的鍵值對。

● GroupByKey：按鍵值把元素重新分組，與MapReduce中的Shuffle類似，將含有相同鍵值的元素分到同一組。

這2個核心原語算子可以組合成聚合、去重和連接等 復合算子，例如，圖6右側的Sum ByKey算子是由圖6左側的GroupByKey和ParDo組合而成的一個復合算子，該復合算子是一個聚合算子，統計每個字母出現次數的總和。其中， GroupByKey操作將含有相同字母的元素分配到同一組，形成新的鍵值對；ParDo在新的鍵值對上進行求和運算，得到最終的聚合結果。

圖5???水位線

圖6???由原語算子組合成的復合算子

3.4 窗口操作

當處理無界數據時，由于ParDo原語只涉及處理單個數據，ParDo可以自然地以一次處理一條已到達數據的方式來處理無界數據。與ParDo原語不同， GroupByKey原語涉及同時處理一個給定Key上的所有數據，而由于數據是無界的，系統永遠無法等到給定Key上的所有數據都到達的那一刻，所以GroupByKey無法直接用于處理無界數據。為了支持無界數據上的GroupByKey操作，需要結合窗口操作將GroupByKey重新定義為GroupByKeyAndWindow。窗口操作的核心是通過引入窗口將無界的數據集切分為有界的數據塊，在每個窗口中的有界數據塊上進一步實現按Key進行聚合。

窗口可以分為基于時間的窗口和基于元組的窗口，但兩者本質上都是基于時間的窗口，這是由于基于元組的窗口本質上可以看作基于邏輯時間域的窗口，每個窗口中的元素帶有遞增的邏輯時間戳。基于時間的窗口又可以進一步分為對齊窗口和非對齊窗口，對齊窗口用于落在窗口時間范圍內的所有數據，非對齊窗口用于落在窗口時間范圍內的特定數據。滑動窗口和會話窗口是處理無界數據時常用的2種窗口。

● 滑動窗口：滑動窗口通過一個窗口長度和一個滑動間隔來定義，滑動間隔小于窗口長度。滑動窗口通常是對齊窗口。例如圖7中定義了一個窗口長度為10 min的滑動窗口，每隔5 min滑動一次生成一個新的窗口。值得注意的是，此處的滑動窗口只是為了給人一種滑動的感覺，實際上3個不同的Key上都有3個窗口，而不僅僅是一個窗口。當滑動間隔等于窗口長度時，該窗口被稱為固定窗口。當滑動間隔大于窗口長度時，該窗口被稱為跳躍窗口。

● 會話窗口：會話窗口是指在數據子集上有一段活動時間的窗口。會話窗口通過一個超時時間來定義，在超時時間內的所有數據都被分在同一個窗口中，形成一個會話窗口。會話窗口是非對齊窗口。例如圖7中定義了一個超時時間為5 min的會話窗口，Key1上的會話1和會話2之間的間隔為6 min，超過了超時時間，因此被劃分為2個會話。

圖7???常用窗口

3.5 觸發器

窗口操作決定了數據按事件時間被分到哪個窗口內一起進行聚合操作，劃分好數據后進一步需要解決的是窗口內的數據按處理時間何時被處理并展示給用戶。本文在第3.2節中介紹了一種水位線機制，水位線機制用于評估窗口內數據到達的完整性，每個窗口都帶有起始和終止事件時間戳，一旦水位線越過了某個窗口的終止時間戳，就認為該窗口中的數據都已到達，于是處理該窗口內的數據，并將結果反饋給用戶。但是水位線機制本質上只是對窗口內數據到達完整性的一種猜測，這種猜測與真實的數據到達完整性相比可能過快或過慢。如圖8所示，如果水位線設置得過快，那么水位線之后仍有屬于該窗口內的數據<a,1>繼續到達，但沒有被處理，造成處理結果不正確；如果水位線設置得過慢，那么當水位線越過窗口終止事件時間戳時才觸發計算，可能導致整個處理結果的展示具有較高的時延。因此，僅僅使用水位線機制來觸發計算和展示結果是不夠的。

圖8???水位線設置過快或過慢

為了既能使用戶盡快獲得結果，又能保證結果的正確性，需要定義多個觸發器，針對每個窗口多次向用戶提供結果。如圖9所示，在水位線觸發窗口計算得到結果之前，可以定義一個基于固定處理時間的觸發器向用戶盡早提供結果，該觸發器按處理時間每隔1 min觸發一次計算并提供結果。同樣地，在水位線之后到達的數據可以由一個基于元組個數的觸發器來處理，該觸發器每遇到一條數據就觸發計算，并為用戶提供結果。

圖9???觸發器

3.6 修正策略

除了控制何時觸發計算并展示結果之外，還需要一種方法來控制同一窗口因多次觸發計算而得到的多個結果之間如何相互關聯，觸發器機制提供了拋棄、累積和累積并撤回3種不同的策略來修正同一個窗口的計算結果。

● 拋棄：觸發器一旦觸發，窗口中的內容就被拋棄，之后觸發得到的結果和之前的結果不存在任何相關性。

● 累積：觸發器觸發后，窗口中數據的聚合結果被保留到系統狀態中，之后觸發的計算會累積到之前的結果上，成為針對之前結果的一個修正版本。

● 累積并撤回：觸發器觸發后，窗口中數據的聚合結果被保留到系統狀態，當窗口再次觸發計算時，先對上一次的結果做撤回處理，再將新的結果作為修正后的結果。

4 數據流編程模型在執行引擎中的實現

本節先介紹批處理引擎和流計算引擎各自的執行模型，再結合執行引擎實例，從數據流編程模型的時間語義和水位線機制、操作算子、窗口操作、觸發器以及修正策略5個方面，分析數據流編程模型在批處理引擎和流計算引擎中的具體實現，最后對這2種執行引擎在實現數據流編程模型上的異同進行對比。

在批處理引擎的執行模型中，數據操作的粒度為一批數據，即一次讀取并處理一整批數據。整個數據處理邏輯通常被劃分為多個階段，多個階段按序被調度執行，每個階段中的任務處理所得的中間結果需要落盤，只有等到該階段所有數據都處理完成后，才能將中間結果發送給下一個階段繼續處理。而在流計算引擎的執行模型中，數據操作的粒度為一條數據，即一次計算一條數據。所有數據處理任務一開始就同時啟動，并長時間運行直到終止，每個長時間任務隨著數據的不斷進入而不停地執行計算，每個任務處理完一條數據后，就將其發送給下一個任務繼續處理，而不需要像批處理引擎的執行模型那樣將中間結果落盤。

4.1 數據流編程模型在批處理引擎中的實現

為了支持基于事件時間語義的處理，批處理引擎要求讀入的每一批數據中的每一條元組都自帶一個事件時間戳，并且在處理數據時由用戶指定每條數據中哪個字段是事件時間戳，該事件時間戳用于生成水位線。按照數據流編程模型中提出的水位線機制，批處理引擎應當能夠根據一個批次中的每一條數據立即更新當前的水位線，并且一旦水位線越過某個窗口的終止事件時間戳，就觸發該窗口的計算，并向用戶展示結果。但是這與批處理引擎的處理機制是矛盾的，因為批處理引擎只能將整個批次中的所有數據一起進行處理，而不能對一個批次中的數據進行切割，只處理一個批次中的一部分數據，所以批處理引擎難以實現數據流編程模型中的水位線機制。例如，在基于批處理引擎的Structured Streaming系統中支持事件時間語義和水位線，但無法按照水位線觸發窗口計算。如圖10所示，假設在Structured Streaming中定義一個窗口長度為1 min的滾動窗口，每隔10 s讀取一批數據且一起進行處理。如果要讓Structured Streaming做到根據每一條數據更新水位線并按水位線觸發計算，則在該例子中，當讀到（b,1,12:01:01）這條數據時，就應該將水位線按照當前收到的數據的最大事件時間戳更新為12:01:01，并觸發[12:00:00,12:01:00]窗口的計算，但這違背了批處理引擎按一整批數據進行計算的機制。Structured Streaming只能做到按一整批數據進行處理，并將水位線設置為當前已收到的所有數據中的最大事件時間戳的值，下一批次中如果存在某個元組的事件時間小于上一批次生成的水位線，如該例子中的（a,1,12:00:58）的事件時間戳12:00:58小于上一批次生成的水位線12:01:02，則直接丟棄該元組，不再對其進行處理。此外，基于批處理引擎的MapReduce、Spark和Dryad等系統都沒有引入時間語義和水位線。在基于批處理引擎的Spark Streaming系統中雖然引入了時間語義，但僅支持基于處理時間語義的處理，不支持基于事件時間語義的處理，因此也沒有水位線機制，無法按水位線觸發計算。

圖10???Structured Streaming中的水位線機制

在操作算子方面，批處理引擎能夠按照數據流編程模型的概念，提供類似ParDo和GroupByKeyAndWindow的算子，但前提是需要批處理引擎支持基于窗口的計算。值得注意的是，批處理引擎中的聚合操作是在每一批數據上的操作，即要等到一個批次中的數據都獲取后，才對這一批次中的所有數據按鍵值進行分組。例如，在Structured Streaming中支持基于窗口的計算，提供了類似ParDo和GroupByKeyAndWindow的算子，最終所有算子被轉換為Spark批處理引擎的RDD數據模型上的操作，一次操作一批數據。在MapReduce、Spark和Dryad等系統中，有類似ParDo的算子，一次處理一批數據，但不提供類似GroupByKeyAndWindow的算子，因為它們都不支持基于窗口的操作。在Spark Streaming中，由于Spark Streaming僅支持基于處理時間語義的窗口，因此無法提供事件時間語義上的GroupByKeyAndWindow算子，僅提供處理時間語義上的GroupByKeyAndWindow算子。

關于窗口操作，批處理引擎按批次將數據分配到窗口。也就是說，對于到達的每一個批次，根據事件時間將該批次中的每一個元組劃分到其所屬的窗口中。對于觸發器來說，由于批處理引擎中數據成批到達、成批處理的特性，批處理引擎難以實現按水位線和按元組個數觸發計算，易實現按照固定處理時間間隔觸發窗口的計算。如上所述，批處理引擎難以按水位線觸發計算，按元組個數觸發計算同樣也要求批處理引擎切割一個批次，只計算一個批次中的一部分數據，這與批處理引擎的處理機制相背離。Structured Streaming只支持按固定時間間隔觸發窗口計算，即根據固定處理時間間隔劃分數據批次，并按 批次觸發窗口計算。如圖11所示，假定Structured Streaming每隔10 s讀取一批數據，如果要支持每到達一個元組就觸發窗口計算，那么當數據元素（a,1,12:00:57）到達時就要觸發計算，并將結果展示給用戶，這違背了批處理引擎成批處理的機制。在該例子中，系統每隔10 s讀取一次數據并觸發一次計算，然后將處理結果展示給用戶，再過10 s讀取下一批數據并觸發下一次的計算。對于每一個窗口多次觸發計算而得到的多個結果，批處理引擎理論上能夠提供拋棄、累積和累積并撤回3種策略來進行關聯，但是目前在Structured Streaming中只實現了累積策略。在MapReduce、Spark和Dryad中，由于不支持基于窗口的計算，因此沒有觸發器和修正策略。而Spark Streaming支持基于處理時間語義的窗口計算，可提供基于固定時間間隔的觸發器和累積修正策略。

圖11???St ructured Streaming中的觸發器

4.2 數據流編程模型在流計算引擎中的實現

與批處理引擎相同，為了支持事件時間，流計算引擎也要求數據源中的每條數據都自帶事件時間戳，并由用戶指定每條數據中的某個字段作為事件時間戳。但是流計算引擎的水位線機制與批處理引擎不同。對于流計算引擎來說，每來一條數據就立即處理一條數據，因此它能夠做到來一條數據就更新一次水位線，并當水位線越過某個窗口的終止事件時間戳時，就觸發該窗口的計算并將結果反饋給用戶。例如，基于流計算引擎的Flink系統支持事件時間語義和水位線，并且能夠按照水位線觸發窗口計算。如圖12所示，在Flink中定義一個窗口長度為1 min的滾動窗口，當數據（b,1,12:01:01）到達時，根據當前已收到的數據的最大事件時間戳，水位線被設置為12:01:01。此時，水位線超過了[12:00:00,12:01:00]窗口的終止事件時間戳，立即觸發該窗口的計算，并將結果反饋給用戶。同樣地，基于流計算引擎的Storm、Millwheel、Samza系統也支持事件時間語義和水位線，并能夠按照水位線觸發窗口計算。

圖12???Flink中的水位線

在操作算子方面，流計算引擎能夠按照數據流編程模型的概念，提供類似ParDo和GroupByKeyAndWindow的算子，但前提是系統支持基于窗口的計算。值得注意的是，與批處理引擎不同，流計算引擎是來一條數據就處理一條數據。因此在流計算引擎中，聚合操作是在每一條數據上的操作，即每來一條數據就將其按鍵值劃分到所屬的分組中。例如，在基于流計算引擎的Flink、Storm和MillWheel、Samza系統中，所有算子都是每來一條數據就處理一條數據。

窗口操作在流計算引擎中的實現與在批處理引擎中不同，流計算引擎按元組將數據分配到窗口。也就是說，每來一個元組，系統就按照事件時間戳將其分配到對應的窗口中。對于觸發器，流計算引擎中每到達一條數據就處理一條數據，因此流計算引擎自然能夠按元組個數觸發窗口計算。如上所述，流計算引擎也能按水位線觸發窗口計算。此外，流計算引擎還能做到按固定處理時間間隔觸發窗口計算，只需在到達處理時間間隔時，對窗口中已到達的數據進行處理，并將處理結果展示給用戶。例如，Flink提供了按水位線、按元組個數和按固定時間間隔3種觸發策略的觸發器，Flink甚至還支持用戶自定義觸發器的觸發策略，以便靈活組合使用多種觸發策略。如圖13所示，在Flink中設置一個按每到達一個元組就觸發窗口計算的觸發器，那么當數據（a,1,12:00:57）到達時就觸發計算，并將處理結果展示給用戶；當數據（b,1,12:01:01）到達時，再次觸發窗口計算，并將結果反饋給用戶。對于每一個窗口多次觸發計算而得到的多個結果，流計算引擎理論上能夠提供拋棄、累積和累積并撤回3種策略來進行關聯，但是目前在Flink中只實現了累積策略。在Storm中也提供了按水位線、按元組個數和按固定時間間隔3種觸發策略的觸發器，但是難以組合使用多種類型的觸發器，在修正策略上Storm僅支持累積策略。Samza支持以上3種觸發策略的觸發器，并且可以基于過早觸發和過晚觸發的條件來組合使用各類觸發器，在修正策略上同樣只支持累積策略。

圖13???Flink 中的觸發器

4.3 數據流編程模型在批/流引擎實現中的異同

數據流編程模型在批處理引擎和流計算引擎中的實現既有相同之處，也有不同之處。相同之處是兩者都要求引入時間語義，并讓用戶指定數據中的某一列為事件時間戳列，以支持基于事件時間語義的處理。此外，修正策略在批處理引擎和流計算引擎中的實現也有相同之處，兩者理論上都能實現數據流編程模型中提出的3種修正策略。

批處理引擎和流計算引擎的數據處理機制不同，兩者在實現數據流編程模型時也有不同之處。批處理引擎一次處理一批數據，因此批處理引擎中的操作算子和窗口操作的對象都是一批數據，而流計算引擎一次計算一條數據，因此流計算引擎中的操作算子和窗口操作的對象都是一條數據。此外，兩者的觸發機制也不同，批處理引擎難以實現按水位線或元組個數觸發窗口計算，只支持按固定處理時間間隔觸發計算。而流計算引擎能夠實現數據流編程模型中提出的各種觸發器，如基于水位線的觸發器、基于元組個數的觸發器以及基于固定處理時間間隔的觸發器等。總體來說，流計算引擎比批處理引擎更適合用于實現數據流編程模型。

5 結束語

本文說明了計算機計算模型中的數據流計算模型與大數據處理中的數據流計算模型的不同。一方面，從執行引擎層面分析了大數據處理中的數據流計算模型體現的數據流圖，并結合Spark批處理引擎和Flink流計算引擎2個典型的執行引擎，描述了數據流圖在兩者中的具體體現；另一方面，從統一編程層面闡述了大數據處理中的數據流計算模型體現的數據流編程模型，結合批處理引擎和流計算引擎各自的執行模型，并選取基于批處理引擎的Structured Streaming、Spark Streaming、Dryad和基于流計算引擎的Flink、Storm、Samza等多個系統，對比分析了數據流編程模型在批處理引擎和流計算引擎中的具體實現。

目前，無界、亂序的大規模數據已經越來越普遍，消費者對數據處理的需求也越來越復雜，這對大數據處理系統提出了更高的要求。本文介紹的數據流計算模型是朝這個方向邁出的重要一步，該模型將批處理引擎和流計算引擎的編程方式進行抽象統一，并引入事件時間、窗口、水位線和觸發器等概念，使得大數據處理系統能夠高效地應對無界、亂序的大規模數據。如今，許多大數據處理系統已經朝著該數據流計算模型發展，基于流計算引擎實現該數據流計算模型的大數據處理系統將是一個研究方向，但是基于批處理引擎的大數據處理系統在時延性和觸發機制等方面還存在缺陷，需要進一步研究。

作者簡介

畢倪飛（1996-），男，華東師范大學數據科學與工程學院碩士生，主要研究方向為異構分布式系統中的查詢優化 。

丁光耀（1996-），男，華東師范大學數據科學與工程學院博士生，主要研究方向為并行與分布式系統 。

陳啟航（1996-），男，華東師范大學數據科學與工程學院碩士生，主要研究方向為異構分布式計算中的查詢優化 。

徐辰（1988-），男，華東師范大學數據科學與工程學院副教授、碩士生導師，主要研究方向為大規模分布式數據管理 E-mail：cxu@dase.ecnu.edu.cn。

周傲英（1965-），男，博士，華東師范大學副校長、“智能+”研究院院長、數據科學與工程學院教授。現任第七屆國務院學位委員會學科評議組成員，中國計算機學會會士，上海市計算機學會副理事長，《計算機學報》《大數據》期刊副主編。曾入選“長江學者計劃”特聘教授，曾獲國家杰出青年基金項目資助，主要研究方向為數據庫、數據管理、數據驅動的計算教育學，以及教育科技（EduTech）、物流科技（LogTech）等基于數據的應用科技 。

大數據期刊

《大數據（Big Data Research，BDR）》雙月刊是由中華人民共和國工業和信息化部主管，人民郵電出版社主辦，中國計算機學會大數據專家委員會學術指導，北京信通傳媒有限責任公司出版的期刊，已成功入選中文科技核心期刊、中國計算機學會會刊、中國計算機學會推薦中文科技期刊，并被評為2018年國家哲學社會科學文獻中心學術期刊數據庫“綜合性人文社會科學”學科最受歡迎期刊。

關注《大數據》期刊微信公眾號，獲取更多內容

往期文章回顧

《大數據》2020年第3期目次&摘要

專題導讀：數據資產化探索

數據資產化框架初探

基于利潤最大化的數據資產價值評估模型

基于區塊鏈的數據市場

數據資產標準研究進展與建議

面向價值實現的數據資產管理體系構建

專題導讀：面向大數據處理的數據流計算技術

面向大數據處理的數據流編程模型和工具綜述

---

總結

以上是生活随笔為你收集整理的数据流计算模型及其在大数据处理中的应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。