從疑問入手了解Flink

Flink網(wǎng)上的資料比起Spark來說是少很多的，我在學習的過程中有一些疑問，然后從疑問入手學習并參考官網(wǎng)文檔和阿里的云棲社區(qū)總結直晨。

批處理和流處理的區(qū)別？

最大的區(qū)別就是二者對流計算認知的不同卵慰。微批處理模式Micro-Batching計算模型可以理解成是"流是批的特例",而純流處理模式Native Streaming則是“批是流的特例”。MapReduce是批處理佛呻、Spark是為微批處理裳朋、Flink是純流式處理。當然Flink支持的批處理是在Native Streaming模式的框架上實現(xiàn)的吓著。

Flink會在什么地方觸發(fā)容錯機制鲤嫡？

在有大量機器的集群中，其中一個節(jié)點計算錯誤或者宕機可能會導致程序執(zhí)行失敗夜矗，或者得到錯誤的結果泛范。目前Flink支持兩種數(shù)據(jù)容錯機制分別是：At Least Once至少消費一次让虐，可能存在重復消費和Exactly Once：精確一次紊撕。同時Flink容錯可以歸納為三種場景

• 系統(tǒng)內(nèi)部容錯時 自身算子

  Flink基于自身的CheckPointing機制實現(xiàn)了剛提到的兩種容錯模式。

• 讀取外部數(shù)據(jù)源時 Source

  一般外部Source都支持 At Least Once模式赡突，如果希望有Exactly Once模式那么就需要對應外部數(shù)據(jù)源有記錄position的支持对扶，可以記錄當前讀取位置，并且支持根據(jù)位置進行讀取類似Kafka惭缰。

• 落地到外部數(shù)據(jù)源時 Sink

  同外部數(shù)據(jù)源Source

Flink什么時候用批處理什么時候用流處理

Flink在網(wǎng)絡傳輸層上有兩種模式：PIPELINED模式即一條數(shù)據(jù)處理完立刻傳輸給下一個節(jié)點處理和BATCH模式即將數(shù)據(jù)緩存起來等所有數(shù)據(jù)處理完后在傳輸?shù)较聜€節(jié)點處理浪南。

我認為一般情況如Map和Count為了更低的延遲和性能都是PIPELINED模式更加高效，但如果要有Sort漱受、Merge络凿、Join這類操作批處理會使用BATCH模式。

Flink中的Table/SQL api到底是如何轉(zhuǎn)換成DataStream和DataSet的呢昂羡？

Flink是使用的Apache開源的Calcite項目做SQL解析的絮记。入門可參考文章

Calcite通過Java CC將SQL解析成AST樹，經(jīng)過校驗虐先、優(yōu)化后進行執(zhí)行怨愤，將物理執(zhí)行計劃轉(zhuǎn)化成Flink可執(zhí)行的程序。

引用云棲社區(qū)的一張圖

image.png

算子如何分類蛹批？

看完官網(wǎng)有很多概念比如Scalar Function撰洗、Table Function篮愉、Aggregate Function、UDF差导、UDTF试躏、UDAF等等，他們的關系需要縷一下柿汛，其實指的都是不同層面上的相同意思冗酿。

可以先把Flink的算子分為單流操作和多流操作。

多流操作 - 可以分為UNION-將字段一致的數(shù)據(jù)流合并和 JOIN-將數(shù)據(jù)類型不一致的的數(shù)據(jù)流連接成一個數(shù)據(jù)流络断。多流操作的目的都是將多個數(shù)據(jù)流合并成一個數(shù)據(jù)流再進行操作裁替。

單流操作 - 按輸入輸出歸類

Flink的時間類型有什么？

image.png

• ProcessingTime 算計開始計算的時間貌笨，F(xiàn)link默認時間類型弱判，效率最高，延遲最低锥惋，因為是算子執(zhí)行的時間所以在分布式數(shù)據(jù)中多次運行會每次都不一致昌腰。
• IngestionTime 是數(shù)據(jù)進入Flink框架時間，相對于ProcessingTime來說較為穩(wěn)定膀跌，因為數(shù)據(jù)源進入只記錄一次遭商。
• EventTime 數(shù)據(jù)在生產(chǎn)后并在進入Flink之前記錄的時間，如果要防止window中的出現(xiàn)的亂序問題用Watermark解決時捅伤，必須設定時間為Event time劫流。