《Confluent-美股公司研究報告-整合Flink后承接關鍵負載IT預算份額有望持續提升-240530（56頁）.pdf》由會員分享，可在線閱讀，更多相關《Confluent-美股公司研究報告-整合Flink后承接關鍵負載IT預算份額有望持續提升-240530（56頁）.pdf（56頁珍藏版）》請在三個皮匠報告上搜索。

1、 本報告由中信建投證券股份有限公司在中華人民共和國（僅為本報告目的，不包括香港、澳門、臺灣）提供。在遵守適用的法律法規情況下，本報告亦可能由中信建投（國際）證券有限公司在香港提供。同時請務必閱讀正文之后的免責條款和聲明。證券研究報告證券研究報告美股公司深度美股公司深度 軟件與服務軟件與服務 整合整合 Flink 后承接關鍵負載，后承接關鍵負載，IT 預算份預算份額有望持續提升額有望持續提升 核心觀點核心觀點 Confluent 受益于 AI，Gen AI 應用直接與 C 端交互，尤其是音頻交互下，延遲敏感度大幅提升，流處理將成為 AI 應用的重要框架。流處理框架競爭方面，Kafka 具備充分競

2、爭力。傳統消息系統受通信協議、架構等影響難以兼顧實時性和擴展性，新興框架Pulsar、Redpanda 等在大規模場景下延遲穩定性不足，而 Kakfa 則有望承接行業主要的場景需求。成長邏輯方面，流處理增長驅動力是對批處理的替代+模型推理/自動駕駛等新場景的增長。過去Confluent 的問題在于 1）Kafka 主要聚焦流存儲/傳輸，而引入Flink 流計算引擎，Confluent 能夠提供更多創造業務價值的用例，并驅動用戶加速部署/遷移，Gen AI 的用例具備推動流處理滲透的影響力。2）流處理在多數企業內部并非關鍵系統，IT 預算占比較低，在 IT 支出提升后，托管帶來的運維成本節約能夠

3、覆蓋工程師成本，企業才會轉向上云，Confluent 的網絡效應才會體現。摘要摘要 Q：為什么需要流處理？為什么需要流處理？A：傳統的數據基礎設施與消息系統難以應對大數據處理需求傳統的數據基礎設施與消息系統難以應對大數據處理需求 1）傳統數據集成方案難以兼顧擴展性和實時性，ETL 擴展性較好，但其批處理模式無法滿足實時性。而 ESB 中心化架構導致難以擴展；2）傳統消息系統無法滿足高吞吐：受通信協議/架構設計制約，AcitveMQ/RabbitMQ 無法滿足高吞吐。Q：為什么需要：為什么需要 Kakfa？A：Pulsar 的主要的主要優勢在于擴展性強優勢在于擴展性強，但，但未滿足未滿足用戶核心

4、需求用戶核心需求。Pulsar 通過存算分離架構解耦存儲與計算，實現靈活性與按需擴展，但對于大多數用例來說，可擴展性不是問題。且存算分離架構引入額外復雜度，導致大規模場景下延遲不穩定。Pulsar 的真正問題是并未提供功能以滿足用戶的核心需求，如缺乏消息隊列支持，事件流支持，不支持一次性交付和處理語義等，其 Kakfa Connect 功能完整度不高，這導致 Pulsar 較難滿足客戶現有的業務需求。首次評級首次評級 買入買入 崔世峰崔世峰 SAC 編號:S1440521100004 SFC 編號:BUI663 許悅許悅 SAC 編號:S1440523030001 發布日期：2024 年 05

5、 月 30 日 當前股價：29.83 美元 目標價格 6 個月：40 美元 主要數據主要數據 股票價格絕對股票價格絕對/相對市場表現（相對市場表現（%）1 個月 3 個月 12 個月 5.68/-2.12-9.13/-14.91 4.40/-30.32 12 月最高/最低價（美元）39.27/16.28 總股本（萬股）31,783.50 流通股本（萬股）24,465.78 總市值（億美元）95.83 流通市值（億美元）95.83 近 3 月日均成交量（萬）394.10 主要股東 Eric Vishria 15.30%股價表現股價表現 相關研究報告相關研究報告 -43%-23%-3%17%37%

6、57%2023/5/262023/6/262023/7/262023/8/262023/9/262023/10/262023/11/262023/12/262024/1/262024/2/262024/3/262024/4/26Confluent納斯達克綜指Confluent(CFLT.O)美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。Redpanda 性能優勢被夸大。性能優勢被夸大。Redpanda 聲稱由于其每核線程架構、使用 C+編寫以及針對高性能 NVMe驅動器優化的存儲設計，其性能優于 Kafka。但深入分析其基準測試可以發現：1）Redpanda 測試跑

7、分中包含定制化配置，且對 Kafka 的部分配置并不公平。2）Redpanda 大規模/長期運行場景下性能不穩定。3）對于很多工作負載支持度不如 Kafka?？傮w而言，Redpanda 的性能對工作負載的敏感性高，并非全面優于 Kafka。競爭邏輯方面：競爭邏輯方面：較 CSP，Confluent 提供數據管道+流處理一體化解決方案，過往客戶主要基于AWS/Azure/GCP 進行流處理主要原因是工作負載占比不高，單獨托管必要性不強且跨云數據傳輸成本高。24 年以來，EU 監管壓力下數據傳輸費逐步取消，且 Confluent 整合 Flink 拓展應用場景，Confluent 發展趨勢向好。具

8、體來看，具體來看，CSP 傾向于提供組件而非完整解決方案，缺乏系統性優化易導致低效率。傾向于提供組件而非完整解決方案，缺乏系統性優化易導致低效率。AWS/Azure/GCP 的流處理組件主要負責將數據導入 AWS 數據存儲，并由數倉/對象存儲等進一步處理/存儲數據，這一過程缺乏系統優化，在大規模場景下運維成本高昂?？蛻舻倪x擇反映大部分企業流處理用例占比低，非核心場景，企業愿意承擔額外運維開支。數據傳輸成本高昂，但監管壓力推動數據傳輸成本高昂，但監管壓力推動 CSP 逐步逐步取消取消數據傳輸費，利好數據傳輸費，利好 Confluent 等中立服務商。等中立服務商。Confluent 作為中立服務

9、提供商的問題在于傳輸成本，對于中大型企業而言，數據自數據管道、流處理后導入 Snowflake/Databricks/MongoDB 等存儲，若下游存儲與流處理層分屬不同云服務商/可用區，客戶面臨大額數據傳輸成本。歐盟數據法案于 2024 年 1 月生效，該法案要求 CSP 消除其自身云服務與競爭云服務之間“有效切換的障礙”。為回應監管，Google、Amazon、Azure 已對數據傳輸費用做出妥協。我們認為，監管壓力下，數據傳輸的高昂成本將逐步消除，利好 Confluent 等中立服務商。成長邏輯方面，成長邏輯方面，流處理增長驅動力是對批處理的替代流處理增長驅動力是對批處理的替代+模型推理

10、模型推理/自動駕駛等新場景的增長。自動駕駛等新場景的增長。行業競爭格局并非導致 Confluent 商業化落后的原因，CSP 主要以組件方式提供服務，缺乏系統優化。相反，Confluent 的問題在于 1）Kafka 主要聚焦流存儲/傳輸，而引入 Flink 流計算引擎，Confluent 能夠提供更多創造業務價值的用例，并驅動用戶加速部署/遷移，我們認為 Gen AI 的用例具備推動流處理滲透的影響力。2）流處理在多數企業內部并非關鍵系統，IT 預算占比較低，在 IT 支出提升后，托管帶來的運維成本節約能夠覆蓋工程師成本，企業才會轉向上云，Confluent 的網絡效應才會體現。估值與建議：

11、估值與建議：Confluent 當前對應 25 年 EV/Rev 比例為 6.66?？杀裙局?，MongoDB、Snowflake、Datadog、Cloudflare 等 EV/Rev 在 10 x 以上，而 Informatica、Dynatrace、Zscaler、Gitlab 等估值在 7x10 x 區間，Elastic、Confluent、DoubleVerify 較上述公司估值存在更明顯的折價。我們預計 Confluent 2024-26 年營業收入分別達 9.8、12.4、15.8 億美元，同比增速分別為 25.8%/27.3%/26.8%。Non-GAAP 凈利潤分別達 1.0

12、、1.5、2.2 億美元，同比增速分別達 629.9%/54.9%/46.2%，對應 Non-GAAP 凈利率為 9.8%/11.9%/13.7%?？傮w來看，我們認為 Confluent在流處理領域地位穩固，Gen AI 用例/自動駕駛對流處理的驅動有望逐步兌現，結合估值與業務增長情況，當前估值具備吸引力，首次覆蓋 Confluent 并給予“買入”評級。aVbUcWeUeZ8XaYfVaQbPbRpNmMpNqMjMmMqNfQsRpP8OpPwPMYsPmMuOnNmQ 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。目錄目錄 投資要點：Gen AI 用例推動流處

13、理負載滲透，競爭壁壘穩固.1 公司簡介：企業級數據流平臺領導者.3 引言：為什么需要 Kafka？.4 1.傳統消息中間件難以兼顧擴展性和吞吐量.7 2.Pulsar 并未及時把握 Kafka 的功能缺失，Kafka 引入 Kora 架構后補齊短板.19 3.Redpanda 的性能優勢被夸大，其基準測試并不具有普遍意義.26 Flink：垂直拓展至流計算領域，向流數據處理平臺演化.39 成長邏輯：數字原生企業仍具增長空間，Flink 有望驅動用戶滲透.45 盈利預測：預計 24-26 年收入維持 Mid-teens 增長，Non-GAAP 利潤率穩步提升.48 估值.49 投資評價和建議.5

14、0 風險分析.50 報表預測.51 1 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。投資要點：投資要點：Gen AI 用例推動流處理負載滲透，競爭壁壘穩固用例推動流處理負載滲透，競爭壁壘穩固 市場關注市場關注 Confluent 主要是主要是 AI 受益邏輯受益邏輯，其核心邏輯為：，其核心邏輯為：1）AI/ML 等延遲敏感型場景滲透。等延遲敏感型場景滲透。AI 應用/推理對于延遲敏感，對于流處理/存儲的需求是原生的，AI 會加速數字原生應用的占比，進而提升流處理的 IT 支出份額，如 OpenAI 等大客戶有望形成示范效應。2）對批處理系統的部分替代。）對批處理系

15、統的部分替代。Flink 流批一體有望獲取增量 IT預算份額，目前流處理市場僅占數據處理10%份額，批處理系統占70%份額，仍有大量遺留系統有機會遷移。圖圖 1:現代數據管理技術?，F代數據管理技術棧 數據來源：Emergence1，中信建投 經過深入的研究，經過深入的研究，我們認為 1）Confluent 確實受益于確實受益于 AI，其下游場景包括網絡游戲實時分析、金融交易欺詐監測、廣告/社交媒體的實時推薦等，而 AI 推理對延遲較為敏感，屬于流處理的核心場景，但過去 AI/ML 的應用量較低，主要應用于 OCR、人臉識別等場景，且這些場景一定程度上可接受秒級延遲。然而 Gen AI 應用直接

16、與 C 端交互，尤其是音頻交互下，延遲敏感度大幅提升，流處理也成為 AI 應用的重要框架。2）Confluent/Kafka具備充分競爭力具備充分競爭力。傳統消息中間件系統 ActiveMQ/RabbitMQ 等受通信協議、架構等影響難以兼顧實時性和擴展性，新型框架 Pulsar、Redpanda 等在大規模場景下的延遲穩定性不足，主要針對垂直場景做定制優化，應用場景不夠廣，而 Kakfa 則有望承接行業主要的場景需求。競爭邏輯方面：競爭邏輯方面：較 CSP，Confluent 提供數據管道+流處理一體化解決方案，過往客戶主要基于 AWS/Azure/GCP進行流處理主要原因是工作負載占比不高

17、，單獨托管必要性不強且跨云數據傳輸成本高。24 年以來，EU 監管壓力下數據傳輸費逐步取消，且 Confluent 整合 Flink 拓展應用場景，Confluent 發展趨勢向好。具體來看，具體來看，CSP 傾向于提供組件而非完整解決方案，缺乏系統性優化易導致低效率。傾向于提供組件而非完整解決方案，缺乏系統性優化易導致低效率。AWS/Azure/GCP 的流處理組件主要負責將數據導入 AWS 數據存儲，并由數倉/對象存儲等進一步處理/存儲數據，這一過程缺乏系統優化，在大規模場景下運維成本高昂?？蛻舻倪x擇反映大部分企業流處理用例占比低，非核心場 1 https:/ 美股公司深度報告 Confl

18、uent 請務必閱讀正文之后的免責條款和聲明。景，企業愿意承擔額外運維開支。數據傳輸成本高昂，但監管壓力推動數據傳輸成本高昂，但監管壓力推動 CSP 逐步逐步取消取消數據傳輸費，利好數據傳輸費，利好 Confluent 等中立服務商。等中立服務商。Confluent 作為中立服務提供商的問題在于傳輸成本，對于中大型企業而言，數據自數據管道、流處理后導入 Snowflake/Databricks/MongoDB 等存儲，若下游存儲與流處理層分屬不同云服務商/可用區，客戶面臨大額數據傳輸成本。歐盟數據法案于 2024 年 1 月生效，該法案要求 CSP 消除其自身云服務與競爭云服務之間“有效切換的

19、障礙”。為回應監管，Google、Amazon、Azure 已對數據傳輸費用做出妥協。我們認為，監管壓力下，數據傳輸的高昂成本將逐步消除，利好 Confluent 等中立服務商。成長邏輯方面，成長邏輯方面，流處理增長驅動力是對批處理的替代流處理增長驅動力是對批處理的替代+模型推理模型推理/自動駕駛等新場景的增長。自動駕駛等新場景的增長。行業競爭格局并非導致 Confluent 商業化落后的原因，CSP 主要以組件方式提供服務，缺乏系統優化。相反，Confluent 的問題在于 1）Kafka 主要聚焦流存儲/傳輸，而引入 Flink 流計算引擎，Confluent 能夠提供更多創造業務價值的用

20、例，并驅動用戶加速部署/遷移，我們認為 Gen AI 的用例具備推動流處理滲透的影響力。2）流處理在多數企業內部并非關鍵系統，IT 預算占比較低，在 IT 支出提升后，托管帶來的運維成本節約能夠覆蓋工程師成本，企業才會轉向上云，Confluent 的網絡效應才會體現。估值與建議：估值與建議：Confluent 當前對應 25 年 EV/Rev 比例為 6.66?？杀裙局?，MongoDB、Snowflake、Datadog、Cloudflare 等明顯存在更高估值倍數（EV/Rev），而 Informatica、Dynatrace、Zscaler、Gitlab 等估值水位更低，Elastic、

21、Confluent、DoubleVerify 較上述公司估值存在更明顯的折價。我們預計公司 FY2024-26 年營業收入分別達 9.7、12.3、15.6 億美元，同比增速分別為 25.0%/26.9%/26.5%。Non-GAAP 凈利潤分別達 1.0、1.5、2.2 億美元，同比增速分別達 629.9%/54.9%/46.2%，對應 Non-GAAP 凈利率為 9.8%/11.9%/13.7%?？傮w來看，我們認為Confluent 在流處理領域地位穩固，Gen AI 用例/自動駕駛對流處理的驅動有望逐步兌現，結合估值與業務增長情況，當前估值具備吸引力，首次覆蓋 Confluent 并給予

22、“買入”評級。風險提示風險提示：市場競爭加劇市場競爭加劇風險風險：隨著數據流處理和事件驅動架構的普及，更多競爭對手可能涌現，如Apache Pulsar 等開源項目，以及已建立企業如 IBM、AWS 等提供的同類服務，可能侵蝕市場份額。技術創新技術創新風險：風險：技術快速迭代，若 Confluent 不能持續創新保持其技術領先地位，可能會被擁有更先進技術的競爭對手超越。許可證變更風險許可證變更風險：作為基于開源項目 Apache Kafka 的公司，Confluent 對其社區版的許可證條款進行的任何更改都可能影響用戶基礎和市場接受度。數據安全與隱私數據安全與隱私：處理大量數據流時，數據保護法

23、規如 GDPR 等的合規成本及潛在違規罰款構成風險。經濟周期性波動經濟周期性波動風險風險：全球經濟衰退或行業特定的經濟周期可能減少企業 IT 支出，影響 Confluent 的業務需求。3 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。公司簡介：企業級數據流平臺領導者公司簡介：企業級數據流平臺領導者 基于基于 Apache Kafka 打造打造企業級數據流平臺，提供實時數據訪問解決方案。企業級數據流平臺，提供實時數據訪問解決方案。Confluent 于 2014 年由 Apache Kafka 的原創者成立，旨在構建云原生數據流平臺，圍繞實時消息流連接公司應用程序，

24、幫助企業做出及時決策。公司擁有兩大數據流平臺，支持部署在本地和云環境中。其中，Confluent Platform（CP）是一款企業級自管理軟件，可部署在客戶的本地、私有云和公有云環境中。Confluent Cloud（CC）是一款全托管云原生 SaaS 產品，可在 AWS、GCP、Azure 等云提供商上使用。公司主要收入來自兩大數據流平臺的訂閱。2023 年訂閱收入達 7.29億美元，同比+36.3%，占比 94%，其中 Confluent Cloud 占比 45%，Confluent Platform 占比 49%；服務收入達0.48 億美元，同比-6.1%，占比 6%。圖圖 2:Con

