本文譯自谷歌大神 Tyler Akidau 關於流式計算的兩篇博客的第一篇，寫於2015年8月，後來又寫過一本書《Streaming Systems》，同樣值得一讀。

流數據處理是當今大數據世界的一大難題，理由如下：

• 業務希望獲取更加及時的數據，因而切換到流式處理是降低延遲的好辦法。
• 為海量又無限的數據而設計的系統，更能應對這種日益增長的業務數據的需求。
• 在數據到達時即處理數據，能夠使得工作負載更加均勻，從而產生更一致和可預測的資源消耗

儘管業務驅動導致流計算的興趣日益增加，但是和批處理相比，現有的大多數流式系統仍然不夠成熟，這也導致了最近該領域的很多有意思的發展。

作為一個最近5年多一直在谷歌的大規模流式系統（MillWheel, Cloud Dataflow）工作的我來說，很樂於看到這種源源不斷的流計算的思潮。對於如何保證人們理解並應用流式系統，特別是在現存的批處理和流處理系統存在一定的語義鴻溝的情況下，我很感興趣。因而接下來的內容將分為兩個部分：

1. Streaming 101：第一篇文章會介紹基本的背景情況以及一些術語，然後再深入到時域，以及對批處理和流處理的一般方法做高度的概括。
2. Dataflow 模型：第二篇文章主要介紹 Cloud Dataflow 所使用的批流統一的模型，並以一個例子應用不同的場景來輔助說明。最後對現有的批處理和流處理系統做一個簡要的語義上的比較。

閑話少說，下面進入主題。

背景

開始前，我會介紹一些重要的背景信息， 以幫助構建接下來我將要討論的主題框架。下面我會分為三個部分：

• 術語：越是討論複雜的話題，就越是需要精準的定義。對於當下有各種解釋的術語，我會具體說明在這裡的含義。
• 功能：我會指出流式系統的缺點，同時提出構建數據處理系統的框架思想，以滿足消費者日益增長的需求。
• 時域：我會介紹數據處理中兩種主要的時域、它們的相關性，並指出二者帶來的困難。

術語： 流（streaming）是什麼？

在接下來的內容之前，首先我們要解決的是：流到底是什麼？「流」可以表示各種不同的意思，這可能導致我們誤解流到底是什麼以及流式系統究竟能做什麼。鑒於此，我會儘可能地準確定義這些術語。

當前問題的關鍵在於許多事情應該由它們是什麼（例如無限數據處理、近似結果等）來定義，然而事實上經常由它們在歷史上是如何（例如通過流計算引擎）實現的來進行介紹。術語上的這種不準確導致了流的真正含義變得模糊，有時候甚至把流式系統的功能局限於流的特性，如近似和推測結果。由於精心設計的流式系統也能夠和批處理系統一樣產生正確、一致、可重複的結果。所以這裡我傾向給「流」下一個更加精確的定義：一種針對無限數據集而設計的數據處理引擎。僅此而已。（為了防止有失偏頗，有必要說明一下這個定義同時包括了真正的流以及微批的實現方式。）

作為「流」的常見場景，下面是我常聽到的，每個都被精確定義，我也建議我們的社區應該採用：

1. 無限數據：一種不斷增長的，本質上無限的數據集。這些通常被稱為「流數據」（streaming data）。然而，當應用於數據集時，流或批的術語是有問題的，因為這意味著使用特定的執行引擎來處理這些數據集。兩種類型的數據集之間的關鍵區別在於現實中它們的有限性，因此最好用這種能夠區分它們特徵的術語。因此，我傾向於將無限的「流」數據集稱為無限數據，有限的「批」數據集叫做有限數據。
2. 無限數據處理：一種持續的數據處理模式，適用於上述的無限數據。雖然我個人很想使用「流」這個術語來描述數據處理的類型，但是這種情況下的使用再次暗示使用了流計算引擎，這根本就是誤導；而自從設計了批處理系統以來，我們就一直重複運行批處理引擎來處理無限數據（相反地，精心設計的流式系統能夠比批處理系統更會處理有限數據）。因此，為了清楚定義，我將簡單地稱之為無限數據處理。
3. 低延遲、近似、推測結果：結果的類型往往和流計算引擎相關。事實上，批處理系統從一開始就沒有被設計為低延遲或者推測結果，這是歷史事實，僅此而已。當然，如果有必要的話批處理引擎完全有能力產生近似結果。因此，對於上述的術語，應該按照它們本來的樣子（低延遲、近似、推測結果）來描述，這勝過說它們歷史上如何表現的（通過流計算引擎）。

