1. 背景

Apache Flink 和 Apache Storm 是當(dāng)前業(yè)界廣泛使用的兩個(gè)分布式實(shí)時(shí)計(jì)算框架。其中 Apache Storm(以下簡(jiǎn)稱“Storm”)在美團(tuán)點(diǎn)評(píng)實(shí)時(shí)計(jì)算業(yè)務(wù)中已有較為成熟的運(yùn)用(可參考 Storm 的可靠性保證測(cè)試)，有管理平臺(tái)、常用 API 和相應(yīng)的文檔，大量實(shí)時(shí)作業(yè)基于 Storm 構(gòu)建。而 Apache Flink(以下簡(jiǎn)稱“Flink”)在近期倍受關(guān)注，具有高吞吐、低延遲、高可靠和精確計(jì)算等特性，對(duì)事件窗口有很好的支持，目前在美團(tuán)點(diǎn)評(píng)實(shí)時(shí)計(jì)算業(yè)務(wù)中也已有一定應(yīng)用。

[[210570]]

為深入熟悉了解 Flink 框架，驗(yàn)證其穩(wěn)定性和可靠性，評(píng)估其實(shí)時(shí)處理性能，識(shí)別該體系中的缺點(diǎn)，找到其性能瓶頸并進(jìn)行優(yōu)化，給用戶提供最適合的實(shí)時(shí)計(jì)算引擎，我們以實(shí)踐經(jīng)驗(yàn)豐富的 Storm 框架作為對(duì)照，進(jìn)行了一系列實(shí)驗(yàn)測(cè)試 Flink 框架的性能，計(jì)算 Flink 作為確保“至少一次”和“恰好一次”語(yǔ)義的實(shí)時(shí)計(jì)算框架時(shí)對(duì)資源的消耗，為實(shí)時(shí)計(jì)算平臺(tái)資源規(guī)劃、框架選擇、性能調(diào)優(yōu)等決策及 Flink 平臺(tái)的建設(shè)提出建議并提供數(shù)據(jù)支持，為后續(xù)的 SLA 建設(shè)提供一定參考。

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

2. 測(cè)試目標(biāo)

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

2.1 測(cè)試場(chǎng)景

“輸入-輸出”簡(jiǎn)單處理場(chǎng)景

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

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

用戶作業(yè)耗時(shí)較長(zhǎng)的場(chǎng)景

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

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

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

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

Storm 僅能保證“至多一次” (At Most Once) 和“至少一次” (At Least Once) 的消息投遞語(yǔ)義，即可能存在重復(fù)發(fā)送的情況。有很多業(yè)務(wù)場(chǎng)景對(duì)數(shù)據(jù)的精確性要求較高，希望消息投遞不重不漏。Flink 支持“恰好一次” (Exactly Once) 的語(yǔ)義，但是在限定的資源條件下，更加嚴(yán)格的精確度要求可能帶來(lái)更高的代價(jià)，從而影響性能。因此，我們測(cè)試了在不同消息投遞語(yǔ)義下兩個(gè)框架的性能，希望為精確計(jì)算場(chǎng)景的資源規(guī)劃提供數(shù)據(jù)參考。

2.2 性能指標(biāo)

吞吐量(Throughput)

單位時(shí)間內(nèi)由計(jì)算框架成功地傳送數(shù)據(jù)的數(shù)量，本次測(cè)試吞吐量的單位為：條/秒。

反映了系統(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è)外賣小哥配送。

延遲(Latency)

數(shù)據(jù)從進(jìn)入系統(tǒng)到流出系統(tǒng)所用的時(shí)間，本次測(cè)試延遲的單位為：毫秒。

反映了系統(tǒng)處理的實(shí)時(shí)性。

金融交易分析等大量實(shí)時(shí)計(jì)算業(yè)務(wù)對(duì)延遲有較高要求，延遲越低，數(shù)據(jù)實(shí)時(shí)性越強(qiáng)。

假設(shè)商家做一份午餐需要 5 分鐘，小哥配送需要 25 分鐘，這個(gè)流程中用戶感受到了 30 分鐘的延遲。如果更換配送方案后延遲變成了 60 分鐘，等送到了飯菜都涼了，這個(gè)新的方案就是無(wú)法接受的。

3. 測(cè)試環(huán)境

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

3.1 集群參數(shù)

3.2 框架參數(shù)

4. 測(cè)試方法

4.1 測(cè)試流程

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

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

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

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

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

Metrics Collector 按 outTime 的時(shí)間窗口從這兩個(gè) Topic 中統(tǒng)計(jì)測(cè)試指標(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ù)表中。最后對(duì) MySQL 表中的吞吐計(jì)算均值，延遲中位數(shù)及延遲 99 線選取中位數(shù)，繪制圖像并分析。

