一、背景

Apache Flink 和 Apache Storm 是當(dāng)前業(yè)界廣泛使用的兩個(gè)分布式實(shí)時(shí)計(jì)算框架。其中 Apache Storm(以下簡稱“Storm”)在美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算業(yè)務(wù)中已有較為成熟的運(yùn)用，有管理平臺、常用 API 和相應(yīng)的文檔，大量實(shí)時(shí)作業(yè)基于 Storm 構(gòu)建。

Apache Storm參考鏈接：http://storm.apache.org/

[[269062]]

而 Apache Flink(以下簡稱“Flink”)在近期倍受關(guān)注，具有高吞吐、低延遲、高可靠和精確計(jì)算等特性，對事件窗口有很好的支持，目前在美團(tuán)點(diǎn)評實(shí)時(shí)計(jì)算業(yè)務(wù)中也已有一定應(yīng)用。

Apache Flink參考鏈接：https://flink.apache.org/

為深入熟悉了解 Flink 框架，驗(yàn)證其穩(wěn)定性和可靠性，評估其實(shí)時(shí)處理性能，識別該體系中的缺點(diǎn)，找到其性能瓶頸并進(jìn)行優(yōu)化，給用戶提供最適合的實(shí)時(shí)計(jì)算引擎，我們以實(shí)踐經(jīng)驗(yàn)豐富的 Storm 框架作為對照，進(jìn)行了一系列實(shí)驗(yàn)測試 Flink 框架的性能。

計(jì)算 Flink 作為確保“至少一次”和“恰好一次”語義的實(shí)時(shí)計(jì)算框架時(shí)對資源的消耗，為實(shí)時(shí)計(jì)算平臺資源規(guī)劃、框架選擇、性能調(diào)優(yōu)等決策及 Flink 平臺的建設(shè)提出建議并提供數(shù)據(jù)支持，為后續(xù)的 SLA 建設(shè)提供一定參考。

Flink 與 Storm 兩個(gè)框架對比：

二、測試目標(biāo)

評估不同場景、不同數(shù)據(jù)壓力下 Flink 和 Storm 兩個(gè)實(shí)時(shí)計(jì)算框架目前的性能表現(xiàn)，獲取其詳細(xì)性能數(shù)據(jù)并找到處理性能的極限;了解不同配置對 Flink 性能影響的程度，分析各種配置的適用場景，從而得出調(diào)優(yōu)建議。

1、測試場景

1)“輸入-輸出”簡單處理場景

通過對“輸入-輸出”這樣簡單處理邏輯場景的測試，盡可能減少其它因素的干擾，反映兩個(gè)框架本身的性能。

同時(shí)測算框架處理能力的極限，處理更加復(fù)雜的邏輯的性能不會比純粹“輸入-輸出”更高。

2)用戶作業(yè)耗時(shí)較長的場景

如果用戶的處理邏輯較為復(fù)雜，或是訪問了數(shù)據(jù)庫等外部組件，其執(zhí)行時(shí)間會增大，作業(yè)的性能會受到影響。因此，我們測試了用戶作業(yè)耗時(shí)較長的場景下兩個(gè)框架的調(diào)度性能。

3)窗口統(tǒng)計(jì)場景

實(shí)時(shí)計(jì)算中常有對時(shí)間窗口或計(jì)數(shù)窗口進(jìn)行統(tǒng)計(jì)的需求，例如一天中每五分鐘的訪問量，每 100 個(gè)訂單中有多少個(gè)使用了優(yōu)惠等。Flink 在窗口支持上的功能比 Storm 更加強(qiáng)大，API 更加完善，但是我們同時(shí)也想了解在窗口統(tǒng)計(jì)這個(gè)常用場景下兩個(gè)框架的性能。

4)精確計(jì)算場景(即消息投遞語義為“恰好一次”)

Storm 僅能保證“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的消息投遞語義，即可能存在重復(fù)發(fā)送的情況。

有很多業(yè)務(wù)場景對數(shù)據(jù)的精確性要求較高，希望消息投遞不重不漏。Flink 支持“恰好一次” (Exactly Once) 的語義，但是在限定的資源條件下，更加嚴(yán)格的精確度要求可能帶來更高的代價(jià)，從而影響性能。