從現在開始，任何時候使用術語「流」，意思都是設計用於無限數據集的執行引擎，僅此而已。當我談到上述任何其他術語時，我會直接說無限數據，無限數據處理或低延遲、近似、推測結果。這些是我們在 Cloud Dataflow 中採用的術語，同時我鼓勵其他人也如此使用。

被過分誇大的流處理的局限

接下來，談一談流式處理系統能做什麼和不能做什麼，重點在能做什麼；其中我最想做的事情就是討論一個精心設計的流處理究竟可以做到什麼。流式系統長期以來一直被放在提供低延遲，不準確/推測結果的場景里，通常結合批處理系統來提供最終正確的結果，即 Lambda 架構。

對於不熟悉 Lambda 架構的你來說，只需要知道它的基本思想就是在批處理系統旁邊運行一個流處理系統，並且執行基本相同的計算。流式處理系統提供低延遲、不準確的結果（由於使用近似演算法，或者因為流系統本身不提供準確性的保證），所以每過一段時間，批處理系統便持續滾動處理並計算出正確的結果。該思想最初是由 Twitter 的 Nathan Marz（Apache Storm 的創始人）提出的，最終是相當成功的因為在當時這是個很棒的想法；流計算引擎在正確性方面讓人失望，而批處理天生笨拙，所以 Lambda 為您提供了一種方法讓您魚和熊掌兼得。然而維護 Lambda 系統是一件麻煩：需要構建和維護兩個版本的管道，並且要將兩者的結果合併。

和一些常年從事於強一致性流計算引擎的人一樣，我對 Lambda 架構的整個概念感到有點討厭。不出所料，當 Jay Kreps 的文章 Lambda 架構質疑 一出，我變成了他的鐵粉。這是反對雙模式執行的必要性的首次有力陳述。Kreps 使用 Kafka 這樣的可重放系統作為流計算架構的內部連接，從而解決了可重複的問題，甚至進一步提出了 Kappa 架構，這基本意味著可以使用一個精心設計的系統來運行單一的管道。我不確定這個概念需要個名字，但是我完全支持這個概念。

老實說，我會走得更遠。我會討論一個精心設計的流式系統事實上提供了一個批處理功能之上的嚴格超集。感謝 Flink 的開發者將這一思想牢記於心，並構建了一個一直完全流式的系統，甚至包含批的模式。

所有這一切的必然結果是廣泛成熟的流式系統，加上用於無限數據處理的健壯框架，最終 Lambda 架構將回到它所屬的大數據的歷史洪荒中去。我相信這將成為現實。因為在這場比賽中打敗批處理，你今需要兩個概念：

1. 正確性——這讓你與批處理平起平坐

   首先，正確性歸結為一致性存儲。流式系統需要伴隨時間存在的檢查點來持久化狀態信息（有些內容 Kreps 在他的 為什麼本地狀態是是流處理的基本原語 有提及），而且必須設計得足夠好，能夠在機器出現故障時保持一致性。當 Spark Streaming 幾年前首次出現在公開的大數據場景下時，那簡直是幽暗的流計算世界裡一致性的燈塔。慶幸的是自那以後情況有所好轉，但是仍然有不少流式系統運行在沒有強一致性的情況下；我真的不敢相信至多一次處理仍然是個問題，但事實就是。

   重申一下，因為這點很重要：僅僅一次的處理要求很強的一致性，這對於正確性是必要條件，而且這對於希望達到甚至超過批處理系統的能力的任何系統而言都是必需的。除非你真的不在乎結果，否則我懇求你不要使用那些不能提供強一致性狀態的流式系統。批處理系統不需要你事先驗證它們是否能夠產生正確的結果；因而不要把時間浪費在那些不能實現相同目標的流式系統上。如果想了解更多關於流式系統中如何實現強一致性，可以參考 MillWheel 和 Spark Streaming 論文。兩篇論文花了大量時間討論一致性。由於這些論文對此給出了高質量的介紹，本文將不會贅述。