25、fluent 業務結構業務結構 數據來源：Confluent，中信建投證券 圖圖 3:1Q20-4Q23 營業收入及同比增長（億美元；營業收入及同比增長（億美元；%）圖圖 4:1Q20-4Q23 收入結構（收入結構（%）數據來源：Confluent，中信建投證券 數據來源：Confluent，中信建投證券 0%10%20%30%40%50%60%70%80%0.000.501.001.502.002.502020Q12020Q22020Q32020Q42021Q12021Q22021Q32021Q42022Q12022Q22022Q32022Q42023Q12023Q22023Q32023Q4

26、營業收入%yoy0%10%20%30%40%50%60%70%80%90%100%Confluent CloudConfluent Platform服務收入 4 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 5:1Q20-4Q23 Confluent Cloud 收入及同比增長（億美收入及同比增長（億美元；元；%）圖圖 6:1Q20-4Q23 Confluent Platform 收入及同比增長（億收入及同比增長（億美元；美元；%）數據來源：Confluent，中信建投證券 數據來源：Confluent，中信建投證券 引言：為什么需要引言：為什么需要 Kafk

27、a？Apache Kafka 是一個分布式實時消息是一個分布式實時消息-訂閱系統，用于低延遲地收集和傳遞大量日志數據訂閱系統，用于低延遲地收集和傳遞大量日志數據2，兼顧實時性和，兼顧實時性和高吞吐。高吞吐。Kafka 誕生于 2009 年，正值大數據快速發展的時期，傳統的數據基礎設施與消息系統難以應對大數據處理需求：1）傳統數據集成方案難以兼顧擴展性和實時性：）傳統數據集成方案難以兼顧擴展性和實時性：傳統 ETL 擴展性較好，但其批處理模式無法滿足實時性，而越來越多的分析任務需要實時數據，秒級、分鐘級響應需求提升。而 ESB 中心化架構導致難以擴展；2）傳統消息系統無法滿足高吞吐：）傳統消息系

28、統無法滿足高吞吐：大數據集成場景要求將海量日志數據快速傳輸到大數據平臺，對吞吐量需求提升，但 AcitveMQ/RabbitMQ 無法滿足高吞吐。圖圖 7:傳統數倉傳統數倉/數據遷移工具存在的問題數據遷移工具存在的問題 數據來源：Confluent，中信建投 2 日志可分為兩類：1）用戶活動數據，如：登錄、頁面瀏覽量、點擊、點贊、分享、評論、查詢搜索等；2）運營數據，如：服務調用棧、調用延遲、錯誤以及系統指標（CPU、內存、網絡、磁盤利用率）0%50%100%150%200%250%300%0.000.200.400.600.801.001.202020Q12020Q22020Q32020Q4

29、2021Q12021Q22021Q32021Q42022Q12022Q22022Q32022Q42023Q12023Q22023Q32023Q4Confluent Cloud%yoy0%5%10%15%20%25%30%35%40%45%50%0.000.200.400.600.801.001.202020Q12020Q22020Q32020Q42021Q12021Q22021Q32021Q42022Q12022Q22022Q32022Q42023Q12023Q22023Q32023Q4Confluent Platform%yoy 5 美股公司深度報告 Confluent 請務必閱讀正文之后的

30、免責條款和聲明。消息隊列的興起是由于實時處理需求提升，而傳統批處理系統難以滿足。消息隊列的興起是由于實時處理需求提升，而傳統批處理系統難以滿足。典型的批處理系統包括 Hadoop，Hadoop的批處理性質不適合實時數據處理和分析，原因在于HDFS通過冗余存儲實現高可用性但導致高延遲。通過冗余存儲實現高可用性但導致高延遲。HDFS 將大文件切分成較小的數據塊并分散存儲在不同的節點上。HDFS 采用最終一致性模型，即系統不保證在數據變動后能夠立即看到更新的結果，但最終會達到一致的狀態。當客戶端進行數據追加或重新寫入數據塊，修改需要通知到各個相關 DataNode，并在這些節點上執行相應的寫操作。該

31、更新操作是異步進行的，期間涉及網絡通信和跨節點的數據復制，無法滿足數據的即時更新和查詢。圖圖 8:HDFS 冗余儲存冗余儲存 數據來源：Hadoop documentation3，中信建投 MapReduce在實時處理方面存在缺陷。在實時處理方面存在缺陷。MapReduce 的計算嚴格按照流程，先進行數據映射、洗牌（Shuffle），最終進行規約，這會產生大量的中間數據，尤其是 Shuffle 階段涉及大量的數據讀寫操作和傳輸。由中間數據產生的數據延遲開銷成為制約 MapReduce 性能的瓶頸，導致無法提供毫秒級或秒級響應。此外，MapReduce 的輸入數據集是靜態的，這意味著它不適合處理

32、動態變化的數據流。3 https:/hadoop.apache.org/docs/r1.2.1/index.html 6 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 9:MapReduce 用于單詞計數的案例用于單詞計數的案例 數據來源：Cornell Univerisity，中信建投 批處理系統無法滿足實時性需求的根本原因是設計哲學批處理系統無法滿足實時性需求的根本原因是設計哲學/需求場景不同。需求場景不同。批處理系統的工作方式是收集一批數據后統一進行處理，而不是對數據進行連續或即時處理。換言之，批處理系統在既有約束下選擇犧牲延遲換取高吞吐，而流處理則相對

33、優化延遲，犧牲一定吞吐量。解決實時性后，核心瓶頸轉變為擴展性，主要由于單機性能存在上限，而需求增長速度遠快于性能增長，因此需要引入分布式架構滿足擴展性。Kakfa 通過分區/副本機制實現水平擴展。據 Building LinkedIns Real-time Activity Data Pipeline，當時 LinkedIn 采用的數據傳輸管道包括處理用戶活動數據的批處理系統、處理運營數據的系統。用戶活動數據系統用于將數據加載到數據倉庫/Hadoop 集群中，其存在一些問題：1）缺乏實時數據）缺乏實時數據訪問：訪問：批處理系統往往按小時/天的周期處理數據；2）傳輸復雜度過高：）傳輸復雜度過高：

34、點對點多系統傳輸的耦合度和復雜度太高。成本方面，XML 類型需要定制解析工作，計算和維護成本較高。服務器指標和日志系統的問題在于：1）指標維護繁瑣：指標維護繁瑣：添加和維護指標的過程需要手工進行；2）監控數據無法實時處理：）監控數據無法實時處理：由于系統的批處理性質，監控數據無法實時處理。因此，LinkedIn 工程團隊在數據生產者和數據使用者間引入中間層，將點對點的“N-to-N”結構轉換為“N-to-1-to-N”結構，實現解耦并降低復雜性。圖圖 10:傳統數據傳輸方式采用點對點的數據管道，復雜度和耦合度高傳統數據傳輸方式采用點對點的數據管道，復雜度和耦合度高 數據來源：Linkedin，

35、中信建投 7 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 11:Kafka 使數據源、消費者與統一日志集成從而實現解耦使數據源、消費者與統一日志集成從而實現解耦 數據來源：Linkedin，中信建投 滿足擴展性和實時性后，流處理框架初步形成，邁向業務落地的關鍵方向轉變為吞吐量，滿足擴展性和實時性后，流處理框架初步形成，邁向業務落地的關鍵方向轉變為吞吐量，即在業務允許的可用性、延遲下盡可能擴大給定時間/資源的消息傳輸，這也是 Kakfa、Pulsar、ActiveMQ、RabbitMQ 等框架的核心競爭要素。1.傳統消息中間件難以兼顧擴展性和吞吐量傳統消息中間

36、件難以兼顧擴展性和吞吐量 ActiveMQ 誕生于 2003 年，是最早支持 Java Message Service(JMS)協議的開源消息隊列軟件之一。此前的商業 MQ 產品價格較高，且生態系統封閉，缺乏互操作性，這限制了不同系統間的集成能力。JMS 的出現為標準消息協議和消息服務提供一組通用接口，兩個應用程序可借助其 API 進行異步通信。ActiveMQ 完全支持 JMS規范，能夠與其他遵循 JMS 的系統無縫集成。ActiveMQ 降低消息隊列技術的門檻，特別是對中小企業而言，它提供低成本、高性能的解決方案，促進消息中間件的滲透。圖圖 12:ActiveMQ 架構架構 圖圖 13:A

37、ctiveMQ 集群集群 數據來源：Performance Evaluation and Comparison of Distributed Messaging Using Message Oriented Middleware，中信建投 數據來源：A JEE-based Architecture for Distributed Multi-Domain Resource Accounting，中信建投 但 ActiveMQ 存在以下問題：通過消息持久化保證可靠性但造成吞吐量瓶頸。通過消息持久化保證可靠性但造成吞吐量瓶頸。ActiveMQ 在處理大量消息時可能會遇到吞吐量瓶頸，其默認的消息存儲

38、引擎 KahaDB 使用 B-Tree 索引來管理持久化消息的存儲和檢索，但帶來相應的性能損失。首先，B-Tree 索引需要占用一定的內存資源。其次，對于每個新消息，KahaDB 需要更 8 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。新其 B-Tree 索引。頻繁的索引更新操作會導致磁盤 I/O 增加，進而影響整體吞吐量。再次，B-Tree 索引在長時間運行后可能會因為刪除操作而造成磁盤空間碎片4，需要定期進行索引整理以保持性能。圖圖 14:B-Tree 索引索引 數據來源：fuxi，中信建投 消息分片功能缺失導致擴展能力弱。消息分片功能缺失導致擴展能力弱。Ac

39、tiveMQ 默認沒有提供消息分片或水平擴展方案，這意味著當單一節點的處理能力達到極限時，用戶必須自行設計和實施集群方案以實現負載均衡和消息的水平擴展。這對于處理海量消息和高并發請求時帶來一定的挑戰。ActiveMQ 由于設計之初軟件架構主要是中心化、集中式，未考慮到大數據時代的分布式需求，而隨著軟件的迭代，添加新的核心功能如水平擴展機制可能會觸及系統的基礎架構，引入復雜的技術債務。JMS 缺少直接支持消息批量發送的缺少直接支持消息批量發送的 API5。在 JMS 框架的設計理念中，直接集成消息批量發送的便捷 API并未被納入核心規范，這反映出 JMS 聚焦于確?；A通信的穩健性而非特定性能優

40、化策略的標準化。因此，在默認配置下，每條消息的發送都遵循標準的網絡交互流程，從建立連接到數據傳輸，直至確認接收，每一步都是獨立完成。這可能會對系統的性能和吞吐量造成影響。但 JMS 允許開發者自定義消息批量發送邏輯。圖圖 15:JMS 框架框架 圖圖 16:AMQP 框架框架 數據來源：javatpoint6，中信建投 數據來源：wallarm7，中信建投 4 當消息被消費掉，相應索引條目被標記為已刪除或從索引中移除，但分配給該條目的磁盤空間不會立即被回收利用，尤其是在 B-Tree 中，為保持索引的平衡性和查詢效率，直接重新分配空間給新條目可能不是最高效的選擇。因此，隨著時間的推移，磁盤上就

41、會出現越來越多不連續的可用空間。這種碎片化導致需要寫入新數據時，系統可能需要在多個不連續的區域分配空間，這顯著增加磁盤頭的移動次數，降低磁盤讀寫的速度。5 Kafka:a Distributed Messaging System for Log Processing 6 https:/ 7 https:/ 9 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。表表 1:JMS vs AMQP 項目項目 AMQP 0-9-1 協議協議 JMS 定義 線級協議 Java API 跨平臺 是 否 跨語言 是 否 消息收發模型 4 種消息收發模型：Direct Exchange

42、 Fanout Exchange Topic Exchange Header Exchange 2 種消息收發模型：P2P Pub/Sub 消息類型 二進制數據類型 5 種消息類型：Text message Object message Bytes message Stream message Map message 消息流 Producer 將消息發送到 Exchange，Exchange 將消息路由到 Queue，Consumer 從 Queue 中消費消息。Producer 將消息發送到 Queue 或者 Topic，Consumer 從 Queue 或 Topic 中消費消息。資料來源

43、：阿里云8，中信建投 RabbitMQ 基于基于 AMQP，具備靈活強大的功能集、高可靠性和跨語言特性。，具備靈活強大的功能集、高可靠性和跨語言特性。JMS 只針對于 Java 應用，其他語言開發的程序無法使用 JMS 完成信息交換。2003 年 John OHara 提出 AMQP，相比于 JMS，基于 AMQP協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品、不同開發語言等條件的限制9。RabbitMQ 是基于 AMQP 協議的消息隊列產品，可跨語言通信，增強不同系統之間的互操作性。AMQP 功能集豐富，支持消息確認、事務、持久化、消息路由等，使得 RabbitMQ 能夠為

44、用戶提供多樣的消息傳遞服務。相比于 Kafka，RabbitMQ 支持死信隊列、延遲隊列、優先隊列、多租戶、推模式消費等。此外，AMQP 協議支持多種消息模型，使得 RabbitMQ 可采用靈活的消息處理方式。8 https:/ 9 例如可以使用 Java 的 AMQP Provider，同時使用一個 Python 的 Producer 加一個 Ruby 的 Consumer 10 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 17:RabbitMQ 架構圖架構圖 數據來源：騰訊云，中信建投 但 RabbitMQ 的缺點在于：AMQP 的復雜性限制吞吐量。的復

45、雜性限制吞吐量。由于 AMQP 協議相對較為復雜，相較于某些輕量級協議：1）報文格式：報文格式：AMQP 定義了一種豐富的二進制編碼格式來表示消息和控制命令，這種格式包括頭信息、負載內容以及可能的元數據字段。允許實現諸如消息路由、事務、消息確認等高級功能，導致消息傳輸前需要更多的處理和編解碼工作，增加網絡帶寬占用和 CPU 消耗。2）握手過程：）握手過程：AMQP 連接建立階段包含完整的 TLS/SSL 握手（若啟用加密）和 AMQP 信道的協商過程，這需要多次網絡往返才能完成，對于頻繁建立短連接的場景來說，這會降低整體的處理效率和吞吐量。3）可靠性機制：）可靠性機制：AMQP 提供多種消息確

46、認和可靠性保障機制，比如持久化消息存儲、事務性發布、消息確認等，這些特性確保消息在傳輸過程中的高可靠性，即使在系統故障情況下也盡可能地保證消息不丟失。但相應地，服務器端和客戶端需要額外邏輯來處理消息確認、重試、死信隊列等操作，這會增加系統開銷。傳統拷貝方式保證高可用但犧牲延遲。傳統拷貝方式保證高可用但犧牲延遲。從 I/O 的角度，為確保高可用性，傳統拷貝方式需要四次拷貝（2次 DMA+2 次 CPU）：1）將磁盤上的數據拷貝到操作系統內核的緩沖區；2）將內核緩沖區的數據拷貝到用戶的緩沖區；3）將已經拷貝到用戶的緩沖區里的數據，再拷貝到內核的 socket 的緩沖區；4）將內核的 socket

47、緩沖區里的數據拷貝到網卡的緩沖區。該過程有助于確保數據在傳輸過程中的一致性和可靠性，但每次數據拷貝和上下文切換（用戶態與內核態之間的轉換）都會帶來時間開銷，尤其是第二次和第三次拷貝，需要 CPU 的直接介入，顯著增加數據從磁盤到網絡傳輸的總延遲。11 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 18:RabbitMQ 采用傳統拷貝方式采用傳統拷貝方式 數據來源：CSDN10，中信建投 Erlang 語言增加二次開發難度。語言增加二次開發難度。Erlang 使用虛擬機（BEAM）內部輕量級線程，而非操作系統進程，這種進程內存占用小，創建和切換速度快。Erlan

48、g 進程間的通信通過消息傳遞實現，而非共享內存，避免數據競爭和死鎖，簡化并發編程的復雜性。此外，作為函數式編程語言，Erlang 強調不可變性和狀態的局部性。這有助于避免副作用和狀態變化，減少對鎖和同步機制的依賴，對并發編程是一個重要優勢?；?Erlang 語言本身的高并發優勢，RabbitMQ 在當時性能較好，能達到微秒級延時。但 Erlang 語言比較小眾11，學習曲線陡峭，因此在開發成本方面有一些劣勢。Erlang 語言的性能優勢明顯。語言的性能優勢明顯。創建 2500 個 Erlang 進程的時間在 1s 以內，進程增加至 3 萬個時，時間增加至 3s；而 Java 和 C#創建小批

49、量進程大約耗費 300s，且無法創建超過 2000 個進程。消息發送方面，對于多達 3 萬個進程，在兩個 Erlang 進程之間發送消息的時間約為 0.8s。對于 C#，每條消息大約需要 50s，最大進程數為 1800。Java 對于 100 個進程，每條消息大約需要 50s，進程上升至 1000 個時，每條消息發送時間上升至 10ms。10 https:/ 11 據 2024Q4 TIOBE 索引，Erlang 在排名前 50 的最受歡迎編程語言中排名第 46。12 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 19:Erlang、Java、C#語言進程創建

