「流計算」是相對於「批計算」來的，mapreduce，spark底層的計算方式是目前主流的「批計算」實現方式，很多公司在使用這種方式做大資料處理。但是越來越多的公司目前開始關注「流計算」，主要有以下一些原因：
1 對處理時間的要求。隨著技術的進步，使用者對「延遲」的忍受能力越來越弱，能更及時發現問題、解決問題，能提公升使用者體驗。
2 在大資料分析領域，資料分析得越及時，價值越高。在推薦、風控等很多場景中，對實時性的要求相當苛刻
3 「流計算」天然支援對事件發生的先後順序、時間關係這方面的分析，這是「mini batch」方式的批處理系統支援不好的
目前批處理的流行是因為以前的流處理技術不夠好，或者說「批處理」是因為技術原因對現實需求所做的妥協。現實中日誌、交易、物流等常見的大資料場景，資料都是以「流」的方式產生，適合以「流計算」的方式及時處理。但以前的storm等流處理系統，在吞吐量、容錯性、準確性方面無法滿足要求，所以大家才使用成熟度更高的「批處理」系統。人為地發資料切分成一批一批的，每天處理一次或者每小時處理一次等。
如果「流處理」系統達到批處理系統類似的吞吐量和容錯性，「流處理」在實時性和「時間序列」處理方面的優勢就非常明顯了。
有3類時間，分別是資料本身的產生時間、進入flink系統的時間和被處理的時間，在flink系統中的資料可以有三種時間屬性：
event time
ingestion time
processing time
event time
是每條資料在其生產裝置上發生的時間。這段時間通常嵌入在記錄資料中，然後進入
flink
，可以從記錄中提取事件的時間戳；
event time
即使在資料發生亂序，延遲或者從備份或永續性日誌中重新獲取資料的情況下，也能提供正確的結果。這個時間是最有價值的，和掛在任何電腦
/作業系統的時鐘時間無關。
processing time 是指執行相應操作的機器的系統時間。如果流計算系統基於processing time來處理，對流處理系統來說是最簡單的，所有基於時間的操作（如time window）將使用執行相應運算元的機器的系統時鐘。然而，在分布式和非同步環境中，processing time並不能保證確定性，它容易受到event到達系統的速度（例如來自訊息佇列）以及資料在flink系統內部處理的先後順序的影響，所以processing time不能準確地反應資料發生的時間序列情況。
ingestion time是事件進入flink的時間。 在source運算元處產生，也就是在source處獲取到這個資料的時間，ingestion time在概念上位於event time和processing time之間。在source處獲取資料的時間,不受flink分布式系統內部處理event的先後順序和資料傳輸的影響，相對穩定一些，但是ingestion time和processing time一樣，不能準確地反應資料發生的時間序列情況。
上面提到event time是最能反映資料時間屬性的，但是event time可能會發生延遲或亂序，flink系統本身只能逐個處理資料，如何應對event time可能會發生延遲或亂序情況呢？
比如需要統計從10:00到11:00發生某個事件的次數，也就是對event time是在10:00和11:00之間的資料統計個數。event time可能會發生延遲或亂序的情況下，flink系統怎麼判斷10:00到11:00發生的事件資料都已到達，可以給出統計結果了呢？長時間地等待會推遲結果輸出時間，而且占用更多系統資源。
watermark是乙個對event time的標識，內容方面watermark是個時間戳，乙個帶有時間戳x的watermark到達，相當於告訴flink系統，任何event time小於x的資料都已到達。比如上面的例子，如果flink收到乙個時間戳是11:01的watermark，它就可以把之前統計的event time在10:00和11:00之間的事件個數輸出，清空相關被占用的資源。
periodic - 一定時間間隔或者達到一定的記錄條數會產生乙個watermark。
punctuated – 基於event time通過一定的邏輯產生watermark，比如收到乙個資料就產生乙個watermark，時間是event time + 5秒。
這兩種產生方式，都有機制來保證產生的watermark是單調遞增的。
即使有了watermark，如果現實中，資料沒有滿足watermark所保證的條件怎麼辦？比如flink處理了11:01的watermark，但是之後遇到了event time是10:00~11:00之間的資料怎麼辦？首先如果這種事情出現的概率非常小，不影響所要求的準確度，可以直接把資料丟棄；如果這種事情出現的概率比較大，就要調整產生water mark的機制了。
除了把違反watermark機制的資料丟棄，也有不丟棄的處理方法，比如通過一些機制來更新之前統計的結果，這種方式會有一定的效能開銷。
本文首先介紹了流計算系統的優勢，流計算系統在功能上是「批處理」系統的超集，除了可以做批計算，也可以提供實時性更高，時間序列處理更完善的功能。然後介紹了在流計算系統中的時間型別和watermark機制，流處理系統中資料的時間屬性非常重要，流處理系統通過water mark機制來解決現實中的資料延遲，資料亂序問題。
歡迎閱讀，有問題可以通過郵件kaiyuan0989愛特163.com一起**。
Flink流計算中SQL表的概念和原理
fink在新發布的1.7版本中，不斷完善和加強了sql table api方面的功能支援。這使得在流計算過程中，使用者同樣能夠運用熟悉的sql語句來做資料處理，查詢。但是相比於窗體的rdbms而言，流計算過程中的sql處理難免讓人覺得不是很好理解，畢竟資料不是fixed sized的，而是連續不斷的...
Flink的時間和視窗的使用 水位線的設定
window分為兩大類 countwindow 按照指定的資料條數生成乙個window，與時間無關。timewindow 按照時間生成window 對於timewindow，可以根據視窗實現原理的不同分成三類 滾動視窗 tumbling window 滑動視窗 sliding window 和會話視...
微信小程式裡的時間差值計算（計算天數）
部分 介紹 replace g,一般用於格式化日期，如 2016 1 1 格式化為 2016 1 1 g 代表全域性，所有的 符號都替換為 gettime 方法返回距 1970 年 1 月 1 日之間的毫秒數 js 引入全域性 var util require utils date.js datao...