因此，我們測試了在不同消息投遞語義下兩個(gè)框架的性能，希望為精確計(jì)算場景的資源規(guī)劃提供數(shù)據(jù)參考。

2、性能指標(biāo)

1)吞吐量(Throughput)

• 單位時(shí)間內(nèi)由計(jì)算框架成功地傳送數(shù)據(jù)的數(shù)量，本次測試吞吐量的單位為：條/秒。
• 反映了系統(tǒng)的負(fù)載能力，在相應(yīng)的資源條件下，單位時(shí)間內(nèi)系統(tǒng)能處理多少數(shù)據(jù)。
• 吞吐量常用于資源規(guī)劃，同時(shí)也用于協(xié)助分析系統(tǒng)性能瓶頸，從而進(jìn)行相應(yīng)的資源調(diào)整以保證系統(tǒng)能達(dá)到用戶所要求的處理能力。假設(shè)商家每小時(shí)能做二十份午餐(吞吐量 20 份/小時(shí))，一個(gè)外賣小哥每小時(shí)只能送兩份(吞吐量 2 份/小時(shí))，這個(gè)系統(tǒng)的瓶頸就在小哥配送這個(gè)環(huán)節(jié)，可以給該商家安排十個(gè)外賣小哥配送。

2)延遲(Latency)

• 數(shù)據(jù)從進(jìn)入系統(tǒng)到流出系統(tǒng)所用的時(shí)間，本次測試延遲的單位為：毫秒。
• 反映了系統(tǒng)處理的實(shí)時(shí)性。
• 金融交易分析等大量實(shí)時(shí)計(jì)算業(yè)務(wù)對延遲有較高要求，延遲越低，數(shù)據(jù)實(shí)時(shí)性越強(qiáng)。
• 假設(shè)商家做一份午餐需要 5 分鐘，小哥配送需要 25 分鐘，這個(gè)流程中用戶感受到了 30 分鐘的延遲。如果更換配送方案后延遲變成了 60 分鐘，等送到了飯菜都涼了，這個(gè)新的方案就是無法接受的。

三、測試環(huán)境

為 Storm 和 Flink 分別搭建由 1 臺主節(jié)點(diǎn)和 2 臺從節(jié)點(diǎn)構(gòu)成的 Standalone 集群進(jìn)行本次測試。其中為了觀察 Flink 在實(shí)際生產(chǎn)環(huán)境中的性能，對于部分測內(nèi)容也進(jìn)行了 on Yarn 環(huán)境的測試。

1、集群參數(shù)

2、框架參數(shù)

四、測試方法

1、測試流程

1)數(shù)據(jù)生產(chǎn)

Data Generator 按特定速率生成數(shù)據(jù)，帶上自增的 id 和 eventTime 時(shí)間戳寫入 Kafka 的一個(gè) Topic(Topic Data)。

2)數(shù)據(jù)處理

Storm Task 和 Flink Task (每個(gè)測試用例不同)從 Kafka Topic Data 相同的 Offset 開始消費(fèi)，并將結(jié)果及相應(yīng) inTime、outTime 時(shí)間戳分別寫入兩個(gè) Topic(Topic Storm 和 Topic Flink)中。

3)指標(biāo)統(tǒng)計(jì)

Metrics Collector 按 outTime 的時(shí)間窗口從這兩個(gè) Topic 中統(tǒng)計(jì)測試指標(biāo)，每五分鐘將相應(yīng)的指標(biāo)寫入 MySQL 表中。

Metrics Collector 按 outTime 取五分鐘的滾動(dòng)時(shí)間窗口，計(jì)算五分鐘的平均吞吐(輸出數(shù)據(jù)的條數(shù))、五分鐘內(nèi)的延遲(outTime - eventTime 或 outTime - inTime)的中位數(shù)及 99 線等指標(biāo)，寫入 MySQL 相應(yīng)的數(shù)據(jù)表中。最后對 MySQL 表中的吞吐計(jì)算均值，延遲中位數(shù)及延遲 99 線選取中位數(shù)，繪制圖像并分析。

2、默認(rèn)參數(shù)

• Storm 和 Flink 默認(rèn)均為 At Least Once語義。
  • Storm 開啟 ACK，ACKer 數(shù)量為 1。
  • Flink 的 Checkpoint 時(shí)間間隔為 30 秒，默認(rèn) StateBackend 為 Memory。
