Streaming System 翻譯中文版-Chapter 1. Streaming 101（2）
更進一步，我認為一個精心設計的流式系統可以提供嚴格意義上的批量功能，這方面Apach Flink已經做了很好的表率。
為了戰勝Lambda架構，其實只要實現兩個關鍵的事情
正確性：
正確性如果可以實現，會極大的幫助流式系統在能力上對齊批量系統，正確性的核心問題是一致性的存儲。流式系統需要一個比較好的設計來做checkpoint的持久化存儲，尤其是在機器失敗的情況下，依舊可以保持一致性。幾年前，Spark Streaming在這方面有一些建樹，自那以後正確性保證又有一些進展，但是值得注意的是，還有很多流式系統，並沒有過於重視正確性。
重申一點，對於exactly-once的處理方式，強一致性是必要條件，而且對於任何想對齊和超越批量系統的流式系統，強一致性都是不可或缺的。
如果您想了解更多有關在流系統中獲得強大一致性所需的知識，建議您查看MillWheel，Spark Streaming和Flink snapshotting論文。這三個人都花費大量時間討論一致性。Reuven將在第5章中介紹一致性保證。
Tools for reasoning about time （沒想好怎麼翻譯，暫時用原文）
為了是流式系統更加優於批量系統，一個好的時間處理工具是十分必要的，（後面一大堆扯淡的跳過了直接切入主題），
加一點我的理解，其實在對於大部分的數據使用場景，都是在某一個時間窗口下進行數據的聚集，進行指標的計算，這裡面“某一個時間窗口就格外重要“，是事件發生的時間，還是系統接收或者處理數據的時間，理想情況下應該是一致的，但是由於系統處理時間、網絡延遲、以及機器失敗重啟等，會導致兩個時間不一致。
老外寫書羅裡吧嗦的，是不是他們按字算錢。
事件事件對比處理時間
事件時間（Event Time）
事件實際發生的時間（加一點我的解釋，其實就是比如你在某個APP上點擊了一個按鈕，這個點擊行為我們叫事件，你點擊按鈕的絕對時間就是事件時間，注意不是客戶端時間，由於客戶端時間是可以調的，所以他不是絕對時間，但是涉及到具體實現，這個時間你需要做服務器和客戶端的通信，NTP可以做，但是又有延遲，做過的都知道其實不好實現，最終妥協成了服務器時間或者客戶端時間，但是定義是絕對實現，只是不好實現。）
處理時間（Processing Time）
這就是你係統裡面遇到的事件的時間，（同樣解釋一下，比如在7點半你點擊一個按鈕，然後後面有埋點服務，Message queue，flume，spark，結果spark收到的時候已經晚上9點半了，這裡面的processtime就是9點半，這個好實現，一般就是機器的本地時間。）
（下面開始說兩個時間的重要性了，坐穩了），
並不是所有的用例都關心事件時間，但是例如計費系統就比較關心事件時間，（這個例子是對的，否則事件已延遲記賬全錯了，就別幹了）。
在理想的狀態下事件事件和處理時間應該是一樣的，但是實際情況往往不一樣（上面解釋了，可以往前看一下）這裡引入一個新的概念叫Time skew，簡單來說就是處理時間和時間時間的偏差。
（需要解釋就留言吧，我覺得前面解釋過了，理想情況下應該是虛線，但是實際情況是哪個紅線，這個是對的，要是有興趣可以畫一下自己系統的數據，差不多就這個樣子）
發佈於 16:36
閱讀更多 北京IT民工 的文章
