核心概念

Flink的核心概念實(shí)際上是流式處理的概念，對(duì)于流式數(shù)據(jù)來說最重要的就是時(shí)間
Time類型Processing TimeEvent TimeIngestion Time
Watermark 這是Flink的一個(gè)難點(diǎn)，在此我想強(qiáng)調(diào)的是很多人翻譯為水印，對(duì)新手有誤導(dǎo)作用，譯做水位更為合理，Watermark實(shí)質(zhì)上就是一個(gè)時(shí)間戳，具體場景可以簡化為如何處理遲到的數(shù)據(jù)，由于在分布式環(huán)境下，會(huì)受到網(wǎng)絡(luò)等影響，數(shù)據(jù)并不能按時(shí)到達(dá)，于是就有了watermark機(jī)制，在此做簡單說明，圖譜每個(gè)節(jié)點(diǎn)我都會(huì)出詳細(xì)文章說明，對(duì)于小白而言，我們首先要了解的是這個(gè)東西到底是干什么的，而不是一頭扎進(jìn)去研究，了解---應(yīng)用--剖析是一個(gè)更合理的路線
Trigger 觸發(fā)器又是什么呢？上文中提到watermark是為了遲到的數(shù)據(jù)，觸發(fā)器實(shí)際上是決定數(shù)據(jù)處理完后什么時(shí)候落地的
State什么是狀態(tài)？這其實(shí)是流式數(shù)據(jù)的特性，計(jì)算數(shù)據(jù)處理的中間結(jié)果，舉個(gè)例子，agg操作中state會(huì)記錄中間聚合的結(jié)果為什么需要有？記錄狀態(tài)的目的是為了恢復(fù)或者重啟任務(wù)，試想一下，流數(shù)據(jù)任務(wù)過程突然掛了怎么辦？有了中間的結(jié)果記錄，不久能夠做到快速恢復(fù)任務(wù)？
區(qū)別（面試常問）核心：
- Flink是標(biāo)準(zhǔn)的流式處理引擎，基于數(shù)據(jù)驅(qū)動(dòng)，把批處理看作流處理的一種特殊情況，Spark恰恰相反，Spark是微批處理模型，把無界的流處理劃分為一個(gè)一個(gè)的階段，縮小為一系列的批次，有一個(gè)形象的比喻，對(duì)于微積分來說，就是劃分為一個(gè)一個(gè)有界的面積進(jìn)行逼近計(jì)算的。
- 架構(gòu)：Spark是Driver master worker executor,Flink則是JobManager TaskManager Client
- 時(shí)間：Spark只支持處理時(shí)間，F(xiàn)link支持處理事件，事件時(shí)間，注入時(shí)間，同時(shí)有watermark處理滯后數(shù)據(jù)
- 容錯(cuò)【大數(shù)據(jù)核心】：Spark無法做到僅消費(fèi)一次，F(xiàn)link可以做到

特性

特性分為兩點(diǎn)，API和架構(gòu)

對(duì)于數(shù)據(jù)處理引擎來說，我們需要解決的問題就是計(jì)算，所以核心就是在哪進(jìn)行計(jì)算？計(jì)算任務(wù)如何找到相應(yīng)的資源，這就是架構(gòu)做的事情，核心就是 資源和任務(wù)的匹配 API
老生常談就是對(duì)數(shù)據(jù)進(jìn)行的操作，畢竟誰不是調(diào)參小能手呢

SQL/Table API :Table API 和 SQL 借助了 Apache Calcite 來進(jìn)行查詢的解析，校驗(yàn)以及優(yōu)化。它們可以與 DataStream 和 DataSet API 無縫集成，并支持用戶自定義的標(biāo)量函數(shù)，聚合函數(shù)以及表值函數(shù)。
DataStream APIDataStream API 為許多通用的流處理操作提供了處理原語。這些操作包括窗口、逐條記錄的轉(zhuǎn)換操作，在處理事件時(shí)進(jìn)行外部數(shù)據(jù)庫查詢等ProcessFunction是 Flink 所提供的最具表達(dá)力的接口。
ProcessFunction 可以處理一或兩條輸入數(shù)據(jù)流中的單個(gè)事件或者歸入一個(gè)特定窗口內(nèi)的多個(gè)事件。它提供了對(duì)于時(shí)間和狀態(tài)的細(xì)粒度控制
- 是否有些深?yuàn)W？這三者的區(qū)別在哪里？在這里可以簡單的認(rèn)為DataStream是ProcessFunction封裝好的黑盒操作，通過提供一些已經(jīng)寫好的算子，用戶直接調(diào)用就可以，但缺點(diǎn)也是顯而易見的，它并不能滿足所有自定義的需求，也就是無法細(xì)粒度的處理，這時(shí)候就需要實(shí)現(xiàn)底層的ProcessFunction
Task 真正干活的單位，經(jīng)過一系列請(qǐng)求過后，Task匹配到資源執(zhí)行，我們知道，大數(shù)據(jù)之一就是體現(xiàn)在數(shù)據(jù)量大，那么對(duì)于巨大的數(shù)據(jù)量來說，就出現(xiàn)了一下幾個(gè)問題
- 如何劃分Task呢？
- Task的多少和什么有關(guān)的？
- Task掛了怎么辦？如何恢復(fù)任務(wù)呢

