1.流計算基礎概念
1.1 Dataflow圖
Dataflow程式描述了資料如何在不同操作之間流動。Dataflow程式通常表示為有向圖。圖中頂點為算子，表示計算；而邊表示資料依賴關系。算子
是Dataflow程式的基本單元，它們從輸入擷取資料，對其進行計算，然後産生資料并發往輸出以供後續處理。沒有輸入端的算子成為資料源，沒有出
輸出端的算子稱為資料彙。一個DataFlow圖至少有一個資料源和一個資料彙。
1.2 資料并行和任務并行
将輸入資料分組，讓同一操作的多個任務并行執行在不同資料子集上，這種并行稱為資料并行。讓不同算子的任務（基于相同或不同的資料）并行計算，
這種并行稱為任務并行。
1.3 資料交換政策
轉發政策：在發送端任務和接受端任務之間一對一地進行資料傳輸。
廣播政策：把每個資料項發往下遊算子的全部并行任務。
基于鍵值的政策：根據某一鍵值屬性對資料分區，并保證鍵值相同的資料項會交有同一任務處理。
1.4 延遲和吞吐
延遲：表示處理一個事件所需時間。本質上，它是從接受事件到在輸出中觀察到事件效果的時間間隔；即從你進入咖啡店門的一刻到你喝到第一口咖啡的時間
吞吐：用來衡量系統處理能力（處理速率）的名額，它告訴我們系統每機關時間可以處理多少事件。
背壓：如果系統持續以力不能及的高速率接受資料，那麼緩沖區可能會用盡，繼而導緻資料丢失，這種情形通常稱為背壓。
1.5 轉換操作
轉換操作是一類“隻過一次”的操作，它們會分别處理每個事件。這些操作逐個讀取事件，對其應用某些轉換産生一條新的輸出流。
1.6 滾動聚合
滾動聚合（如求和、求最小值和求最大值）會根據每個到來的事件持續更新結果。聚合操作都是有狀态的，它們通過将新到來的事件合并到已有狀态來生成更
新後的聚合值。
1.7 時間語義
處理時間：是目前流處理算子所在機器上的本地時鐘時間。
事件時間：是資料流中時間發生的時間，它以附加在資料流中事件的時間戳為依據。
水位線：是一個全局名額，表示我們确信不會再有延遲時間到來的某個時間點。本質上，水位線提供了一個邏輯時鐘，用來通知系統目前的事件時間，當一個
算子接受到時間為T的水位線，就可以認為不會再收到任何時間戳小于或等于T的事件了，水位線對于事件時間視窗還是處理亂序事件的算子都很關鍵。算子一
旦收到某個水位線，就相當于接受到信号：某個特定時間區間的時間戳已經到齊，可以觸發視窗計算或對接受的資料進行排序了。激進的水位線政策保證了
低延遲，但随之而來的是低可信度。保守的水位線，雖然可信度得以保證，但可能會無謂地增加處理延遲。
1.8 狀态
狀态管理：系統需要高效管理狀态并保證它們不受并發更新的影響。
狀态劃分：狀态按照鍵值劃分，并獨立管理每一部分。
狀态恢複：有狀态算子需要保證狀态可以恢複，并且即使出現故障也要確定結果正确。
1.10 任務故障
任務故障有可能發生如下三個步驟的其中之一：
1）接收事件并将它們存在本地緩沖區；
2）選擇性地更新内部狀态；
3）産生輸出記錄。
1.11 結果保障
1) 至多一次：保證每個事件至多被處理一次，換句話說，事件可以随意丢棄，沒有任何機制來保證結果的正确性。這類保障也被稱作“沒有保障”，因為即便
系統丢掉所有事件也能滿足其條件。如果你能接受近似結果并且僅關注怎樣降低延遲，這種保障似乎也可以接受。
2) 至少一次：不丢事件，這類保障稱為至少一次。意味着所有事件最終都會處理，雖然有些可能會處理多次，如果正确性僅依賴資訊的完整度，那重複處理
或許可以接受。采取的辦法是記錄确認，該方法會将所有事件存放在緩沖區中，直到處理管道中所有任務都确認某個事件已經處理完畢才會将事件丢棄。
3) 精确一次：表示不但沒有事件丢棄，而且每個事件對于内部狀态的更新都隻有一次。本質上，精确一次保障意味着應用總會提供正确的結果，就如同故障
從未發生過一般。Flink采用輕量級檢查點機制來實作精确一次結果保障。
4) 端到端的精确一次：在整個資料處理管道上結果都是正确的。
2.Flink的設計理念
Flink 是一個純流式的計算引擎，它的基本資料模型是資料流。流可以是無邊界的無限流，即一般意義上的流處理。也可以是有邊界的有限流，
這樣就是批處理。 是以 Flink 用一套架構同時支援了流處理和批處理。
3.Flink 的特點
1). 流批統一
2). 支援高吞吐、低延遲、高性能的流處理
3). 支援帶有事件時間視窗（Window）操作
4). 支援有狀态計算的Exactly-once語義
5). 支援高度靈活的視窗（Window）操作，支援基于time、count、session視窗操作
6). 支援具有背壓（Backpressure）功能的持續流模型
7). 支援基于輕量級分布式快照（Snapshot）實作的容錯
8). 支援疊代計算
9). Flink 在JVM内部實作了自己的記憶體管理
10).支援程式自動優化，避免特定情況下Shuffle、排序等昂貴操作，中間結果有必要進行緩存
4. Flink 應用場景
4.1 事件驅動型應用
事件驅動型應用是一類具有狀态的應用，該應用會根據事件流中的事件觸發計算、更新狀态或進行外部系統操作。 事件驅動型應用常見于實時計算業務中，
比如：實時推薦、金融反欺詐、實時規則預警等。
4.2 資料分析型應用
資料分析型應用是從原始資料中提取有價值的資訊和名額。
4.3 資料分析型應用vs事件驅動型應用
4.4 資料管道&ETL應用
ETL (Extract-Transform-Load)從資料源抽取/轉換/加載/資料至目的端的過程。ETL資料同步方式分為：增量同步、全量同步、實時同步
5.Flink與其他計算架構對比
| 架構 | 優點 | 缺點 |
|---|---|---|
| Storm | 低延遲 | 吞吐量低、不能保證exactly-once、程式設計API不豐富 |
| Spark Streaming | 吞吐量高、可以保證exactly-once、程式設計API豐富 | 延遲較高 |
| Flink | 低延遲、吞吐量高、可以保證exactly-once、程式設計API豐富 | 快速疊代中，API變化比較快 |
6.Flink與Spark Streaming 角色對比
| Spark Streaming | Flink |
|---|---|
| DStream | DataStream |
| Trasnformation | Trasnformation |
| Action | Sink |
| Task | SubTask |
| Pipeline | Oprator chains |
| DAG | DataFlow Graph |
| Master + Driver | JobManager |
| Work + Executor | TaskManager |
**下面我們就分幾個方面對比兩個架構的主要差別：**
1）架構模型Spark Streaming 在運作時的主要角色包括：Master、Worker、Driver、Executor，Flink 在運作時主要包含：Jobmanager、
Taskmanager和Slot。
2）任務排程Spark Streaming 連續不斷的生成微小的資料批次，建構有向無環圖DAG，Spark Streaming 會依次建立 DStreamGraph、
JobGenerator、JobScheduler。 Flink 根據使用者送出的代碼生成 StreamGraph，經過優化生成 JobGraph，然後送出給 JobManager進行處理，
JobManager 會根據 JobGraph 生成 ExecutionGraph，ExecutionGraph 是 Flink 排程最核心的資料結構，JobManager 根據
ExecutionGraph 對 Job 進行排程。
3）時間機制Spark Streaming 支援的時間機制有限，隻支援處理時間。 Flink 支援了流處理程式在時間上的三個定義：處理時間、事件時間、
注入時間。同時也支援 watermark 機制來處理滞後資料。
4）容錯機制對于 Spark Streaming 任務，我們可以設定 checkpoint，然後假如發生故障并重新開機，我們可以從上次 checkpoint 之處恢複，但是這
個行為隻能使得資料不丢失，可能會重複處理，不能做到恰好一次處理語義。Flink 則使用兩階段送出協定來解決這個問題。
【學習資源】
跟星哥學習Flink
Apache Flink 知其然，知其是以然
Flink 中文社群