4.2 默認(rèn)參數(shù)

Storm 和 Flink 默認(rèn)均為 At Least Once 語(yǔ)義。

Storm 開(kāi)啟 ACK，ACKer 數(shù)量為 1。

Flink 的 Checkpoint 時(shí)間間隔為 30 秒，默認(rèn) StateBackend 為 Memory。

保證 Kafka 不是性能瓶頸，盡可能排除 Kafka 對(duì)測(cè)試結(jié)果的影響。

測(cè)試延遲時(shí)數(shù)據(jù)生產(chǎn)速率小于數(shù)據(jù)處理能力，假設(shè)數(shù)據(jù)被寫入 Kafka 后立刻被讀取，即 eventTime 等于數(shù)據(jù)進(jìn)入系統(tǒng)的時(shí)間。

測(cè)試吞吐量時(shí)從 Kafka Topic 的最舊開(kāi)始讀取，假設(shè)該 Topic 中的測(cè)試數(shù)據(jù)量充足。

4.3 測(cè)試用例

Identity

Identity 用例主要模擬“輸入-輸出”簡(jiǎn)單處理場(chǎng)景，反映兩個(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。

Sleep

Sleep 用例主要模擬用戶作業(yè)耗時(shí)較長(zhǎng)的場(chǎng)景，反映復(fù)雜用戶邏輯對(duì)框架差異的削弱，比較兩個(gè)框架的調(diào)度性能。

輸入數(shù)據(jù)和輸出數(shù)據(jù)均與 Identity 相同。

讀入數(shù)據(jù)后，等待一定時(shí)長(zhǎng)(1 ms)后在字符串末尾追加時(shí)間戳后輸出

Windowed Word Count

Windowed Word Count 用例主要模擬窗口統(tǒng)計(jì)場(chǎng)景，反映兩個(gè)框架在進(jìn)行窗口統(tǒng)計(jì)時(shí)性能的差異。

此外，還用其進(jìn)行了精確計(jì)算場(chǎng)景的測(cè)試，反映 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 對(duì) window 的支持較弱，CountWindow 使用一個(gè) HashMap 手動(dòng)實(shí)現(xiàn)，F(xiàn)link 用了原生的 CountWindow 和相應(yīng)的 Reduce 函數(shù)。

5. 測(cè)試結(jié)果

5.1 Identity 單線程吞吐量

上圖中藍(lán)色柱形為單線程 Storm 作業(yè)的吞吐，橙色柱形為單線程 Flink 作業(yè)的吞吐。

Identity 邏輯下，Storm 單線程吞吐為 8.7 萬(wàn)條/秒，F(xiàn)link 單線程吞吐可達(dá) 35 萬(wàn)條/秒。

當(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 倍。

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

采用 outTime – eventTime 作為延遲，圖中藍(lán)色折線為 Storm，橙色折線為 Flink。虛線為 99 線，實(shí)線為中位數(shù)。

從圖中可以看出隨著數(shù)據(jù)量逐漸增大，Identity 的延遲逐漸增大。其中 99 線的增大速度比中位數(shù)快，Storm 的 增大速度比 Flink 快。

其中 QPS 在 80000 以上的測(cè)試數(shù)據(jù)超過(guò)了 Storm 單線程的吞吐能力，無(wú)法對(duì) Storm 進(jìn)行測(cè)試，只有 Flink 的曲線。

對(duì)比折線最右端的數(shù)據(jù)可以看出，Storm QPS 接近吞吐時(shí)延遲中位數(shù)約 100 毫秒，99 線約 700 毫秒，F(xiàn)link 中位數(shù)約 50 毫秒，99 線約 300 毫秒。Flink 在滿吞吐時(shí)的延遲約為 Storm 的一半。

5.3 Sleep 吞吐量

從圖中可以看出，Sleep 1 毫秒時(shí)，Storm 和 Flink 單線程的吞吐均在 900 條/秒左右，且隨著并發(fā)增大基本呈線性增大。

對(duì)比藍(lán)色和橙色的柱形可以發(fā)現(xiàn)，此時(shí)兩個(gè)框架的吞吐能力基本一致。

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

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

5.5 Windowed Word Count 單線程吞吐量

單線程執(zhí)行大小為 10 的計(jì)數(shù)窗口，吞吐量統(tǒng)計(jì)如圖。

從圖中可以看出，Storm 吞吐約為 1.2 萬(wàn)條/秒，F(xiàn)link Standalone 約為 4.3 萬(wàn)條/秒。Flink 吞吐依然為 Storm 的 3 倍以上。

5.6 Windowed Word Count Flink At Least Once 與 Exactly Once 吞吐量對(duì)比

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

上圖中橙色柱形為 At Least Once 的吞吐量，黃色柱形為 Exactly Once 的吞吐量。對(duì)比兩者可以看出，在當(dāng)前并發(fā)條件下，Exactly Once 的吞吐較 At Least Once 而言下降了 6.3%

5.7 Windowed Word Count Storm At Least Once 與 At Most Once 吞吐量對(duì)比

Storm 將 ACKer 數(shù)量設(shè)置為零后，每條消息在發(fā)送時(shí)就自動(dòng) ACK，不再等待 Bolt 的 ACK，也不再重發(fā)消息，為 At Most Once 語(yǔ)義。

上圖中藍(lán)色柱形為 At Least Once 的吞吐量，淺藍(lán)色柱形為 At Most Once 的吞吐量。對(duì)比兩者可以看出，在當(dāng)前并發(fā)條件下，At Most Once 語(yǔ)義下的吞吐較 At Least Once 而言提高了 16.8%

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

Identity 和 Sleep 觀測(cè)的都是 outTime – eventTime，因?yàn)樽鳂I(yè)處理時(shí)間較短或 Thread.sleep() 精度不高，outTime – inTime 為零或沒(méi)有比較意義;Windowed Word Count 中可以有效測(cè)得 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ù)量的增大而減小(此處未測(cè)至 Flink 吞吐量，接近吞吐時(shí) Flink 延遲依然會(huì)上升)。

