大家好，我是雲祁！
之前在團隊裡和小夥伴們做了關于 Flink 與阿裡雲 Realtime Compute 的技術分享，今天有時間就把PPT的内容做了整理分享給大家 （多圖預警）🙄
前言
Flink 最早期起源于德國柏林工業大學的一個研究項目Stratosphere，直到 2014年4月 捐獻給Apache軟體基金會...
要知道，在2015年的時候，Filnk幾乎沒有人知道，更沒有人大規模使用它 😭
而阿裡是全球第一批使用Flink做大資料計算引擎研發的公司，2015年就引入内部，但最早Flink隻能支援小流量網際網路場景的資料處理。阿裡覺得Flink很有潛力，決定進行改造，并把這個内部版本取名Blink，是英文眨眼的意思：“一眨眼，所有東西都計算好了！😜
在2017年雙11，Blink就已成功支援全集團（阿裡巴巴、阿裡雲、菜鳥）所有交易資料的實時計算任務，也驗證了Flink可以通過改造支援企業大規模資料計算的場景 。
目前，國内諸多網際網路大廠都已經完全擁抱了Flink。本次的分享就是圍繞實時計算Flink和Alibaba Cloud Realtime Compute相關的知識點（能力、限制、典型場景，差別）進行分析。
什麼是 Apache Flink？
如果用一句話聊聊什麼是 Apache Flink 的命脈?
那我的答案可能是：Apache Flink 是以"批是流的特例"的認知進行系統設計的。
就目前最熱的兩種流計算引擎 Apache Spark 和 Apache Flink 而言，誰最終會成為No1呢?
單從 “低延時” 的角度看，Spark是Micro Batching(微批式)模式，延遲Spark能達到0.5~2秒左右，Flink是Native Streaming(純流式)模式，延時能達到微秒。
很顯然是相對較晚出道的 Apache Flink 後來者居上。那麼為什麼Apache Flink能做到如此之 "快"呢?根本原因是 Apache Flink 設計之初就認為 “批是流的特例”，整個系統是 Native Streaming 設計，每來一條資料都能夠觸發計算。相對于需要靠時間來積攢資料 Micro Batching 模式來說，在架構上就已經占據了絕對優勢。
那麼為什麼關于流計算會有兩種計算模式呢?
歸其根本是因為對流計算的認知不同，是"流是批的特例" 和 “批是流的特例” 兩種不同認知産物。
首先，我覺得 Flink 應用開發需要先了解 Flink 的 Streams、State、Time 等基礎處理語義以及 Flink 兼顧靈活性和友善性的多層次API。
Streams：流，分為有限資料流與無限資料流，unbounded stream 是有始無終的資料流，即無限資料流；而bounded stream 是限定大小的有始有終的資料集合，即有限資料流，二者的差別在于無限資料流的資料會随時間的推演而持續增加，計算持續進行且不存在結束的狀态，相對的有限資料流資料大小固定，計算最終會完成并處于結束的狀态。
在 Spark 的世界觀中，一切都是由批次組成的，離線資料是一個大批次，而實時資料是由一個一個無限的小批次組成的。
而在 Flink 的世界觀中，一切都是由流組成的，離線資料是有界限的流，實時資料是一個沒有界限的流，這就是所謂的有界流和無界流。
State：狀态是計算過程中的資料資訊，在容錯恢複和 Checkpoint 中有重要的作用，流計算在本質上是Incremental Processing（增量處理），是以需要不斷查詢保持狀态；另外，為了確定Exactly- once 語義，需要資料能夠寫入到狀态中；而持久化存儲，能夠保證在整個分布式系統運作失敗或者挂掉的情況下做到Exactly- once，這是狀态的另外一個價值。
流式計算分為無狀态和有狀态兩種情況。無狀态的計算觀察每個獨立事件，并根據最後一個事件輸出結果。- 例如，流處理應用程式從傳感器接收溫度讀數，并在溫度超過 90 度時發出警告。
有狀态的計算則會基于多個事件輸出結果。以下是一些例子：
- 所有類型的視窗。例如，計算過去一小時的平均溫度，就是有狀态的計算
- 所有用于複雜事件處理的狀态機。例如，若在一分鐘内收到兩個相差 20 度以上的溫度讀數，則發出警告，這是有狀态的計算
- 流與流之間的所有關聯操作，以及流與靜态表或動态表之間的關聯操作，都是有狀态的計算
Time，分為Event time、Ingestion time、Processing time，Flink 的無限資料流是一個持續的過程，時間是我們判斷業務狀态是否滞後，資料處理是否及時的重要依據。
EventTime，因為我們要根據日志的生成時間進行統計。
- 在不同的語義時間有不同的應用場景
- 我們往往更關心事件時間 EventTime
API 通常分為三層，由上而下可分為SQL / Table API、DataStream API、ProcessFunction 三層，API 的表達能力及業務抽象能力都非常強大，但越接近SQL 層，表達能力會逐漸減弱，抽象能力會增強，反之，ProcessFunction 層API 的表達能力非常強，可以進行多種靈活友善的操作，但抽象能力也相對越小。
實際上，大多數應用并不需要上述的底層抽象，而是針對核心 API（Core APIs） 進行程式設計，比如 DataStream API（有界或無界流資料）以及 DataSet API（有界資料集）。這些 API 為資料處理提供了通用的構模組化塊，比如由使用者定義的多種形式的轉換（transformations），連接配接（joins），聚合（aggregations），視窗操作（windows）等等。DataSet API 為有界資料集提供了額外的支援，例如循環與疊代。這些 API處理的資料類型以類（classes）的形式由各自的程式設計語言所表示。
- 第一：Flink 具備統一的架構處理有界和無界兩種資料流的能力。
- 第二：部署靈活，Flink 底層支援多種資源排程器，包括 Yarn、Kubernetes 等。Flink 自身帶的 Standalone 的排程器，在部署上也十分靈活。
- 第三：極高的可伸縮性，可伸縮性對于分布式系統十分重要，阿裡巴巴雙 11 大屏采用 Flink 處理海量資料，使用過程中測得 Flink 峰值可達 17 億 / 秒。
- 第四：極緻的流式處理性能。Flink 相對于 Storm 最大的特點是将狀态語義完全抽象到架構中，支援本地狀态讀取，避免了大量網絡 IO，可以極大提升狀态存取的性能。
接下來聊聊 Flink 常見的三種應用場景 ：
- 實時數倉
當下遊要建構實時數倉時，上遊則可能需要實時的Stream ETL。這個過程會進行實時清洗或擴充資料，清洗完成後寫入到下遊的實時數倉的整個鍊路中，可保證資料查詢的時效性，形成實時資料采集、實時資料處理以及下遊的實時Query。
- 搜尋引擎推薦
搜尋引擎這塊以淘寶為例，當賣家上線新商品時，背景會實時産生消息流，該消息流經過Flink 系統時會進行資料的處理、擴充。然後将處理及擴充後的資料生成實時索引，寫入到搜尋引擎中。這樣當淘寶賣家上線新商品時，能在秒級或者分鐘級實作搜尋引擎的搜尋。
- 移動應用中的使用者行為分析
- 消費者技術中的實時資料即席查詢
幹貨 | Apache Flink 入門技術 PPT 分享
在觸發某些規則後，Data Driven 會進行處理或者是進行預警，這些預警會發到下遊産生業務通知，這是Data Driven 的應用場景，Data Driven 在應用上更多應用于複雜事件的處理。
- 實時推薦（例如在客戶浏覽商家頁面的同時進行商品推薦）
- 模式識别或複雜事件處理（例如根據信用卡交易記錄進行欺詐識别）
- 異常檢測（例如計算機網絡入侵檢測）
接下來就該講講 Apache Flink 的幾點優勢：
Flink作為分布式的處理引擎，在分布式的場景下，進行多個本地狀态的運算，隻産生一個全域一緻的快照，如需要在不中斷運算值的前提下産生全域一緻的快照，就涉及到分散式狀态容錯。
如果項鍊上有很多珠子，大家顯然不想從頭再數一遍，尤其是當三人的速度不一樣卻又試圖合作的時候，更是如此(比如想記錄前一分鐘三人一共數了多少顆珠子，回想一下一分鐘滾動視窗。
于是，我們可以想一個比較好的辦法: 在項鍊上每隔一段就松松地系上一根有色皮筋，将珠子分隔開; 當珠子被撥動的時候，皮筋也可以被撥動; 然後，你安排一個助手，讓他在你和朋友撥到皮筋時記錄總數。用這種方法，當有人數錯時，就不必從頭開始數。相反，你向其他人發出錯誤警示，然後你們都從上一根皮筋處開始重數，助手則會告訴每個人重數時的起始數值。
在執行流應用程式期間，Flink會定期儲存狀态的一緻檢查點
如果發生故障，Flink将會使用最近的檢查點來一緻恢複應用程式的狀态，并重新啟動處理流程遇到故障後
- 第一步就是重新啟動
-
第二步是從 checkpoint 中讀取狀态，将狀态重置
從檢查點重新啟動應用程式後，其内部狀态與檢查點完成時的狀态完全相同
-
第三步：開始消費并處理檢查點到發生故障之間的所有資料
這種檢查點的儲存和恢複機制可以為應用程式提供“精确一次”（exactly-once）的一緻性，因為所有的算子都會儲存檢查點并恢複其所有的狀态，這樣一來所有的輸入流就都會被重置到檢查點完成時的位置
- 一種簡單的想法暫停應用，儲存狀态到檢查點，再重新恢複應用
-
Flink 的改進實作基于Chandy-Lamport 算法的分布式快照
将檢查點的儲存和資料處理分離開，不暫停整個應用
檢查點分界線（Checkpoint Barrier）
- Flink 的檢查點算法用到了一種稱為分界線（barrier）的特殊形式，用來吧一條流上資料按照不同的檢查點分開
- 分界線之前來的資料導緻的狀态更改，都會被包含在目前分界線所屬的檢查點中；而基于分界線之後的資料導緻的所有更改，就會被包含在之後的檢查點中
在以上的基礎上，當資料源收到Checkpoint barrier N 之後會先将自己的狀态儲存，以讀取Kafka資料為例，資料源的狀态就是目前它在Kafka 分區的位置，這個狀态也會寫入到上面提到的表格中。
下遊的Operator 1 會開始運算屬于Checkpoint barrier N 的資料，當Checkpoint barrier N 跟着這些資料流動到Operator 1 之後,Operator 1 也将屬于Checkpoint barrier N 的所有資料都反映在狀态中，當收到Checkpoint barrier N 時也會直接對Checkpoint去做快照。
分布式快照可以用來做狀态容錯，任何一個節點挂掉的時候可以在之前的Checkpoint 中将其恢複。繼續以上Process，當多個Checkpoint 同時進行，Checkpoint barrier N 已經流到Job manager 2，Flink job manager 可以觸發其他的Checkpoint，比如Checkpoint N + 1，Checkpoint N + 2 等等也同步進行，利用這種機制，可以在不阻擋運算的狀況下持續地産生Checkpoint。
完整的表格就可以做容錯。
算子狀态的作用範圍限定為算子任務。這意味着由同一并行任務所處理的所有資料都可以通路到相同的狀态，狀态對于同一任務而言是共享的。算子狀态不能由相同或不同算子的另一個任務通路。鍵控狀态是根據輸入資料流中定義的鍵（key）來維護和通路的。Flink 為每個鍵值維護一個狀态執行個體，并将具有相同鍵的所有資料，都分區到同一個算子任務中，這個任務會維護和處理這個 key 對應的狀态。
Flink 為算子狀态提供三種基本資料結構 …. Keyed State 支援四種資料類型 …
MemoryStateBackend / FsStateBackend / RocksDBStateBackend
JVM Heap 狀态後端會在每一次運算值需要讀取狀态時，用Java object read / writes 進行讀或寫，不會産生較大代價，但當Checkpoint 需要将每一個運算值的本地狀态放入Distributed Snapshots 的時候，就需要進行序列化。
在Runtime 的本地狀态後端讓使用者去讀取狀态的時候會經過磁盤，相當于将狀态維護在磁盤裡，與之對應的代價可能就是每次讀取狀态時，都需要經過序列化和反序列化的過程。當需要進行快照時隻将應用序列化即可，序列化後的資料直接傳輸到中央的共享DFS 中。
Flink實際上是用 Watermarks 來實作Event – Time 的功能。
Watermarks 在Flink 中也屬于特殊事件，其精髓在于當某個運算值收到帶有時間戳“ T ”的 Watermarks 時就意味着它不會接收到新的資料了。使用Watermarks 的好處在于可以準确預估收到資料的截止時間。
舉例，假設預期收到資料時間與輸出結果時間的時間差延遲5 分鐘，那麼Flink 中所有的 Windows Operator 搜尋3 點至4 點的資料，但因為存在延遲需要再多等5分鐘直至收集完4：05 分的資料，此時方能判定4 點鐘的資料收集完成了，然後才會産出3 點至4 點的資料結果。這個時間段的結果對應的就是 Watermarks 的部分。
Watermark 就是觸發前一視窗的“關窗時間”，一旦觸發關門那麼以目前時刻為準在視窗範圍内的所有所有資料都會收入窗中。隻要沒有達到水位那麼不管現實中的時間推進了多久都不會觸發關窗。
Savepoint 跟Checkpoint 的差别在于Checkpoint是Flink 對于一個有狀态應用在運作中利用分布式快照持續周期性的産生Checkpoint，而Savepoint 則是手動産生的Checkpoint，Savepoint 記錄着流式應用中所有運算元的狀态。
Savepoint産生的原理是在Checkpoint barrier 流動到所有的Pipeline 中手動插入進而産生分布式快照，這些分布式快照點即Savepoint。Savepoint 可以放在任何位置儲存，當完成變更時，可以直接從Savepoint 恢複、執行。
Flink vs. Blink
在設計一個低延遲、exactly once、流和批統一的，能夠支撐足夠大體量的複雜計算的引擎時，Spark Streaming 等的劣勢就顯現出來。
Spark Streaming的本質還是一個基于microbatch計算的引擎。這種引擎一個天生的缺點就是每個microbatch的排程開銷比較大，當我們要求的延遲越低，額外的開銷就越大。這就導緻了Spark Streaming實際上不是特别适合于做秒級甚至亞秒級的計算。
Kafka Streams 是從一個日志系統做起來的，它的設計目标是足夠輕量，足夠簡潔易用。這一點很難滿足我們對大體量的複雜計算的需求。
Storm是一個沒有批處理能力的資料流處理器，除此之外Storm隻提供了非常底層的API，使用者需要自己實作很多複雜的邏輯。
簡單地說，Blink就是阿裡巴巴開發的基于開源Flink的企業版計算引擎。如前面所說，雖然Flink在理論模型和架構方面有很多創新，但是在工程實作上還有不少問題。
2015年以來，阿裡巴巴團隊主要專注于解決Blink的runtime穩定性和scalability的問題。
在擁有了穩定的runtime之後，開始專注于增強Blink的易用性 。是以在2016年底到現在，阿裡巴巴團隊大力開發Blink實時計算SQL，通過SQL作為統一API服務于各種複雜業務。
從規範Streaming SQL的語義和标準，到實作UDX、join、aggregation、window等一系列SQL最重要的算子，幾乎一手打造了完整的Streaming SQL，并且将這些工作推回了FLink社群，得到Flink社群的認可。
學習建議
End
Real -Time Is The Future . 我是雲祁，我們下期見啦 ~