2. 關於時間的推理工具——這讓你超越批處理對於亂序無限數據流，數據產生的時間和數據真正被處理的時間之間的的偏差很大，用於推理時間的工具至關重要。越來越多的現代數據集體現了這個特點，現有的批處理系統（以及大多數流處理系統）缺乏必要的工具來應對這個問題。接下來以及下一篇文章，我們都將聚焦於此。首先，我們將對時域概念有一個基本的了解，之後我們將更深入了解我所說的無限的、亂序的、不同的事件時間傾斜是什麼意思。剩下的時間我們再了解使用批處理和流式系統處理有限和無限的數據的常用方法。

事件時間 vs. 處理時間

要闡述無限數據的處理方式，需要清楚地了解時間所涉及的領域。在任何數據處理系統中，通常有兩種時間值得關註：

• 事件時間，即事件發生的真實時間
• 處理時間，即事件被系統觀察到的時間

並不是所有情況下都需要關心事件的時間（如果你的不需要，萬歲啊——你的生活因此更加簡單），但大多數情況下需要，例如根據時間刻畫用戶行為，大多數計費應用程序、不同類型的異常檢測。

在一個理想的世界中，事件在發生時即被處理，因而事件時間和處理時間總是相等的。然而，現實並非如此，事件時間和處理時間之間總會存在偏差，而且通常嚴重受到數據底層輸入源，執行引擎甚至硬體的影響。可能影響的因素包括：

• 共享資源限制，如網路擁塞，網路分區或在非專用環境中共享CPU。
• 軟體因素，如分散式系統的複雜邏輯、資源競爭等。
• 數據本身的特性，包括 key 的分布、吞吐的差異、亂序（例如將飛機上的所有乘客的手機都從飛行模式中退出來）。

因此，如果要將實際系統中事件時間和處理時間的進度關係畫出來的話，您得到的應該是類似於圖1中紅線的結果。

斜率為1的黑色虛線表示理想狀態下，處理時間和事件時間一致；紅線表示現實情況。在這個例子中，系統在處理時間的前段落後一點，在中間偏向理想狀態，然後再次落後直到最後。黑色虛線與紅線之間的水平距離是處理時間和事件時間之間的偏差。這種偏差本質上就是處理管道所帶來的延遲。

由於事件時間和處理時間之間的關係不是靜態的，如果關注數據的事件時間，那麼就不能僅僅基於在你的數據管道中所觀察到的時間來分析數據。不幸的是，現有的大多數系統都是為處理時間而設計的。為了處理無限數據集的無窮的特性，這些系統通常對於傳入的數據提供了窗口概念。下面將深入討論窗口，但它本質上其實就是將無限數據集沿著時間的邊界切分成有限數據集。

如果您關注正確性並且希望基於事件時間分析數據，那麼就不能像那些現有的系統一樣來使用處理時間（即處理時間窗口）來定確定那些邊界；由於處理時間和事件時間不具備一致的相關性，使用處理時間會導致一些數據劃分到錯誤的窗口中（由於分散式系統的固有滯後，各種類型輸入源的在線/離線特性等等），導致不正確的結果。我會在下面的例子以及接下來一篇文章中詳細介紹這個問題。

