作者：家泽
本文整理自 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 上数据传输的过程视图------在可视化图表中回答复杂的数据关系和问题，并对其可信度作出更明智的决策。您可以清楚地看到流来自哪里、它们要去哪里以及如何使用它们。这意味着，您的团队不再需要担心更改或演进可能产生的不确定的问题。
- 数据入表： 最后，结构化数据入表、入湖。这种集成极大地简化了以分析查询引擎所需的格式访问所需数据的过程，为您节省了大量的成本。