與傳統批處理作業方式不同，實時流的計算處理過程是連續的。所以當我們在流式作業中要做傳統的階段統計工作（求和，取均值計算）的時候，需要在邏輯上對這些資料進行分片，然後再處理。本文我們來聊聊流計算過程中按照時間的處理方式。
在傳統批處理的作業執行方式裡，我們可以一次性讀取入所有的輸入資料，然後經過計算，再輸出結果。對於原始資料，我們可以做任意我們想做的預處理工作，包括資料項的排序等等操作。但是在實時流計算引擎下，很多東西就不會這麼直接，簡單了。至少，我們需要明白乙個點：在連續不斷的流資料中，我們如何對其進行邏輯意義上的拆分，這個拆分線我們到底怎麼來劃分。
按照最最常考慮到的2大維度，大小和時間。這2大維度，按照自由組合，我們可以組合出以下3種視窗型別：
固定大小視窗和滑動視窗的效果圖如下圖所示。
在現實的場景中，我們用時間視窗會比較多一些，比如分時段內的數理統計需求等等。於是這裡會衍生出另乙個話題：按照視窗的時間計算，這個「時間」要依據的是哪個呢？
假設是完全理想的情況，我們預設的時間當然指的是任務當前的處理時間為視窗目前依據的時間。如下圖所示。
但是在現實的環境中，有很多影響會導致資料的真正時間不完全等於其處理時間，直接地來說，就是資料被處理的時間距離它的原始生成是有延時的。這裡的延時原因至少包括以下2點：
而且以上延時會導致資料出現亂序的問題，比如後乙個時間點的視窗內突然到來了乙個「遲到」的資料點。那麼這個時候這個遲到的資料要怎麼被處理呢？總不能算到當前的視窗週期內吧。
這裡我們用event time來表示資料的本身時間，用process time來代表其被處理的時間。絕對理想狀況下，二者是完全想到的，但是實際場景中，event time和process time總是會存在略微偏差，如下圖。
鑑於真實場景中，資料的當前處理並不等於其產生時間，所以更多的時候我們會選用資料的時間，也就是event time來做視窗計算。
網路資料在傳輸過程中，有很多不穩定的因素，導致存在亂序的情況，比如這個時刻點接收到了上上個時刻點的資料。那麼這個時候，我們怎麼處理呢？
這裡有以下幾種辦法。
第一種，完全丟棄這樣的資料。這裡我們基於的乙個假設是，這樣的異常延時的資料不會太多，將不會影響到整體的資料。更簡單地來說，這是一種不增加系統處理複雜性的前提下，保證整體準確性的做法，是一種近似準確性的方法。
第二種，允許一定容忍度內的「亂序」資料。當乙個視窗時間過去之後，下乙個新的視窗開始計算的時候，此時我們不會立即關閉上乙個視窗，等上一段時間，來確保晚到的本屬於上個視窗的「最晚」時刻的資料被處理掉。然後再關閉上個視窗。所以這裡要引入乙個能夠表示event time進度的概念，我們這裡叫watermark。乙個資料的watermark可以由其event time時間轉化計算得來，一種常用的轉化公式如下：
watermark=event time - allowmaxlatency上述公式的意思是：如果我們處理到當前資料的watermark時間（其event time減去最大允許延時時間）已經超過視窗區間的閉區間時間，則表明此視窗的資料都已完全到達。
其實從這裡我們可以看出，視窗資料的真實生命週期是被拉長了一部分，會同時存在前後多個視窗存在的情況，因為資料是允許一定latency到達的。當然，我們也不會一直死等那個「落單」的資料。在watermark的運用下，視窗資料的準確性能得到保證。
[1].
流計算過程中對於視窗的處理方式
與傳統批處理作業方式不同，實時流的計算處理過程是連續的。所以當我們在流式作業中要做傳統的階段統計工作 求和，取均值計算 的時候，需要在邏輯上對這些資料進行分片，然後再處理。本文我們來聊聊流計算過程中按照時間的處理方式。在傳統批處理的作業執行方式裡，我們可以一次性讀取入所有的輸入資料，然後經過計算，再...
棧在表示式計算過程中的應用
棧在表示式計算過程中的應用 建立運算元棧和運算子棧。運算子有優先順序。規則 自左至右掃瞄表示式，凡是遇到運算元一律進運算元棧。當遇到運算子時，如果它的優先順序比運算子棧棧頂元素的優先順序高就進棧。反之，取出棧頂運算子和運算元棧棧頂的連續兩個運算元進行運算，並將結果存入運算元棧，然後繼續比較該運算子與...
卷積神經網路計算過程中的維度變化
最近在學習pytorch,在閱讀pytorch教程的時候，發現有乙個簡單的卷積神經網路，之前搞明白過這個過程，時間太久，都忘的差不多了，正好寫個筆記記錄總結一下 如下 usr bin env python3 coding utf 8 author macan time 2019 10 29 19 5...