• 保證 Kafka 不是性能瓶頸，盡可能排除 Kafka 對測試結(jié)果的影響。
• 測試延遲時(shí)數(shù)據(jù)生產(chǎn)速率小于數(shù)據(jù)處理能力，假設(shè)數(shù)據(jù)被寫入 Kafka 后立刻被讀取，即 eventTime 等于數(shù)據(jù)進(jìn)入系統(tǒng)的時(shí)間。
• 測試吞吐量時(shí)從 Kafka Topic 的最舊開始讀取，假設(shè)該 Topic 中的測試數(shù)據(jù)量充足。

3、測試用例

1)Identity

• Identity 用例主要模擬“輸入-輸出”簡單處理場景，反映兩個(gè)框架本身的性能。
• 輸入數(shù)據(jù)為“msgId, eventTime”，其中 eventTime 視為數(shù)據(jù)生成時(shí)間。單條輸入數(shù)據(jù)約 20 B。
• 進(jìn)入作業(yè)處理流程時(shí)記錄 inTime，作業(yè)處理完成后(準(zhǔn)備輸出時(shí))記錄 outTime。
• 作業(yè)從 Kafka Topic Data 中讀取數(shù)據(jù)后，在字符串末尾追加時(shí)間戳，然后直接輸出到 Kafka。
• 輸出數(shù)據(jù)為“msgId, eventTime, inTime, outTime”。單條輸出數(shù)據(jù)約 50 B。

Identity 流程圖

2)Sleep

• Sleep 用例主要模擬用戶作業(yè)耗時(shí)較長的場景，反映復(fù)雜用戶邏輯對框架差異的削弱，比較兩個(gè)框架的調(diào)度性能。
• 輸入數(shù)據(jù)和輸出數(shù)據(jù)均與 Identity 相同。
• 讀入數(shù)據(jù)后，等待一定時(shí)長(1 ms)后在字符串末尾追加時(shí)間戳后輸出。

Sleep 流程圖

3)Windowed Word Count

• Windowed Word Count 用例主要模擬窗口統(tǒng)計(jì)場景，反映兩個(gè)框架在進(jìn)行窗口統(tǒng)計(jì)時(shí)性能的差異。
• 此外，還用其進(jìn)行了精確計(jì)算場景的測試，反映 Flink 恰好一次投遞的性能。
• 輸入為 JSON 格式，包含 msgId、eventTime 和一個(gè)由若干單詞組成的句子，單詞之間由空格分隔。單條輸入數(shù)據(jù)約 150 B。
• 讀入數(shù)據(jù)后解析 JSON，然后將句子分割為相應(yīng)單詞，帶 eventTime 和 inTime 時(shí)間戳發(fā)給 CountWindow 進(jìn)行單詞計(jì)數(shù)，同時(shí)記錄一個(gè)窗口中最大最小的 eventTime 和 inTime，最后帶 outTime 時(shí)間戳輸出到 Kafka 相應(yīng)的 Topic。
• Spout/Source 及 OutputBolt/Output/Sink 并發(fā)度恒為 1，增大并發(fā)度時(shí)僅增大 JSONParser、CountWindow 的并發(fā)度。
• 由于 Storm 對 window 的支持較弱，CountWindow 使用一個(gè) HashMap 手動(dòng)實(shí)現(xiàn)，F(xiàn)link 用了原生的 CountWindow 和相應(yīng)的 Reduce 函數(shù)。

Windowed Word Count 流程圖

五、測試結(jié)果

① Identity 單線程吞吐量

Identity 單線程吞吐量

• 上圖中藍(lán)色柱形為單線程 Storm 作業(yè)的吞吐，橙色柱形為單線程 Flink 作業(yè)的吞吐。
• Identity 邏輯下，Storm 單線程吞吐為 8.7萬條/秒，F(xiàn)link 單線程吞吐可達(dá)35萬條/秒。
• 當(dāng) Kafka Data 的 Partition 數(shù)為 1 時(shí)，F(xiàn)link 的吞吐約為 Storm 的 3.2 倍;當(dāng)其 Partition 數(shù)為 8 時(shí)，F(xiàn)link 的吞吐約為 Storm 的 4.6 倍。
• 由此可以看出，F(xiàn)link 吞吐約為 Storm 的 3-5 倍。