50、時間對比語言進程創建時間對比 圖圖 20:Erlang、Java、C#消息發送時間對比消息發送時間對比 數據來源：Concurrency Oriented Programming in Erlang，中信建投 數據來源：Concurrency Oriented Programming in Erlang，中信建投 表表 2:ActiveMQ、RabbitMQ、Kafka 對比對比 ActiveMQ RabbitMQ Kafka 架構 P2P&Pub/Sub P2P P2P&Pub/Sub 通信協議 OpenWire(主要)、AMQP、MQTT、STOMP 等-OpenWire 是為性能優化而設

51、計的，它的二進制格式更緊湊，旨在最小化網絡傳輸的開銷。-默認設置下不支持批量消息直接發送 API，導致每條消息單獨發送導致更多的網絡 I/O 操作和資源開銷，影響整體性能。AMQP(主要)、STOMP、MQTT 等-AMQP 的復雜性限制吞吐量。的復雜性限制吞吐量。AMQP 編碼格式包括頭信息、負載內容、元數據字段。允許實現消息路由、事務、消息確認等功能，導致額外的處理和編解碼工作，增加網絡帶寬占用和 CPU 消耗。-復雜握手過程。AMQP 連接建立需安全握手，及信道協商，這涉及多次網絡往返，導致額外資源開銷，增加延遲?；赥CP的一組自定義二進制協議-Kafka 使用自定義的二進制協議，該協

52、議簡潔、高效，專為大數據量傳輸優化，減少序列化和反序列化的開銷。-Kafka 支持消息批次處理，生產者可以將多條消息打包成一個批次發送，減少網絡請求次數和相關的鎖操作。語言 Java 語言，支持如 JMS 標準。-Java 特性在高并發環境下資源消耗和性能存在一定缺陷。例如 Java 應用程序在進行垃圾回收（GC）時，可能會引起短暫的性能波動，引發內存瓶頸。-在高并發場景下，創建大量線程會導致較高的內存消耗（每個線程都有占用堆?？臻g），且線程間的上下文切換也會消耗 CPU 資源。Erlang 語言，在 BEAM 虛擬機運行。-Erlang 使用虛擬機內部輕量級線程，內存占用小，創建/切換速度快

53、，進程間通信通過消息傳遞實現，而非共享內存，避免數據競爭和死鎖，簡化并發編程的復雜性。-但 Erlang 語言比較小眾，學習曲線陡峭，因此在開發成本方面有一些劣勢。Scala/Java 語言，在 Java 虛擬機運行。-Kafka 采用異步 I/O 模型，減少 I/O操作的阻塞時間，提高吞吐量。-Scala 提供豐富的庫（如 Akka 框架）來支持高并發和并行處理，使得 Kafka 能更高效地管理線程/任務，避免傳統 Java 多線程模型中的線程競爭/上下文切換開銷。其他優化包括零拷貝、內存映射文件、分區。13 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。消息順序

54、性12 支持消息順序性，在點對點隊列模型中，消息是按照發布的順序被消費，但若涉及到多個消費者或者消息被分發到多個隊列，則難以維持全局順序。支持消息順序性，但默認不保證全局消息順序?？梢酝ㄟ^限制條件實現順序性，但會制約效率。支持分區內消息順序性。通過劃分消息分區，不同分區的消息不按照順序送達/消費，但同一分區內的消息符合順序。消息持久化和事務支持 支持消息持久化和事務支持-默認 KahaDB 運行在單機上，不支持分片和水平擴展。需要開發者自定義。適合中小數據場景。適合中小數據場景。-默認消息存儲引擎 KahaDB 使用B-Tree 索引，而 B-Tree 索引需要占用一定的內存資源，且頻繁更新導

55、致I/O 瓶頸。另外，長期允許導致磁盤碎片，增加尋址成本。支持消息持久化和事務支持-傳統 I/O 拷貝方式為確保高可用性，犧牲延遲性能。傳統 I/O 拷貝采用四次拷貝，且帶來額外 CPU資源消耗，增加延遲。支持消息持久化和事務支持-Kafka 支持水平擴展和分片，因此因此適合大數據處理場景。適合大數據處理場景。-Kafka 采用分布式架構，減少鎖競爭壓力。-順序寫入磁盤，比隨機寫入減少磁盤 I/O 的等待時間，并避免在文件系統級別產生鎖競爭。-Kafka利用零拷貝技術將數據從磁盤文件傳輸到網絡接口，幾乎不需要 CPU 參與數據復制，避免相關資源的競爭。資料來源：Apache ActiveMQ，

56、Apache RabbitMQ，Apache Kafka，中信建投 總結來看，Kafka 在高吞吐和延遲方面的優勢來自 1）架構設計層面，Kafka 采用分區與副本機制，通過水平擴展和數據分區來支持高吞吐量、高可用性和負載均衡。副本機制確保數據的持久性和系統的容錯能力；2）存儲方面，Kafka 通過順序寫入與 Append-only 日志提高寫入效率，并引入稀疏索引與日志壓縮減少存儲空間占用，提升數據檢索效率；3）I/O 優化，通過引入 Linux 的零拷貝技術減少數據在內核態與用戶態之間的復制，以及優化數據包處理流程，提高數據傳輸效率。架構方面，架構方面，Kafka 的分布式架構和分區策略天

57、然支持水平擴展。的分布式架構和分區策略天然支持水平擴展。ActiveMQ 支持通過網絡連接多個 Broker 形成代理網絡，但它的擴展性設計相對較為基礎，主要依賴于主從模式進行故障轉移。RabbitMQ 使用集群方法來實現可擴展性，集群中的節點可是內存鏡像或是通過隊列共享來實現負載均衡。RabbitMQ 的擴展性較強，但相比 Kafka，其在極端高吞吐量場景下的擴展和性能調優可能更加復雜。Kafka 采用分布式、分區和副本機制，天然支持水平擴展，通過增加 Broker 節點就能線性地提高系統的存儲和處理能力。每個 Topic 可以劃分為多個分區，并且這些分區可以在集群中的多個 Broker 上

58、分布，進而實現高并發生產和消費。據 Instaclustr，Kafka 分區數量的增加會使吞吐量增加，但分區數量過多會降低吞吐并增加延時。12 以快遞公司送包裹為例，1)ActiveMQ 盡量保證包裹按順序送達，尤其是當你只有一位快遞員負責一片區域的時候。但如果區域太大，需要多位快遞員分擔工作，這導致包裹無法嚴格按順序到達，除非特別限定一位快遞員只給一家客戶服務，但會犧牲效率。2)RabbitMQ 允許快遞員們同時從倉庫取包裹，但同一個顧客的包裹就不一定能按順序到。特別是當顧客訂閱多個包裹來源時，每個來源的包裹可能會交錯到達。RabbitMQ 可通過一些特殊規定，如限制每個顧客只能由一個快遞員

59、服務，來保持順序，但會犧牲效率。3)Kafka 把城市分成很多小區，每個小區有一個固定的快遞員。只要包裹寄往同一個小區，都能按順序送達。但若包裹要送到不同小區，每個小區的快遞員就會各自行動，這時就無法保證跨小區的包裹順序。14 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 21:Kafka 分區數量與吞吐量的關系分區數量與吞吐量的關系 圖圖 22:Kafka 分區數量與生產者延遲的關系分區數量與生產者延遲的關系 數據來源：instaclustr13，中信建投 數據來源：instaclustr，中信建投 圖圖 23:磁盤順序讀寫性能高于內存隨機讀寫磁盤順序讀寫性

60、能高于內存隨機讀寫 數據來源：ACM Queue14，中信建投 存儲方面，順序磁盤寫入優于隨機寫入性能，而存儲方面，順序磁盤寫入優于隨機寫入性能，而 ActiveMQ/RabbitMQ 涉及更多隨機寫入操作。涉及更多隨機寫入操作。磁盤順序寫入的性能約為 600MB/秒，但隨機寫入的性能僅約為 100k/秒，相差 6000 倍以上15。據 ACM Queue16，順序磁盤訪問在某些情況下比隨機內存訪問還要快。原因在于：1）HDD 隨機寫帶來物理尋道開銷：隨機寫帶來物理尋道開銷：隨機訪問時，磁頭需要物理移動到不同的磁道讀取數據。順序訪問時磁頭只需沿著磁道連續讀取，無需頻繁尋道，因此讀取速度得以提高

61、；2）SSD 隨機寫導致垃圾回收開銷：隨機寫導致垃圾回收開銷：SSD 的介質是閃存，無法原地更新（in-place update）只能進行塊擦除，因此需要垃圾回收算法清理無效的數據塊并將分散的數據重新整理，隨機寫可能導致進一步碎片化，導致更大的資源開銷。ActiveMQ 和 RabbitMQ 在索引更新、隊列管理、消息確認等方面涉及到更多隨機 I/O，不如 Kafka 的順序寫入高效，導致性能損失。Kafka 減少消息復制提升存儲效率減少消息復制提升存儲效率。傳統 MQs 消息復制過程限制其性能，如 RabbitMQ 允許為每個消費者創建獨立隊列，雖然并非每個消息都會被復制到所有隊列，但在需要

62、鏡像隊列時，復制操作會增加存儲開銷17。Kafka 采用分區日志存儲，消息僅需存儲一次，并通過設置分區副本實現高可用，減少存儲資源的需求，且消費 13 https:/ https:/queue.acm.org/detail.cfm?id=1563874 15 https:/kafka.apache.org/documentation/#majordesignelements 16 https:/queue.acm.org/detail.cfm?id=1563874 17 https:/ 15 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。時不依賴于消費者的數量。Ka

63、fka 采用稀疏索引提升批量查詢性能。采用稀疏索引提升批量查詢性能。ActiveMQ 利用 B-Tree 索引來維護消息元數據，這在高負載下可能導致性能損耗。Kafka 采取稀疏索引策略，僅每隔固定字節數創建索引項，減少索引存儲空間。Kafka 采用二分查找法，Kafka 能夠在索引層級上迅速定位到包含目標消息的索引區塊，然后再在該區塊內順序查找，這種設計在處理批量消費時較高效，但犧牲單條消息查詢性能。圖圖 24:Kafka 文件結構與稀疏索引文件結構與稀疏索引 數據來源：hufeifei，中信建投 I/O 方面，方面，Kafka 采用預讀取采用預讀取+延遲寫延遲寫(Read-Ahead+Wr

64、ite-Behind)和頁緩存和頁緩存(PageCache)優化優化 I/O 開銷。開銷。預讀取即在讀取數據時，先以數據塊為單位預讀取數據；寫入數據時，將多個小邏輯寫入合并成一次大型磁盤寫入。順序讀寫時，數據在磁盤空間上更加連續，便于系統預測寫入/讀取位置，因而能提升效率。緩存方面，Kafka在寫入數據時，先寫入頁緩存，操作系統會在合適時機把這些數據寫到磁盤上，因而減少頻繁寫入操作，且降低 JVM 直接管理數據的負擔，避免垃圾回收頻繁發生，節省 JVM 內存。零拷貝顯著提升數據傳輸效率。零拷貝顯著提升數據傳輸效率。傳統 I/O 流程包括用戶空間到內核空間的拷貝及內核空間到硬件緩沖區的拷貝。使用

65、 Sendfile 零拷貝時流程簡化為 DMA（直接內存訪問）從磁盤到內核空間，內核空間直接到 NIC 緩沖區，省略了用戶空間到內核空間的數據拷貝過程，減少至少一次的數據拷貝操作18。此外，上下文切換次數也有所減少，因為數據不再需要進入用戶空間，減少用戶空間和內核空間之間的切換。當運行 Linux 內核 2.4 及更高版本以及支持收集操作的網絡接口卡時，磁盤數據通過 DMA 拷貝到內核態 Buffer 后，直接通過 DMA 拷貝到 NIC Buffer，無需 CPU 拷貝。據 NI 和 IBM，零拷貝可帶來數據傳輸時吞吐量和延時增益。18 零拷貝技術通過優化減少了這些步驟：1）消除應用緩沖區拷

66、貝：零拷貝的核心在于數據不必復制到應用緩沖區，而是直接從 OS 讀取緩沖區傳遞到 Socket 緩沖區，進而到網卡，這樣就省去了第 2 和第 3 次數據拷貝及相應的兩次上下文切換。2）使用 scatter-gather 操作：DMA 引擎能夠直接根據 Socket 緩沖區中的文件描述符引用，將數據從 OS 讀取緩沖區聚合到網卡緩沖區，進一步減少數據移動的開銷。16 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。表表 3:零拷貝相比于傳統拷貝數據傳輸效率有所提升零拷貝相比于傳統拷貝數據傳輸效率有所提升 Method Per Device(MB/s)Total Data

67、(GB/s)Copy BW(GB/s)Data to Disk(GB/s)Total Memory BW(GB/s)Read(with copy)550 4.4 8.8 4.4 17.6 零拷貝 850 6.8 0.0 6.8 13.6 資料來源：NI，中信建投 注：單個設備的吞吐量從550MB/s提升至850MB/s，系統總數據處理量從4.4GB/s提升到6.8GB/s，同時顯著降低內存帶寬的需求，從17.6GB/s降至13.6GB/s。圖圖 25:Kafka 頁緩存頁緩存 圖圖 26:零拷貝相比于傳統拷貝延時有所改進（零拷貝相比于傳統拷貝延時有所改進（ms）數據來源：阿里云，中信建投 數據

68、來源：Efficient data transfer through zero copy，中信建投 注：對于7MB到1GB的文件大小，零拷貝可使延時降低50%70%。圖圖 27:零拷貝與傳統拷貝方式的對比零拷貝與傳統拷貝方式的對比 數據來源：2minutestreaming，中信建投 內存映射顯著改善讀取性能。內存映射顯著改善讀取性能。Kafka 的日志文件分為數據文件和索引文件。為提高索引文件的讀取性能，020004000600080001000012000140001600018000200007MB21MB63MB98MB 200MB 350MB 700MB1GB文件大小傳統方法零拷貝

69、17 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。Kafka 對索引文件采用 mmap 內存映射，即：將索引文件映射到進程的內存空間，避免從磁盤進行讀取。數據顯示19，對于一個 4GB 的文件，分別在冷緩存和熱緩存20條件下測試，采用不同塊大小進行順序或隨機讀取，mmap 比系統調用快 2-6 倍。mmap 更快的原因一方面在于系統調用需要在用戶空間和內核空間之間切換，而mmap 直接把數據從映射到地址空間的一個內核緩沖區復制到另一個內核緩沖區，減少了上下文切換。另一方面在于 mmap 的代碼更加簡潔。圖圖 28:mmap 內存映射調用與系統調用讀取性能對比（順序

70、內存映射調用與系統調用讀取性能對比（順序讀取，熱緩存）讀取，熱緩存）圖圖 29:mmap 內存映射調用與系統調用讀取性能對比（順序內存映射調用與系統調用讀取性能對比（順序讀取，冷緩存）讀取，冷緩存）數據來源：Medium，中信建投 數據來源：Medium，中信建投 圖圖 30:mmap 內存映射調用與系統調用讀取性能對比（隨機內存映射調用與系統調用讀取性能對比（隨機讀取，熱緩存）讀取，熱緩存）圖圖 31:mmap 內存映射調用與系統調用讀取性能對比（隨機內存映射調用與系統調用讀取性能對比（隨機讀取，冷緩存）讀取，冷緩存）數據來源：Medium，中信建投 數據來源：Medium，中信建投 批處理

71、批處理+數據壓縮以犧牲延遲的方式換取高吞吐。數據壓縮以犧牲延遲的方式換取高吞吐。批處理即 Kafka 將消息寫入磁盤時并不是直接寫入，而是等積攢夠一定消息量后一并寫入磁盤中。相應的，讀取消息時也是等到一段時間積攢足夠的消息一并打包發送至消費端。這樣做減少單次操作的開銷，如減少磁盤 I/O 操作次數和網絡請求的次數，從而顯著提高整體的吞吐量，但累積過程中帶來額外的延遲。數據壓縮是在消息發送之前對其進行編碼，以減少消息的大小。在網絡傳輸中，這可以減少帶寬的使用，使得在同樣的時間內能傳輸更多的數據，即提高吞吐量。但壓縮和解壓縮過程需要計算資源，這會引入額外的時間延遲。通常情況下，增加一點點延遲可以換

72、來吞吐量更大的提升21，這對 19 https:/sasha- 20 使用冷緩存進行測試意味著在測試開始前，目標文件的內容沒有被預加載到緩存中；使用熱緩存進行測試，是指文件數據已經存在于緩存中。21 在簡化情景下，假設 Kafka producer 以 2ms/條的時延處理消息，TPS=1/0.002=500 條/秒。如果發送前選擇等待 8ms 積攢消息批量發送，由于 producer 累積消息是在內存緩沖區進行（納秒級）而不像發送消息涉及 I/O（毫秒/秒級），因此 8ms 18 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。大規模數據處理場景非常有利。需要注意的

73、是，Kafka 在設計上對即時性的相對妥協意味著在某些場景下可能不太適用，例如低延遲交互系統如高頻交易、實時在線交易系統、實時游戲通信等場景。在即時性要求極高的場景中，可能需要考慮 RabbitMQ、ActiveMQ 或其他專為低延遲設計的消息隊列系統。圖圖 32:負載、吞吐、延時、負載、吞吐、延時、CPU 資源利用率之間的關系資源利用率之間的關系 圖圖 33:M/M/m22（m=8）系統下利用率與延時的關系）系統下利用率與延時的關系 數據來源：Medium23，中信建投 數據來源：Thinking Clearly about Performance24，中信建投 最終性能實現上，Kafka

