Flink 基本原理与生产实践分享【入门必读，概念清晰】
Flink 基本原理與生產實踐分享【入門必讀，概念清晰】
https://zh.wikipedia.org/zh-hans/Apache_Flink
Apache Flink是由Apache軟件基金會開發的開源流處理框架，其核心是用Java和Scala編寫的分布式流數據流引擎。Flink以數據并行和流水線方式執行任意流數據程序，Flink的流水線運行時系統可以執行批處理和流處理程序。此外，Flink的運行時本身也支持迭代算法的執行。
Flink提供高吞吐量、低延遲的流數據引擎以及對事件-時間處理和狀態管理的支持。Flink應用程序在發生機器故障時具有容錯能力，并且支持exactly-once語義。程序可以用Java、Scala、Python和SQL等語言編寫，并自動編譯和優化到在集群或云環境中運行的數據流程序。
Flink并不提供自己的數據存儲系統，但為Amazon Kinesis、Apache Kafka、HDFS、Apache Cassandra和ElasticSearch等系統提供了數據源和接收器。
?
概述
Apache Flink的數據流編程模型在有限和無限數據集上提供單次事件（event-at-a-time）處理。在基礎層面，Flink程序由流和轉換組成。 “從概念上講，流是一種（可能永無止境的）數據流記錄，轉換是一種將一個或多個流作為輸入并因此產生一個或多個輸出流的操作”。
Apache Flink包括兩個核心API：用于有界或無界數據流的數據流API和用于有界數據集的數據集API。Flink還提供了一個表API，它是一種類似SQL的表達式語言，用于關系流和批處理，可以很容易地嵌入到Flink的數據流和數據集API中。Flink支持的最高級語言是SQL，它在語義上類似于表API，并將程序表示為SQL查詢表達式。
編程模型和分布式運行時
Flink程序在執行后被映射到流數據流，每個Flink數據流以一個或多個源（數據輸入，例如消息隊列或文件系統）開始，并以一個或多個接收器（數據輸出，如消息隊列、文件系統或數據庫等）結束。Flink可以對流執行任意數量的變換，這些流可以被編排為有向無環數據流圖，允許應用程序分支和合并數據流。
Flink提供現成的源和接收連接器，包括Apache Kafka、Amazon Kinesis、HDFS和Apache Cassandra等。
Flink程序可以作為集群內的分布式系統運行，也可以以獨立模式或在YARN、Mesos、基于Docker的環境和其他資源管理框架下進行部署。
狀態：檢查點、保存點和容錯
Apache Flink具有一種基于分布式檢查點的輕量級容錯機制。檢查點是應用程序狀態和源流中位置的自動異步快照。在發生故障的情況下，啟用了檢查點的Flink程序將在恢復時從上一個完成的檢查點恢復處理，確保Flink在應用程序中保持一次性（exactly-once）狀態語義。檢查點機制暴露應用程序代碼的接口，以便將外部系統包括在檢查點機制中（如打開和提交數據庫系統的事務）。
Flink還包括一種名為保存點的機制，它是一種手動觸發的檢查點。用戶可以生成保存點，停止正在運行的Flink程序，然后從流中的相同應用程序狀態和位置恢復程序。 保存點可以在不丟失應用程序狀態的情況下對Flink程序或Flink群集進行更新。從Flink 1.2開始，保存點還允許以不同的并行性重新啟動應用程序，這使得用戶可以適應不斷變化的工作負載。
-------------------------------------------
下面是小象學院的公開課，原始地址在：http://www.chinahadoop.cn/course/1102
下面是我以前的聽課筆記，花了很多時間自己一個字一個字敲出來的，想想還是分享給大家看看，這樣其他人就不用按暫停來寫聽課筆記了。
原講座時間：2018.1.29? ? 作者：羅江宇
實時計算的一些基本概念
有界數據：在離線層面很常見，讀文件最終會結束就是有界。
實時計算用有界數據計算無界數據，比如幾分鐘的。實時計算就是處理無界數據的。
事件時間：事件產生的時間，一條日志產生的時間
處理時間：實時計算處理時候的時間。
窗口：最近一分鐘或者幾分鐘的數據進行切割聚合，窗口就是切分有界數據。
水位線：水位線以下的事件已經到齊就是一個標準。
觸發器：很多情況就是和窗口結合，觸發窗口里的數據計算
轉換：也稱算子。
at-most-once：數據計算至多一次，會丟數據，很少用。
at-lease-once：最少處理一次，數據傳輸計算肯能會重復計算，有數據重復的情況
at-exactly-once:整一次，會有性能損失。
blink:SQL 方面做了很多改進，還有就是onyarn做了很多改進。
自己公司是Flink千萬級每秒
其他引擎是用微批 ，10秒或者1秒一批，就會影響延遲。
用系統時間計算窗口會丟失一些時間，用eventtime就不會丟。
狀態：機器宕機，可以恢復。一個有狀態的算。
storm：因為進程掛掉，導致狀態丟失。storm已經沒人用了，jstorm只是在其上做一些優化。
支持者at-least-once.
從kafka消費一個數據，再寫到kafka。管理應用有很多為問題，穩定性也有問題，比如進程掛了。
一進來數據就是微批做了切割。低延遲很難達到。ss2.2做了一個融合離線和實時寫法一樣。也會支持全流式。
部署：local IDE底下做一些測試；
cluster:standalone:利用率比較低。
onyarn:提高機器利用率。
datastreamAPI：流式處理的API
datasetAPI：批量處理，是通過流式處理做批處理。
用flink還是流失的多。
CEP：復雜事件處理。有做用戶行為分析，實時分控，提高分控吞吐量，業界有些吞吐量不行。
SQL+CEP和動態CEP，因為用戶寫代碼很復雜。
要先有數據構建一個數據流，一開始上面代碼還少了一塊要構建流失環境變量。選擇是dataset還是datastream.
source:數據源，從kafka讀。讀完后做一些轉化。這里Map這個算子就是1對1的概念。
10秒聚合統計這個id的次數。
整體是來一條數據就流下去，象工廠的流水線一樣。
并行度：多少個線程去跑。
數據切割，一個算子
timewindow:按時間切割，等時間的。這個實際用的最多。
Count ：按事件的個數。
滾動window:時間是對齊的。適合做BI類似的東西。
固定長度：兩個窗口之間無交集數據。一個數據不會同時屬于2個window..可以有時間的也可可以有count的。
?
?
移動窗口，適合求比如最近5分鐘的。也可以做一些監控這些事情。
不支持countWindow，只支持timewindow。
<sesion gap的就可以聚合在一起，認為是一個seeeion，適合線上行為分析。在這個session時間內做了哪些事情。
sesion gap設置太大就不合理，因為都聚合在一起了。
?
3種時間，
eventtime:事件產生的時間，這個一般用的比較多。
ingestion:進入flink的時間（進入souce的時間）,
processingtime:某個算子開始處理的時間（window）
window和eventtime結合起來做事情。
水印：數據處理到那個位置了。水印到了說明之前的數據已經到齊了。
數據沒有到齊，都存起來先。一些中間狀態。
不要做持久化，只要做配置就會被Flink托管。機器掛了，進程結束都可以根據這些狀態恢復。
operatorstate:算子的狀態
keyedstate:存hash的key
checkpoint：把狀態做一些容錯。以前的流式計算為了計算一個state，所有的算子都要停止，獲取一個快照，記錄下狀態。相當于全局同步。Flink是全局異步，只有某個標志到了，會把這個狀態做一個快照。
exavtly-once:假如需要依賴外部的東西需要三方都保證。不光是flink保證，還要souce好sink都要保證。
原理是數據源加一個標志barriers，以這個算子為例所有的barriers都到齊了就會做一個快照。數據源會定時發送barriers進來，就是一個要做快照的標志。
checkpoint主要做內部失敗，從最近的一個成功的checkpoint恢復。
生成t1就會刪除t0，會fork一個版本出來。從t3時刻做了一次恢復從這個點進行一次回溯的計算。
主要是作為外部恢復，原來需要的資源不夠，需要把資源改大一點，需要重啟。
目前官方的需要通過命令去做還沒有一套好的API讓用戶直接調用java代碼或者scala代碼，目前的savepoint還不是很好用。
運行時架構分為三個角色：client,jobmanager,taskmanager.
先生成一個圖，通過AKKA把“”圖“”發給jobmanager（看成一個master，做協調和分發的概念）
jobmanager兩個比較重要的功能：一個是調度，這個節點分配到那個taskmanager.
二是checkpoint的協調器，checkpoint官方也說了是定時注入到source數據源。
taskmanager：真正干事情的，它有task槽的概念。
task槽實際上就是對taskmanager資源的分割。task是跑在task槽上真正在執行任務。
taskmanager也會匯報心跳做一些統計。
taskmanager可以看做一個進程。把內存和CPU分割為3部分。虛線表示一個task,可以看成一個線程。
做一個chain:source和map 這2個算子泡在一個subtask上，這2個是可以串一起。這種是可以做一些優化。
具體組成operatorChain有7個條件。
operator:一些算子
task:真正運行的，就是幾個operator組成一個chain運行在一個task上。
ETL：數據清洗。
數據埋點agent。怎么清洗任務下發給flinkETL。
大應用好管理，也有風險大的topic，某一臺機器一掛影響所有ETL。
小應用每個ETL是隔離不影響，管理成本又增大了，要做監控，只會影響某一個ETL。
實際經驗還是用小應用。
計算規則中心下發給Flink，Flink做一個聚合到es或者druid。druid做一個OLAP引擎，做一些預聚合。再落到dashboard做一個實時的BI和告警。ES：日志檢索的。
這里有個問題就是數據是先在flink聚合再到druid還是只是flink做個ETL，聚合在druid里做，因為他有預聚合。
實際生產下要做個權衡，如果flink不夠強大的話，那么只做個ETL。因為window聚合有些狀態管理比較消耗資源。
或者可以在flink做1分鐘的基本單元的聚合然后再到druid做10分鐘的很大的聚合進行累加也是比較常見的，相當于只做一個基本單元的聚合。因為流式處理window比較大是不可以的，會有內存過大導致各自問題。
CEP只能靜態不能動態加載CEP實時生效。可以做一些匹配告警這種。
實時機器學習做一些推薦，相對CEP還不是很成熟。
source擴大并行度能不能起到作用，有些擴大了沒用。
遇到很多自己寫一些狀態，不符合flink托管的狀態，實際開發中要考慮狀態問題。
異常一捕獲就會丟失數據。不捕獲又不好。需要權衡。
在一定延遲范圍業務方可以接受多少延遲，用多少并行度去處理。
追數據能力：機器宕機，從上一個checkpoint去恢復數據。官方說追數據能力3-5倍（正常數據量的3-5倍）以上。數據完整性和數據延遲。否則如果數據很大需要去掉checkpoint，直接從kafka消費數據開始計算。所以追數據能力不行要做一個權衡。
從運維角度。
如果用戶說丟數據，需要有可以反駁用戶。也可能是發送方延遲，構筑一個簡單的數據質量體系告訴用戶。
flinkUI上的度量比較簡單，需要自己構建收集flink的度量。
flink的日志在大規模生產有問題，日志比較多會把flinkUI 搞掛，需要構建flink日志的滾動。還有用戶會去看。
要做一些flink平臺服務化，應用監控的質量體系。
穩定性保證：純流式的，還有很多問題，很多都是某一個組件抖動，為了保證一致性會有一些問題。
構建SQL平臺：SQL給用戶直接寫SQL。
學習流式計算作為一個函數式編程語言需要scala，面試必須。
Flink核心的通訊是AKKA也就是scala寫的。
paper:論文。
源碼上的接口上有注釋，官方文檔畢竟不完善。
總結
以上是生活随笔為你收集整理的Flink 基本原理与生产实践分享【入门必读，概念清晰】的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 苹果手表多少钱啊？
- 下一篇： Java线上问题排障：Linux内核bu