② Identity 單線程作業(yè)延遲

Identity 單線程作業(yè)延遲

• 采用 outTime - eventTime 作為延遲，圖中藍(lán)色折線為 Storm，橙色折線為 Flink。虛線為 99 線，實(shí)線為中位數(shù)。
• 從圖中可以看出隨著數(shù)據(jù)量逐漸增大，Identity 的延遲逐漸增大。其中 99 線的增大速度比中位數(shù)快，Storm 的 增大速度比 Flink 快。
• 其中 QPS 在 80000 以上的測試數(shù)據(jù)超過了 Storm 單線程的吞吐能力，無法對 Storm 進(jìn)行測試，只有 Flink 的曲線。
• 對比折線最右端的數(shù)據(jù)可以看出，Storm QPS 接近吞吐時(shí)延遲中位數(shù)約 100 毫秒，99 線約 700 毫秒，F(xiàn)link 中位數(shù)約 50 毫秒，99 線約 300 毫秒。Flink 在滿吞吐時(shí)的延遲約為 Storm 的一半。

③ Sleep吞吐量

Sleep 吞吐量

• 從圖中可以看出，Sleep 1 毫秒時(shí)，Storm 和 Flink 單線程的吞吐均在 900 條/秒左右，且隨著并發(fā)增大基本呈線性增大。
• 對比藍(lán)色和橙色的柱形可以發(fā)現(xiàn)，此時(shí)兩個(gè)框架的吞吐能力基本一致。

④ Sleep 單線程作業(yè)延遲(中位數(shù))

Sleep 單線程作業(yè)延遲(中位數(shù))

• 依然采用 outTime - eventTime 作為延遲，從圖中可以看出，Sleep 1 毫秒時(shí)，F(xiàn)link 的延遲仍低于 Storm。

⑤ Windowed Word Count 單線程吞吐量

Windowed Word Count 單線程吞吐量

• 單線程執(zhí)行大小為 10 的計(jì)數(shù)窗口，吞吐量統(tǒng)計(jì)如圖。
• 從圖中可以看出，Storm 吞吐約為 1.2 萬條/秒，F(xiàn)link Standalone 約為 4.3 萬條/秒。Flink 吞吐依然為 Storm 的 3 倍以上。

⑥ Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對比

Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對比

• 由于同一算子的多個(gè)并行任務(wù)處理速度可能不同，在上游算子中不同快照里的內(nèi)容，經(jīng)過中間并行算子的處理，到達(dá)下游算子時(shí)可能被計(jì)入同一個(gè)快照中。這樣一來，這部分?jǐn)?shù)據(jù)會被重復(fù)處理。因此，F(xiàn)link 在 Exactly Once 語義下需要進(jìn)行對齊，即當(dāng)前最早的快照中所有數(shù)據(jù)處理完之前，屬于下一個(gè)快照的數(shù)據(jù)不進(jìn)行處理，而是在緩存區(qū)等待。當(dāng)前測試用例中，在 JSON Parser 和 CountWindow、CountWindow 和 Output 之間均需要進(jìn)行對齊，有一定消耗。為體現(xiàn)出對齊場景，Source/Output/Sink 并發(fā)度的并發(fā)度仍為 1，提高了 JSONParser/CountWindow 的并發(fā)度。具體流程細(xì)節(jié)參見前文 Windowed Word Count 流程圖。
• 上圖中橙色柱形為 At Least Once 的吞吐量，黃色柱形為 Exactly Once 的吞吐量。對比兩者可以看出，在當(dāng)前并發(fā)條件下，Exactly Once 的吞吐較 At Least Once 而言下降了 6.3%。

⑦ Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對比

Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對比

• Storm 將 ACKer 數(shù)量設(shè)置為零后，每條消息在發(fā)送時(shí)就自動(dòng) ACK，不再等待 Bolt 的 ACK，也不再重發(fā)消息，為 At Most Once 語義。
• 上圖中藍(lán)色柱形為 At Least Once 的吞吐量，淺藍(lán)色柱形為 At Most Once 的吞吐量。對比兩者可以看出，在當(dāng)前并發(fā)條件下，At Most Once 語義下的吞吐較 At Least Once 而言提高了 16.8%。

⑧ Windowed Word Count 單線程作業(yè)延遲

Windowed Word Count 單線程作業(yè)延遲