74、在數據生產和消費雙端性能均優于 ActiveMQ 和 RabbitMQ。據 Kafka:a Distributed Messaging System for Log Processing，在生產端，Kafka 不等待代理的確認，以代理能處理的最快速度發送消息，且省去 JMS 所需的沉重消息頭，以及維護各種索引結構的開銷，因此具有較好的性能，尤其是批處理條件下。平均而言，Kafka 每條消息有 9 字節的開銷，而 ActiveMQ 有 144 字節。在消費端，由于 Kafka 高效存儲和消費機制以及零拷貝等，Kafka 平均每秒消耗 22,000 條信息，是 ActiveMQ 和 RabbitM

75、Q 的 4 倍多。圖圖 34:生產者性能生產者性能 圖圖 35:消費者性能消費者性能 數據來源：Kafka:a Distributed Messaging System for Log Processing，中信建投 數據來源：Kafka:a Distributed Messaging System for Log Processing，中信建投 內累計消息數遠多于發送消息數。假設能夠緩存 1000 條消息，時延是 8ms+2ms=10ms/0.01s，TPS=1000/0.01=100000 條/秒。犧牲了 8ms 時延，但吞吐量大幅提升。22 第一個M表示顧客（或請求、任務）到達的過程遵循

76、泊松過程，第二個M表示服務時間也是隨機的，并且服從指數分布，s表示系統中有 s 個并行的服務臺 23 https:/ 24 https:/queue.acm.org/detail.cfm?id=1854041 19 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。注：對每個系統，運行一個生產者，總共發布 1000 萬條消息，每條消息 200 字節。Kafka 生產者以 1 和 50 批量方式發送消息。ActiveMQ 和 RabbitMQ 似乎沒有簡單的辦法來批量發送消息，假定批處理大小為1。注：LinkedIn 使用一個消費者獲取總共 1000 萬條消息。Linke

77、dIn 讓所有系統每次拉請求都預獲取大約相同數量的數據，最多 1000 條消息或者 200KB。圖圖 36:Kafka 開發者生態方面優勢明顯開發者生態方面優勢明顯 圖圖 37:Flink/Pulsar/Kafka Github Star 趨勢趨勢 數據來源：Stackflow25，中信建投 數據來源：Github26，中信建投 2.Pulsar 并未及時把握并未及時把握 Kafka 的功能缺失，的功能缺失，Kafka 引入引入 Kora 架構后補齊短板架構后補齊短板 Pulsar 的創新在于存算分離架構。的創新在于存算分離架構。早期系統常將數據處理與存儲合并于同一節點，雖減少網絡開銷，卻犧牲

78、擴展性和高可用性。Pulsar 通過解耦存儲與計算，實現靈活性與按需擴展。架構上，Pulsar 由計算層（Broker集群）處理消息傳遞，與存儲層（BookKeeper 集群，由 Bookies 組成）負責數據持久化。Broker 管理主題分區，對接生產者和消費者，而 BookKeeper 集群以分布式日志形式存儲主題分區，每個日志切分為 Segment，分散存儲于多個 Bookie 以確保均衡和高可用性。因此，Pulsar 可實現 1）存儲擴展能力強：主題分區通過 Segment 跨越 Bookies 分布存儲，擴容只需添加 Bookie 節點，不受單節點容量限制。2）即時擴展性：Broke

79、r 無狀態設計，Topic 遷移無需數據復制，僅需變更 Broker 所有權，即刻連接，實現快速擴展。3）獨立擴展能力：存算分離允許存儲與計算層獨立擴展，彈性適配資源需求，優化成本與性能。25 https:/ 26 https:/star- 20 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 38:Apache Pulsar 架構架構 圖圖 39:Apache Pulsar Broker 層層 數據來源：Slidestalk，中信建投 數據來源：Slidestalk，中信建投 圖圖 40:Apache Pulsar BookKeeper 層層 圖圖 41:Ap

80、ache Pulsar 特點特點 數據來源：Slidestalk，中信建投 數據來源：Slidestalk，中信建投 可擴展性的重要性可能被過度放大，可擴展性的重要性可能被過度放大，如 Confluent 演示27所提到的，對于大多數用例來說，可擴展性不是問題。在 Confluent Cloud 中將 Apache Kafka 擴展至每秒 10+GB，這意味著除非客戶有像 Netflix（每天處理 PB 級數據）或 LinkedIn（處理數萬億條消息）這樣的需求，否則絕大多數客戶并不需要考慮可擴展性方面的問題。因此，Pulsar 所強調的擴展性優勢并未集中客戶痛點，對 Kafka 的潛在威脅較

81、為有限。且存算分離的架構引入額外復雜度，導致大規模場景下延遲不穩定且存算分離的架構引入額外復雜度，導致大規模場景下延遲不穩定。據 2023 年 10 月的研究 Comparative Evaluation of Java Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis,Pulsar,and RocketMQ，1）Kafka 在吞吐量方面表現出色，證明其在處理大規模消息量時的高效性，適合高吞吐量需求。盡管 Kafka 在50%分位數的延遲上略有落后，但在評估的所有吞吐量下表現出穩定性，即可預測的性能，而

82、Pulsar 在較高百分位上的延遲明顯升高。2）但具有較高的 CPU 使用率，意味著它更適合資源豐富的環境，而 Pulsar 的 CPU 使用相對平衡，適應性更廣。3）Kafka 性能強大，但對內存資源要求較高；Pulsar 在內存使用效率上更優，適合內存受限的場景。整體來看，Kafka 優先考慮處理性能以最大化吞吐量并減少延遲，這以犧牲資源效率為代價。相反，Pulsar 在節約資源的同時可能會犧牲一些性能。27 https:/www.confluent.io/blog/scaling-kafka-to-10-gb-per-second-in-confluent-cloud/21 美股公司深度

83、報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 42:默認設置下默認設置下 Pulsar 端到端中位數延遲高于端到端中位數延遲高于 Kafka 圖圖 43:默認設置下默認設置下 Kafka 吞吐量基本與吞吐量基本與 Pulsar 不相上下不相上下 數據來源：Comparative Evaluation of Java Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis,Pulsar,and RocketMQ，中信建投 數據來源：Comparative Evaluation of Java

84、 Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis,Pulsar,and RocketMQ，中信建投 圖圖 44:10KB 消息大小下消息大小下 CPU 利用率利用率 圖圖 45:10KB 大小下內存使用率大小下內存使用率 數據來源：Comparative Evaluation of Java Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis,Pulsar,and RocketMQ，中信 數據來源：Comparati

85、ve Evaluation of Java Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis,Pulsar,and RocketMQ，中信 安特衛普大學研究團隊 2022 年 9 月的研究28證實了 Pulsar 在大/小規模場景下的性能差異。原理上，Pulsar 引入計算層（broker）與存儲層（BookKeeper）分離的架構，旨在提升擴展性。當處理大量數據時，這種分離可以獨立擴展存儲和計算資源，但可能對小消息處理引入額外的網絡延遲，因為數據需要在兩層間傳輸。且 Pulsar 用 Bundle 作為

86、負載均衡單元而非單個 Topic，當某個 Topic 負載輕，但同 Bundle 中其他 Topic 活躍時，可能會間接影響資源分配，造成小消息處理延遲。這種策略實際上追求高吞吐，并犧牲延遲，因此 Pulsar 在延遲和吞吐的平衡方面不如 Kafka 穩定。具體而言，如果消息大小非常平均且偏向中大尺寸，Pulsar 的策略更能發揮優勢，因為它可以高效地利用資源和優化吞吐量。反之，如果消息大小非常不平均，特別是存在大量小消息，Pulsar 可能會因為其資源分配和處理策略，相比 Kafka 等其他系統展現出更高的延遲。28 Data Management Platform For Smart Or

87、chestration of Decentralized and Heterogeneous Vehicular Edge Networks。22 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 46:ActiveMQ、Zenoh、Kafka、Pulsar 發送發送 N 個消息所需時間（個消息所需時間（ms）數據來源：Data Management Platform For Smart Orchestration of Decentralized and Heterogeneous Vehicular Edge Networks，中信建投 圖圖 47:Kafka

88、 相比相比 Pulsar 在大規模場景下擴展性更強在大規模場景下擴展性更強 圖圖 48:Kafka 較較 Pulsar 總體上性能更穩定總體上性能更穩定 數據來源：Data Management Platform For Smart Orchestration of Decentralized and Heterogeneous Vehicular Edge Networks，中信建投 數據來源：Comparative Evaluation of Java Virtual Machine-Based Message Queue Services:A Study on Kafka,Artemis

89、,Pulsar,and RocketMQ，中信建投 Pulsar 的真正問題是并未提供功能以滿足用戶的核心需求，的真正問題是并未提供功能以滿足用戶的核心需求，如缺乏消息隊列支持，事件流支持，不支持一次性交付和處理語義等，其 Kakfa Connect 功能完整度不高，這意味著 Pulsar 較難滿足客戶現有的業務需求，而是提供一個概念框架，滿足初創/中小企業的簡單需求。更重要的是，Kafka 的迭代較快，為簡化運維且提升擴展性，Kafka 于 2023 年提出 Kora 架構，用 KRaft 替代 Zookeeper，并引入分層存儲強化存算分離的彈性。從商業邏輯上看，技術架構的創新是為業務服務

90、的，新技術對現有技術的替代更多是以創新架構更快、更可靠或以更低成本地實現現有需求，而非等待客戶主動適配新架構。因此，對于 Pulsar 競爭力的評估首要考慮的應當回歸 Pulsar 在業務場景的性能表現，是否滿足高可用、實時性等。-20,000 40,000 60,000 80,000 100,000 120,00011010010002000 10000100000ActiveMQZenohKafka JavaKafka PythonPulsar-0.5 1.0 1.5 2.0 2.550th75th99th 23 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。K

91、ora 的的分層存儲分層存儲結合本地存儲和對象存儲，降低成本并兼顧讀取效率。結合本地存儲和對象存儲，降低成本并兼顧讀取效率。一般來講，磁盤本地存儲的存儲空間有限，受制于物理硬件不易擴展，且存儲成本更高，但訪問延遲低、性能好、適合實時訪問和快速讀寫。而對象存儲相對便宜（例如 AWS S3），且分布式架構提升其擴展能力，但訪問速度慢于本地存儲。傳統 Kafka 依賴于本地存儲，由此產生兩個問題：1）成本問題：）成本問題：隨著數據量的增加，維持高性能的本地存儲成本會快速上升，可能變得過于昂貴。2）實時彈性不足：）實時彈性不足：傳統 Kafka 在擴縮容時涉及流量的重平衡，需要大量遷移數據，導致實時彈

92、性能力不足29。分層存儲帶來的成本分層存儲帶來的成本+彈性大幅優化。彈性大幅優化。Kora 結合本地存儲和對象存儲，采用分層存儲的方案，即：將熱數據保留本地，而冷數據移至對象存儲中。此外，Kora 具有自平衡機制，可將數據在內存、本地存儲、對象存儲之間智能分配、主動遷移且持續優化。這種平衡難度較高，需要遵循單元放置規則和租戶公平性，還要平衡 CPU和本地 I/O 使用率，同時減少分區移動造成的不穩定成本。因此，Kora 在保持關鍵數據的高性能訪問的同時，大幅降低總體存儲成本，同時由于只有少量熱數據保留本地，數據遷移簡化，彈性大幅提升。圖圖 49:Kora 架構架構 圖圖 50:Kora 智能分

93、層存儲智能分層存儲 數據來源：Kora:A Cloud-Native Event Streaming Platform For Kafka，中信建投 數據來源：Confluent30，中信建投 Kafka 最初集成最初集成 ZooKeeper 進行分布式協調和管理元數據，但后續帶來運維復雜度及擴展性瓶頸。進行分布式協調和管理元數據，但后續帶來運維復雜度及擴展性瓶頸。ZooKeeper 通過提供一致性的服務，幫助 Kafka 管理集群配置、選舉控制器（controller）、以及存儲和同步元數據等關鍵任務。這種設計雖然帶來可靠性，但也附加了復雜性和伸縮性的局限：1）復雜性高：）復雜性高：ZooK

94、eeper+Kafka需要開發人員同時維護兩個分布式系統，增加系統的管理和運維復雜度。2）伸縮性瓶頸：）伸縮性瓶頸：假設一個系統有三個broker，其中作為領導者的 broker 想請求關閉，controller 首先確定 broker1 管理的分區嘗試更新元數據，并隨機選舉產生新的領導者。然后執行 ZooKeeper 寫入操作，更改這些分區的元數據。最后，將更改的元數據傳播到所有其他 broker。這一過程造成較高的延時；假設原有控制器意外崩潰，新控制器需要從 ZooKeeper 讀取全部元數據，同樣造成較長的延時和不可用窗口。為解決這些問題，為解決這些問題，Kafka 采用基于采用基于 R

95、aft 協議的協議的 KRaft 模式替代模式替代 ZooKeeper。KRaft 模式的核心變化包括 1）元數據自管理，Kafka 將元數據從 ZooKeeper 遷移至內部存儲，這意味著元數據可以利用 Kafka 的日志復制和持久化機制來保證數據的安全性和一致性；2）仲裁控制器：Kafka 集群中的部分 Broker 被指定為仲裁控制器，它 29 以一個 100MB/s 流量的 Kafka 分區為例，運行一天產生的數據量約為 8.2T，如果此時需要將該分區遷移到其他 Broker，則需要對全量數據進行復制，即使對擁有 1 Gbps 帶寬的節點，也需要小時級的時間來完成遷移，這使得 Apac

96、he Kafka 集群幾乎不具備實時彈性能力。30 https:/www.confluent.io/blog/cloud-native-data-streaming-kafka-engine/24 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。們使用 Raft 協議來達成共識，管理元數據的更新和分布，從而替代 ZooKeeper 的角色。圖圖 51:Zookeeper 模式模式 圖圖 52:KRaft 模式模式 數據來源：騰訊云，中信建投 數據來源：騰訊云，中信建投 其優點在于：1）縮短不可用窗口，）縮短不可用窗口，由于元數據存儲在 Kafka 內部，當 Broke

97、r 重啟或故障恢復時，可以直接從日志中恢復缺失的元數據信息，減少系統不可用的時間；2）簡化架構，）簡化架構，Kafka 架構大大簡化，減少外部組件運維，使系統更加輕量級和穩定；3）伸縮性提升，）伸縮性提升，KRaft 模式下，由于元數據管理的高效性和 Raft 協議的高效共識機制，Kafka 集群可以更平滑地擴展到數百萬個分區，遠超依賴 ZooKeeper 時的伸縮性限制，可以更好地滿足以下三種情景：1）由于業務需要多主題而產生大量分區；2）需要大量分區實現消費者并發處理，從而達到高吞吐；3）由于消費者消費速度緩慢而需要增加消費者數量和分區。圖圖 53:KRaft 如何運作如何運作 圖圖 54

98、:Kraft 代替代替 ZK 后節點關閉和故障轉移的速度更快后節點關閉和故障轉移的速度更快 數據來源：baeldung31，中信建投 數據來源：confluent32，中信建投 31 https:/ 32 https:/developer.confluent.io/learn/kraft/25 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 55:KRaft 代替代替 ZK 后最大分區數量擴展約后最大分區數量擴展約 7.5X 倍倍 圖圖 56:Kraft 代替代替 ZK 后創建分區的速度更快后創建分區的速度更快 數據來源：instaclustr33，中信建投 數

99、據來源：instaclustr，中信建投 圖圖 57:Kraft 代替代替 ZK 后分區增加的速度更快后分區增加的速度更快 圖圖 58:Kraft 代替代替 ZK 后分區在代理間移動的速度更快后分區在代理間移動的速度更快 數據來源：instaclustr，中信建投 數據來源：instaclustr，中信建投 資源調配策略方面，Kora 采用多租戶模式。多租戶的核心挑戰在于資源分配和隔離：1）超額訂閱或引起代）超額訂閱或引起代理過載，理過載，大多數租戶為應對流量洪峰往往超額訂閱物理集群，由于多租戶模式下單個節點由多個租戶共享，若需求激增，可能引起節點過載導致所有用戶高延遲。2）工作負載可能隨時間

100、在不同節點之間切換，）工作負載可能隨時間在不同節點之間切換，若將租戶級配額靜態平均分配給每一個節點，熱分區所在的節點會較早達到配額限制并開始節流，但此時整個集群的使用量低于全體租戶配額，造成使用效率低下。針對超額訂閱與代理過載，針對超額訂閱與代理過載，Kora 為節點上的資源設置安全閾值，通過反壓和自動調優減輕節點壓力。為節點上的資源設置安全閾值，通過反壓和自動調優減輕節點壓力。Kora通過在每個節點上設定資源使用的上限，比如帶寬、CPU 和連接數，來防止過載。這些閾值作為安全網，確保即使在租戶需求激增的情況下，也能維持基本的服務質量。一旦達到限制，節點就會使用自動調優機制對租戶的請求進行反壓

101、，即暫時減緩或限制某些租戶的流量，確保整體資源使用保持在安全范圍內，緩解節點壓力，避免全局性的服務降級。對于動態工作負載與靜態配額不匹配，對于動態工作負載與靜態配額不匹配，Kora 使用動態配額機制，根據租戶帶寬消耗調整帶寬分配。使用動態配額機制，根據租戶帶寬消耗調整帶寬分配。Kora 設計配額協調器管理租戶間共享配額。例如，租戶 A 有 100MB/sec 的總配額，分配給代理 1、2 和 3。節點定期向配額協調器上報每個租戶和每個節點的帶寬使用數據和相關的限額信息。如果監測到某個節點上的租戶 A 使用率低，而其他節點該租戶的需求高，配額協調器會重新平衡，將未充分利用的配額轉移到需求更高的節