即使僅關(guān)注 outTime – inTime(即圖中實(shí)線部分)，依然可以發(fā)現(xiàn)，當(dāng) QPS 逐漸增大的時(shí)候，F(xiàn)link 在延遲上的優(yōu)勢(shì)開(kāi)始體現(xiàn)出來(lái)。

5.9 Windowed Word Count Flink At Least Once 與 Exactly Once 延遲對(duì)比

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

5.10 Windowed Word Count Storm At Least Once 與 At Most Once 延遲對(duì)比

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

5.11 Windowed Word Count Flink 不同 StateBackends 吞吐量對(duì)比

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

5.12 Windowed Word Count Flink 不同 StateBackends 延遲對(duì)比

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

6. 結(jié)論及建議

6.1 框架本身性能

• 由 5.1、5.5 的測(cè)試結(jié)果可以看出，Storm 單線程吞吐約為 8.7 萬(wàn)條/秒，F(xiàn)link 單線程吞吐可達(dá) 35 萬(wàn)條/秒。Flink 吞吐約為 Storm 的 3-5 倍。
• 由 5.2、5.8 的測(cè)試結(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)勢(shì)開(kāi)始體現(xiàn)出來(lái)。

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

6.2 復(fù)雜用戶邏輯對(duì)框架差異的削弱

• 對(duì)比 5.1 和 5.3、5.2 和 5.4 的測(cè)試結(jié)果可以發(fā)現(xiàn)，單個(gè) Bolt Sleep 時(shí)長(zhǎng)達(dá)到 1 毫秒時(shí)，F(xiàn)link 的延遲仍低于 Storm，但吞吐優(yōu)勢(shì)已基本無(wú)法體現(xiàn)。

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

6.3 不同消息投遞語(yǔ)義的差異

• 由 5.6、5.7、5.9、5.10 的測(cè)試結(jié)果可以看出，F(xiàn)link Exactly Once 的吞吐較 At Least Once 而言下降 6.3%，延遲差異不大;Storm At Most Once 語(yǔ)義下的吞吐較 At Least Once 提升 16.8%，延遲稍有下降。
• 由于 Storm 會(huì)對(duì)每條消息進(jìn)行 ACK，F(xiàn)link 是基于一批消息做的檢查點(diǎn)，不同的實(shí)現(xiàn)原理導(dǎo)致兩者在 At Least Once 語(yǔ)義的花費(fèi)差異較大，從而影響了性能。而 Flink 實(shí)現(xiàn) Exactly Once 語(yǔ)義僅增加了對(duì)齊操作，因此在算子并發(fā)量不大、沒(méi)有出現(xiàn)慢節(jié)點(diǎn)的情況下對(duì) Flink 性能的影響不大。Storm At Most Once 語(yǔ)義下的性能仍然低于 Flink。

6.4 Flink 狀態(tài)存儲(chǔ)后端選擇

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

6.5 推薦使用 Flink 的場(chǎng)景

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

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

7. 展望

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

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

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

• Flink 使用 RocksDBStateBackend 時(shí)的吞吐較低，有待進(jìn)一步探索和優(yōu)化。
• 關(guān)于 Flink 的更高級(jí) API，如 Table API & SQL 及 CEP 等，需要進(jìn)一步了解和完善。