再談 Flink
前一陣痴迷於calcite，打算寫一些streaming sql相關的東西，正好時逢置辦年貨，就買了本書《Flink基礎教程》，開啟看了一下，就放不下了，一口氣都看完了，書不厚，很薄的一本小冊子，有種醍醐灌頂的感覺，回想起9月份寫的《阿卡姆科普報告——Flink》未免有些稚嫩......
還是那些內容，但是現在和當時的理解完全不一樣了，希望半年後的我，再來看這篇文章的時候，也覺得很稚嫩吧...
首先Flink和其他流框架的區別：
這張圖，就充分表達了flink的特點，保證高吞吐量、低延遲、正確性、操作簡單以及語義化時間窗幾個特點。
說到高吞吐量和低延遲，那麼就不得不說一說lambda和kappa架構了，在最傳統的ETL跑批的基礎上，演化出來的lambda，目前可以說已經獨領風騷了，而且基本整個生態體系，都是這個樣子，大家自知或是不自知的都在往這個解決方案上靠攏。
建立在跑批加流處理的方式雖然解決問題，但是總感覺不夠優雅，那麼kappa架構，估計就是你的菜了，至少在理論上，是看著舒服和優雅那麼一點。
這也是flink推薦的架構方式
之所以，kappa架構成為可能，除了kafka體系提供的支援外，也是由於flink能很好的完成exactly-once，這讓不負責任的at-most-once，和湊合用的at-least-once情何以堪。
說到這裡，flink是如何完成 exactly-once的？通過檢查點，那麼怎麼加的檢查點呢？是通過 watermark，看文章有人翻譯成水位線，有人翻譯成水印，個人比較推薦使用水印的，因為這樣可以方便你後續理解程式，反正我開始看一些文章，總覺得水位線這個翻譯，和他起到的作用，有一種很割裂的感覺。
對於一個沒做過流系統的人，時間和視窗可能是比較陌生的概念了，時間可以分成事件時間和處理時間，舉個不太恰當的例子：
一個系列影片的故事線時間，相當於處理時間，而發行時間是事件時間，所以事件時間，很有可能是亂序，如果不是亂序，事件時間可能是很好的水印選擇了。
下面一個圖，就是對時間視窗和滾動最好的詮釋了
對於 狀態部分， 我真的還沒理解，其完全的內涵.... 如果你懂的話，還請不吝賜教.....
也許是最近研究calcite的原因，個人總感覺calcite+flink會是一個很有意思的組合，如果加上ranger可能形成一套系統......
容我三思......
後續，在完成 calcite streaming sql前，可能會發幾個flink的程式入門教程，一起來學習學習......