102、點，從 33 https:/ 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。而優化資源使用效率，并響應租戶的動態需求。圖圖 59:Kora 配額協調器配額協調器 圖圖 60:Kora 動動態租戶平衡態租戶平衡 數據來源：Kora:A Cloud-Native Event Streaming Platform For Kafka，中信建投 數據來源：confluent34，中信建投 3.Redpanda 的性能優勢被夸大，其基準測試并不具有普遍意義的性能優勢被夸大，其基準測試并不具有普遍意義 Redpanda 的的性能性能優勢被夸大優勢被夸大，其基準測試并不具有普遍意

103、義，其基準測試并不具有普遍意義。Redpanda 聲稱由于其每核線程架構、使用C+編寫以及針對高性能NVMe驅動器優化的存儲設計，其性能優于Kafka35。但深入分析其基準測試可以發現：Redpanda 測試跑分中為自身引入了定制化配置，且對 Kafka 的部分配置并不公平。例如：1）使用 Java 11 而非 Java 17 運行 Kafka36；2）使用實際生產中較為少用的參數配置，迫使 Kafka 在每個消息批上進行 fsync，導致Kafka 性能降低；3）對 Redpanda 和 Kafka 分別應用兩種不同的偏移量提交策略，沒有保持一致。Redpanda 大規模/長期運行場景下性能

104、不穩定。據 Jack Vanlightly，Redpanda 在 50 個生產者時性能明顯下降，表現為延時迅速增加而吞吐量存在 1000MB/s 的瓶頸，與 Redpanda 基準測試相沖突。同時，在運行 12 小時后，Redpanda 的端到端延時發生抖動，尾部延時大量增加。而 Kafka 的表現更加平穩，且隨時間延長，延遲甚至表現出優化趨勢?？傮w上，Redpanda 性能比 Kafka 更不穩定，對多種因素敏感，例如批量大小不能太小，高分區工作負載的吞吐量不能太高，驅動器需要充分配置足夠的空位，以滿足其存儲層的隨機 IO 性質。34 https:/www.confluent.io/blog

105、/cloud-native-data-streaming-kafka-engine/35 https:/ 36 Java 11 已經有 5 年的歷史，而 Kafka 通常在 Java 17 中運行良好。27 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 61:百分位端到端延時（百分位端到端延時（ms，越低越好），越低越好）圖圖 62:生產者吞吐量（生產者吞吐量（MB/s，越高越好），越高越好）數據來源：Jack Vanlightly，中信建投 數據來源：Jack Vanlightly，中信建投 圖圖 63:Redpanda 在運行早期表現出極致的低延遲，但隨著

106、時間延長在運行早期表現出極致的低延遲，但隨著時間延長其其延遲不如延遲不如 Kafka 穩定穩定 數據來源：Jack Vanlightly，中信建投 對于很多工作負載支持度不如 Kafka。Jack Vanlightly 發現 Redpanda 在 1GB/s 生產者負載下無法排出積壓的數據。而 Kafka 則能成功處理積壓并恢復到低延遲狀態。這表明 Redpanda 在處理瞬時或持續高負載沖擊時的彈性不足。此外，對于需要排序的工作負載，使用記錄鍵后 Redpanda 性能明顯下降37。37 隨著消息批處理率的增加但批處理量的下降，Redpanda 的優勢下降甚至完全消失。對于高分區和高消息批處

107、理率的基準測試，即使是 50MB/s 的測試，fsync 速率通常也非常高（200K/s），這可能解釋了較高的延遲。28 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 64:Kafka 能夠在能夠在 100 個生產者使用記錄鍵的情況下達個生產者使用記錄鍵的情況下達到到 500MB/s 的目標。的目標。Redpanda 的最高速度是的最高速度是 330MB/s 圖圖 65:Redpanda 在處理在處理大量大量使用記錄鍵進行消息排序的生使用記錄鍵進行消息排序的生產者時產者時延時大幅增加延時大幅增加 數據來源：Jack Vanlightly，中信建投 數據來源：J

108、ack Vanlightly，中信建投 圖圖 66:9 小時后，小時后，Redpanda 積壓的訂單仍積壓的訂單仍未完全耗盡未完全耗盡 圖圖 67:Kafka 在在 3 小時內耗盡積壓的訂單小時內耗盡積壓的訂單 數據來源：Jack Vanlightly，中信建投 注：1 GB/s 生產者負載，5TB 積壓，消費者扇出為 1 數據來源：Jack Vanlightly，中信建投 注：1 GB/s 生產者負載，5TB 積壓，消費者扇出為 1 總體而言，總體而言，Redpanda 的性能對工作負載的敏感性高，的性能對工作負載的敏感性高，并非全面優于并非全面優于 Kafka。Redpanda 擁有最強大

109、的端到端延遲結果，隨著增加吞吐量，工作負載的具體情況會對性能產生不成比例的影響。同時，Redpanda 對驅動器延遲也非常敏感。Kafka 的問題在于頁面緩存是一把雙刃劍。Kafka 對各種工作負載的性能穩定性好，但會導致端到端的延遲峰值，從而影響尾部延遲。29 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。競爭分析：Kafka 兼具高吞吐+低延遲，已成為流處理的事實標準 Kafka 成為流處理的事實標準，成為流處理的事實標準，主要競爭對手大多提供原生 Kakfa/支持 Kakfa 協議的服務。流處理市場包含 1）原生 Apache Kafka：產品或云服務利用開源

110、框架進行實時消息傳遞和事件存儲。Kafka API 100%兼容。不包括 Kafka Streams 和 Kafka Connect；許多供應商排除了這些 Kafka 功能。2）Kafka 協議：產品或云服務實現自己的代碼，但支持 Kafka API。這些產品通常不是 100%兼容的。通常，Kafka Connect 和 Kafka Streams 通常不屬于這些產品。3）流處理：框架和云服務以無狀態或有狀態的方式關聯數據。圖圖 68:流處理市場格局流處理市場格局 數據來源：KAI WAEHNER38，中信建投 圖圖 69:Confluent 在事件流處理市場中處于領導者地位在事件流處理市場中

111、處于領導者地位 圖圖 70:Kafka 在消息隊列市場中處于頭部地位在消息隊列市場中處于頭部地位 數據來源：G2，中信建投 數據來源：G2，中信建投 Confluent 面臨的競爭對手有三類，包括開源 Kafka 用戶（即企業內部 IT 團隊）、三大云服務商以及傳統技 38 https:/www.kai-waehner.de/blog/2023/12/21/the-data-streaming-landscape-2024/30 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。術供應商39。對比 CSP：AWS Kinesis 主要負責將數據導入主要負責將數據導入 A

112、WS 數據存儲，并由數據存儲，并由 AWS 其他產品服務滿足流數據處理其他產品服務滿足流數據處理/存儲需求，存儲需求，普遍問題是缺乏系統優化。普遍問題是缺乏系統優化。其余 CSP 如 Azure Event Hub/Google Datflow 均提供類似方案，即提供組件而非完整解決方案，這種方式的問題在于缺乏系統性優化導致低效率，如 Doordash 2022 年從 Amazon SQS 和 Kinesis 遷移至 Flink/Kafka。Doordash 指出混合不同類型的數據傳輸并經歷多個消息傳遞/排隊系統，導致數據延遲高、成本高、運營開銷大。引入 Kakfa/Flink 后，Doord

113、ash 可增強數據集成能力，如通過 API 或通信范例訪問，并且使用 Confluent Schema Registry 實現模式實施和模式演變的端到端數據治理。圖圖 71:Doordash 基于基于 Amazon SQL/Kinesis 提取并將數據傳遞到提取并將數據傳遞到 Snowflake 上，但存在高延遲、高成本和運維開銷上，但存在高延遲、高成本和運維開銷 數據來源：DoordashBuilding Scalable Real Time Event Processing with Kafka and Flink，中信建投 圖圖 72:引入引入 Kafka 后后 Doordash 的數據

114、處理框架的數據處理框架 數據來源：DoordashBuilding Scalable Real Time Event Processing with Kafka and Flink，中信建投 此外，此外，Kinesis 主要被詬病的問題包括成本和數據集成功能。主要被詬病的問題包括成本和數據集成功能。1）成本主要體現在數據擴展后的規模不經濟。Kafka 通過增減 Broker 或調整分區實現靈活擴展，這允許根據需求精細分配虛擬資源，提高了資源使用的靈活性和效率。相比之下，Kinesis 依賴增加分片來擴展容量，雖然操作簡便，但擴展粒度較為固定，可能在某些場景下影響資源利用率的優化。另外 Kafk

115、a 扇出能力40優于 Kinesis，主要由于采用發布-訂閱模式，使得消息能被多個消費者組并行處理；內置的消費者組協調確保新消費者無縫加入或退出時任務重新分配，維持系統的高扇出及穩定性；分區機制增強并行處理能力。相比之下，Kinesis 通過分片支持多個消費者共享訪問，但分片的吞吐上限限定了其扇出規模，一般情況下扇出能力相對有限；2）數據集成功能有限。Kinesis 并非原生 Kafka，因此對 Kafka 的核心功能支持度不高，用戶需要自行配置或采用 AWS 的其他組件，這引發運維成本提升或供應商鎖定等問題。39 傳統技術供應商更多是客戶遺留 IT 系統/工作負載，總體呈現遷出的趨勢。40

116、一條消息被多個消費者或處理單元并行消費的能力 31 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。AWS MSK Serverless 版本是版本是 Kafka 的托管版，但其功能完整性均存在一定欠缺。的托管版，但其功能完整性均存在一定欠缺。Confluent Cloud 集成全套 Confluent Platform 特性，如 Schema Registry、KSQL，提供高級安全監控和自動化管理。AWS MSK 側重與AWS 生態集成，如 Lambda、Glue，但不支持 Kafka Connect/Streams 等功能。一個例證是 Confluent Clo

117、ud 用戶可使用開源監控工具如 Kafka UI，而 MSK 用戶需手動配置 CloudWatch 或承擔額外費用，尤其是對于代理和分區級的詳細監控。MSK Serverless 用戶可免費訪問基本監控指標，但代理和分區級指標需收費，并且主題-分區級指標很少41。據 Metricfire，CloudWatch 企業級花費每年可能超過 50,000 美元42。同時 CloudWatch 無法與 Datadog 和 Dynatrace 等第三方監控工具進行原生集成。圖圖 73:Apache Kafka 集群的集群的 8 大大 UI 監監控工具控工具功能對比功能對比 圖圖 74:Kafka UI 界

118、面界面 數據來源：Towards Data Science43，中信建投 數據來源：Towards Data Science,中信建投 Confluent 相比于相比于 MSK 的差異化的差異化在于在于全托管全托管 ksqlDB，降低，降低 TCO，Kinesis 流處理能力弱于流處理能力弱于 Flink。流處理方面，Confluent 提供完全托管的 Flink 和 ksqlDB，流處理只需要使用類 SQL 語言即可完成；而 MSK 僅支持自管理的 ksqlDB，MSK Severless 不支持 ksqlDB。雖然兩者都支持 Flink，但 MSK 需要自托管 ksqlDB。ksqlDB

119、屬屬于社區許可協議，其他競爭者不允許提供任何于社區許可協議，其他競爭者不允許提供任何 ksqlDBaaS 或其他與或其他與 Confluent 有競爭關系的類似服務有競爭關系的類似服務44。盡管Kinesis Data Analytics 內置 Flink，其功能相比原生 Flink 可能有所精簡，比如缺少自定義操作符和計時器功能。因此，在處理高度復雜的事件流上，Confluent 提供的 Flink 服務憑借更完整的功能集展現優勢。Azure Event Hubs（AEH）主要負責數據攝取，流處理功能不完整且對）主要負責數據攝取，流處理功能不完整且對 Kafka 協議兼容性有限。協議兼容性有

120、限。Azure Event Hubs45不支持核心 Kafka 功能，如事務、壓縮或日志壓縮、Kafka Connect 和 Kafka Streams。另外，AEH 并非100%兼容 Apache Kafka46，而是允許用戶調用 Kafka 的部分 API 進行數據處理。41 僅有 EstimatedTimeLag 和 OffsetLag 兩個；https:/ 42 https:/ https:/ 44 https:/ 45 https:/ 46 https:/ 32 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 75:Azure Event Hubs 架

121、構架構 數據來源：Microsoft，中信建投 Azure Event Hubs 與與 Kafka 底層架構上的不同之處在于：底層架構上的不同之處在于：Kafka 在可用性、一致性、順序性之間的選擇在可用性、一致性、順序性之間的選擇更加靈活。更加靈活。對于 AEH，如果業務重視可用性，則發送消息時不能傳遞 Parition Key，消息以輪詢方式發送，一個分區不可用則傳遞至其他分區，保證可用性但犧牲消息順序性。如果業務重視順序性，所有消息只能往一個Partition 上發送同時指定 Partition Key。當 Partition 不可用則部分業務不可用。AEH 不支持分區負載再平衡不支持分

122、區負載再平衡可能導致擴展性受限?？赡軐е聰U展性受限。AEH 的分區數在創建后固定，高級和專用層級雖能增加分區但不可減少，影響擴展靈活性。Kafka 則可通過增加分區調整擴展，并支持工作負載再平衡。AEH 其他功能上缺點在于：1）配額）配額過多過多：AEH 有很多配額限制，官方稱是為幫助客戶準確配置資源、避免錯誤消耗，但實際上給用戶帶來困擾，例如消息不能超過 256KB（Kafka 以 MB 為單位），命名空間的事件中心數量限制為 10 個，如需擴大則需更高級版本；2）保留期過短：）保留期過短：AEH 基本版保留期僅 1 天，專用版保留期也有 90 天限制，因而限制歷史數據的分析；3）重要重要功

123、能缺失：功能缺失：AEH 缺少 Kafka Connect、Kafka Streams、缺少架構注冊表、RBAC、審核日志等，這些功能在眾多企業廣泛使用。表表 4:Azure Event Hubs 配額和限制配額和限制 限制限制 基本基本 標準標準 高級高級 專用專用 事件中心發布的最大大小 256 KB 1 MB 1 MB 1 MB 每個事件中心的使用者組數 1 20 100 1000，單個 CU 沒有限制 每個域名的 Kafka 使用者組數 NA 1000 1000 1000 每個命名空間的中轉連接數 100 5,000 每個 PU 10000 每個 CU 100,000 事件數據的最長保

124、留期限 1 天 7 天 90 天 90 天 用于保留的事件存儲 每個 TU 84 GB 每個 TU 84 GB 每個 PU 1 TB 每個 CU 10 TB 最大 TU、PU 或 CU 數 40 個 TU 40 個 TU 16 PU 20 CU 每個事件中心的分區數 32 32 每個事件中心 100 個，但在命名空間級別，每個 PU 限制為 200 個。每個事件中心 1024 個 每個 CU 2000 個 每個訂閱的命名空間數 1000 1000 1000 1000（每個 CU 50）33 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。每個命名空間的事件中心數 10

125、 10 每個 PU 100 1000 捕獲 不適用 按每小時支付 已含 附送 壓縮事件中心的大小 空值 每個分區 1 GB 每個分區 250 GB 每個分區 250 GB 架構注冊表（命名空間）的大?。ㄒ哉鬃止潪閱挝唬┎贿m用 25 100 1024 架構注冊表或命名空間中的架構組數 不適用 1-排除默認組 100，每個架構 1 MB 1000，每個架構 1 MB 所有架構組的架構版本數 不適用 25 1000 10000 每個單位的吞吐量 流入量-每秒 1 MB 或每秒 1000 個事件 流出量-每秒 2 MB 或每秒 4,096 個事件 流入量-每秒 1 MB 或每秒 1000 個事件 流出

126、量-每秒 2 MB 或每秒 4,096 個事件 單個 PU 無限制*單個 CU 無限制*資料來源：Azure，中信建投 注：CU 是容量單位，PU 是處理單位，TU 是吞吐量單位。GCP Pub/Sub 是是 Google 基于云的分布式消息傳遞服務，而并非完整的流處理平臺?；谠频姆植际较鬟f服務，而并非完整的流處理平臺。架構上，主題（Topics）是作為消息的發布目標；發布者（Publishers）負責向主題發送消息；訂閱者（Subscribers）則訂閱這些主題以異步接收消息，支持推（Push）與拉（Pull）兩種模式。作為 GCP 的一部分，Pub/Sub 與 Google 的其他服

127、務（如Dataflow、BigQuery、Cloud Functions 等）有深度集成，便于構建端到端的云解決方案。對于已經使用 GCP 服務的用戶來說，集成更為順暢。兩者架構差異在于：Kafka 底層底層架構保證單分區內順序性，架構保證單分區內順序性，GCP Pub/Sub 需需要額外要額外傳輸傳輸消息鍵。消息鍵。在 Kafka 中，每個主題可以被劃分為多個分區，而每個分區內部的消息是嚴格有序的，生產者可利用單分區有序性，將消息發送到同一個分區中，以此保證消息的順序性。而 GCP Pub/Sub 并未內置消息的順序性。雖然可以啟用消息鍵，使用消息排序功能，但消息鍵產生的額外開銷可能會增加消

