勺挥排呵前言随着 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 消息确认事件被业务感知。在语音智能识别风险等场景中采用 MQTTKafka 的方案能显著减轻构建和维护底层数据链路的工作量使开发者专注于核心业务逻辑的实现加速业务创新与产品上线。以上是云消息队列 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 版为客户提供自适应、定时弹性能力用于满足波峰业务持续平稳地运行提供多可用区秒级 RTO0 RPO 的稳定性容灾能力。同时客户基于 Serverless 的不同版本相比自建成本平均节省 20% 以上。当然我们在服务客户的过程中也发现了 Kafka 仅作为流量入口的不足这些将成为我们今年后半年的规划目标。云消息队列 Kafka 版下阶段目标阿里云消息队列 Kafka 版的下阶段目标是打造面向 AI 场景的数据流平台 。我们要在云消息队列 Kafka 版产品上提供完整的流传输、流处理、流治理的能力。流传输 Kafka 丰富的 Connector 构建一个事件流网络它会不断将数据流向需要的任何地方 ------ 无论是流向数据仓库、数据湖还是您的应用程序。因此每个下游消费者都可以一致地查看最新数据。格式管理 使用 Kafka Schema可以约定数据格式 ------ 数据生产者和数据消费者之间的明确协议将预期的结构、语义形式化并在管道中执行策略避免不规范数据的渗入。流处理 提供基于 SQL 语义的流处理能力。这意味着数据可以不断转换、过滤、聚合形成新的、符合业务要求的数据。这消除了冗余处理的成本和复杂性一次性正确地构建数据实现数据的复用。数据关系 提供了 Kafka 上数据传输的过程视图 ------ 在可视化图表中回答复杂的数据关系和问题并对其可信度作出更明智的决策。您可以清楚地看到流来自哪里、它们要去哪里以及如何使用它们。这意味着您的团队不再需要担心更改或演进可能产生的不确定的问题。数据入表 最后结构化数据入表、入湖。这种集成极大地简化了以分析查询引擎所需的格式访问所需数据的过程为您节省了大量的成本。