不幸的是，按照事件時間進行窗口操作也不是那麼樂觀。對於事件時間窗口來說，基於無限的數據，亂序和可變的時間延遲會引入一致性的問題：處理時間和事件時間之間的關係是不可預測的，那麼給定一個事件時間 X，你如何確定所有數據都到達了？對於多數真實的數據源，你恐怕無法簡簡單單就做到。目前使用的絕大多數數據處理系統都依賴於一些完整性的概念，這使得它們不太容易處理無限的數據集。

所以我建議與其試圖將無限數據變成最終一致的有限批次數據，還不如設計一些工具讓我們生活在這種不確定的世界中，從而應對這些複雜的數據集。新數據將要到達，舊數據可能會被撤回或更新，我們構建的任何系統都應該能夠應對這些事實，這裡使用完整性的概念是方便闡述，而不是必要的術語。

在深入研究我們是如何使用 Cloud Dataflow 中用到的 Dataflow 模型來構建這樣一個系統之前，讓我們先學習一些背景知識：一般的數據處理模式。

數據處理模式

至此，我們已經掌握了足夠的背景知識，現在開始研究有限及無限數據處理中常見的幾種處理模式。我們針對這兩種計算引擎，研究它們的處理類型以及相關之處（這裡指的是批處理和流式處理，我把微批處理和流處理放在了一起，因為這二者在這級別上的差異並不是很大）。

有限數據

處理有限數據是非常簡單的，我們都很熟悉，例如Hadoop，在最開始都是為了處理有限數據集而出現的。在下圖中，從左邊開始，一個混亂無序的數據集，經過數據處理引擎（通常是批處理引擎，精心設計的流處理引擎也可以），如 MapReduce，最後在右側產生一個更具價值的新的結構化數據集：

儘管作為這個方案的一部分，您實際上可以計算出無數種可能性，但整個模型是非常簡單的。而更有意思的的是處理無限數據集。現在來看看處理無限數據的幾種方式，從傳統批處理引擎使用的方法開始，最後看看設計用於無限數據的系統使用的方法，諸如大多數流處理或微批引擎。

無限數據——批處理

批處理引擎雖然不是為無限數據集處理而設計，但是自批處理系統誕生以來都在用於處理無限數據集。而且很容想到，這種處理方式就是將無限數據集分解成適合於批處理的有限數據集。

固定窗口

處理無限數據集的最常見方法就是將輸入數據分配到固定大小的窗口中，將這些窗口中作為單獨、有限的數據集進行處理，然後不斷運行。例如像日誌這種輸入源，將事件寫入文件目錄，名稱對應所屬的窗口，只要基於時間執行 shuffle，讓數據分配到合適的事件時間窗口中即可。

實際上，大多數系統仍然有一個完整性的問題需要處理：如果一些事件由於網路分區而延遲該怎麼辦？如果需要從全球各地收集事件，必須在處理之前傳輸到一個公共的位置？如果事件來自移動設備又該怎麼辦？這意味著必須要有某種方式來解決此類問題（例如延遲處理直到確定已收集所有事件，或者在數據遲到時，為指定窗口重新處理整個批次）。

會話

當您面對更加複雜的窗口策略（如會話）時，還希望使用批處理引擎來處理無限數據，這樣幾乎是徒勞的。會話窗口通常被定義為一個活動周期，超過一定時間不再活動就認為會話窗口中止。當使用批處理引擎計算會話窗口時，通常會遇到會話的數據拆分在2個或多個批次中的情況，如下圖中的紅色標記所示。可以通過增加每批次數據量的大小來減少拆分數量，但是代價是增加了延遲。另一個選擇是增加額外的邏輯，從之前的運行中合併會話，但帶來了更高的複雜度。

不管怎樣，使用傳統的批處理引擎來計算會話都不夠理想。更好的方式是以流的方式來構建會話，接下來我們一起看看吧。

無限數據——流式處理

與大多數基於批的無限數據處理方法的特殊性相反，流式系統是專為無限數據構建的。如前所述，對於現實世界的很多分散式輸入數據源，不僅要處理無限的數據，而且要處理這樣的數據：

