Streaming System 翻譯中文版-Chapter 1. Streaming 101（3）
如上圖所示；有兩個明顯的timeskew，主要是一橫一豎兩個線，每一個在不同的時間區域中，（下面主要解釋這個一橫一豎代表的含義）
處理時間lag（processing-time lag）：
那一條豎著的線，這代表processtime和eventtime之間延遲的距離有多大，也代表一個時間從產生到真正處理的時間差，這個線比較直觀，
事件時間偏移（event-time skew），
那一條水平的線，代表距離理想的狀態，當前pipeline的的延遲與多大。
在實際情況下，processing-time lag和event-time skew應該是相等的，只是對於同一件事情，不同的方式。對於processing-time lag或event-time skew需要重視的一點是，由於processing-time和event-time之間的差距是動態變化的，所以如果你很關心event-time你很難在上下文中得到有利的信息（解釋一下，這一段有點繞，我覺得作者想說的是，如果你想知道當天eventtime後面是否還有對應的數據，比如比他早或者晚的數據，你很難通過你已經讀取的數據判斷，比如你現在看到了一條eventtime 8點的數據，後面來的都是8點01的了，那是不是說明8點之前的數據沒有了，這並不代表，應該有可能有一些7點59的數據卡在了某些地方，多以很難用已知信息進行預測。如果event-time skew固定的就能預測了）
但是，很多系統為了更好的處理流式數據，都會提供窗口計算，稍後會對窗口計算做更加深入的介紹，本質上窗口計算就是在時間的維度上把數據切割成若干片段。 如果你關心正確性，並且想用eventtime來做窗口計算，顯然processtime是不適用的。但是在實際實現的系統當中很多時候都是用processtime來做的窗口計算本來打算用eventtime做窗口的。從而導致結果不準確。（解釋一下，一句話，現在好多系統要麼沒區分eventtime，processtime，要麼不支持processtime和eventtime，所以要是你想要精確地基於eventtime的結果，現在做不到）
對於數據完整性現在的很多系統是與要求的，但是對於processtime和eventtime之間的timeskew，目前的系統又不能預測，所以這是一個問題。
下面將給出一個解決方案，與其追求講無限的數據流變成有限的數據流，不如換個思路，來設計一個工具，應對複雜場景：新數據到達，舊數據被更新或者拋棄。（這一段直接翻譯有點繞，解釋一下，其實思路是這樣的，現在面臨的問題是，永遠不知道是否還有某個eventtime之前的數據再過來，那能不能這樣，把結果變成變化的，而不是不變的，一旦有新的數據過來，直接更新原來舊的結果）
在詳細介紹更多的細節之前，先介紹一下其他有用的概念
閱讀更多 北京IT民工 的文章