狀態(tài)

什么是狀態(tài)？這也是初學(xué)者最容易懵逼的地方

狀態(tài)有哪些種類，存在哪？誰又在管理狀態(tài)呢？這就是狀態(tài)管理狀態(tài)存儲(chǔ) 狀態(tài)種類
區(qū)別？種類多種，管理方式多樣，存儲(chǔ)介質(zhì)多種，區(qū)別在哪里？如何選擇？
狀態(tài)的用途呢？存儲(chǔ)干嘛？這就牽扯到上文我們提到了疑問，Task掛了怎么辦呢？這就牽扯到狀態(tài)容錯(cuò)
狀態(tài)容錯(cuò)的機(jī)制是什么？checkpoint?那checkpoint的底層實(shí)現(xiàn)又是什么呢？

libraries

這里的重難點(diǎn)是CEP

什么是CEP? CEP是Flink相當(dāng)nice的功能，它的語義是復(fù)雜事件處理，什么，聽不懂？舉個(gè)例子對(duì)于常見的電商平臺(tái)，是根據(jù)用戶停留時(shí)長，收藏，加購，點(diǎn)擊次數(shù)來判斷用戶是否喜歡這個(gè)東西，那我們?nèi)绾味x滿足這一條件的函數(shù)呢？CEP就派上了用場
Gelly圖處理對(duì)于初學(xué)者來說其實(shí)沒必要涉及

監(jiān)控

對(duì)于大數(shù)據(jù)組件來說，長鏈路如何確保整個(gè)環(huán)節(jié)都沒有問題呢？那就需要監(jiān)控出馬了，點(diǎn)一點(diǎn)，看看web UI就可以更直觀的看到任務(wù)運(yùn)行情況，方便定位數(shù)據(jù)處理過程中的問題

源碼解析(吹牛篇)

眾所周知，面試官最喜歡的就是問你，熟悉某個(gè)技術(shù)的源碼嗎？熟悉源碼對(duì)于面試來說是有相當(dāng)?shù)膬?yōu)勢(shì)，功利性來說，源碼對(duì)于初學(xué)者的用途更多在于面試，在這個(gè)模塊，我將會(huì)列出Flink源碼解析的例子，幫助大家了解源碼【吹牛】

落地實(shí)踐

你會(huì)Spark Flink Hadoop，精通源碼，但一問到如何針對(duì)應(yīng)用場景進(jìn)行方案設(shè)計(jì)，就傻眼了，我就只會(huì)寫SQL，寫scala代碼，統(tǒng)計(jì)指標(biāo)，這遠(yuǎn)遠(yuǎn)是不夠的，技術(shù)是為業(yè)務(wù)服務(wù)的，沒有業(yè)務(wù)也就何談什么技術(shù)？這一章我會(huì)據(jù)一些具體公司實(shí)踐已經(jīng)常見的應(yīng)用場景

總結(jié)

這只是一個(gè)思維導(dǎo)圖，也就是個(gè)啟蒙貼，以疑問為主，主要是為了讓大家思考為什么這樣做？這些年見多很多的面試者，背書很溜，原理也能巴拉巴拉說出來，一問道為什么這樣做就傻眼了，這多半是面經(jīng)看多了，面試造火箭，入職只會(huì)擰螺絲。只有知道why才能更好做到對(duì)技術(shù)的理解

接下來，我會(huì)為大家更新思維導(dǎo)圖知識(shí)點(diǎn)的詳細(xì)擴(kuò)展，希望大家支持丫