• 高度無序的事件時間，這意味著如果想在事件發生的上下文來分析數據，則需要在Pipeline中進行基於時間的 shuffle。
• 多樣的事件時間差，這意味著你不能僅僅假設大部分數據的事件時間 X 的與時間 Y 的差距在一個常數 ε 內。

處理具備這些特徵的數據，一般有幾種方法，我通常將它們分為以下四類：

• 時間無關
• 近似解
• 基於處理時間的窗口
• 基於事件時間的窗口

下面我們來依次分析。

時間無關

時間無關的處理一般用於與時間無關的場景，即所有相關邏輯都是數據驅動的。由於這種情況下持續的數據輸入最為重要，流處理引擎除了滿足數據傳輸的特性外，不需要其他的。因此，基本上所有流處理系統都支持時間無關的使用場景（系統到系統的一致性保證，對關心正確性的人有用）。批處理系統非常適用於時間無關的無限數據集處理，它會通過簡單地將無限數據切分成任意的有限數據集然後單獨地處理它們。我們將在本節中看幾個具體的例子，由於時間無關的處理簡單直觀，所以並不會花很多時間在上面。

過濾

一種最基本的時間無關的處理就是過濾。假設正在處理 Web 流量日誌，並且要過濾掉非特定域名的所有流量。每條記錄到達時，檢查是否來自某個來源，如果不是則丟棄。由於這種處理只針對單個元素，而事實上數據源是無限的、亂序的以及多樣的事件時間差這幾個因素是無關緊要的。

內連接

另一個時間無關的例子是內連接（或者叫哈希連接）。當 join 兩個無限數據源時，如果只關心連接的結果，則不需要關注時間。從一個數據源接收1個值，你可以直接緩存為持久化狀態；一旦來自另一個源的第2個值到達時，僅需要發出連接上的記錄。（在實際中，有一些記錄可能沒有合適的關聯數據進行連接，此時可能需要基於時間進行清理掉舊數據，但是對於很少或沒有未完成連接的情況，這問題不大。）

至於外連接則存在我們之前討論過的數據完整性問題：一方數據到了，你怎麼知道另一方數據是否會到達？ 在實際中，很難確定，所以必須使用超時的概念，這也因此要引入時間元素。而時間元素在本質上就是一種窗口形式，稍後會更詳細地介紹。

近似演算法

第二類方法是近似演算法，例如近似Top-N、流的K均值等。它們採用無限輸入數據源，並提供輸出數據。近似演算法的優點在於它們的開銷比較小，專為無限數據集而設計。缺點是演算法本身往往是複雜的（這使得難以引出新的演算法），並且這種近似的特性限制了它的用武之地。

值得注意的是：這些演算法通常在其設計中考慮了時間因素（例如某種內置的衰減）。而且一般採用到達時處理元素的策略，所以通常是基於處理時間的。這一點對於可以證明近似演算法的誤差範圍特別重要。如果這些誤差範圍在數據順序到達的情況下可以證明，那麼在應對不同事件時間的差距時它們什麼也不是，這些演算法也將無用。

近似演算法是一個很有趣的主題，由於它們本質上是與時間無關的處理，因此它們非常簡單易用，此處便不再贅述。

窗口

無限數據剩下的兩種處理，都是基於窗口的變體。 在深入不同窗口類型的差異之前，需要明確一下窗口的含義。 窗口其實就是對數據源（不論是無限還是有限的）在時間上進行切分，得到有限的數據塊。 下圖顯示了三種不同的窗口模式：

