前言
在流式計算方面，有兩篇經典文章是必讀的：The world beyond batch: Streaming 101與The world beyond batch: Streaming 102。這兩篇文章的作者是Google流式系統的負責人Tyler Akidau，他是MillWheel與DataFlow的開發者，在流式系統方面十分權威。這兩篇文章非常詳細並且適合初學者，可以幫助我們理清流式系統的各種概念與面臨的挑戰，是十分難得的佳作。其中Streaming101主要介紹了流式系統的一些基本概念和困境，同時提出了一個核心觀點：設計優良的流式系統完全可以代替批量系統。在Streaming102這篇文章中，作者以實際的流式系統（DataFlow）的設計爲例，列舉了多個場景，具體講解了如何設計流式系統，解決這些問題。
英文好的同學可以直接看英文原文，本文是我見過Streaming101的翻譯最好的中文版本.
背景
一開始，我會介紹一些重要的背景信息，這有助於理解後面我想討論的主題。我們會從三個部分來介紹：
- 術語：爲了準確地討論複雜的主題需要精確的術語定義。當前有一些術語被賦予了過多解釋，當我使用這些術語時會明確說明我的的意思。
- 能力邊界：我會列舉流式系統的常見的缺點。我也會提出一個我認爲數據處理系統構建者需要採用的想法，來達到解決現代數據處理需求的目的。
- 時間概念：我將會介紹兩個基礎的與數據處理相關的時間概念，介紹它們之間的關係，並且指出這兩個概念相關的一些難題。
術語：什麼是streaming？
在深入介紹之前，我想先解決一個問題：什麼是streaming？如今術語”streaming”意味着很多不同的東西，這會導致我們誤解streaming真正的含義，或者誤解 streaming 系統真正的功能。所以，我會精確的定義這個術語。
問題的本質是本來很多術語應該是描述它們是什麼（例如無界數據處理，近似結果等等），卻被描述成它們是如何實現的（也就是通過流式計算引擎）。沒有精確定義的 streaming，被人們狹隘的認爲 streaming 的功能只是被限制在某些被稱作”streaming”的特性，例如近似或者推測結果。一個設計良好的流式系統可以跟現在的批量引擎一樣，可以生成正確、一致、可重複計算的結果。我對術語 streaming 的定義是：一種被設計用於處理無窮數據的數據處理引擎。（爲了完整性，這個定義包含了真正的流式和微批兩種實現）。
下面是一些經常和”streaming”聯繫在一起的幾個術語，我分別爲它們給出了更精確，更清楚的定義，我建議整個工業界都應該採納它們：
- Unbounded data：一種持續產生無窮的數據。它們經常被稱爲”streaming data”。然而， 用術語 streaming 或者 batch 描述數據都是有問題的，正如上面提到的，它們的含義是用某種類型的計算引擎來處理這些數據。這兩種類型數據的關鍵區別是它們的有限性，所以使用能夠表名它們的區別的術語是更好的。因此，我將無窮的”streaming”數據稱爲unbounded data，將有限的”batch”數據稱爲bounded data。
- Unbounded data processing：一種持續的數據處理模式，應用於前面提到的unbounded data。我自己也常使用術語 streaming 來描述這種類型的數據處理，但是在本文中 streaming 還是意味着流式計算引擎，這會造成誤解；重複執行批量引擎也可以處理 unbounded data（相反，良好設計的流式系統也可以處理 bounded data）。因此，爲了清楚，我會使用unbounded data processing這個術語。
- Low-latency, approximate, and/or speculative results：這些類型的結果通常都與流式引擎相關。批量系統通常不是設計用來解決低延遲或者近似結果的只是一種歷史觀念。事實上，批量引擎也可以生成近似結果。因此，使用上面這些術語可以更好的描述它們是什麼（低延遲，近似或者推測結果），而不是通過流式引擎代表它們。
從此開始，每當我使用術語”streaming”，我都是在說一個爲無界數據設計的計算引擎。當我要表達上面的其它術語時，我都會說unbounded data, unbounded data processing, 或者 low-latency / approximate / speculative results。這些術語都是在Cloud Dataflow中採用的，我也希望其他人可以採用它們。
streaming 被誇大的能力限制
下面，讓我們討論下流式系統能做和不能做的，重點看看能做的；在這篇文章裏我想介紹的是一個設計良好的流式系統能做什麼。流式系統長久以來被認爲是提供低延遲、不準確/推測的結果，通常與一個提供最終準確結果的批量系統協作配合，也就是說 Lambda 架構。
Lambda 架構基本的理念就是同時運行一個流式系統和一個批量系統，二者都執行本質上相同的計算。流式系統提供低延遲但是不準確的結果（或者是由於使用近似算法，或者是由於流式系統本身不提供準確性保證），過段時間之後批量系統會提供準確的輸出。 Lambda 架構最開始由 Twitter 的Nathan Marz（Storm 的作者）提出，在當時是很奇妙的想法，也是相當成功的；流式引擎在正確性上不能令人滿意，批量引擎天生不夠靈活，所以Lambda提供了一種短期的解決方案。不幸的是，維護一個 Lambda 系統很麻煩：你需要構建維護兩個獨立的系統，而且還要在最後合併兩個系統的結果。
作爲研究強一致流式引擎多年的從業者，我也發現 Lambda 架構的整個原則是有問題的。我是Jay Kreps的文章《Questioning the Lambda Architecture》的粉絲。這篇文章是最早質疑雙引擎模式的必要性的。Kreps 使用一個像 Kafka 這樣的可重放系統作爲流式系統的內部連接來解決可重複性的問題，他提出 Kappa 架構，基本思想就是用一個設計良好的系統作爲單系統來運行。我不認爲這個概念需要一個新名字，但是我完全支持他的思想。
我認爲應該更進一步。我認爲設計良好的流式系統提供的功能應該是批量系統的超集。除去資源利用率方面的考慮，現在完全可以不需要批量系統了。Flink 就是採用這種想法構建的完全的 streaming系統，並且支持”batch”模式，我非常喜歡它。
隨着流式系統越來越成熟，它提供一種爲無界數據處理的健壯架構，將會使 Lambda 架構消失在大數據的歷史中。我相信這正在變成現實。如果想打敗批量系統，我們只需要做兩件事：
1. 正確性 – 這使streaming 能夠和 batch 等同。
本質上，正確性取決於一致性存儲。流式系統需要一個定期的持久化狀態的方法（就是 Kreps 在他的文章中討論的爲什麼在流式處理中本地狀態是基礎），並且它必須設計的足夠好，即使機器故障後也能保持一致性。當幾年前Spark Streaming首先出現在公共大數據視野中時，它就是黑暗的流式世界中的一個燈塔。一切都在向前發展，但是仍有很多流式系統不能提供強一致性；我實在不理解爲啥at-most-once處理仍然存在，但是實際情況是它確實存在。
再重申一次，因爲這一點很重要：強一致是exactly-once處理所必須的，是正確性所必須的，是任何有機會趕超批量系統的系統所必須的。除非你真的不關心結果，我都建議你放棄那些不提供強一致狀態的流式系統，不要在它們身上浪費你的時間。
如果你想學習在流式系統中如何做到強一致性，我建議你閱讀MillWheel和Spark Streaming的論文。二者都花費了很多時間討論一致性。本文時間有限，我就不再此詳述了。
2. 推導時間的工具 – 這令 streaming 超越 batch。
處理無界、無序數據時，好的時間推導工具是基礎。越來越多的需求需要我們處理無界無序的數據，但是目前的批量系統（包括大多數流式系統）缺少必要的工具來解決這些問題。我會用本文剩餘的篇幅，以及下一篇文章着重介紹它。
我們首先會理解時間方面中一些重要的概念，然後深入分析無界無序數據的 event-time skew。之後會介紹對於有界和無界數據處理的通用方法，包括批量和流式系統。
Event time vs. processing time
爲了透徹地講解無界數據處理，需要對於涉及的時間概念有清晰的理解。在任何數據處理系統中，有兩種典型的時間概念需要我們關心:
-
Event time，就是事件真正發生的時間。
-
Processing time，就是事件進入系統被處理的時間。
不是所有的業務都關心event times（如果你的不關心，則你的生活會簡單很多），但是很多業務都要關心。例如爲帶時序的用戶行爲刻畫特徵，大部分付費應用，以及很多類型的異常檢測。
理想情況下，event time 和 processing time 總是相同的，也就是事件一發生立刻就被處理了。而現實是殘酷的，event time 和 processing time 之間的 skew 不僅不是0，而是一個與輸入源、執行引擎以及硬件相關的函數。可以影響 skew 的因素包括：
- 共享資源限制，例如網絡擁塞，網絡分區，或者非獨佔環境中的共享 CPU。
- 軟件原因，例如分佈式系統邏輯，競爭等等。
- 數據本身的特徵，包括 key 的分佈，吞吐量差異，無序。
如果將真實系統中的 event time 和 processing time 的繪製出來，將會得到圖1中的紅線。
圖1：時間映射舉例。X 軸代表 event time。Y 軸代表 processing time。
黑色虛線代表理想情況，也就是 processing time 與 event time 完全相同；紅線代表真實情況。在這個例子中，系統在 processing time 的開始有一點延遲，中間階段接近理想情況，在最後又有一點延遲。在理想情況和紅線之間的水平距離就是 processing time 和 event time 的skew。skew基本都是由處理管道的延遲引入的。
由於 event time 和 processing time 之間的映射關係不是固定的，這意味着如果你關心數據的 event times（也就是事件真正發生的時間），你就不能用 processing time 來分析數據。不幸的是，這是目前大部分系統爲無界數據設計的處理方法。爲了處理無界數據的無窮特性，這些系統提供了一些將數據按時間窗口劃分的概念。我們會在下面深入討論時間窗口，它的基本含義就是將數據沿着臨時的分界線切分成有限的分片。
如果你關心正確性，並且需要用 event time 來分析數據，你就不能像大部分已有的系統那樣，用 processing time 來定義這些臨時分界線（也就是 processing time 窗口）；由於processing time 和 event time 之間沒有一致性的關聯關係，一些數據就會被劃分到錯誤的 processing time 窗口中（由於分佈式系統內在的延遲，很多類型的輸入源的在線/離線等原因），導致無正確性可言。我們會在下面看到更多這樣的例子。
不幸的是，即使按 event time 劃分窗口也不是那麼完美的。在無界數據環境中，無序和變化的skew會爲 event time 窗口帶來完整性問題： processing time 和 event time 之間缺少可預測的映射關係，那你如何確定對於某個 event time 時刻爲 X 的數據是否已經都進入系統處理過了？對於很多真實世界中的數據源，你是無法確定的。現在大部分數據處理系統都依賴某種完整性，但是當應用到無界數據時它們就遇到了嚴重的問題。
我建議應該設計工具能夠讓我們處理這種由複雜的數據帶來的不確定性，而不是將無界數據劃分成最終會變成完整的有限的數據片。新數據將會到達，老數據可能會被撤銷或者更新，我們構建的任何系統都應該能夠獨立處理這些情況。在這些系統中完備性的概念只是一個輔助而非一個必要條件。
在深入介紹如何實現Cloud Dataflow數據模型前，我們先了解一個更有用的背景：常見數據處理模式。
文章轉自：