128、息的延遲。GCP Pub/Sub 的設計更側重于可靠性和可擴展性，而非低延遲。的設計更側重于可靠性和可擴展性，而非低延遲。GCP Pub/Sub 可以保證消息傳遞不遺失，具有高可靠性。然而它的消息傳遞機制可能引入一定延遲，因此不太適合那些需要即時響應或超低延遲處理的任務，比如高頻交易系統或實時交互應用。圖圖 76:GCP Pub/Sub 架構架構 數據來源：Google，中信建投 34 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 77:Kafka 和和 Pub/Sub 擴縮策略之間的差異擴縮策略之間的差異 數據來源：Google，中信建投 注：每個 M 代表

129、一條消息。Kafka 代理管理著多個有序消息分區，由消息的水平行表示。消費者從特定分區讀取消息，該分區的容量取決于托管該分區的機器。Pub/Sub 沒有分區，而是由消費者從根據需求自動擴縮的主題中讀取?？梢詾槊總€ Kafka 主題配置處理預期消費者負載所需的分區數。Pub/Sub 會根據需求自動擴縮。反壟斷壓力下，反壟斷壓力下，CSP 有望逐步消除數據傳輸費以緩解監管壓力。有望逐步消除數據傳輸費以緩解監管壓力。Confluent 作為中立服務提供商的問題在于傳輸成本，對于中大型企業而言，數據自數據管道、流處理后導入 Snowflake/Databricks/MongoDB 等存儲，而如果下游存

130、儲與流處理層分屬不同云服務商/可用區，則客戶面臨較高數據傳輸成本，這削弱了重度用戶采用 Confluent Cloud/Platform 的 ROI。但 2024 年以來，Google Cloud 于 1 月宣布面向全球用戶取消跨云/本地上云的數據傳輸費47，Amazon48、Azure49于 3 月跟進了這一舉措，此外 Azure 于 5 月進一步宣布對于同一云廠商跨可用區的數據傳輸免費50。盡管 Google51/Amazon52仍然對跨可用區的數據傳輸收費。圖圖 78:現代數據管理技術?，F代數據管理技術棧 數據來源：Emergence53，中信建投 47 https:/ 48 https

131、:/ https:/ https:/ https:/ 52 https:/ https:/ 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。CSP 的舉動是對監管的回應，2023 年 4 月英國通信監管機構 Ofcom 提交調查報告54，其認為AWS/Azure/GCP/Oracle 等對數據傳輸、遷移收取的費用構成用戶切換云服務的障礙，從而限制競爭，建議英國監管當局對云計算行業啟動正式且全面的調查。此外，歐盟數據法案（EU Data Act）于 2024 年 1 月生效，該法案要求 CSP 消除其自身云服務與競爭云服務之間“有效切換的障礙”，包括商業、合同、技術或組

132、織障礙。我們認為，監管壓力下，數據傳輸的高昂成本將逐步消除，對于依托云廠商基礎設施的 Confluent 等中立服務商，其成本劣勢有望消除。此外，Confluent 集成能力較為廣泛，整合集成能力較為廣泛，整合 Flink 后有望提升易用性且保持部分專有連機器的優勢后有望提升易用性且保持部分專有連機器的優勢。Confluent在流數據處理市場的競爭優勢之一在于其提供的120+預構建的連接器。這些連接器在實踐過程中存在一些問題，例如 1）并非所有連接器都能直接使用，有些需要自行托管；2）在大型企業中，尤其是使用本地系統的企業，使用云連接器連接到本地數據庫時會遇到網絡問題。3）數據轉換也構成挑戰，

133、Kafka Connect 框架只支持基本的轉換，而更復雜的轉換則需要使用 ksqlDB。但隨著 Flink 的更深入整合到 Confluent Cloud 平臺，這些問題有望得到緩解。Flink 與連接器的結合使用可以實現數據轉換，這對于流數據處理來說是一個重要的優勢。值得注意的是，Confluent 擁有一些關鍵的專有連接器，如 Oracle 和 ServiceNow 連接器，以及適用于物聯網用例的 MQTT連接器。這些專有連接器只能由 Confluent 托管，競爭對手如 Redpanda、MSK 等無法提供類似服務，這使得Confluent 占據流處理市場的重要地位。表表 5:Conf

134、luent Cloud 與與 Amazon MSK、MSK Serverless、Kinesis 等對比等對比 Confluent Cloud Amazon MSK MSK Serverless Kinesis 服務模式 云原生 云托管 云原生 云原生 是 否 基 于Kafka Kafka Kafka Kafka 非 Kafka 存儲 無限存儲，每個分區的存儲無限存儲，每個分區的存儲量量均無限制均無限制55 每個分區最多 250 GB，每個集群最多 120 個分區（但可以通過請求增加）每個代理存儲量最多為16TB，每個集群最多 30 個代理（但可以通過請求增加）能夠持久保存數據，確保數據不會丟

135、失，但由于保留期限制，數據的長期存儲需要將 Kinesis 與其他 AWS 存儲服務(如 S3)結合使用 擴展性 可彈性擴展，集群自動平衡 需要進行手動再平衡 可彈性擴展，集群自動平衡 可彈性擴展，自動管理分片提供必要的吞吐量 服務集成 集成廣泛，且已經預建：集成廣泛，且已經預建：具有 120+預構建的連接器，能夠與本地/公有云服務無縫集成。-與與 AWS 生態集成：生態集成：Amazon Athena、Redshift、Kinesis Data Firehose-第三方集成：第三方集成：不支持Kafka Connect，僅包含MSK Connect 服務，需利用自建或社區構建的連接-與與 A

136、WS 生態集成：生態集成：AWS PrivateLink（提供私有連接）、IAM（使用 0Java 和非 Java 語言進行身份驗證和授權）、AWS Glue 架構注冊表，（架構管理）、AWS 托管 Apache Flink 服務(流處理)、-與與 Kafka 相比，生態系相比，生態系統有限統有限 與與 AWS 生態無縫集成：生態無縫集成：AWS Amplify 等56-第三方集成第三方集成：Apache Flink、Fluentd、Debezium、Oracle GoldenGate、Kafka 54 https:/ https:/docs.confluent.io/cloud/curren

137、t/clusters/cluster-types.html#types-basic-limits-per-partition 56 AWS Amplify、Amazon Aurora、Amazon CloudFront、Amazon CloudWatch Logs、Amazon Connect、AWS Database、Migration Service、Amazon DynamoDB、Amazon EventBridge、AWS IoT Core、Amazon Relational Database Service、Amazon Pinpoint、Amazon Quantum Ledger

138、Database 36 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。器，AWS 無明確的技術支持 Lambda（事件處理）-第三方集成：第三方集成：不支持Kafka Connect，僅包含MSK Connect 服務，需利用自建/社區構建連接器，AWS 無明確的技術支持 Connect、Adobe Experience、Striim 多語言開發能力 支持 C+，Python，Go和.NET 等非 java 客戶端 需利用開源客戶端，AWS沒有技術支持 需利用開源客戶端，AWS沒有技術支持 支持 Python、Node.js、.NET、Go 和 C+等非 java

139、客戶端 消息保留期 無限存儲無限存儲 默認 7 天，broker 存儲有限制 默認 7 天，支持無限存儲支持無限存儲57 24h 到 365 天不等 流處理 功能豐富，功能豐富，差異化在于獨有差異化在于獨有的的 KsplDB 服務：服務：提供完全托管的 Flink、ksqlDB、Lambda，流處理只需使用類 SQL 語言即可方便完成 支持 Flink 但復雜性較高；支持自管理的 ksqlDB 支持 Flink 和 Lambda，但Flink 配置復雜性較高；不支持 ksqlDB；缺少 Kafka Streams 流處理功能有限，有流處理功能有限，有 Flink但功能不完整：但功能不完整：1）

140、Kinesis Data Streams 用于捕獲流數據；2）Kinesis Data Firehose 將流數據傳輸到數據存儲端；3）Kinesis Data Analytics 提供完全托管的 Flink 服務 管理和監控-提供主動集群監控和維護，支持無限集群存儲，無需監控存儲瓶頸；-免費提供主題/集群運作的重要指標；-Kafka UI 功能功能強大強大-可使用 Metrics API 選擇第三方監控服務 需要進行自管理需要進行自管理：-需要分配資源來監控代理指標和磁盤空間；-需手動計算監控指標并付費消費-提供主動集群監控和維護，支持無限集群存儲，無需監控存儲瓶頸；-使用 CloudWat

141、ch 監控：免費訪問 DEFAULT 監控級別指標，但代理和分區但代理和分區額額外外收費收費；CloudWatch 無無法與法與 Datadog 和和 Dynatrace 等第三方監控等第三方監控工具原生集成工具原生集成-使用 CloudWatch 監控：免費訪問基本流級指標，但但分片級指標分片級指標額外額外收費；收費；-使用 Prometheus 監控：可與 Datadog、Lenses、New Relic 和 Sumo logic集成 部署環境 可在 AWS、Azure 和Google Cloud 等部署，提供跨云一致的體驗 僅適用于 AWS，無法滿足混合云和多云需求 僅適用于 AWS，無

142、法滿足混合云和多云需求 僅適用于 AWS，無法滿足混合云和多云需求 專家支持 Kafka 專家團隊提供 247企業級支持 一般 AWS 支持 一般 AWS 支持 一般 AWS 支持 資料來源：Confluent，AWS，中信建投 總結來看，CSP 提供的流處理服務組件化明顯，核心工作負載往往需要進一步系統優化，AWS/GCP/Azure在運維自動化及解決方案成熟度方面存在一定差異，其優勢主要在于客戶主要負載位于云廠商數據庫/數據湖/存儲之上，對于非關鍵任務（流處理）更在意易用性而非性能/穩定性等，因此當前 Confluent 的主要邏輯是 1）業 57 https:/ 美股公司深度報告 Con

143、fluent 請務必閱讀正文之后的免責條款和聲明。務運行是否必須用流處理？如果非必要，則 Confluent 作為中立解決方案服務商的重要性則會被削弱；2）如果必要，Confluent 解決方案的核心壁壘是什么？圖圖 79:流處理的業務價值（增收、降本、風險管理）流處理的業務價值（增收、降本、風險管理）數據來源：Kai Waehner58，中信建投 通常而言，微批處理的延遲在秒級59，而流處理的延遲在毫秒級別。目前看，1）Netflix 等視頻平臺對于流處理的需求是顯著剛性的，主要由于視頻播放延遲直接影響用戶體驗，因此流處理服務有重要業務價值。2）金融交易欺詐監測，由于金融欺詐往往具有時效性，

144、欺詐者會快速轉移資金或完成非法交易，因此延遲對于風險管理/損失控制有非常重要的業務價值。3）物聯網/自動駕駛，自動駕駛汽車的決策延遲直接影響行駛安全。例如，緊急制動或避障動作需要在 0.1 秒級內完成。4）本地生活，如 Uber、Yelp、Doordash 等，服務履約的時效性與用戶體驗直接相關。5）實時推薦系統，根據用戶實時點擊行為計算從而進行內容/商品/廣告的實時推薦。6）深度學習，可用于模型的在線推理和離線訓練，降低模型推理延遲。對于上述業務而言，流處理顯然是必需品，其延遲對于業務為關鍵價值/指標，難以通過批處理系統替代。隨著流處理系統在逐步成熟，有望承接更多業務場景。隨著流處理系統在逐

145、步成熟，有望承接更多業務場景。據A survey on the evolution of stream processing systems，近年流處理系統在狀態管理、容錯機制上逐步成熟，如 Flink 的 Checkpoint 機制和與 Kafka 集成實現端到端僅一次處理語義，它們能更好地保證數據處理的準確性和一致性，這是過去批處理系統的核心優勢。研究認為批處理系統更適合處理有界、靜態的大數據集，可以充分利用集群資源進行高度并行化。而流處理系統則專門為連續到達的無界數據流設計，能夠實時處理并生成結果。流處理增長驅動力是流處理增長驅動力是對批處理的替代對批處理的替代+模型推理模型推理/自動駕

146、駛等新場景的增長自動駕駛等新場景的增長。據阿里云開發者公眾號，2016年 Flink 支持阿里雙 11 搜索推薦全鏈路實時化后，2017 年阿里開始將全集團的實時數據業務都遷移到 Flink 平 58 https:/www.kai-waehner.de/blog/2023/12/21/the-data-streaming-landscape-2024/59 Micro-batch and Data Frequency for Stream Processing on Multi-cores。38 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。臺上。2020 年，Fl

147、ink 流批一體 SQL/Table API 在雙 11 落地60，21 年阿里逐步用 Flink 替代批處理任務場景61。另一方面，如 OpenAI 推出 GPT 系列大模型，Tesla 24 年年內推進 FSD 上線，這意味著 AI 推理/自動駕駛的需求顯著增長，進而推動對于流處理系統的需求增長?？傮w來看，2019 年 Flink China 大會，阿里提出當前流處理需求占比約占所有數據處理需求的不到 10%，而批處理占70%，OLAP 處理10%。即便不考慮對批處理的替代，相比于 OLAP 2023 年 118 億美元的市場規模，流處理當前的商業化進展也較為落后，Confluent FY

148、2023 收入 7.77 億美元，對比 OLAP 龍頭 MongoDB（23 年收入 16.8 億美元）有一定差距。我們認為行業競爭格局并非導致 Confluent 商業化落后的原因，可以看到 CSP 主要以組件方式提供服務，缺乏系統優化。相反，Confluent的問題在于 1）Kafka 主要聚焦流存儲，而引入 Flink 流計算引擎，Confluent 能夠提供更多創造業務價值的用例，并驅動用戶加速部署/遷移。2）流處理在多數企業內部并非關鍵系統，IT 預算占比較低，在 IT 支出提升后，托管帶來的運維成本節約能夠覆蓋工程師成本，企業才會轉向上云，Confluent 的網絡效應才會體現。圖

149、圖 80:70%業務由批處理系統負責，流處理系統占比低于業務由批處理系統負責，流處理系統占比低于 10%數據來源：Flink-構建下一代大數據處理引擎，中信建投 圖圖 81:引入引入 Flink 后的后的 Confluent Cloud 解決方案解決方案 數據來源：Confluent62，中信建投 60 Flink 流批一體在阿里雙 11 首次落地的背后。61 https:/ 62 https:/www.confluent.io/blog/introducing-flink-on-confluent-cloud/39 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。F

150、link：垂直拓展至流計算領域，向流數據處理平臺演化：垂直拓展至流計算領域，向流數據處理平臺演化 流處理正逐步取代流處理正逐步取代 Lambda 架構，架構，Flink 提供了同類最優選擇。提供了同類最優選擇。大數據的 Lambda 架構主要分為批處理層和流處理層，批處理層采用 MapReduce、Spark 等技術進行數據批量處理，而流處理層中采用 Storm、Spark Streaming等技術進行實時處理。由于需要同時維護兩個單獨的代碼庫分別進行批處理和流處理，維護和調試復雜性很高，因此需要一種范式進行流批一體處理。Storm 雖然可以做到低延遲，但是無法實現高吞吐，也不能在故障發生時準

151、確地處理計算狀態。Spark Streaming 通過采用微批處理方法實現了高吞吐和容錯性，但是犧牲了低延遲和實時處理能力。而 Flink 是一種兼具高吞吐、低延遲和高性能的實時流計算框架。圖圖 82:大數據處理的大數據處理的 Lambda 架構架構 圖圖 83:流處理架構流處理架構 數據來源：Fink原理、實戰與性能優化，中信建投 數據來源：Fink原理、實戰與性能優化，中信建投 Flink 采用采用 JobManager 和和 TaskManager 的主的主/從架構。從架構。JobManager 是主節點，作為 Flink 集群的控制中心，負責協調和調度。TaskManager 作為工作

152、節點，負責執行實際的數據處理任務，管理任務的運行狀態，并參與檢查點的創建以實現狀態的一致性保證。Client 不是運行時和程序執行的一部分，但它用于提交作業到 Flink 集群。圖圖 84:Flink 組件棧組件棧 圖圖 85:Flink 架構架構 數據來源：Apache Flink，中信建投 數據來源：Apache Flink，中信建投 Flink 使用分布式快照（使用分布式快照（Distributed Snapshots）代替微批處理模型，避免高吞吐量以犧牲延遲為代價。代替微批處理模型，避免高吞吐量以犧牲延遲為代價。傳統快照機制的問題在于：1）需要所有節點停止工作，即暫停整個計算過程，影響

153、到數據處理效率和時效性；2）需要保存所有節點的操作中的狀態以及所有在傳輸中的數據，消費大量的存儲空間。Flink 采用基于 Chandy-lamport 算法的異步快照方式。Flink 定期對正在運行的流拓撲的狀態做快照，在數據流中插入稱為 Barrier 的特 40 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。殊標記，并將這些快照存儲到持久存儲（例如，存儲到 HDFS 或內存中文件系統）。通過狀態保存，當系統需要從故障中恢復時，可利用這些快照迅速回滾到之前的快照生成式時刻重新進行流處理。Flink 僅記錄自上一個檢查點以來狀態的變化（即增量檢查點），而不是整個狀

