全網第一 | Flink學習面試靈魂40問答案，文末有福利!
來源:王知無
做者:王知無
By
暴走大數據
場景描述：這是一份Flink學習面試指北。看看你搞清楚本身的定位沒有？
關鍵詞：Flink 學習 面試
《大數據技術與架構》和《暴走大數據》讀者擁有本文的優先閱讀權。
轉載請聯繫做者本人。
概念和基礎篇html
1. 簡單介紹一下Flink
Flink核心是一個流式的數據流執行引擎，其針對數據流的分佈式計算提供了數據分佈、數據通訊以及容錯機制等功能。基於流執行引擎，Flink提供了諸多更高抽象層的API以便用戶編寫分佈式任務：
DataSet API， 對靜態數據進行批處理操做，將靜態數據抽象成分佈式的數據集，用戶能夠方便地使用Flink提供的各類操做符對分佈式數據集進行處理，支持Java、Scala和Python。
DataStream API，對數據流進行流處理操做，將流式的數據抽象成分佈式的數據流，用戶能夠方便地對分佈式數據流進行各類操做，支持Java和Scala。
Table API，對結構化數據進行查詢操做，將結構化數據抽象成關係表，並經過類SQL的DSL對關係表進行各類查詢操做，支持Java和Scala。
此外，Flink還針對特定的應用領域提供了領域庫，例如：
Flink ML，Flink的機器學習庫，提供了機器學習Pipelines API並實現了多種機器學習算法。
Gelly，Flink的圖計算庫，提供了圖計算的相關API及多種圖計算算法實現。
2. Flink相比Spark Streaming有什麼區別？
這個問題問的很大，分幾個方面回答：
架構模型上：Spark Streaming 的task運行依賴driver 和 executor和worker，固然driver和excutor還依賴於集羣管理器Standalone或者yarn等。而Flink運行時主要是JobManager、TaskManage和TaskSlot。另一個最核心的區別是：Spark Streaming 是微批處理，運行的時候須要指定批處理的時間，每次運行 job 時處理一個批次的數據；Flink 是基於事件驅動的，事件能夠理解爲消息。事件驅動的應用程序是一種狀態應用程序，它會從一個或者多個流中注入事件，經過觸發計算更新狀態，或外部動做對注入的事件做出反應。
任務調度上：Spark Streaming的調度分爲構建 DGA 圖，劃分 stage，生成 taskset，調度 task等步驟而Flink首先會生成 StreamGraph，接着生成 JobGraph，而後將 jobGraph 提交給 Jobmanager 由它完成 jobGraph 到 ExecutionGraph 的轉變，最後由 jobManager 調度執行。
時間機制上：flink 支持三種時間機制事件時間，注入時間，處理時間，同時支持 watermark 機制處理滯後數據。Spark Streaming 只支持處理時間，Structured streaming則支持了事件時間和watermark機制。
容錯機制上：兩者保證exactly-once的方式不一樣。spark streaming 經過保存offset和事務的方式；Flink 則使用兩階段提交協議來解決這個問題。
3. Flink的組件棧是怎麼樣的
Flink是一個分層架構的系統，每一層所包含的組件都提供了特定的抽象，用來服務於上層組件。Flink分層的組件棧以下圖所示：
Deployment層
該層主要涉及了Flink的部署模式，Flink支持多種部署模式：本地、集羣（Standalone/YARN）、雲（GCE/EC2）。
Runtime層
Runtime層提供了支持Flink計算的所有核心實現，好比：支持分佈式Stream處理、JobGraph到ExecutionGraph的映射、調度等等，爲上層API層提供基礎服務。
API層
API層主要實現了面向無界Stream的流處理和麪向Batch的批處理API，其中面向流處理對應DataStream API，面向批處理對應DataSet API。
Libraries層
該層也能夠稱爲Flink應用框架層，根據API層的劃分，在API層之上構建的知足特定應用的實現計算框架，也分別對應於面向流處理和麪向批處理兩類。面向流處理支持：CEP（復瑣事件處理）、基於SQL-like的操做（基於Table的關係操做）；面向批處理支持：FlinkML（機器學習庫）、Gelly（圖處理）。
4. Flink的基礎編程模型瞭解嗎？
Flink 程序的基礎構建單元是流（streams）與轉換（transformations）。DataSet API 中使用的數據集也是一種流。數據流（stream）就是一組永遠不會中止的數據記錄流，而轉換（transformation）是將一個或多個流做爲輸入，並生成一個或多個輸出流的操做。
執行時，Flink程序映射到 streaming dataflows，由流（streams）和轉換操做（transformation operators）組成。每一個 dataflow 從一個或多個源（source）開始，在一個或多個接收器（sink）中結束。
詳細參考：https://www.cnblogs.com/cxhfuujust/p/10925843.html
5. 說說Flink架構中的角色和做用？
JobManager：
JobManager是Flink系統的協調者，它負責接收Flink Job，調度組成Job的多個Task的執行。同時，JobManager還負責收集Job的狀態信息，並管理Flink集羣中從節點TaskManager。
TaskManager：
TaskManager也是一個Actor，它是實際負責執行計算的Worker，在其上執行Flink Job的一組Task。每一個TaskManager負責管理其所在節點上的資源信息，如內存、磁盤、網絡，在啓動的時候將資源的狀態向JobManager彙報。
Client：
當用戶提交一個Flink程序時，會首先建立一個Client，該Client首先會對用戶提交的Flink程序進行預處理，並提交到Flink集羣中處理，因此Client須要從用戶提交的Flink程序配置中獲取JobManager的地址，並創建到JobManager的鏈接，將Flink Job提交給JobManager。Client會將用戶提交的Flink程序組裝一個JobGraph， 而且是以JobGraph的形式提交的。一個JobGraph是一個Flink Dataflow，它由多個JobVertex組成的DAG。其中，一個JobGraph包含了一個Flink程序的以下信息：JobID、Job名稱、配置信息、一組JobVertex等。
6. 說說Flink中經常使用的算子？用過哪些？
舉一些經常使用的例子：
flink中提供的大量的算子，下面將介紹經常使用的算子操做方式：
map
DataStream --> DataStream：輸入一個參數產生一個參數，map的功能是對輸入的參數進行轉換操做。
flatMap
DataStream --> DataStream：輸入一個參數，產生0、1或者多個輸出，這個多用於拆分操做
filter
DataStream --> DataStream：結算每一個元素的布爾值，並返回爲true的元素
keyBy
DataSteam --> DataStream：邏輯地將一個流拆分紅不相交的分區，每一個分區包含具備相同key的元素，在內部以hash的形式實現的。以key來分組。
注意：如下類型沒法做爲key
POJO類，且沒有實現hashCode函數面試
任意形式的數組類型算法
reduce
KeyedStream --> DataStream：滾動合併操做，合併當前元素和上一次合併的元素結果。
fold
KeyedStream --> DataStream：用一個初始的一個值，與其每一個元素進行滾動合併操做。
aggregation
KeyedStream --> DataStream：分組流數據的滾動聚合操做：min和minBy的區別是min返回的是一個最小值，而minBy返回的是其字段中包含的最小值的元素（一樣元原理適用於max和maxBy）
window
KeyedStream --> DataStream：windows是在一個分區的KeyedStreams中定義的，windows根據某些特性將每一個key的數據進行分組（例如：在5s內到達的數據）。
windowAll
DataStream --> AllWindowedStream：Windows能夠在一個常規的DataStream中定義，Windows根據某些特性對全部的流（例如：5s內到達的數據）。
注意：這個操做在不少狀況下都不是並行操做的，全部的記錄都會彙集到一個windowAll操做的任務中
window apply
WindowedStream --> DataStream
AllWindowedStream --> DataStream：將一個通用的函數做爲一個總體傳遞給window。
window reduce
WindowedStream --> DataStream：給窗口賦予一個reduce的功能，並返回一個reduce的結果。
window fold
WindowedStream --> DataStream：給窗口賦予一個fold的功能，並返回一個fold後的結果。
aggregation on windows
WindowedStream --> DataStream：對window的元素作聚合操做，min和minBy的區別是min返回的是最小值，而minBy返回的是包含最小值字段的元素。（一樣原理適用於max和maxBy）
union
DataStream --> DataStream：對兩個或兩個以上的DataStream作union操做，產生一個包含全部的DataStream元素的新DataStream。
注意：若是將一個DataStream和本身作union操做，在新的DataStream中，將看到每一個元素重複兩次
window join
DataStream，DataStream --> DataStream：根據給定的key和window對兩個DataStream作join操做
window coGroup
DataStream，DataStream --> DataStream：根據一個給定的key和window對兩個DataStream作CoGroups操做。
connect
DataStream，DataStream --> ConnectedStreams：鏈接兩個保持它們類型的數據流。
coMap、coFlatMap
ConnectedStreams --> DataStream：做用於connected數據流上，功能與map和flatMap同樣。
split
DataStream --> SplitStream：根據某些特徵把一個DataStream拆分紅兩個或多個DataStream
select
SplitStream --> DataStream：從一個SplitStream中獲取一個或多個DataStream
iterate
DataStream --> IterativeStream --> DataStream：在流程中建立一個反饋循環，將一個操做的輸出重定向到以前的操做，這對於定義持續更新模型的算法來講頗有意義的。
extract timestamps
DataStream --> DataStream：提取記錄中的時間戳來跟須要事件時間的window一塊兒發揮做用。
參考：https://ci.apache.org/projects/flink/flink-docs-release-1.9/dev/batch/
7. Flink中的分區策略有哪幾種？
GlobalPartitioner: DataStream => DataStream
GlobalPartitioner,GLOBAL分區。將記錄輸出到下游Operator的第一個實例。
ShufflePartitioner: DataStream => DataStream
ShufflePartitioner，SHUFFLE分區。將記錄隨機輸出到下游Operator的每一個實例。
RebalancePartitioner: DataStream => DataStream
RebalancePartitioner,REBALANCE分區。將記錄以循環的方式輸出到下游Operator的每一個實例。
RescalePartitioner: DataStream => DataStream
RescalePartitioner,RESCALE分區。基於上下游Operator的並行度，將記錄以循環的方式輸出到下游Operator的每一個實例。舉例: 上游並行度是2，下游是4，則上游一個並行度以循環的方式將記錄輸出到下游的兩個並行度上;上游另外一個並行度以循環的方式將記錄輸出到下游另兩個並行度上。若上游並行度是4，下游並行度是2，則上游兩個並行度將記錄輸出到下游一個並行度上；上游另兩個並行度將記錄輸出到下游另外一個並行度上。
BroadcastPartitioner: DataStream => DataStream
BroadcastPartitioner,BROADCAST分區。廣播分區將上游數據集輸出到下游Operator的每一個實例中。適合於大數據集Join小數據集的場景。
ForwardPartitioner
ForwardPartitioner,FORWARD分區。將記錄輸出到下游本地的operator實例。ForwardPartitioner分區器要求上下游算子並行度同樣。上下游Operator同屬一個SubTasks。
KeyGroupStreamPartitioner(HASH方式):
KeyGroupStreamPartitioner,HASH分區。將記錄按Key的Hash值輸出到下游Operator實例。
CustomPartitionerWrapper
CustomPartitionerWrapper,CUSTOM分區。經過Partitioner實例的partition方法(自定義的)將記錄輸出到下游。
8. Flink的並行度有了解嗎？Flink中設置並行度須要注意什麼？
Flink程序由多個任務（Source、Transformation、Sink）組成。任務被分紅多個並行實例來執行，每一個並行實例處理任務的輸入數據的子集。任務的並行實例的數量稱之爲並行度。
Flink中人物的並行度能夠從多個不一樣層面設置：
操做算子層面(Operator Level)、執行環境層面(Execution Environment Level)、客戶端層面(Client Level)、系統層面(System Level)。
Flink能夠設置好幾個level的parallelism，其中包括Operator Level、Execution Environment Level、Client Level、System Level
在flink-conf.yaml中經過parallelism.default配置項給全部execution environments指定系統級的默認parallelism；在ExecutionEnvironment裏頭能夠經過setParallelism來給operators、data sources、data sinks設置默認的parallelism；若是operators、data sources、data sinks本身有設置parallelism則會覆蓋ExecutionEnvironment設置的parallelism。
9. Flink支持哪幾種重啓策略？分別如何配置？
重啓策略種類：
固定延遲重啓策略（Fixed Delay Restart Strategy）
故障率重啓策略（Failure Rate Restart Strategy）
無重啓策略（No Restart Strategy）
Fallback重啓策略（Fallback Restart Strategy）
詳細參考：https://www.jianshu.com/p/22409ccc7905
10. Flink的分佈式緩存有什麼做用？
如何使用？
Flink提供了一個分佈式緩存，相似於hadoop，可使用戶在並行函數中很方便的讀取本地文件，並把它放在taskmanager節點中，防止task重複拉取。
此緩存的工做機制以下：程序註冊一個文件或者目錄(本地或者遠程文件系統，例如hdfs或者s3)，經過ExecutionEnvironment註冊緩存文件併爲它起一個名稱。
當程序執行，Flink自動將文件或者目錄複製到全部taskmanager節點的本地文件系統，僅會執行一次。用戶能夠經過這個指定的名稱查找文件或者目錄，而後從taskmanager節點的本地文件系統訪問它。
詳細參考：https://www.jianshu.com/p/7770f9aec75d
11. Flink中的廣播變量，使用廣播變量須要注意什麼事項？
在Flink中，同一個算子可能存在若干個不一樣的並行實例，計算過程可能不在同一個Slot中進行，不一樣算子之間更是如此，所以不一樣算子的計算數據之間不能像Java數組之間同樣互相訪問，而廣播變量Broadcast即是解決這種狀況的。
咱們能夠把廣播變量理解爲是一個公共的共享變量，咱們能夠把一個dataset 數據集廣播出去，而後不一樣的task在節點上都可以獲取到，這個數據在每一個節點上只會存在一份。
https://www.jianshu.com/p/3b6698ec10d8
12. Flink中對窗口的支持包括哪幾種？說說他們的使用場景
詳細參考：https://www.jianshu.com/p/0ad104778bcd
13. Flink 中的 State Backends是什麼？有什麼做用？分紅哪幾類？說說他們各自的優缺點？
Flink流計算中可能有各類方式來保存狀態：
窗口操做apache
使用了KV操做的函數編程
繼承了CheckpointedFunction的函數windows
當開始作checkpointing的時候，狀態會被持久化到checkpoints裏來規避數據丟失和狀態恢復。選擇的狀態存儲策略不一樣，會致使狀態持久化如何和checkpoints交互。後端
Flink內部提供了這些狀態後端:數組
MemoryStateBackend緩存
FsStateBackend網絡
RocksDBStateBackend
若是沒有其餘配置，系統將使用MemoryStateBackend。
詳細參考：https://www.cnblogs.com/029zz010buct/p/9403283.html
14. Flink中的時間種類有哪些？各自介紹一下？
Flink中的時間與現實世界中的時間是不一致的，在flink中被劃分爲事件時間，攝入時間，處理時間三種。
若是以EventTime爲基準來定義時間窗口將造成EventTimeWindow,要求消息自己就應該攜帶EventTime
若是以IngesingtTime爲基準來定義時間窗口將造成IngestingTimeWindow,以source的systemTime爲準。
若是以ProcessingTime基準來定義時間窗口將造成ProcessingTimeWindow，以operator的systemTime爲準。
參考：https://www.jianshu.com/p/0a135391ff41
15. WaterMark是什麼？是用來解決什麼問題？如何生成水印？水印的原理是什麼？
Watermark是Apache Flink爲了處理EventTime 窗口計算提出的一種機制,本質上也是一種時間戳。
watermark是用於處理亂序事件的，處理亂序事件一般用watermark機制結合window來實現。
詳細參考：
https://www.jianshu.com/p/1c2542f11da0
16. Flink的table和SQL熟悉嗎？Table API和SQL中TableEnvironment這個類有什麼做用？
TableEnvironment是Table API和SQL集成的核心概念。它負責：
A)在內部catalog中註冊表
B)註冊外部catalog
C)執行SQL查詢
D)註冊用戶定義（標量，表或聚合）函數
E)將DataStream或DataSet轉換爲表
F)持有對ExecutionEnvironment或StreamExecutionEnvironment的引用
17. Flink如何實現SQL解析的呢？
StreamSQL API的執行原理以下：
一、用戶使用對外提供Stream SQL的語法開發業務應用；
二、用calcite對StreamSQL進行語法檢驗，語法檢驗經過後，轉換成calcite的邏輯樹節點；最終造成calcite的邏輯計劃；
三、採用Flink自定義的優化規則和calcite火山模型、啓發式模型共同對邏輯樹進行優化，生成最優的Flink物理計劃；
四、對物理計劃採用janino codegen生成代碼，生成用低階API DataStream 描述的流應用，提交到Flink平臺執行
詳細參考：https://cloud.tencent.com/developer/article/1471612
進階篇
1. Flink是如何作到批處理與流處理統一的？
Flink設計者認爲：有限流處理是無限流處理的一種特殊狀況，它只不過在某個時間點中止而已。Flink經過一個底層引擎同時支持流處理和批處理。
詳細參考：https://cloud.tencent.com/developer/article/1501348
2. Flink中的數據傳輸模式是怎麼樣的？
在一個運行的application中，它的tasks在持續交換數據。TaskManager負責作數據傳輸。
TaskManager的網絡組件首先從緩衝buffer中收集records，而後再發送。也就是說，records並非一個接一個的發送，而是先放入緩衝，而後再以batch的形式發送。這個技術能夠高效使用網絡資源，並達到高吞吐。相似於網絡或磁盤 I/O 協議中使用的緩衝技術。
詳細參考：https://www.cnblogs.com/029zz010buct/p/10156836.html
3. Flink的容錯機制
Flink基於分佈式快照與可部分重發的數據源實現了容錯。用戶可自定義對整個Job進行快照的時間間隔，當任務失敗時，Flink會將整個Job恢復到最近一次快照，並從數據源重發快照以後的數據。
詳細參考：https://www.jianshu.com/p/1fca8fb61f86
4. Flink中的分佈式快照機制是怎麼樣的
Flink容錯機制的核心就是持續建立分佈式數據流及其狀態的一致快照。這些快照在系統遇到故障時，充當能夠回退的一致性檢查點（checkpoint）。Lightweight Asynchronous Snapshots for Distributed Dataflows 描述了Flink建立快照的機制。此論文是受分佈式快照算法 Chandy-Lamport啓發，並針對Flink執行模型量身定製。
能夠參考：
https://zhuanlan.zhihu.com/p/43536305
https://blog.csdn.net/u014589856/article/details/94346801
5. Flink是如何實現Exactly-once的？
Flink經過狀態和兩次提交協議來保證了端到端的exactly-once語義。
詳細請看：https://www.jianshu.com/p/9d875f6e54f2
6. Flink的Kafka-connector是如何作到向下兼容的呢？
在新的鏈接器中，Flink提供了一個基礎connector模塊，它是實現全部connector的核心模塊，全部的connector都依賴於基礎connector。
Kafka社區也改寫了Java clients底層的網絡客戶端代碼，裏面會自動地判斷鏈接的broker端所支持client請求的最高版本，並自動建立合乎標準的請求。
詳細參考：
https://www.cnblogs.com/Springmoon-venn/p/10690531.html
https://www.cnblogs.com/huxi2b/p/6784795.html
關於flink-kafka-connector的實現參考：
https://www.cnblogs.com/0x12345678/p/10463539.html
7. Flink中的內存管理是如何作的？
Flink 並非將大量對象存在堆上，而是將對象都序列化到一個預分配的內存塊上，這個內存塊叫作 MemorySegment，它表明了一段固定長度的內存（默認大小爲 32KB），也是 Flink 中最小的內存分配單元，而且提供了很是高效的讀寫方法。每條記錄都會以序列化的形式存儲在一個或多個MemorySegment中。
Flink堆內存劃分：
Network Buffers: 必定數量的32KB大小的緩存，主要用於數據的網絡傳輸。在 TaskManager啓動的時候就會分配。默認數量是2048個，能夠經過 taskmanager.network.numberOfBuffers來配置。
Memory Manager Pool:這是一個由MemoryManager管理的，由衆多MemorySegment組成的超大集合。Flink中的算法（如 sort/shuffle/join）會向這個內存池申請MemorySegment，將序列化後的數據存於其中，使用完後釋放回內存池。默認狀況下，池子佔了堆內存的70% 的大小。
Remaining (Free) Heap: 這部分的內存是留給用戶代碼以及TaskManager 的數據結構使用的，能夠把這裏當作的新生代。
Flink大量使用堆外內存。
詳細參考：
https://www.cnblogs.com/ooffff/p/9508271.html
8. Flink中的序列化是如何作的？
Flink實現了本身的序列化框架，Flink處理的數據流一般是一種類型，因此能夠只保存一份對象Schema信息，節省存儲空間。又由於對象類型固定，因此能夠經過偏移量存取。
Java支持任意Java或Scala類型，類型信息由TypeInformation類表示，TypeInformation支持如下幾種類型：
BasicTypeInfo:任意Java 基本類型或String類型。
BasicArrayTypeInfo:任意Java基本類型數組或String數組。
WritableTypeInfo:任意Hadoop Writable接口的實現類。
TupleTypeInfo:任意的Flink Tuple類型(支持Tuple1 to Tuple25)。Flink tuples 是固定長度固定類型的Java Tuple實現。
CaseClassTypeInfo: 任意的 Scala CaseClass(包括 Scala tuples)。
PojoTypeInfo: 任意的 POJO (Java or Scala)，例如，Java對象的全部成員變量，要麼是 public 修飾符定義，要麼有 getter/setter 方法。
GenericTypeInfo: 任意沒法匹配以前幾種類型的類。
針對前六種類型數據集，Flink皆能夠自動生成對應的TypeSerializer，能很是高效地對數據集進行序列化和反序列化。對於最後一種數據類型，Flink會使用Kryo進行序列化和反序列化。每一個TypeInformation中，都包含了serializer，類型會自動經過serializer進行序列化，而後用Java Unsafe接口寫入MemorySegments。以下圖展現 一個內嵌型的Tuple3<integer,double,person> 對象的序列化過程：
操縱二進制數據：
Flink提供瞭如group、sort、join等操做，這些操做都須要訪問海量數據。以sort爲例:首先，Flink會從MemoryManager中申請一批 MemorySegment，用來存放排序的數據。
這些內存會分爲兩部分，一個區域是用來存放全部對象完整的二進制數據。另外一個區域用來存放指向完整二進制數據的指針以及定長的序列化後的key（key+pointer）。將實際的數據和point+key分開存放有兩個目的。
第一，交換定長塊（key+pointer）更高效，不用交換真實的數據也不用移動其餘key和pointer;
第二，這樣作是緩存友好的，由於key都是連續存儲在內存中的，能夠增長cache命中。排序會先比較 key 大小，這樣就能夠直接用二進制的 key 比較而不須要反序列化出整個對象。訪問排序後的數據，能夠沿着排好序的key+pointer順序訪問，經過 pointer 找到對應的真實數據。
詳細參考：https://www.cnblogs.com/ooffff/p/9508271.html
9.Flink中的RPC框架選型是怎麼樣的？
對於Flink中各個組件（JobMaster、TaskManager、Dispatcher等），其底層RPC框架基於Akka實現。若是你對akka不瞭解，那麼參考：https://www.cnblogs.com/letsfly/p/10853341.html
10. Flink在使用Window時出現數據傾斜，你有什麼解決辦法？
注意：這裏window產生的數據傾斜指的是不一樣的窗口內積攢的數據量不一樣，主要是由源頭數據的產生速度致使的差別。
核心思路：1.從新設計key 2.在窗口計算前作預聚合
能夠參考這個：
https://blog.csdn.net/it_lee_j_h/article/details/88641894
11. Flink SQL在使用Groupby時出現熱點數據，如何處理？
對於開源的Flink，能夠參考：https://help.aliyun.com/knowledge_detail/68645.html
12. Flink任務，delay極高，請問你有什麼調優策略？
首先要肯定問題產生的緣由，找到最耗時的點，肯定性能瓶頸點。好比任務頻繁反壓，找到反壓點。主要經過：資源調優、做業參數調優。資源調優便是對做業中的Operator的併發數（parallelism）、CPU（core）、堆內存（heap_memory）等參數進行調優。做業參數調優包括：並行度的設置，State的設置，checkpoint的設置。
13. Flink是如何處理反壓的？和Spark有什麼區別？Storm呢？
參考：https://yq.aliyun.com/articles/64821
14. Operator Chains（算子鏈）這個概念你瞭解嗎？Flink是如何優化的？什麼狀況下Operator纔會chain在一塊兒？
爲了更高效地分佈式執行，Flink會盡量地將operator的subtask連接（chain）在一塊兒造成task。每一個task在一個線程中執行。將operators連接成task是很是有效的優化：它能減小線程之間的切換，減小消息的序列化/反序列化，減小數據在緩衝區的交換，減小了延遲的同時提升總體的吞吐量。
兩個operator chain在一塊兒的的條件：
上下游的並行度一致
下游節點的入度爲1 （也就是說下游節點沒有來自其餘節點的輸入）
上下游節點都在同一個 slot group 中（下面會解釋 slot group）
下游節點的 chain 策略爲 ALWAYS（能夠與上下游連接，map、flatmap、filter等默認是ALWAYS）
上游節點的 chain 策略爲 ALWAYS 或 HEAD（只能與下游連接，不能與上游連接，Source默認是HEAD）
兩個節點間數據分區方式是 forward（參考理解數據流的分區）
用戶沒有禁用 chain
關於源碼篇：建議去讀源碼找答案，若是沒讀過源碼，答案沒有意義。
推薦一個源碼解析電子書。
連接: https://pan.baidu.com/s/1L5KOhly6AvJb6nWBXeHYjQ
提取碼: mwa5
或者長按掃描二維碼下載：
歡迎點贊+收藏
歡迎轉發至朋友圈