• 固定窗口：固定窗口將時間分割成具有固定大小時間段。通常（如圖8所示），固定窗口均勻的分隔整個數據集，這是對齊窗口的示例。在某些情況下，希望對於數據的不同子集（如根據鍵來）進行相移，以隨著時間的推移更均勻地擴展窗口完成負載，而不是隨著數據變化，否則那就是非對齊窗口了。
• 滑動窗口：滑動窗口由固定長度和時間周期定義。如果時間周期小於長度，則窗口重疊。如果周期等於長度，則等同於固定窗口。如果周期大於長度，有一些數據就無法分配到窗口中。與固定窗口一樣，滑動窗口通常對齊，在某些使用情況下可能會為優化性能而不對齊。注意，圖 8 中的滑動窗口被繪製出滑動感；實際上，所有五個窗口將應用於整個數據集。
• 會話窗口：會話是一種動態窗口，會話由事件序列組成，會話之間由於大於某個超時時間而產生間隔。會話通常用於分析一段時間內的用戶行為，通過將一系列時間相關的事件（例如，一次觀看的視頻序列）分組在一起。會話很有意思的，因為長度不能被事先定義而取決於實際數據。它是非對齊窗口的典型示例，因為會話在不同的數據子集（例如不同的用戶）上幾乎不相同。

其中的處理時間和事件時間時我們主要關注的。窗口在兩種時間類型中都是有意義的，接下來我們看看二者的區別。 因為處理時間在現有系統中應用最廣，那麼首先從處理時間開始。

基於處理時間的窗口

當基於處理時間劃分窗口時，系統將進入的數據緩衝到窗口中，一直到窗口末尾的時間。 例如，在5分鐘固定窗口的情況下，系統將緩衝數據，處理時間為5分鐘，之後將其在5分鐘內收到所有數據視為1個窗口，並將其發送到下游進行處理。

處理時間有以下幾個優點：

• 簡單。不需要根據時間 shuffle 數據，因而實現起來容易。只需在數據到達時緩衝數據，並在窗口關閉時向下游發送。
• 容易判斷完整性。由於系統很清楚地知道窗口的數據，所以很容易判斷窗口是否已經完成。這意味著使用處理時間可以不再需要處理「遲到的」數據。
• 如果你想根據收到的數據推測信息，那麼處理時間很合適。許多監控方案屬於這一類。 舉例來說，跟蹤每秒發送到全球規模Web服務的請求數， 來檢測中斷，計算這些請求的速率是處理時間窗口的完美用法。

此外，處理時間窗口有一個很大的缺點：如果數據中帶有事件時間，而處理時間窗口需要反映出這些事件真實發生的時間的話，那麼則要求這些事件以事件時間的順序到達。可惜的是，事件時間有序的數據在大多數現實的分散式場景中並不常見。

考慮一個簡單的案例，有一個移動 App 收集使用統計信息以供後續處理。如果給定的移動設備離線（短時間內連接失敗，調為飛行模式等），則在該設備上線之前不會上傳數據。這意味著數據可能會出現事件時間偏差幾分鐘、幾個小時、幾天、幾周甚至更長時間。這時使用處理時間窗口的話是無法從這樣的數據集中推斷出設備離線或者其他有用的信息的。

再舉一個例子，當整個系統正常時，一些分散式輸入源在一切正常運轉時似乎能夠提供事件時間有序（或接近有序）的數據。這個時候的事件時間偏差比較小，但並不意味著會始終這樣。在全球性的場景中，Web 服務跨越了多個大陸，收集數據受限於跨洋線路的帶寬，進一步降低了帶寬和/或提高了延遲，那麼輸入數據的一部分可能突然以比以前更大的偏差到達系統。如果通過處理時間窗口處理數據，則窗口不再代表其中實際發生的數據；相反，窗口代表事件到達系統的時間窗口，而這會導致舊數據和當前數據混在一起。

在這兩種情況下，要想事件按照事件時間順序的處理，需要的是事件時間窗口。

基於事件時間的窗口

在你需要以事件真實發生的時間來觀察數據時，需要使用事件時間窗口。這是窗口的黃金法則。可惜的是，當今的大多數系統缺乏對於事件事件的本地支持（雖然有些具有很好的一致性模型的系統，比如 Hadoop 或者 Spark Streaming，也可以構建這樣的一個窗口的系統）。

下圖顯示了將無限數據源中的數據，按照1小時長度的固定窗口進行切分的示例：