154、態的全量復制，減少了創建檢查點所需的時間和存儲空間，降低了對吞吐量的影響。同時檢查點的創建與數據處理同步進行，barrier 像業務數據數據管道中流動，減少了處理延遲，避免了因定期停止處理來創建快照而造成的吞吐下降。對于小狀態（例如，計數或其他統計摘要），這種持久化開銷通?？珊雎圆挥?，而對于大狀態，狀態持久化間隔需要在吞吐量和恢復時間之間進行權衡。圖圖 86:Flink 異步快照機制異步快照機制 數據來源：Slidestalk 63，中信建投 Flink 通過通過 MicroBatch 訪問狀態數據實現高吞吐。訪問狀態數據實現高吞吐。為保證流計算狀態一致性64，流處理系統要將狀態數據存儲在狀態

155、后端，用來做分布式快照保證容錯。但主流的狀態后端，如 RocksDB、Niagara 等，成為一個性能瓶頸：每次讀寫狀態時，數據必須序列化和反序列化，這會消耗 CPU 資源；當狀態存儲在磁盤上時，涉及磁盤 I/O操作。Flink 采取的解決方式是當需要訪問狀態時，緩存一批事件數據后再做批量處理，對于相同 key 的事件只需對狀態進行一次訪問操作，減少了狀態訪問的總次數。在數據中 key 重復率較高的場景下效果更為明顯。Flink 采用有狀態的運算采用有狀態的運算實現低延時實現低延時。在 Flink 中會將算子的中間計算結果/緩存數據保存在內存/文件系統中，下一個算子可從當前狀態獲取中間結果進行

156、運算，而無需反復訪問外部存儲或重新處理所有歷史數據，減少不必要的數據副本，優化系統性能。63 https:/ 64 一致性是指在流處理系統中，無論發生何種情況，包括系統正常運行、故障恢復、擴展或升級等，流處理任務內部維護的狀態信息以及對外輸出的數據應當保持邏輯上的一致性。41 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 87:狀態共享狀態共享 圖圖 88:狀態共享帶來性能優化狀態共享帶來性能優化 數據來源：A catalog of stream processing optimizations，中信建投 數據來源：A catalog of stream pr

157、ocessing optimizations，中信建投 Flink 原生迭代運算符使其在圖形分析和機器學習場景有優勢。原生迭代運算符使其在圖形分析和機器學習場景有優勢。Flink 的迭代運算符允許在數據流上直接定義循環處理邏輯，無需用戶手動管理中間狀態或數據交換。迭代運算符內部實現了數據的循環流動，直到滿足某個停止條件（如達到指定迭代次數、收斂閾值）為止。這種方式自然適合于需要多次迭代以逐漸逼近結果的算法，如機器學習模型訓練。如機器學習領域的梯度下降法。Flink 的迭代運算符允許模型參數在每輪迭代中自動更新，同時利用 Flink 的狀態管理機制來維護中間結果，簡化編程模型實現，減少序列化和網

158、絡傳輸開銷而加快了迭代速度。此外，Flink 的低延遲特性使得模型訓練和在線預測更加實時，有利于實時 ML 應用。對于圖形處理，如廣度優先搜索、最短路徑等圖算法往往需要多輪遍歷圖的節點和邊。Flink 的迭代機制天然適配這類問題，它可以在每次迭代中處理一部分圖結構，更新節點狀態，然后基于更新狀態繼續下一輪迭代，直到找到解或滿足終止條件。這比傳統批處理方式更高效，因為它能連續處理數據流并在內存中維護狀態，減少磁盤 I/O。圖圖 89:Built-in Looping 與與 Driver-based Looping 數據來源：Slidestalk，中信建投 注：Flink采用內置循環允許數據在計算

159、過程中自然地流動并通過循環結構多次傳遞，而無需顯式地將數據寫入外部存儲再讀取回來；Hadoop、Spark等基于驅動器的循環中，驅動器會調度任務執行，并在所有任務完成后收集結果，然后決定是否需要再次迭代。每個作業的輸出成為下一個作業的輸入，每次迭代之間涉及大量的磁盤I/O操作 42 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。最終性能方面，據 Yahoo 早期測試結果，Flink 和 Storm 的性能相似，而 Spark Streaming 延遲更高，但能夠處理更高的吞吐量。據美團，Identity 邏輯下，Flink 吞吐是 Storm 的 3.2x（1 個分

160、區）/4.6x（8 個分區），且延時大幅低于 Storm。在 Sleep 邏輯下，兩者吞吐相似，但 Flink 的延遲只有 Storm 的 15.5%。Exactly Once 的吞吐較 At Least Once 而言下降了 6.3%，延遲基本沒有差異。而 Storm 在 At Most Once 語義下的吞吐較 At Least Once 而言提高了 16.8%，并且在 QPS 較低時，延遲基本無差異，但隨著 QPS 增大差異開始增大，At Most Once 的延遲較低?？偟膩碚f，總的來說，Flink 適合適合 Exactly Once+高吞吐高吞吐+低延遲需要進行狀態管理低延遲需要進行

161、狀態管理/窗口統計的場景。窗口統計的場景。圖圖 90:Storm、Flink、Spark 窗口時間對比窗口時間對比 圖圖 91:Storm、Flink、Spark 吞吐量與延時關系圖吞吐量與延時關系圖 數據來源：Yahoo，中信建投 數據來源：Yagoo65，中信建投 圖圖 92:Storm、Flink Identity 單線程吞吐量單線程吞吐量 圖圖 93:Storm、Flink Identity 單線程作業延遲單線程作業延遲 數據來源：美團，中信建投 數據來源：美團，中信建投 65 https:/ 43 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 94:

162、Storm、Flink Sleep 單線程吞吐量單線程吞吐量 圖圖 95:Storm、Flink Sleep 單線程單線程延遲延遲 數據來源：美團，中信建投 數據來源：美團，中信建投 圖圖 96:Windowed Word Count Flink 不同語義吞吐量對比不同語義吞吐量對比 圖圖 97:Windowed Word Count Storm 不同語義吞吐量對比不同語義吞吐量對比 數據來源：美團，中信建投 數據來源：美團，中信建投 圖圖 98:Windowed Word Count Flink 不同語義延遲對比不同語義延遲對比 圖圖 99:Windowed Word Count Storm

163、 不同語義延遲對比不同語義延遲對比 數據來源：美團，中信建投 數據來源：美團，中信建投 44 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。表表 6:Storm、Spark、Flink 對比對比 Storm Spark Flink 產生時間 2011 2014 2016 架構 Kappa 架構 主從架構 Kappa 架構 計算模型 流處理 批處理和流處理 批處理和流處理 流處理模式 事件驅動 微批處理，批是流的特例 實時處理，流是批的特例 編程語言 Java/Closure Java/Scala Java/Scala 集群協調 ZooKeeper Standalon

164、e/YARN/Mesos Standalone/YARN/Mesos 容錯機制 Record ACKs：對每個消息進行全鏈路跟蹤，失敗或超時進行重發?；诨?RDD 的的血統血統+檢查點檢查點：RDD 的Lineage 機制記錄了每一個 RDD 的依賴關系鏈；檢查點將 RDD 的數據寫入到一個持久化存儲，在 RDD 的依賴鏈變得過于長，重新計算成本過高時，系統可以直接從檢查點恢復，避免了從頭開始重做大量的計算。分布式一致性快照機制：分布式一致性快照機制：通過分布式一致性快照機制，對數據流和算子狀態進行保存。在發生錯誤時，使系統能夠進行回滾 至多一次 支持 支持 支持 至少一次 支持 支持 支

165、持 精確一次 通過 Trident 支持，但會增加延遲 支持，通過 Structured Streaming 的流處理模式支持，但也會增加延遲 支持：通過狀態管理跟蹤中間結果和狀態，采用檢查點機制從最近的檢查點恢復狀態，狀態保存、barrier 對齊等影響延遲，但通過局部攢批減少性能負面影響。延時 延時低，毫秒級：延時低，毫秒級：網絡直傳+內存計算 延時高，秒級：延時高，秒級：采用微批處理，緩沖機制導致延時較高 延時低，毫秒級：延時低，毫秒級：1）Flink 使用原生閉環迭代運算符，這使得機器學習和圖形處理更快。支持毫秒級批處理和流處理；2）有狀態的運算保存中間結果，避免重復計算 吞吐量 低低

166、：Storm容錯機制中緩存容量限制和Acker Bolt 處理能力限制導致吞吐不高。高高：采用批處理框架吞吐量高 高高：通過 MicroBatch 訪問狀態數據 擴展性 高：高：允許用戶通過增加更多的工作節點（Worker nodes）來線性地擴展處理能力 高：高：高度可擴展性，可以在集群中不斷添加 n 個節點，一個已知的大型 Spark 集群可以有 8000 個節點 高：高：憑借其高效的網絡通信協議，可擴展到數千個節點，同時減少延遲和吞吐量損失 滑動窗口 支持 支持 支持 計數窗口 支持 不支持 支持 會話窗口 不支持 不支持 支持 反壓 支持 支持 支持 成本 資源消耗相對較低，適合大規模

167、集群 由于 Spark 需要大量 RAM 才能在內存中運行，因此在集群中增加它會逐漸增加其成本。Apache Flink 也需要大量的 RAM 在內存中運行，所以它的成本會逐漸增加。45 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。語言支持 支持 Clojure、Java、Ruby 和 Python等。支持 Java、Scala、Python 和 R。Spark是在 Scala 中實現的，提供其他語言的 API，如 Java、Python 和 R。支持 Java、Scala、Python 和 R。Flink 是用 Java 實現的，同時也提供了Scala API。

168、資料來源：Apache Storm，Apache Spark，Apache Flink，中信建投 Flink 和和 Kakfa 的協同如何體現？的協同如何體現？流處理技術正改變著數據管理與分析的格局。Kafka 擅長處理大規模、高速的流數據攝入，能自動擴展以適應任意規模的數據流量，確保數據被精準導向所需位置，這是其核心優勢之一。在此基礎上，流處理不僅僅是數據攝取，更重要的是對這些實時數據流進行即時轉換，包括合并不同數據源、數據過濾與清洗等操作，這在 ksqlDB 等工具中通過維護狀態實現。目前，大多數應用場景集中于數據的即時攝取階段，即流攝取，而非流處理本身。數據處理通常發生在數據被導入到 S

169、nowflake 或 Redshift 等數據倉庫之后。然而，隨著 Flink 這類技術的集成，流處理的潛力可被進一步挖掘，它使得更多的客戶能夠在數據流入時直接進行高級處理，這不僅增加了數據處理的深度和價值，還可能通過數據流的拆分、合并等操作提升處理效率，進而提高整體吞吐量，例如從每秒 5MB 提升至 8MB。因此，Flink 的加入對于 Confluent 而言，是一個戰略性的補充，預示著從單純的流數據攝取向更高附加值的流處理轉型，有望開啟新的增長點，并顯著提升其市場競爭力和客戶價值。成長邏輯：數字原生企業仍具增長空間，成長邏輯：數字原生企業仍具增長空間，Flink 有望驅動用戶滲透有望驅動

170、用戶滲透 基于 Gartner 和 Confluent 內部估計，2022 年 Confluent 的 TAM 為600 億美元，包含 1）應用基礎設施和中間件（500 億美元73%）；2）數據庫管理市場（920 億美元10%）；3）分析平臺市場（320 億美元30%）；4）數據管理市場（100 億美元50%）。Confluent 預計 2022-25 年 CAGR 為 19%，至 2025 年 TAM 將達 1000億美元。從客戶結構上看，Confluent 預計 LTM$1B 的大型企業將貢獻 53.1%的收入，而 LTM$1B 的企業將貢獻 46.9%的收入。圖圖 100:Conflue

171、nt TAM 及增長（及增長（$bn）數據來源：Confluent 4Q23 Investor Presentation，中信建投 注：(1)市場規模來自Gartner；(2)市場份額來自Confluent內部分析；(3)基于Gartner對2022-2025年各個市場規模的估計 46 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 101:Confluent TAM（按公司拆分）（按公司拆分）數據來源：Confluent 4Q23 Investor Presentation，中信建投 注：(1)公司數量來自Capital IQ；(2)ARR來自Confluen

172、t內部預測。1Q24 大型客戶拓客大型客戶拓客驅動驅動總客戶數增長速率提升?？偪蛻魯翟鲩L速率提升。Confluent 1Q24 總客戶數已突破 5000 家，同比+3%，2020-2023 CAGR 為 46%。其中 APP 大于 100K+的客戶數為 1260 家，同比+3%，2020-2023 CAGR 為 38%。APP 大于 1M 的客戶數為 168 家，同比+6%。Confluent 1Q24 總客戶數增長速度環比提升，且主要由大型客戶拓客驅動。展望未來，Kafka 與 Flink 的客戶重疊度約為 75%，Flink 的收購將有望顯著增加公司的客戶數和 TAM。圖圖 102:Con

173、fluent 總客戶數及增長總客戶數及增長 圖圖 103:Confluent 按按 ARR 分類的客戶數分類的客戶數 數據來源：Confluent，中信建投 數據來源：Confluent，中信建投 0%5%10%15%20%25%30%35%01000200030004000500060001Q202Q203Q204Q201Q212Q213Q214Q211Q222Q223Q224Q221Q232Q233Q234Q231Q24總客戶數量%yoy0%10%20%30%0500100015001Q202Q203Q204Q201Q212Q213Q214Q211Q222Q223Q224Q221Q232Q

174、233Q234Q231Q24ARR超$100K+的客戶ARR超$1M+的客戶ARR超$100K+的客戶%yoyARR超$1M+的客戶%yoy 47 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。圖圖 104:在同一生命周期階段在同一生命周期階段，Flink 的增長大致與的增長大致與 Kafka相匹配相匹配（基于月獨立用戶數）（基于月獨立用戶數）圖圖 105:在同一生命周期階段在同一生命周期階段，Flink 的增長大致與的增長大致與 Kafka相匹配相匹配（基于月下載量）（基于月下載量）數據來源：Confluent66，中信建投 數據來源：Confluent，中信建投

175、 圖圖 106:Flink 與與 Kafka 的協同：的協同：Flink 管理計算需求，而管理計算需求，而 Kafka 則提供存儲層則提供存儲層 數據來源：Confluent，中信建投 目前 Confluent Cloud 客戶結構中，25%30%的客戶是由 Confluent Platform 轉化而來；約 50%的客戶由開源 Kafka/新用例轉化而來；另外 25%的客戶是從 AWS Kinesis、AWS MSK、GCP Pub/Sub 或 Azure Event Hubs等服務中遷移過來。Confluent 最容易獲取的客戶是內部沒有相關專業知識的公司，他們最傾向于購買完全托管服務。對

176、于開源 Kafka 用戶，如果他們在部署和允許中遇到困難，例如集群擴展和工作負載重新平衡，這部分客戶的轉化相對容易，大約在 1 個月之內可以完成轉化。如果開源 Kafka 用戶只是認為部署和運維較為繁重，大致需要 46 個月的銷售周期進行轉換。數字原生企業客戶仍有較大增長空間。數字原生企業客戶仍有較大增長空間。從企業性質上看，Confluent 的客戶可分為數字原生公司（Digital-Native Business）和傳統企業。數字原生公司使用量較高，達到 GB/s 級使用規模，例如 Pinterest、Uber、Lyft、Stripe、Square 等。對于這類企業，流處理在其業務中的重要

177、性高，他們往往擁有自己的 DevOps 團隊，更有可能會選擇自己進行流處理，而不是使用簡化的 API。主要原因在于對自主控制能力和定制化能力的需求。其他原因包括對數據隱私和網絡傳輸流量成本的考慮。這部分市場 Confluent 尚未滲透，仍有很大增長空間。對數字原生公司來說，80%90%的成本在于網絡傳輸成本，Confluent 的主要策略是采用多種技術避免數據跨區域傳輸以降低成本。如前所述，EU/英國反壟斷監管壓力下微軟/谷歌/亞馬遜均取消數據遷移費用，未來數據傳輸費用 66 https:/www.confluent.io/blog/apache-flink-for-stream-proce

178、ssing/48 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。有望下降。圖圖 107:2021-2026E 全球數字原生企業全球數字原生企業 IT 支出預測支出預測 圖圖 108:數字原生企業分類數字原生企業分類 數據來源：IDC，中信建投 數據來源：IDC，中信建投 傳統企業方面，高盛、摩根大通、沃爾瑪等大型企業使用量較高，但大部分非科技傳統企業的使用規模在15MB/s。對他們來講，90%的成本是計算成本，Confluent 采取的現有策略包括云原生多租戶能力，并且根據用戶實際使用的計算能力，而不是固定的節點集群來收費等。盈利預測盈利預測：預計：預計 24-26

179、 年收入維持年收入維持 Mid-teens 增長，增長，Non-GAAP 利潤利潤率穩步提升率穩步提升 我們預計公司 FY2024-26 年營業收入分別達 9.7、12.3、15.6 億美元，同比增速分別為 25.0%/26.9%/26.5%。其中，訂閱業務 FY2024-26 收入預計可達 9.2、11.7、14.9 億美元，同比增速分別達 26.6%/27.2%/27.0%，服務收入分別達 0.5、0.6、0.7 億美元，同比增速分別達 0.5%/21.1%/16.4%。Non-GAAP 凈利潤分別達 1.0、1.5、2.2億美元，同比增速分別達 629.9%/54.9%/46.2%，對應

