作者：家澤
本文整理自 2025 年雲棲大會阿里雲智能集團產品專家劉堯的主題演講《AI 時代的數據通道：雲消息隊列 Kafka 的演進與實踐》
前言
隨着 AI 業務的蓬勃興起與發展，Apache Kafka 作為數據流的關鍵入口與通道，在企業智能化轉型中的核心價值日益凸顯。非常榮幸能夠在 2025 雲棲大會上，系統性地回顧並分享雲消息隊列 Kafka 版在過去一年所取得的產品技術演進與行業實踐成果。作為承載海量消息的核心基礎設施，雲消息隊列 Kafka 版通過在架構創新、性能優化與生態融合等方面的突破性進展，為企業構建實時數據驅動的應用提供了堅實支撐，持續賦能客户業務創新。
雲消息隊列 Kafka 版的演進路線
自 2018 年基於 RocketMQ 內核支持 Kafka 協議以來，雲消息隊列 Kafka 版的產品演進始終以低成本、穩定可靠、豐富生態作為核心目標。
2023 年，我們發佈了 Kafka V2 版本，100% 兼容 Apache Kafka 開源版本，並支持跨可用區的容災能力。此階段，我們重點打磨產品穩定性，解決客户升、降配，或節點異常宕機時，數據負載因資源消耗過大、IO 負載過高，造成的服務讀寫能力差等問題，為客户提供持續可靠的 Kafka 服務。
2024 年，我們成功落地了 Kafka 的存算分離架構，實現了計算、存儲的自適應無損彈性，副本秒級切換與擴容。基於此架構，我們發佈了 Kafka V3 Severless 版本，提供 2 倍的預留彈性能力與定時彈性伸縮能力，以應對業務突發流量和大型活動高流量等場景，顯著降低客户固定預留成本。此外，增加了風險掃描、風險提示能力，幫助業務儘早發現服務可能出現的問題，進一步增強 Kafka 服務的穩定性。
2025 年截至 9 月底，我們在 Serverless 系列上拓展了基於低成本資源交付的基礎版，以及提供 10 倍彈性能力和跨可用區部署的專業版，滿足客户對極致成本效益和更高可靠性的需求。
隨着智能車聯網業務的迅速發展，Kafka 加強了終端數據分析場景鏈路的支持，提供通過 MQTT 協議傳輸數據到 Kafka 的能力，並在 Kafka 服務端提供消息數據格式化的 Schema 能力，為 RAG、數據提取、數據打標等數據加工場景奠定基礎。
在下半年，我們將加強消息數據計算能力，提供基於 SQL 語法的流數據處理，數據入表、入庫、入湖以及可視化流數據關係等能力，打造完整的流數據處理平台，為 AI 數據採集與處理提供一體化的解決方案。
接下來，我們具體介紹 2025 年產品演進的核心能力。
雲消息隊列 Kafka 版 2025 年重要演進
數據是 AI 應用的基石。面向 AI 場景 GB/PB 級別的數據，降低數據交互與存儲的成本，始終是業務發展的關鍵。基於這一目標，今年，我們在 Serverless 系列標準版的基礎上，發佈兩個新版本。
- 基礎版： 與開源自建預部署相同，但集羣採用更大比例的低成本資源，包括 HDD、OSS、Spot 實例等。同時，增加轉冷存儲，將歷史數據存儲到分佈式文件服務來降低計算與存儲的使用成本。基礎版服務可用性 99.9%，依靠使用者自主升降配提升集羣能力，一般建議用於測試或流量穩定業務場景。
- 專業版： 專業版與物理硬件調優，採用 3AZ 部署架構，提供基於預留彈性最高 10 倍無損彈性能力，滿足更高可用性及更高毛刺業務場景需要，服務可用性 99.99%。
相較於 1200MB/s 集羣吞吐量、讀寫比 1:1、SSD 雲盤三副本構建的開源集羣成本估算：基礎版降本 90%，標準版降本 75%，專業版降本 60%。
對於追求更高穩定性與可靠性的核心業務，我們建議選擇專業版。
今年 7 月，阿里雲消息隊列 ApsaraMQ 產品家族中的ApsaraMQ for RocketMQ、ApsaraMQ for Kafka，首批通過了中國信通院“Serverless 雲服務能力要求 - 消息隊列” 的權威評估，這充分彰顯了 ApsaraMQ 系列產品在自適應彈性、穩定可靠方面的技術成熟度與行業領先性。
今年，為應對 AI 驅動下智能終端業務的蓬勃發展，如車聯網/智能駕駛、語音智能識別風險等場景，我們加強了從終端到雲上服務端全鏈路的產品能力。MQTT 為終端連接雲服務提供輕量化的協議基礎，在後端數據處理前，採用 Kafka 作為流存儲的核心引擎，為數據鏈路提供按設備維度的順序性。
在數據進入 Kafka 前，MQTT 服務可提供基於 SQL 標準的數據提取，數據與數據格式處理等能力，減少數據二次處理的工作量，同時提供基於 MQTT 協議的事件查詢能力（包括訂閲/取消訂閲、消息確認等），方便實現業務邏輯閉環。典型業務場景如車聯網指令下發後，能通過 MQTT 消息確認事件被業務感知。
在語音智能識別風險等場景中，採用 MQTT+Kafka 的方案，能顯著減輕構建和維護底層數據鏈路的工作量，使開發者專注於核心業務邏輯的實現，加速業務創新與產品上線。
以上是雲消息隊列 Kafka 版在 2025 上半年重點交付的能力，接下來分享我們對雲消息隊列 Kafka 版在 AI 應用場景的一些思考。
雲消息隊列 Kafka 版在 AI 場景作為數據通道的思考
人工智能的大致分類
在過去十年間，人工智能已發展為一項變革性技術，在不知不覺中深刻地滲透到我們的日常生活。從智能手機、自動駕駛，到聊天機器人、虛擬助理，AI 改變了我們與機器的交互方式。
目前，人工智能的應用主要可以分為兩大類——預測性人工智能和生成式人工智能。
儘管人工智能技術已經存在多年，但其近期的爆發式增長，是多種因素共同作用的結果。可重複使用的大型語言模型 (LLM)、更易於訪問的機器學習 (ML) 和 GPU 的突破，共同提高了模型性能，降低了雲數據基礎設施成本，使生成式 AI 成為當下最火熱的應用方向，例如 ChatGPT、Github Copilot 等。
但任何 AI 模型，無論是用於預測 AI 還是 GenAI，都不能獨立存在。你可以有一個很棒的模型，但如果數據質量不高、不可靠、不可信或不能立即應用，這些模型就不會產生太多價值。
AI 場景下的數據特徵
下圖左側的流程圖展示了生成式人工智能從學習數據到最終應用調用，包含持續學習和迭代的完整過程。流程節點（從左到右）如下：
- 第一步：收集各種來源的原始數據，包括文本、圖像、音頻、視頻等。對數據進行清洗、標註、格式化和預處理，使其適用於模型訓練。
- 第二步：模型訓練，使用準備好的數據訓練模型。這通常涉及選擇合適的模型，定義函數和優化器，並通過大量的迭代來調整模型參數，使其能夠更好的理解數據。
- 第三步：模型評估與優化，使用獨立的評估數據集來衡量訓練好的模型的性能，例如生成內容的質量、相關性、多樣性等。根據評估結果，對模型進行調優，包括調整超參數、修改模型結構或重新訓練等，以提高模型性能。
- 第四步：模型部署，將訓練和優化好的模型部署到實際的應用環境中。
- 第五步：應用調用，用户通過應用程序或接口與部署好的模型進行交互，模型根據輸入生成相應的輸出（例如文本、圖像、音頻等）。
- 第六步：反饋與迭代，用户在使用模型的過程中產生反饋，例如對生成結果的評價、修改或新的需求。這些反饋被收集起來，作為新的數據用於模型的持續學習和改進，從而形成一個閉環。
AI 應用場景的數據呈現出與傳統業務截然不同的特徵，對數據處理與傳輸系統提出了新的挑戰。其主要特徵包括：
- 非結構化/半結構化數據佔比高：AI 模型常需處理圖像、音頻、視頻、文本、JSON、日誌等非結構化或半結構化數據。消息隊列中傳遞的往往是原始數據包（如 JSON、Protobuf、Avro格式），包含豐富的上下文信息。
- 高吞吐、低延遲：AI 系統（如實時推薦、異常檢測、自動駕駛）通常要求實時或近實時響應，數據源可能包括傳感器、日誌流、用户行為事件等，產生持續不斷的流式數據。因此，需要通過消息隊列實現高吞吐、低延遲的數據傳輸。
- 數據量大、持續性強：AI 訓練和推理依賴大規模數據，數據流具有持續性（如 24/7 運行），導致數據累積速度快，例如：IoT 設備每秒生成數百萬條消息。
- 數據語義複雜，上下文依賴強：數據內容往往包含時間戳、設備信息、用户信息、地理位置等元數據，用於後續特徵工程或模型推理。事件之間可能存在時序依賴（如用户行為序列），需要保持順序或窗口聚合。
- 多源異構數據融合：AI 系統常需融合來自多個系統的數據（如用户畫像、行為日誌、外部 API），數據格式不一致。
傳統 ETL 實現 AI 數據鏈路的挑戰
傳統的數據入庫或入湖方案，是採用 ETL 的方式對數據進行處理加工後，放入規模較大的共享存儲，用於後續的數據價值實現，比如可觀測報表、數據分析。
數據挑戰的根源在於當前的數據集成方法，尤其 ELT 管道。管道是提取和處理數據的重要途徑，但現實情況是，這些基於批處理的管道帶來的問題，可能比解決的問題還多。
問題 1：數據的時效性
當數據以批量方式提取和處理時，最終會得到低保真的快照，導致數據不一致和過時信息。首先，“低保真快照” 在批量處理過程中，由於數據提取和處理的時間間隔較長，導致數據無法及時反映最新的狀態，從而降低了數據的準確性。這就好比每隔一段時間才拍一張照片，照片之間的間隔可能導致某些變化沒有被捕捉到，最終導致快照之間的不一致。過時的信息可能因為數據沒有及時更新，導致下游系統基於舊數據進行處理，從而做出錯誤的決策。
問題 2：改造和再加工的成本和複雜性
在批量處理過程中，為了滿足不同的業務需求，需要對數據進行多次改造和重新加工，這會帶來高昂的計算成本和維護不同數據集的複雜性。此外，將這些增量變化拼接在一起，這對處理邏輯提出了更高的要求，尤其是當數據來自多個源或用於多個下游系統時，處理起來非常複雜。
問題 3：數據質量和數據的可信度
當應用程序發生變化或數據格式發生變化時，數據倉庫或數據湖中會積累“垃圾 data”，導致所有依賴於這些數據的系統和應用程序基於不準確的數據運行。修復這些問題通常需要多步驟的、繁瑣的、手動的過程。
那麼，如何解決數據質量和可信度的問題呢？
需要在數據處理的各個環節引入數據質量管理的機制，比如數據清洗、數據驗證、數據補充等，確保數據在進入數據倉庫或數據湖之前已經過嚴格的檢查和處理。同時，建立數據質量監控機制，實時監測數據的質量，及時發現和修復數據問題。此外，採用數據格式管理的工具和策略，確保數據格式的變化能夠被有效管理和控制，減少數據變化的風險。
分析的目的是讓業務獲得更好的改變和發展，將企業多年積攢的不同格式的數據進行彙總分析，最終應用於業務中，以支持應用開發團隊為客户構建實時的 GenAI 應用程序和聊天機器人等。
因此，您需要添加更多工具（例如反向 ETL 管道），將數據從分析系統發送回運營系統和應用程序。如果前序分析數據有偏差，會使得系統因髒數據產生的“負債”越來越多。
Kafka + Flink 更好地釋放數據價值
面對傳統批處理數據管道帶來的數據時效性差、加工成本高和質量不可控等挑戰，基於 Kafka 與 Flink 的實時流處理架構提供的解決方案可以更好地釋放數據價值，將數據的處理和治理轉移到數據流中，這樣您就可以實現構建一次數據，並在創建後的幾毫秒內隨時隨地重複使用。
通過數據的處理和治理，您可以消除數據不一致的問題，減少重複處理的相關成本，避免數據質量問題影響下游處理，並最大限度地提高數據處理過程的投資回報率。之所以選用 Kafka 與 Flink 的組合，主要基於以下優勢：
- 首先，Kafka 是業界公認的數據庫、SaaS 和客户應用程序等系統之間的數據流通信的事實標準。
- 其次，Flink 作為流處理引擎，可以動態處理、清理和豐富數據流，並提供豐富的入庫、入湖、入表集成。
儘管該方案優勢顯著，但在實踐中，技術團隊仍然面臨着流處理引擎選型、技術組件網絡架構和網絡通信設計、版本兼容性等挑戰。這些都需要一定的技術門檻和相應的資源投入。
雲消息隊列 Kafka 版客户案例
今年我們增加了許多基於阿里雲消息隊列 Kafka 版構建統一數據處理架構的客户案例，如理想，吉利、極氪、長城汽車的智駕業務，MiniMax 的人工智能業務，貨拉拉、運滿滿、尚遊遊戲的大數據分析業務。
客户的流數據處理系統基本按照上一章的架構構建，用於解決高吞吐與低延時、數據持久化和可靠性、高效管理成本、資源成本、大規模集羣運維複雜度等問題。
雲消息隊列 Kafka 版為客户提供自適應、定時彈性能力，用於滿足波峯業務持續平穩地運行；提供多可用區秒級 RTO，0 RPO 的穩定性容災能力。同時，客户基於 Serverless 的不同版本，相比自建成本平均節省 20% 以上。
當然，我們在服務客户的過程中，也發現了 Kafka 僅作為流量入口的不足，這些將成為我們今年後半年的規劃目標。
雲消息隊列 Kafka 版下階段目標
阿里雲消息隊列 Kafka 版的下階段目標是打造面向 AI 場景的數據流平台。我們要在雲消息隊列 Kafka 版產品上提供完整的流傳輸、流處理、流治理的能力。
- 流傳輸： Kafka + 豐富的 Connector 構建一個事件流網絡，它會不斷將數據流向需要的任何地方——無論是流向數據倉庫、數據湖，還是您的應用程序。因此，每個下游消費者都可以一致地查看最新數據。
- 格式管理： 使用 Kafka Schema，可以約定數據格式——數據生產者和數據消費者之間的明確協議，將預期的結構、語義形式化並在管道中執行策略，避免不規範數據的滲入。
- 流處理： 提供基於 SQL 語義的流處理能力。這意味着數據可以不斷轉換、過濾、聚合形成新的、符合業務要求的數據。這消除了冗餘處理的成本和複雜性，一次性正確地構建數據，實現數據的複用。
- 數據關係： 提供了 Kafka 上數據傳輸的過程視圖——在可視化圖表中回答複雜的數據關係和問題，並對其可信度作出更明智的決策。您可以清楚地看到流來自哪裏、它們要去哪裏以及如何使用它們。這意味着，您的團隊不再需要擔心更改或演進可能產生的不確定的問題。
- 數據入表： 最後，結構化數據入表、入湖。這種集成極大地簡化了以分析查詢引擎所需的格式訪問所需數據的過程，為您節省了大量的成本。
