- 人民郵電出版社
第一章 為何選擇Flink
競品：SparkStreaming/Storm/Samza/Apex
Lambda架構(gòu)(不懂為何叫Lambda)
https://ask.hellobi.com/blog/transwarp/5107在大型分布式系統(tǒng)各種，數(shù)據(jù)一致性和對事件發(fā)生順序的理解必然都是有限的。
來源德語：快速、靈巧
-
Flink將批處理（有限的靜態(tài)數(shù)據(jù)）視作一種特殊的流處理
image.png -
Flink Runtime是核心引擎，直接基于此的程序冗長編寫費(fèi)力——提供API
20190120113636940.png
第二章 流處理架構(gòu)
- 傳統(tǒng)分布式的問題：
- 數(shù)據(jù)到達(dá)分析階段的流程復(fù)雜緩慢
- 都需要訪問數(shù)據(jù)庫，數(shù)據(jù)架構(gòu)單一
- 復(fù)雜的異常處理，難以保證異常出現(xiàn)后系統(tǒng)的正常運(yùn)行
- 實(shí)際數(shù)據(jù)與狀態(tài)數(shù)據(jù)的一致性
- 消息傳輸層（Kafka或者M(jìn)apR Streams）
- 從生產(chǎn)者采集連續(xù)事件產(chǎn)生的數(shù)據(jù)，并傳輸給訂閱了的app和服務(wù)
- 流處理層
持續(xù)將數(shù)據(jù)在app和系統(tǒng)間移動
聚合、處理事件
在本地維持app的狀態(tài)
兼具高性能和持久性（消息重播，而非到流處理層后就消失了）
解耦生產(chǎn)者和消費(fèi)者（消息立刻到達(dá)，但無需立刻處理——支持多、微服務(wù)）
第三章 Flink用途
- 計算用戶連續(xù)訪問時長（解決了剛工作時遇到的一個痛點(diǎn)——用python腳本分析用戶在JZB_App上的訪問時長。當(dāng)時問題很多，除了數(shù)據(jù)處理的緩慢，內(nèi)存消耗，如何定義連續(xù)訪問都很麻煩，沒法確定哪種是最好的，否則就要每個定義都計算一份數(shù)據(jù)）
- 如果使用微批處理，可能人工定義的計算窗口與會話窗口不吻合
- Flink可以設(shè)置非活動閾值——可以根據(jù)真實(shí)情況設(shè)置計算窗口
- Flink優(yōu)勢——能夠區(qū)分這兩類時間
- 事件事件——實(shí)際發(fā)生時間（容易實(shí)現(xiàn)計算的正確性）
- 處理時間——開始被程序處理
- 故障后保持準(zhǔn)確
- 檢查點(diǎn)checkpoint機(jī)制
第四章 對時間的處理
批處理
- 缺點(diǎn)
- 太多獨(dú)立部分（太多系統(tǒng)——數(shù)據(jù)分割攝取、計算、調(diào)度 依賴混淆，都要需要時間概念；學(xué)習(xí)成本和bug）
- 時間處理方法不明確（比如改為半小時一次）
- 預(yù)警（需要通過增加Storm實(shí)時提供近似計數(shù)，這樣就變成Lambda了）
- 亂序事件流（到達(dá)數(shù)據(jù)中心的順序和實(shí)際發(fā)生順序）
- 批處理作業(yè)時間界限不清洗（分割點(diǎn)前后的時間，以及要分析時間段聚合結(jié)果無法滿足）
流處理
- 流即是流不必人為分割
- 時間定義被寫入應(yīng)用程序代碼（時間窗口等），而非牽扯到多個模塊
流處理中的批處理
- 批處理只作為提高系統(tǒng)性能的機(jī)制。批量越大，系統(tǒng)吞吐量越大
- 為提高性能使用的批處理必須完全獨(dú)立于定義窗口時用的緩沖，或者為了保證容錯性而提交的代碼，也不能作為API的一部分。否則系統(tǒng)將受到限制，難以使用且脆弱。
（有點(diǎn)不好理解）
時間
- 事件時間，帶有時間戳的記錄
- 處理時間，處理事件的機(jī)器測量的時間
- 攝取時間/進(jìn)入時間，進(jìn)入流處理框架的時間
時間窗口
支持滾動和滑動
stream.timeWindow(Time.minutes(1))
stream.timeWindow(Time.minutes(1), Time.seconds(30))
計數(shù)窗口
采用計數(shù)窗口時，分組依據(jù)不再是時間戳，而是元素的數(shù)量。滾動和滑動的計數(shù)窗口分別定義如下。
stream.countWindow(4)
stream.countWindow(4, 2)
假設(shè)計數(shù)窗口定義的元素數(shù)量為 100，而某個 key 對應(yīng)的元素永遠(yuǎn)達(dá)不到 100 個，那么窗口就永遠(yuǎn)不會關(guān)閉，被該窗口占用的內(nèi)存也就浪費(fèi)了。
會話窗口
可方便處理用戶連續(xù)訪問頁面時長的問題（通過設(shè)定間隔時長）。
stream.window(SessionWindows.withGap(Time.minutes(5))
時空穿梭
很有用：調(diào)試或者重新處理數(shù)據(jù)。但需要流處理器支持事件時間，否則結(jié)果會不同（機(jī)器時間不同了）
水印
當(dāng)計算基于事件時間時，如何判斷所有的事件已到達(dá)？需要依靠由數(shù)據(jù)驅(qū)動的時鐘而非系統(tǒng)時鐘。
比如滾動窗口中，計算10:00:00-10:01:00的事件，因為時間戳就是數(shù)據(jù)，那如何判斷是否存在某個10:00:59的元素還沒到呢？
Flink 通過水印來推進(jìn)事件時間。水印是嵌在流中的常規(guī)記錄，計算程序通過水印獲知某個時間點(diǎn)已到。水印使事件時間與處理時間完全無關(guān)。
水印由應(yīng)用程序開發(fā)人員生成，需要領(lǐng)域知識。啟發(fā)式水印可能出錯。
第五章 有狀態(tài)的計算
一致性
流處理一致性三個級別（對于故障發(fā)生后的恢復(fù)能力）：
- at-most-once: 計數(shù)結(jié)果可能丟失，沒有能力
- at-least-once: 計數(shù)結(jié)果>=正確值（Storm/Samza）
- exactly-once: 計數(shù)結(jié)果=正確值 (Strorm Trident/ Spark Streaming)
Flink——既保證exactly，也有低延遲高吞吐
檢查點(diǎn)
- 保證exactly-once的機(jī)制，在出現(xiàn)故障時將系統(tǒng)重置回正確狀態(tài)。
總體而言就是在數(shù)據(jù)流中嵌入檢查點(diǎn)，遇到檢查點(diǎn)時記錄檢查點(diǎn)的位置與此時的計數(shù)狀態(tài)，以方便在遇到故障時恢復(fù)最近的狀態(tài)并重跑檢查點(diǎn)后的數(shù)據(jù)。
詳情可見（也是部分圖源）：
http://www.linkedkeeper.com/1415.html