180、 Non-GAAP 凈利率為 9.8%/11.9%/13.7%。表表 7:FY2021-26 Confluent 盈利預測（百萬美元）盈利預測（百萬美元）2021A 2022A 2023A 2024E 2025E 2026E 營業收入(百萬美元)387.9 585.9 777.0 971.2 1,232.4 1,559.0 同比增速(%)63.9%51.1%32.6%25.0%26.9%26.5%訂閱收入 347.1 535.0 729.1 923.1 1,174.2 1,491.3 同比增速(%)66.4%54.1%36.3%26.6%27.2%27.0%服務收入 40.8 50.9 47.

181、8 48.1 58.2 67.8 同比增速(%)45.9%24.9%-6.1%0.5%21.1%16.4%毛利潤 250.6 383.5 547.3 703.5 905.1 1,160.5 毛利率(%)64.6%65.5%70.4%72.4%73.4%74.4%Non-GAAP 凈利潤-342.8-161.4 13.1 95.4 147.7 215.9 同比增速（%）-49.2%-27.5%1.7%9.8%12.0%13.8%資料來源：公司公告，中信建投 49 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。估值估值 Confluent 當前對應 25 年 EV/Re

182、v 比例為 6.66?？杀裙局?，MongoDB、Snowflake、Datadog、Cloudflare 等明顯存在更高估值倍數（EV/Rev），而 Informatica、Dynatrace、Zscaler、Gitlab 等估值水位更低，Elastic、Confluent、DoubleVerify 較上述公司估值存在更明顯的折價。圖圖 109:25 年年 EV/Rev 估值對比估值對比（數據截止（數據截止 2024/5/27）數據來源：彭博，中信建投 表表 8:25 年年 EV/Rev 估值對比估值對比（數據截止（數據截止 2024/5/27）EV/Rev-24E EV/Rev-25E F

183、Y24 收入增長 FY25 收入增長 FY24 經調整利潤增長 FY25 經調整利潤增長 CFLT 8.30 6.66 23.50%24.57%409.82%68.48%SNOW 13.10 10.58 24.03%23.87%-36.708 58.43%MDB 12.00 9.99 15.06%20.10%-26.62%37.04%ESTC 6.80 5.76 21.05%17.99%370.10%16.96%GLTB 9.80 7.74 25.71%27%7.96%115.70%DDOG 13.90 11.26 22.33%23.46%18.62%22.36%ZS 9.60 7.66 31

184、.16%25.26%54.05%18.66%NET 13.60 10.66 27.33%27.59%27.28%23.81%CRWD 19.20 15.21 29.99%26.23%27.45%23.80%INFA 5.60 5.21 6.32%7.52%21.23%9.98%DV 4.10 3.45 16.77%18.83%34.28%24.76%資料來源：彭博，中信建投 CFLTSNOWMDBESTCGLTBDDOGZSNETINFADVDT-2 4 6 8 10 120%5%10%15%20%25%30%50 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。投資

185、評價和建議投資評價和建議 Confluent 當前對應 25 年 EV/Rev 比例為 6.66?？杀裙局?，MongoDB、Snowflake、Datadog、Cloudflare 等明顯存在更高估值倍數（EV/Rev），而 Informatica、Dynatrace、Zscaler、Gitlab 等估值水位更低，Elastic、Confluent、DoubleVerify 較上述公司估值存在更明顯的折價。我們預計公司 FY2024-26 年營業收入分別達 9.7、12.3、15.6億美元，同比增速分別為 25.0%/26.9%/26.5%。Non-GAAP 凈利潤分別達 1.0、1.5、2

186、.2 億美元，同比增速分別達629.9%/54.9%/46.2%，對應 Non-GAAP 凈利率為 9.8%/11.9%/13.7%?？傮w來看，我們認為 Confluent 在流處理領域地位穩固，Gen AI 用例/自動駕駛對流處理的驅動有望逐步兌現，結合估值與業務增長情況，當前估值具備吸引力，首次覆蓋 Confluent 并給予“買入”評級。風險分析風險分析 市場市場競爭加劇競爭加劇風險風險：隨著數據流處理和事件驅動架構的普及，更多競爭對手可能涌現，如 Apache Pulsar 等開源項目，以及已建立企業如 IBM、AWS 等提供的同類服務，可能侵蝕市場份額。技術創新風險：技術創新風險：技

187、術快速迭代，若 Confluent 不能持續創新保持其技術領先地位，可能會被擁有更先進技術的競爭對手超越。許可證變更風險許可證變更風險：作為基于開源項目 Apache Kafka 的公司，Confluent 對其社區版的許可證條款進行的任何更改都可能影響用戶基礎和市場接受度。數據安全與隱私數據安全與隱私：處理大量數據流時，數據保護法規如 GDPR 等的合規成本及潛在違規罰款構成風險。經濟周期性波動經濟周期性波動風險風險：全球經濟衰退或行業特定的經濟周期可能減少企業 IT 支出，影響 Confluent 的業務需求。表表 9:Confluent 收入增速變化對于收入增速變化對于 25 年年 No

188、n-GAAP EPS 的敏感性分析的敏感性分析 -10%-5%0%5%10%-10%-5.8%-6.8%-7.5%-8.6%-9.5%-5%-2.0%-3.0%-3.8%-4.8%-5.7%0%1.8%0.8%0.0%-1.0%-1.9%5%5.6%4.6%3.8%2.8%1.9%10%9.4%8.4%7.5%6.6%5.7%資料來源：公司公告，中信建投 51 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。報表預測報表預測 資產負債表（百萬資產負債表（百萬美美元）元）利潤表（百萬利潤表（百萬美美元）元）會計年度會計年度 2022A 2023A 2024E 2025E

189、 2026E 會計年度會計年度 2022A 2023A 2024E 2025E 2026E 流動資產流動資產 2,198.13 2,251.66 1,962.53 1,702.43 1,492.25 營業收入營業收入 585.94 776.95 971.19 1,232.44 1,559.04 現金 1,926.83 1,900.77 1,491.11 1,104.21 735.50 營業成本 202.42 229.67 267.66 327.34 398.50 應收票據及應收賬款合178.19 229.96 309.02 392.15 496.07 其他營業費用 0.00 34.85 0.0

190、0 0.00 0.00 其他應收款 0.00 0.00 0.00 0.00 0.00 銷售和管理費用 582.16 642.45 715.65 846.54 1,008.52 預付賬款 57.23 76.99 101.19 128.41 162.44 研發費用 264.04 348.75 377.67 429.96 497.13 存貨 0.00 0.00 0.00 0.00 0.00 財務費用 0.00 0.00 46.85 48.24 49.56 其他流動資產 35.88 43.94 61.21 77.67 98.25 其他經營損益 0.00 0.00 0.00 0.00 0.00 非流動資

191、產非流動資產 146.72 209.15 191.44 173.73 156.02 投資收益 0.00 0.00 0.00 0.00 0.00 長期投資 0.00 0.00 0.00 0.00 0.00 公允價值變動收益 0.00 0.00 0.00 0.00 0.00 固定資產 29.09 54.01 45.55 37.09 28.63 營業利潤營業利潤-462.67-478.77-436.64-419.65-394.67 無形資產 0.00 55.49 46.24 36.99 27.75 其他非經營損益 16.42 72.10 28.83 28.83 28.83 其他非流動資產 117.6

192、4 99.65 99.65 99.65 99.65 利潤總額利潤總額-446.26-406.67-407.81-390.82-365.84 資產總計資產總計 2,344.85 2,460.81 2,153.97 1,876.17 1,648.28 所得稅 6.29 36.07 0.00 0.00 0.00 流動負債流動負債 424.33 487.02 588.00 701.01 838.97 凈利潤凈利潤-452.55-442.75-407.81-390.82-365.84 短期借款 0.00 0.00 0.00 0.00 0.00 少數股東損益 0.00 0.00 0.00 0.00 0.0

193、0 應付票據及應付賬款合21.44 6.71 16.99 20.78 25.30 歸屬母公司凈利潤歸屬母公司凈利潤-452.55-442.75-407.81-390.82-365.84 其他流動負債 402.89 480.31 571.01 680.23 813.67 EBITDA-397.50-343.06-343.26-324.87-298.57 非流動負債非流動負債 1,151.04 1,163.37 1,163.37 1,163.37 1,163.37 EPS（元）-1.42-1.39-1.28-1.23-1.15 長期借款 1,084.50 1,088.31 1,088.31 1,0

194、88.31 1,088.31 Non-GAAP 凈利潤凈利潤-161.35 13.07 95.37 147.69 215.92 其他非流動負債 66.54 75.06 75.06 75.06 75.06 Non-GAAP 凈利率-27.5%1.7%9.8%12.0%13.8%負債合計負債合計 1,575.37 1,650.39 1,751.37 1,864.39 2,002.34 主要財務比率主要財務比率 少數股東權益 0.00 0.00 0.00 0.00 0.00 會計年度會計年度 2022A 2023A 2024E 2025E 2026E 股本 0.00 0.00 0.00 0.00 0

195、.00 成長能力成長能力 資本公積 1,980.34 2,453.29 2,453.29 2,453.29 2,453.29 營業收入(%)51.07 32.60 25.00 26.90 26.50 留存收益-1,210.86-1,642.88-2,050.70-2,441.52-2,807.36 歸屬于母公司凈利潤-30.62 8.87 11.24 5.09 7.68 歸屬母公司股東權益 769.48 810.42 402.60 11.78-354.06 獲利能力獲利能力 負債和股東權益負債和股東權益 2,344.85 2,460.81 2,153.97 1,876.17 1,648.28

196、毛利率(%)65.45 70.44 72.44 73.44 74.44 凈利率(%)-77.23-56.98-41.99-31.71-23.47 ROE(%)-58.81-54.63-101.30-3,317.44 103.33 ROIC(%)1,014.51 3,656.90-514.35-382.47-289.04 償債能力償債能力 現金流量表（百萬現金流量表（百萬美美元）元）資產負債率(%)67.18 67.07 81.31 99.37 121.48 會計年度會計年度 2022A 2023A 2024E 2025E 2026E 凈負債比率(%)-109.47-100.25-100.05-

197、134.91-99.65 經營活動現金流經營活動現金流-157.33 -103.66-369.64-367.49 -347.98 流動比率 5.18 4.62 3.34 2.43 1.78 凈利潤-452.55-442.75-407.81-390.82-365.84 速動比率 5.10 4.53 3.23 2.32 1.66 折舊攤銷 48.76 63.61 17.71 17.71 17.71 營運能力營運能力 財務費用 0.00 0.00 46.85 48.24 49.56 總資產周轉率 0.25 0.32 0.45 0.66 0.95 其他經營現金流 246.46 275.48-48.38

198、-42.63-49.41 應收賬款周轉率 3.29 3.38 3.14 3.14 3.14 投資活動現金流投資活動現金流-865.81-84.85 28.83 28.83 28.83 每股指標（元）每股指標（元）資本支出-17.44-29.20 0.00 0.00 0.00 每股收益(最新攤薄)-1.42-1.39-1.28-1.23-1.15 其他投資現金流-848.37-55.65 28.83 28.83 28.83 每股經營現金流(最新-0.50-0.33-1.23-1.16-1.09 籌資活動現金流籌資活動現金流 82.24 102.37-46.85-48.24-49.56 每股凈資產

199、(最新攤薄)2.42 2.55 1.27 0.04-1.11 短期借款 0.00 0.00 0.00 0.00 0.00 估值比率估值比率 長期借款 3.80 3.81 0.00 0.00 0.00 P/E-21.17-21.64-23.50-24.52-26.19 其他籌資現金流 78.44 98.56-46.85-48.24-49.56 P/B 12.45 11.82 23.80 813.42-27.07 現金凈增加額現金凈增加額-940.90-86.14-409.66-386.91-368.71 EV/EBITDA 1.97 2.14 0.89-0.33-1.70 資料來源：公司公告，i

200、FinD，中信建投 52 美股公司深度報告 Confluent 請務必閱讀正文之后的免責條款和聲明。分析師介紹分析師介紹 崔世峰崔世峰 海外研究首席分析師，南京大學碩士，7 年買方及賣方復合從業經歷，專注于互聯網及科技公司研究，擅長游戲行業研究。2022-2023 年新財富港股及海外最佳研究團隊入圍，2019-2020 年新財富傳媒最佳研究團隊第二名核心成員。許悅許悅 海外研究員，南洋理工大學碩士，專注于港股互聯網及美股軟件研究，2022 年加入中信建投海外前瞻組，2023 年新浪金麒麟港股及海外市場菁英分析師第二名，2023 第十七屆水晶球最佳分析師海外行業入圍。美股公司深度報告 Confl

201、uent 評級說明評級說明 投資評級標準 評級 說明 報告中投資建議涉及的評級標準為報告發布日后 6個月內的相對市場表現，也即報告發布日后的 6 個月內公司股價（或行業指數）相對同期相關證券市場代表性指數的漲跌幅作為基準。A 股市場以滬深300 指數作為基準；新三板市場以三板成指為基準；香港市場以恒生指數作為基準；美國市場以標普 500 指數為基準。股票評級 買入 相對漲幅 15以上 增持 相對漲幅 5%15 中性 相對漲幅-5%5之間 減持 相對跌幅 5%15 賣出 相對跌幅 15以上 行業評級 強于大市 相對漲幅 10%以上 中性 相對漲幅-10-10%之間 弱于大市 相對跌幅 10%以上

202、 分析師聲明分析師聲明 本報告署名分析師在此聲明：（i）以勤勉的職業態度、專業審慎的研究方法，使用合法合規的信息，獨立、客觀地出具本報告,結論不受任何第三方的授意或影響。（ii）本人不曾因，不因，也將不會因本報告中的具體推薦意見或觀點而直接或間接收到任何形式的補償。法律主體說明法律主體說明 本報告由中信建投證券股份有限公司及/或其附屬機構（以下合稱“中信建投”）制作，由中信建投證券股份有限公司在中華人民共和國（僅為本報告目的，不包括香港、澳門、臺灣）提供。中信建投證券股份有限公司具有中國證監會許可的投資咨詢業務資格，本報告署名分析師所持中國證券業協會授予的證券投資咨詢執業資格證書編號已披露在報

203、告首頁。在遵守適用的法律法規情況下，本報告亦可能由中信建投（國際）證券有限公司在香港提供。本報告作者所持香港證監會牌照的中央編號已披露在報告首頁。一般性聲明一般性聲明 本報告由中信建投制作。發送本報告不構成任何合同或承諾的基礎，不因接收者收到本報告而視其為中信建投客戶。本報告的信息均來源于中信建投認為可靠的公開資料，但中信建投對這些信息的準確性及完整性不作任何保證。本報告所載觀點、評估和預測僅反映本報告出具日該分析師的判斷，該等觀點、評估和預測可能在不發出通知的情況下有所變更，亦有可能因使用不同假設和標準或者采用不同分析方法而與中信建投其他部門、人員口頭或書面表達的意見不同或相反。本報告所引證

204、券或其他金融工具的過往業績不代表其未來表現。報告中所含任何具有預測性質的內容皆基于相應的假設條件，而任何假設條件都可能隨時發生變化并影響實際投資收益。中信建投不承諾、不保證本報告所含具有預測性質的內容必然得以實現。本報告內容的全部或部分均不構成投資建議。本報告所包含的觀點、建議并未考慮報告接收人在財務狀況、投資目的、風險偏好等方面的具體情況，報告接收者應當獨立評估本報告所含信息，基于自身投資目標、需求、市場機會、風險及其他因素自主做出決策并自行承擔投資風險。中信建投建議所有投資者應就任何潛在投資向其稅務、會計或法律顧問咨詢。不論報告接收者是否根據本報告做出投資決策，中信建投都不對該等投資決策提

205、供任何形式的擔保，亦不以任何形式分享投資收益或者分擔投資損失。中信建投不對使用本報告所產生的任何直接或間接損失承擔責任。在法律法規及監管規定允許的范圍內，中信建投可能持有并交易本報告中所提公司的股份或其他財產權益，也可能在過去 12 個月、目前或者將來為本報告中所提公司提供或者爭取為其提供投資銀行、做市交易、財務顧問或其他金融服務。本報告內容真實、準確、完整地反映了署名分析師的觀點，分析師的薪酬無論過去、現在或未來都不會直接或間接與其所撰寫報告中的具體觀點相聯系，分析師亦不會因撰寫本報告而獲取不當利益。本報告為中信建投所有。未經中信建投事先書面許可，任何機構和/或個人不得以任何形式轉發、翻版、

206、復制、發布或引用本報告全部或部分內容，亦不得從未經中信建投書面授權的任何機構、個人或其運營的媒體平臺接收、翻版、復制或引用本報告全部或部分內容。版權所有，違者必究。中信建投證券研究發展部中信建投證券研究發展部 中信建投（國際）中信建投（國際）北京 上海 深圳 香港 東城區朝內大街2 號凱恒中心B座 12 層 上海浦東新區浦東南路528號南塔 2103 室 福田區福中三路與鵬程一路交匯處廣電金融中心 35 樓 中環交易廣場 2 期 18 樓 電話：（8610）8513-0588 電話：（8621）6882-1600 電話：（86755）8252-1369 電話：（852）3465-5600 聯系人：李祉瑤 聯系人：翁起帆 聯系人：曹瑩 聯系人：劉泓麟 郵箱： 郵箱： 郵箱： 郵箱：charleneliucsci.hk