StreamingSystem (Google 流式團隊著)-c1.Streaming101-8
其他章節的內容可以點擊作者頭像在主頁列表找到
Windowing by processing time
如果窗口是基於Processing time的，其實就是緩存數據知道窗口內的數據時間窗口達到後即可。
對於Processing time的窗口計算有一些優越的特質
- 簡單：利用Processing time做窗口計算，只需要在固定的時間段打開窗口結束的時候直接將數據產出就可以了
- 判斷窗口完整性很方便，不需要過多的關注"late"數據
- 如果想針對來源的數據進行一些推斷和了解，利用Processing time是一個比較好的選擇，例如對於監控系統。
上述介紹了利用Processing time的好處，簡單總結一句就是簡單直接。但是也存在著很明顯的缺點： 如果要處理的問題是對於eventtime強一來的話，Processing time將很難適用，而且在現實的分佈式系統當中，從eventtime角度來看數據都是亂序的。
（下面他介紹了幾個例子，我們前面已經有類似的介紹了，如果想看可以往前面的文章看一下，大概就是強調實際生產環境下）
在目前的很多處理場景下，我們雖然很多場景期望用的是Processing time但是實際情況期望使用的是Eventtime，下面將詳細介紹eventime的窗口。
Windowing by event time
在我們嘗試處理數據的時候，很多時候基於事件時間的窗口是真正需要的。它能更好的反映實際情況，但是在2016年之前，大部分的數據處理系統，缺少對於事件時間窗口的支持。例如Hadoop和Spark 1.x，這一情況目前有所改變，更多的系統，例如Flink，Spark，Storm，Apex，原生的支持了事件時間的窗口。圖1-10描述了，將無限的數據源劃分為一個小時固定大小的窗口中
上圖中能夠的黑色箭頭，便是將Processing time和event time不同的事件更好的遷移到了event time對應的窗口，如果只是簡單的使用Processing time來處理，結果顯然是不對。
另外一個event time 更加適用的場景是創建動態大小的窗口，比如session窗口。而且session 窗口不會因為時間的原因被分列。如圖1-11
天下沒有免費的午餐，強大的語義也是需要付出更多的代價，Event time 窗口有兩個明顯的缺點，究其原因，主要是很多時候窗口的存在時間要比實際窗口的大小要長很多。
緩存
由於需要存在更長時間，因為需要緩存更多的數據，但是相對而言，緩存所需要的硬件設備，要價格便宜很多。相對於需要強一致存儲的數據系統或者其他的基於內存的緩存層，現在討論的緩存要簡單很多，。此外大部分的緩存不需要緩存整個數據，只是魂村一些中間的聚集結果即可。
Completeness（完整性）
通常情況下，沒有太好的辦法來確定當前窗口的數據已經完全到達了，在實際操作中，我們是如何實現呢？實際上在目前的很多系統中MillWheel，Cloud Dataflow和Flink，利用水印的形式，通過啟發規則的方式來估算窗口應該關閉的時間。但是，在某些需要精確結果的情況下（例如訂單系統），期望系統提供一種機制來通知進行窗口計算以及隨著時間的變化來逼近真實的結果。對於這個事情，是一個值得探討的話題，將在後文中進行詳細介紹。
閱讀更多 北京IT民工 的文章