• Identity 和 Sleep 觀測的都是 outTime - eventTime，因?yàn)樽鳂I(yè)處理時(shí)間較短或 Thread.sleep 精度不高，outTime - inTime 為零或沒有比較意義;Windowed Word Count 中可以有效測得 outTime - inTime 的數(shù)值，將其與 outTime - eventTime 畫在同一張圖上，其中 outTime - eventTime 為虛線，outTime - InTime 為實(shí)線。
• 觀察橙色的兩條折線可以發(fā)現(xiàn)，F(xiàn)link 用兩種方式統(tǒng)計(jì)的延遲都維持在較低水平;觀察兩條藍(lán)色的曲線可以發(fā)現(xiàn)，Storm 的 outTime - inTime 較低，outTime - eventTime 一直較高，即 inTime 和 eventTime 之間的差值一直較大，可能與 Storm 和 Flink 的數(shù)據(jù)讀入方式有關(guān)。
• 藍(lán)色折線表明 Storm 的延遲隨數(shù)據(jù)量的增大而增大，而橙色折線表明 Flink 的延遲隨著數(shù)據(jù)量的增大而減小(此處未測至 Flink 吞吐量，接近吞吐時(shí) Flink 延遲依然會上升)。
• 即使僅關(guān)注 outTime - inTime(即圖中實(shí)線部分)，依然可以發(fā)現(xiàn)，當(dāng) QPS 逐漸增大的時(shí)候，F(xiàn)link 在延遲上的優(yōu)勢開始體現(xiàn)出來。

⑨ Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對比

Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對比

• 圖中黃色為 99 線，橙色為中位數(shù)，虛線為 At Least Once，實(shí)線為 Exactly Once。圖中相應(yīng)顏色的虛實(shí)曲線都基本重合，可以看出 Flink Exactly Once 的延遲中位數(shù)曲線與 At Least Once 基本貼合，在延遲上性能沒有太大差異。

⑩ Windowed Word Count Storm At Least Once 與 At Most Once 延遲對比

Windowed Word Count Storm At Least Once 與 At Most Once 延遲對比

• 圖中藍(lán)色為 99 線，淺藍(lán)色為中位數(shù)，虛線為 At Least Once，實(shí)線為 At Most Once。QPS 在 4000 及以前的時(shí)候，虛線實(shí)線基本重合;QPS 在 6000 時(shí)兩者已有差異，虛線略高;QPS 接近 8000 時(shí)，已超過 At Least Once 語義下 Storm 的吞吐，因此只有實(shí)線上的點(diǎn)。
• 可以看出，QPS 較低時(shí) Storm At Most Once 與 At Least Once 的延遲觀察不到差異，隨著 QPS 增大差異開始增大，At Most Once 的延遲較低。

⑪Windowed Word Count Flink 不同 StateBackends 吞吐量對比

Windowed Word Count Flink 不同 StateBackends 吞吐量對比

• Flink 支持 Standalone 和 on Yarn 的集群部署模式，同時(shí)支持 Memory、FileSystem、RocksDB 三種狀態(tài)存儲后端(StateBackends)。由于線上作業(yè)需要，測試了這三種 StateBackends 在兩種集群部署模式上的性能差異。其中，Standalone 時(shí)的存儲路徑為 JobManager 上的一個(gè)文件目錄，on Yarn 時(shí)存儲路徑為 HDFS 上一個(gè)文件目錄。
• 對比三組柱形可以發(fā)現(xiàn)，使用 FileSystem 和 Memory 的吞吐差異不大，使用 RocksDB 的吞吐僅其余兩者的十分之一左右。
• 對比兩種顏色可以發(fā)現(xiàn)，Standalone 和 on Yarn 的總體差異不大，使用 FileSystem 和 Memory 時(shí) on Yarn 模式下吞吐稍高，使用 RocksDB 時(shí) Standalone 模式下的吞吐稍高。

⑫Windowed Word Count Flink 不同 StateBackends 延遲對比

Windowed Word Count Flink 不同 StateBackends 延遲對

• 使用 FileSystem 和 Memory 作為 Backends 時(shí)，延遲基本一致且較低。
• 使用 RocksDB 作為 Backends 時(shí)，延遲稍高，且由于吞吐較低，在達(dá)到吞吐瓶頸前的延遲陡增。其中 on Yarn 模式下吞吐更低，接近吞吐時(shí)的延遲更高。