該圖中的白實線標出了兩個感興趣的數據。 從圖中可以看出，這兩類數據都到達處理時間窗口，但是與它們所屬的事件時間窗口不匹配。 因此，想按照事件時間進行處理，如果使用處理時間窗口，則計算結果將不正確。顯然，使用事件時間窗口才能達到事件時間上的正確性。

另外在處理無限數據的時候，使用事件時間窗口，可以創建動態大小的窗口。例如會話窗口，此種情況下，使用固定窗口會將緊密相關聯數據分隔到不同的窗口（之前在「無限數據——批處理」部分的會話窗口示例中說明過）：

當然，強大的語義來之不易，事件時間窗口也不例外。事件時間窗口由於通常比窗口本身的實際長度（處理時間）更長，因而具有以下兩個缺點：

• 緩存：由於窗口的生命周期變長，需要緩存更多的數據。持久化存儲通常是最廉價緩存方式（其他主要是CPU，網路帶寬和RAM）。因此，當使用具有強一致持久化狀態和良好的內存緩存的數據處理系統時，這一般不是個大問題。此外，一些聚合運算不需要緩存整個輸入集（例如求和或平均值），而是只需要增量計算，這在持久化狀態中佔用很小。
• 完整性：由於難以知道一個窗口是否所有的數據都到齊了，那麼我們怎麼知道在哪個時刻計算結果呢？事實上，不必如此。但是對於許多類型的輸入源，系統可以通過像 MillWheel 的 Watermark（下篇文章將詳細討論）來給出對於窗口的數據到齊的準確的啟發式估計。但是在必須要保證絕對正確的情況下（例如計費），唯一的選擇是為管道提供一種方式來表示何時計算結果，以及這些結果如何隨著時間的推移而更正。處理窗口的完整性是一個有趣的話題，但最好結合具體的例子來探討，下一章我們再見。

總結

哇喔，信息量好大啊。對於看到此處的你值得表揚！到這裡我們已經完成了我想要介紹的一半的內容，所以回頭看看，回顧一下之前介紹過的內容，在深入到第二部分之前，我們稍微放慢腳步。第一部分是無聊的闡述，第二部分才是真正有趣的地方。

回顧

總結下，我講過：

• 澄清了術語，特別是將」流」（streaming）的定義限定為僅適用於執行引擎，而使用更加描述到位的術語如無限數據和近似/推測結果這樣不歸屬於流的範疇的概念。
• 評估了精心設計的批處理和流式系統的相對功能，假定流式處理事實上是批處理的嚴格超集，而像 Lambda 架構這樣的概念（認為流式處理不如批處理）註定會隨著流式處理的成熟而退役。
• 提出了流式系統趕超批處理系統所需的兩個高階概念，分別是正確性和時間推理工具。
• 分析了事件時間和處理時間之間的重要區別，介紹了在分析數據時這些差異所帶來的困難，並提出了方法上的轉變，從完整性的概念轉向簡單地適應數據隨時間而變化。
• 研究了當今世界針對有限和無限數據，批處理和流式處理引擎常用的主要數據處理方法，一般將無限數據處理方法分為以下幾種：時間無關、近似解、基於處理時間的窗口、基於事件時間的窗口。

接下來

本文為我在第二部分的具體案例做了鋪墊，接下來將包含以下幾點：

• 將 Dataflow 模型中的數據處理概念分解為四塊：what、where、when、how。
• 詳細介紹在多個場景下處理簡單、具體的數據集實例，重點介紹 Dataflow 模型所支持的多個用例，以及涉及到的具體 API。這些例子將有助於理解本文介紹的事件時間和處理時間的概念，另外將探索一些新概念，如水位線。
• 對於現有的數據處理系統，比較這兩篇文章中涉及到的一些重要特徵，從而更容易從中作出選擇，並改善其中的不足，我的終極目標是在整個大數據社區對於數據處理系統，尤其是流式系統的改善。

點擊下方查看博客原文

Streaming 101: The world beyond batch?

www.oreilly.com

本文首發於公眾號「數據Man」，歡迎關注！

推薦閱讀：

相关文章