六、結(jié)論及建議

1、框架本身性能

由①、⑤的測試結(jié)果可以看出，Storm 單線程吞吐約為 8.7 萬條/秒，F(xiàn)link 單線程吞吐可達(dá) 35 萬條/秒。Flink 吞吐約為 Storm 的 3-5 倍。

由②、⑧的測試結(jié)果可以看出，Storm QPS 接近吞吐時(shí)延遲(含 Kafka 讀寫時(shí)間)中位數(shù)約 100 毫秒，99 線約 700 毫秒，F(xiàn)link 中位數(shù)約 50 毫秒，99 線約 300 毫秒。Flink 在滿吞吐時(shí)的延遲約為 Storm 的一半，且隨著 QPS 逐漸增大，F(xiàn)link 在延遲上的優(yōu)勢開始體現(xiàn)出來。

綜上可得，F(xiàn)link 框架本身性能優(yōu)于 Storm。

2、復(fù)雜用戶邏輯對框架差異的削弱

對比①和③、②和④的測試結(jié)果可以發(fā)現(xiàn)，單個(gè) Bolt Sleep 時(shí)長達(dá)到 1 毫秒時(shí)，F(xiàn)link 的延遲仍低于 Storm，但吞吐優(yōu)勢已基本無法體現(xiàn)。

因此，用戶邏輯越復(fù)雜，本身耗時(shí)越長，針對該邏輯的測試體現(xiàn)出來的框架的差異越小。

3、不同消息投遞語義的差異

由⑥、⑦、⑨、⑩的測試結(jié)果可以看出，F(xiàn)link Exactly Once 的吞吐較 At Least Once 而言下降 6.3%，延遲差異不大;Storm At Most Once 語義下的吞吐較 At Least Once 提升 16.8%，延遲稍有下降。

由于 Storm 會對每條消息進(jìn)行 ACK，F(xiàn)link 是基于一批消息做的檢查點(diǎn)，不同的實(shí)現(xiàn)原理導(dǎo)致兩者在 At Least Once 語義的花費(fèi)差異較大，從而影響了性能。而 Flink 實(shí)現(xiàn) Exactly Once 語義僅增加了對齊操作，因此在算子并發(fā)量不大、沒有出現(xiàn)慢節(jié)點(diǎn)的情況下對 Flink 性能的影響不大。Storm At Most Once 語義下的性能仍然低于 Flink。

4、Flink 狀態(tài)存儲后端選擇

Flink 提供了內(nèi)存、文件系統(tǒng)、RocksDB 三種 StateBackends，結(jié)合⑪、⑫的測試結(jié)果，三者的對比如下：

5、推薦使用 Flink 的場景

綜合上述測試結(jié)果，以下實(shí)時(shí)計(jì)算場景建議考慮使用 Flink 框架進(jìn)行計(jì)算：

• 要求消息投遞語義為 Exactly Once的場景;
• 數(shù)據(jù)量較大，要求高吞吐低延遲的場景;
• 需要進(jìn)行狀態(tài)管理或窗口統(tǒng)計(jì)的場景。

七、展望

本次測試中尚有一些內(nèi)容沒有進(jìn)行更加深入的測試，有待后續(xù)測試補(bǔ)充。例如：

• Exactly Once 在并發(fā)量增大的時(shí)候是否吞吐會明顯下降?
• 用戶耗時(shí)到 1ms 時(shí)框架的差異已經(jīng)不再明顯(Thread.sleep() 的精度只能到毫秒)，用戶耗時(shí)在什么范圍內(nèi) Flink 的優(yōu)勢依然能體現(xiàn)出來?

本次測試僅觀察了吞吐量和延遲兩項(xiàng)指標(biāo)，對于系統(tǒng)的可靠性、可擴(kuò)展性等重要的性能指標(biāo)沒有在統(tǒng)計(jì)數(shù)據(jù)層面進(jìn)行關(guān)注，有待后續(xù)補(bǔ)充。

Flink 使用 RocksDBStateBackend 時(shí)的吞吐較低，有待進(jìn)一步探索和優(yōu)化。

關(guān)于 Flink 的更高級 API，如 Table API & SQL 及 CEP 等，需要進(jìn)一步了解和完善。