2024年Confluent公司研究：整合Flink后承接关键负载，IT预算份额有望持续提升

公司简介：企业级数据流平台领导者

基于 Apache Kafka 打造企业级数据流平台，提供实时数据访问解决方案。Confluent 于 2014 年由 Apache Kafka 的原创者成立，旨在构建云原生数据流平台，围绕实时消息流连接公司应用程序，帮助企业做出及时决 策。公司拥有两大数据流平台，支持部署在本地和云环境中。其中，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%。

引言：为什么需要 Kafka？

Apache Kafka 是一个分布式实时消息-订阅系统，用于低延迟地收集和传递大量日志数据2，兼顾实时性和 高吞吐。Kafka 诞生于 2009 年，正值大数据快速发展的时期，传统的数据基础设施与消息系统难以应对大数据 处理需求：1）传统数据集成方案难以兼顾扩展性和实时性：传统 ETL 扩展性较好，但其批处理模式无法满足 实时性，而越来越多的分析任务需要实时数据，秒级、分钟级响应需求提升。而 ESB 中心化架构导致难以扩展； 2）传统消息系统无法满足高吞吐：大数据集成场景要求将海量日志数据快速传输到大数据平台，对吞吐量需求 提升，但 AcitveMQ/ RabbitMQ 无法满足高吞吐。

消息队列的兴起是由于实时处理需求提升，而传统批处理系统难以满足。典型的批处理系统包括 Hadoop， Hadoop的批处理性质不适合实时数据处理和分析，原因在于①HDFS通过冗余存储实现高可用性但导致高延迟。 HDFS 将大文件切分成较小的数据块并分散存储在不同的节点上。HDFS 采用最终一致性模型，即系统不保证在 数据变动后能够立即看到更新的结果，但最终会达到一致的状态。当客户端进行数据追加或重新写入数据块， 修改需要通知到各个相关 DataNode，并在这些节点上执行相应的写操作。该更新操作是异步进行的，期间涉及 网络通信和跨节点的数据复制，无法满足数据的即时更新和查询。

②MapReduce 在实时处理方面存在缺陷。MapReduce 的计算严格按照流程，先进行数据映射、洗牌（Shuffle）， 最终进行规约，这会产生大量的中间数据，尤其是 Shuffle 阶段涉及大量的数据读写操作和传输。由中间数据产 生的数据延迟开销成为制约 MapReduce 性能的瓶颈，导致无法提供毫秒级或秒级响应。此外，MapReduce 的输 入数据集是静态的，这意味着它不适合处理动态变化的数据流。

批处理系统无法满足实时性需求的根本原因是设计哲学/需求场景不同。批处理系统的工作方式是收集一 批数据后统一进行处理，而不是对数据进行连续或即时处理。换言之，批处理系统在既有约束下选择牺牲延迟 换取高吞吐，而流处理则相对优化延迟，牺牲一定吞吐量。 解决实时性后，核心瓶颈转变为扩展性，主要由于单机性能存在上限，而需求增长速度远快于性能增长， 因此需要引入分布式架构满足扩展性。Kakfa 通过分区/副本机制实现水平扩展。据《Building LinkedIn’s Real-time Activity Data Pipeline》，当时 LinkedIn 采用的数据传输管道包括处理用户活动数据的批处理系统、处理运营数 据的系统。用户活动数据系统用于将数据加载到数据仓库/Hadoop 集群中，其存在一些问题：1）缺乏实时数据 访问：批处理系统往往按小时/天的周期处理数据；2）传输复杂度过高：点对点多系统传输的耦合度和复杂度太 高。成本方面，XML 类型需要定制解析工作，计算和维护成本较高。服务器指标和日志系统的问题在于：1） 指标维护繁琐：添加和维护指标的过程需要手工进行；2）监控数据无法实时处理：由于系统的批处理性质，监 控数据无法实时处理。因此，LinkedIn 工程团队在数据生产者和数据使用者间引入中间层，将点对点的“N-toN” 结构转换为 “N-to-1-to-N ”结构，实现解耦并降低复杂性。

满足扩展性和实时性后，流处理框架初步形成，迈向业务落地的关键方向转变为吞吐量，即在业务允许的 可用性、延迟下尽可能扩大给定时间/资源的消息传输，这也是 Kakfa、Pulsar、ActiveMQ、RabbitMQ 等框架的 核心竞争要素。

1. 传统消息中间件难以兼顾扩展性和吞吐量

ActiveMQ 诞生于 2003 年，是最早支持 Java Message Service (JMS)协议的开源消息队列软件之一。此前的 商业 MQ 产品价格较高，且生态系统封闭，缺乏互操作性，这限制了不同系统间的集成能力。JMS 的出现为标 准消息协议和消息服务提供一组通用接口，两个应用程序可借助其 API 进行异步通信。ActiveMQ 完全支持 JMS 规范，能够与其他遵循 JMS 的系统无缝集成。ActiveMQ 降低消息队列技术的门槛，特别是对中小企业而言， 它提供低成本、高性能的解决方案，促进消息中间件的渗透。

但 ActiveMQ 存在以下问题：①通过消息持久化保证可靠性但造成吞吐量瓶颈。ActiveMQ 在处理大量消息 时可能会遇到吞吐量瓶颈，其默认的消息存储引擎 KahaDB 使用 B-Tree 索引来管理持久化消息的存储和检索， 但带来相应的性能损失。首先，B-Tree 索引需要占用一定的内存资源。其次，对于每个新消息，KahaDB 需要更新其 B-Tree 索引。频繁的索引更新操作会导致磁盘 I/O 增加，进而影响整体吞吐量。再次，B-Tree 索引在长时 间运行后可能会因为删除操作而造成磁盘空间碎片4，需要定期进行索引整理以保持性能。

②消息分片功能缺失导致扩展能力弱。ActiveMQ 默认没有提供消息分片或水平扩展方案，这意味着当单 一节点的处理能力达到极限时，用户必须自行设计和实施集群方案以实现负载均衡和消息的水平扩展。这对于 处理海量消息和高并发请求时带来一定的挑战。ActiveMQ 由于设计之初软件架构主要是中心化、集中式，未考 虑到大数据时代的分布式需求，而随着软件的迭代，添加新的核心功能如水平扩展机制可能会触及系统的基础 架构，引入复杂的技术债务。

③JMS 缺少直接支持消息批量发送的 API5。在 JMS 框架的设计理念中，直接集成消息批量发送的便捷 API 并未被纳入核心规范，这反映出 JMS 聚焦于确保基础通信的稳健性而非特定性能优化策略的标准化。因此，在 默认配置下，每条消息的发送都遵循标准的网络交互流程，从建立连接到数据传输，直至确认接收，每一步都 是独立完成。这可能会对系统的性能和吞吐量造成影响。但 JMS 允许开发者自定义消息批量发送逻辑。

RabbitMQ 基于 AMQP，具备灵活强大的功能集、高可靠性和跨语言特性。JMS 只针对于 Java 应用，其 他语言开发的程序无法使用 JMS 完成信息交换。2003 年 John O'Hara 提出 AMQP，相比于 JMS，基于 AMQP 协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同开发语言等条件的限制9。 RabbitMQ 是基于 AMQP 协议的消息队列产品，可跨语言通信，增强不同系统之间的互操作性。AMQP 功能集 丰富，支持消息确认、事务、持久化、消息路由等，使得 RabbitMQ 能够为用户提供多样的消息传递服务。相比 于 Kafka，RabbitMQ 支持死信队列、延迟队列、优先队列、多租户、推模式消费等。此外，AMQP 协议支持多 种消息模型，使得 RabbitMQ 可采用灵活的消息处理方式。

但 RabbitMQ 的缺点在于：①AMQP 的复杂性限制吞吐量。由于 AMQP 协议相对较为复杂，相较于某些轻 量级协议：1）报文格式：AMQP 定义了一种丰富的二进制编码格式来表示消息和控制命令，这种格式包括头信 息、负载内容以及可能的元数据字段。允许实现诸如消息路由、事务、消息确认等高级功能，导致消息传输前 需要更多的处理和编解码工作，增加网络带宽占用和 CPU 消耗。2）握手过程：AMQP 连接建立阶段包含完整 的 TLS/SSL 握手（若启用加密）和 AMQP 信道的协商过程，这需要多次网络往返才能完成，对于频繁建立短连 接的场景来说，这会降低整体的处理效率和吞吐量。3）可靠性机制：AMQP 提供多种消息确认和可靠性保障机 制，比如持久化消息存储、事务性发布、消息确认等，这些特性确保消息在传输过程中的高可靠性，即使在系 统故障情况下也尽可能地保证消息不丢失。但相应地，服务器端和客户端需要额外逻辑来处理消息确认、重试、 死信队列等操作，这会增加系统开销。

②传统拷贝方式保证高可用但牺牲延迟。从 I/O 的角度，为确保高可用性，传统拷贝方式需要四次拷贝（2 次 DMA+2 次 CPU）：1）将磁盘上的数据拷贝到操作系统内核的缓冲区；2）将内核缓冲区的数据拷贝到用户 的缓冲区；3）将已经拷贝到用户的缓冲区里的数据，再拷贝到内核的 socket 的缓冲区；4）将内核的 socket 缓 冲区里的数据拷贝到网卡的缓冲区。该过程有助于确保数据在传输过程中的一致性和可靠性，但每次数据拷贝 和上下文切换（用户态与内核态之间的转换）都会带来时间开销，尤其是第二次和第三次拷贝，需要 CPU 的直 接介入，显著增加数据从磁盘到网络传输的总延迟。

③Erlang 语言增加二次开发难度。Erlang 使用虚拟机（BEAM）内部轻量级线程，而非操作系统进程，这 种进程内存占用小，创建和切换速度快。Erlang 进程间的通信通过消息传递实现，而非共享内存，避免数据竞 争和死锁，简化并发编程的复杂性。此外，作为函数式编程语言，Erlang 强调不可变性和状态的局部性。这有助 于避免副作用和状态变化，减少对锁和同步机制的依赖，对并发编程是一个重要优势。基于 Erlang 语言本身的 高并发优势，RabbitMQ 在当时性能较好，能达到微秒级延时。但 Erlang 语言比较小众11，学习曲线陡峭，因此 在开发成本方面有一些劣势。 Erlang 语言的性能优势明显。创建 2500 个 Erlang 进程的时间在 1μs 以内，进程增加至 3 万个时，时间增 加至 3μs；而 Java 和 C#创建小批量进程大约耗费 300μs，且无法创建超过 2000 个进程。消息发送方面，对于多 达 3 万个进程，在两个 Erlang 进程之间发送消息的时间约为 0.8μs。对于 C#，每条消息大约需要 50μs，最大 进程数为 1800。 Java 对于 100 个进程，每条消息大约需要 50μs，进程上升至 1000 个时，每条消息发送时间 上升至 10ms。

总结来看，Kafka 在高吞吐和延迟方面的优势来自 1）架构设计层面，Kafka 采用分区与副本机制，通过水 平扩展和数据分区来支持高吞吐量、高可用性和负载均衡。副本机制确保数据的持久性和系统的容错能力；2） 存储方面，Kafka 通过顺序写入与 Append-only 日志提高写入效率，并引入稀疏索引与日志压缩减少存储空间占 用，提升数据检索效率；3）I/O 优化，通过引入 Linux 的零拷贝技术减少数据在内核态与用户态之间的复制， 以及优化数据包处理流程，提高数据传输效率。 架构方面，Kafka 的分布式架构和分区策略天然支持水平扩展。ActiveMQ 支持通过网络连接多个 Broker 形 成代理网络，但它的扩展性设计相对较为基础，主要依赖于主从模式进行故障转移。RabbitMQ 使用集群方法来 实现可扩展性，集群中的节点可是内存镜像或是通过队列共享来实现负载均衡。RabbitMQ 的扩展性较强，但相 比 Kafka，其在极端高吞吐量场景下的扩展和性能调优可能更加复杂。Kafka 采用分布式、分区和副本机制，天 然支持水平扩展，通过增加 Broker 节点就能线性地提高系统的存储和处理能力。每个 Topic 可以划分为多个 分区，并且这些分区可以在集群中的多个 Broker 上分布，进而实现高并发生产和消费。据 Instaclustr，Kafka 分 区数量的增加会使吞吐量增加，但分区数量过多会降低吞吐并增加延时。

存储方面，顺序磁盘写入优于随机写入性能，而 ActiveMQ/RabbitMQ 涉及更多随机写入操作。磁盘顺序 写入的性能约为 600MB/秒，但随机写入的性能仅约为 100k/秒，相差 6000 倍以上15。据 ACM Queue16，顺序磁 盘访问在某些情况下比随机内存访问还要快。原因在于：1）HDD 随机写带来物理寻道开销：随机访问时，磁 头需要物理移动到不同的磁道读取数据。顺序访问时磁头只需沿着磁道连续读取，无需频繁寻道，因此读取速 度得以提高；2）SSD 随机写导致垃圾回收开销：SSD 的介质是闪存，无法原地更新（in-place update）只能进行 块擦除，因此需要垃圾回收算法清理无效的数据块并将分散的数据重新整理，随机写可能导致进一步碎片化， 导致更大的资源开销。ActiveMQ 和 RabbitMQ 在索引更新、队列管理、消息确认等方面涉及到更多随机 I/O， 不如 Kafka 的顺序写入高效，导致性能损失。 Kafka 减少消息复制提升存储效率。传统 MQs 消息复制过程限制其性能，如 RabbitMQ 允许为每个消费者 创建独立队列，虽然并非每个消息都会被复制到所有队列，但在需要镜像队列时，复制操作会增加存储开销17。 Kafka 采用分区日志存储，消息仅需存储一次，并通过设置分区副本实现高可用，减少存储资源的需求，且消费时不依赖于消费者的数量。 Kafka 采用稀疏索引提升批量查询性能。ActiveMQ 利用 B-Tree 索引来维护消息元数据，这在高负载下可 能导致性能损耗。Kafka 采取稀疏索引策略，仅每隔固定字节数创建索引项，减少索引存储空间。Kafka 采用二 分查找法，Kafka 能够在索引层级上迅速定位到包含目标消息的索引区块，然后再在该区块内顺序查找，这种设 计在处理批量消费时较高效，但牺牲单条消息查询性能。

I/O 方面，Kafka 采用预读取+延迟写(Read-Ahead + Write-Behind)和页缓存(PageCache)优化 I/O 开销。预 读取即在读取数据时，先以数据块为单位预读取数据；写入数据时，将多个小逻辑写入合并成一次大型磁盘写 入。顺序读写时，数据在磁盘空间上更加连续，便于系统预测写入/读取位置，因而能提升效率。缓存方面，Kafka 在写入数据时，先写入页缓存，操作系统会在合适时机把这些数据写到磁盘上，因而减少频繁写入操作，且降 低 JVM 直接管理数据的负担，避免垃圾回收频繁发生，节省 JVM 内存。 零拷贝显著提升数据传输效率。传统 I/O 流程包括用户空间到内核空间的拷贝及内核空间到硬件缓冲区的 拷贝。使用 Sendfile 零拷贝时流程简化为 DMA（直接内存访问）从磁盘到内核空间，内核空间直接到 NIC 缓冲 区，省略了用户空间到内核空间的数据拷贝过程，减少至少一次的数据拷贝操作18。此外，上下文切换次数也有 所减少，因为数据不再需要进入用户空间，减少用户空间和内核空间之间的切换。当运行 Linux 内核 2.4 及更 高版本以及支持收集操作的网络接口卡时，磁盘数据通过 DMA 拷贝到内核态 Buffer 后，直接通过 DMA 拷 贝到 NIC Buffer，无需 CPU 拷贝。据 NI 和 IBM，零拷贝可带来数据传输时吞吐量和延时增益。

内存映射显著改善读取性能。Kafka 的日志文件分为数据文件和索引文件。为提高索引文件的读取性能，Kafka 对索引文件采用 mmap 内存映射，即：将索引文件映射到进程的内存空间，避免从磁盘进行读取。数据 显示19，对于一个 4GB 的文件，分别在冷缓存和热缓存20条件下测试，采用不同块大小进行顺序或随机读取， mmap 比系统调用快 2-6 倍。mmap 更快的原因一方面在于系统调用需要在用户空间和内核空间之间切换，而 mmap 直接把数据从映射到地址空间的一个内核缓冲区复制到另一个内核缓冲区，减少了上下文切换。另一方 面在于 mmap 的代码更加简洁。

批处理+数据压缩以牺牲延迟的方式换取高吞吐。批处理即 Kafka 将消息写入磁盘时并不是直接写入，而是 等积攒够一定消息量后一并写入磁盘中。相应的，读取消息时也是等到一段时间积攒足够的消息一并打包发送 至消费端。这样做减少单次操作的开销，如减少磁盘 I/O 操作次数和网络请求的次数，从而显著提高整体的吞 吐量，但累积过程中带来额外的延迟。数据压缩是在消息发送之前对其进行编码，以减少消息的大小。在网络 传输中，这可以减少带宽的使用，使得在同样的时间内能传输更多的数据，即提高吞吐量。但压缩和解压缩过 程需要计算资源，这会引入额外的时间延迟。通常情况下，增加一点点延迟可以换来吞吐量更大的提升21，这对大规模数据处理场景非常有利。 需要注意的是，Kafka 在设计上对即时性的相对妥协意味着在某些场景下可能不太适用，例如低延迟交互系 统如高频交易、实时在线交易系统、实时游戏通信等场景。在即时性要求极高的场景中，可能需要考虑 RabbitMQ、 ActiveMQ 或其他专为低延迟设计的消息队列系统。

最终性能实现上，Kafka 在数据生产和消费双端性能均优于 ActiveMQ 和 RabbitMQ。据《Kafka: a Distributed Messaging System for Log Processing》，在生产端，Kafka 不等待代理的确认，以代理能处理的最快速度发送消 息，且省去 JMS 所需的沉重消息头，以及维护各种索引结构的开销，因此具有较好的性能，尤其是批处理条件 下。平均而言，Kafka 每条消息有 9 字节的开销，而 ActiveMQ 有 144 字节。在消费端，由于 Kafka 高效存 储和消费机制以及零拷贝等，Kafka 平均每秒消耗 22,000 条信息，是 ActiveMQ 和 RabbitMQ 的 4 倍多。

2. Pulsar 并未及时把握 Kafka 的功能缺失，Kafka 引入 Kora 架构后补齐短板

Pulsar 的创新在于存算分离架构。早期系统常将数据处理与存储合并于同一节点，虽减少网络开销，却牺 牲扩展性和高可用性。Pulsar 通过解耦存储与计算，实现灵活性与按需扩展。架构上，Pulsar 由计算层（Broker 集群）处理消息传递，与存储层（BookKeeper 集群，由 Bookies 组成）负责数据持久化。Broker 管理主题分区， 对接生产者和消费者，而 BookKeeper 集群以分布式日志形式存储主题分区，每个日志切分为 Segment，分散存 储于多个 Bookie 以确保均衡和高可用性。因此，Pulsar 可实现 1）存储扩展能力强：主题分区通过 Segment 跨 越 Bookies 分布存储，扩容只需添加 Bookie 节点，不受单节点容量限制。2）即时扩展性：Broker 无状态设计， Topic 迁移无需数据复制，仅需变更 Broker 所有权，即刻连接，实现快速扩展。3）独立扩展能力：存算分离允 许存储与计算层独立扩展，弹性适配资源需求，优化成本与性能。

可扩展性的重要性可能被过度放大，如 Confluent 演示27所提到的，对于大多数用例来说，可扩展性不是问 题。在 Confluent Cloud 中将 Apache Kafka 扩展至每秒 10+ GB，这意味着除非客户有像 Netflix（每天处理 PB 级数据）或 LinkedIn（处理数万亿条消息）这样的需求，否则绝大多数客户并不需要考虑可扩展性方面的问题。 因此，Pulsar 所强调的扩展性优势并未集中客户痛点，对 Kafka 的潜在威胁较为有限。 …且存算分离的架构引入额外复杂度，导致大规模场景下延迟不稳定。据 2023 年 10 月的研究《Comparative Evaluation of Java Virtual Machine-Based Message Queue Services: A Study on Kafka, Artemis, Pulsar, and RocketMQ》， 1）Kafka 在吞吐量方面表现出色，证明其在处理大规模消息量时的高效性，适合高吞吐量需求。尽管 Kafka 在 50%分位数的延迟上略有落后，但在评估的所有吞吐量下表现出稳定性，即可预测的性能，而 Pulsar 在较高百 分位上的延迟明显升高。2）但具有较高的 CPU 使用率，意味着它更适合资源丰富的环境，而 Pulsar 的 CPU 使 用相对平衡，适应性更广。3）Kafka 性能强大，但对内存资源要求较高； Pulsar 在内存使用效率上更优，适合 内存受限的场景。整体来看，Kafka 优先考虑处理性能以最大化吞吐量并减少延迟，这以牺牲资源效率为代价。 相反，Pulsar 在节约资源的同时可能会牺牲一些性能。

安特卫普大学研究团队 2022 年 9 月的研究28证实了 Pulsar 在大/小规模场景下的性能差异。原理上，Pulsar 引入计算层（broker）与存储层（BookKeeper）分离的架构，旨在提升扩展性。当处理大量数据时，这种分离可 以独立扩展存储和计算资源，但可能对小消息处理引入额外的网络延迟，因为数据需要在两层间传输。且 Pulsar 用 Bundle 作为负载均衡单元而非单个 Topic，当某个 Topic 负载轻，但同 Bundle 中其他 Topic 活跃时，可能会 间接影响资源分配，造成小消息处理延迟。这种策略实际上追求高吞吐，并牺牲延迟，因此 Pulsar 在延迟和吞 吐的平衡方面不如 Kafka 稳定。 具体而言，如果消息大小非常平均且偏向中大尺寸，Pulsar 的策略更能发挥优势，因为它可以高效地利用 资源和优化吞吐量。反之，如果消息大小非常不平均，特别是存在大量小消息，Pulsar 可能会因为其资源分配 和处理策略，相比 Kafka 等其他系统展现出更高的延迟。

Pulsar 的真正问题是并未提供功能以满足用户的核心需求，如缺乏消息队列支持，事件流支持，不支持一 次性交付和处理语义等，其 Kakfa Connect 功能完整度不高，这意味着 Pulsar 较难满足客户现有的业务需求， 而是提供一个概念框架，满足初创/中小企业的简单需求。更重要的是，Kafka 的迭代较快，为简化运维且提升 扩展性，Kafka 于 2023 年提出 Kora 架构，用 KRaft 替代 Zookeeper，并引入分层存储强化存算分离的弹性。从 商业逻辑上看，技术架构的创新是为业务服务的，新技术对现有技术的替代更多是以创新架构更快、更可靠或 以更低成本地实现现有需求，而非等待客户主动适配新架构。因此，对于 Pulsar 竞争力的评估首要考虑的应当 回归 Pulsar 在业务场景的性能表现，是否满足高可用、实时性等。

Kora 的分层存储结合本地存储和对象存储，降低成本并兼顾读取效率。一般来讲，磁盘本地存储的存储空 间有限，受制于物理硬件不易扩展，且存储成本更高，但访问延迟低、性能好、适合实时访问和快速读写。而 对象存储相对便宜（例如 AWS S3），且分布式架构提升其扩展能力，但访问速度慢于本地存储。传统 Kafka 依 赖于本地存储，由此产生两个问题：1）成本问题：随着数据量的增加，维持高性能的本地存储成本会快速上升， 可能变得过于昂贵。2）实时弹性不足：传统 Kafka 在扩缩容时涉及流量的重平衡，需要大量迁移数据，导致实 时弹性能力不足29。 分层存储带来的成本+弹性大幅优化。Kora 结合本地存储和对象存储，采用分层存储的方案，即：将热数 据保留本地，而冷数据移至对象存储中。此外，Kora 具有自平衡机制，可将数据在内存、本地存储、对象存储 之间智能分配、主动迁移且持续优化。这种平衡难度较高，需要遵循单元放置规则和租户公平性，还要平衡 CPU 和本地 I/O 使用率，同时减少分区移动造成的不稳定成本。因此，Kora 在保持关键数据的高性能访问的同时， 大幅降低总体存储成本，同时由于只有少量热数据保留本地，数据迁移简化，弹性大幅提升。

Kafka 最初集成 ZooKeeper 进行分布式协调和管理元数据，但后续带来运维复杂度及扩展性瓶颈。 ZooKeeper 通过提供一致性的服务，帮助 Kafka 管理集群配置、选举控制器（controller）、以及存储和同步元数 据等关键任务。这种设计虽然带来可靠性，但也附加了复杂性和伸缩性的局限：1）复杂性高：ZooKeeper+Kafka 需要开发人员同时维护两个分布式系统，增加系统的管理和运维复杂度。2）伸缩性瓶颈：假设一个系统有三个 broker，其中作为领导者的 broker 想请求关闭，controller 首先确定 broker1 管理的分区尝试更新元数据，并随机 选举产生新的领导者。然后执行 ZooKeeper 写入操作，更改这些分区的元数据。最后，将更改的元数据传播到 所有其他 broker。这一过程造成较高的延时；假设原有控制器意外崩溃，新控制器需要从 ZooKeeper 读取全部 元数据，同样造成较长的延时和不可用窗口。 为解决这些问题，Kafka 采用基于 Raft 协议的 KRaft 模式替代 ZooKeeper。KRaft 模式的核心变化包括 1） 元数据自管理，Kafka 将元数据从 ZooKeeper 迁移至内部存储，这意味着元数据可以利用 Kafka 的日志复制和持 久化机制来保证数据的安全性和一致性；2）仲裁控制器：Kafka 集群中的部分 Broker 被指定为仲裁控制器，它们使用 Raft 协议来达成共识，管理元数据的更新和分布，从而替代 ZooKeeper 的角色。

其优点在于：1）缩短不可用窗口，由于元数据存储在 Kafka 内部，当 Broker 重启或故障恢复时，可以直接 从日志中恢复缺失的元数据信息，减少系统不可用的时间；2）简化架构，Kafka 架构大大简化，减少外部组件 运维，使系统更加轻量级和稳定；3）伸缩性提升，KRaft 模式下，由于元数据管理的高效性和 Raft 协议的高效 共识机制，Kafka 集群可以更平滑地扩展到数百万个分区，远超依赖 ZooKeeper 时的伸缩性限制，可以更好地满 足以下三种情景：1）由于业务需要多主题而产生大量分区；2）需要大量分区实现消费者并发处理，从而达到 高吞吐；3）由于消费者消费速度缓慢而需要增加消费者数量和分区。

资源调配策略方面，Kora 采用多租户模式。多租户的核心挑战在于资源分配和隔离：1）超额订阅或引起代 理过载，大多数租户为应对流量洪峰往往超额订阅物理集群，由于多租户模式下单个节点由多个租户共享，若 需求激增，可能引起节点过载导致所有用户高延迟。2）工作负载可能随时间在不同节点之间切换，若将租户级 配额静态平均分配给每一个节点，热分区所在的节点会较早达到配额限制并开始节流，但此时整个集群的使用 量低于全体租户配额，造成使用效率低下。 针对超额订阅与代理过载，Kora 为节点上的资源设置安全阈值，通过反压和自动调优减轻节点压力。Kora 通过在每个节点上设定资源使用的上限，比如带宽、CPU 和连接数，来防止过载。这些阈值作为安全网，确保 即使在租户需求激增的情况下，也能维持基本的服务质量。一旦达到限制，节点就会使用自动调优机制对租户 的请求进行反压，即暂时减缓或限制某些租户的流量，确保整体资源使用保持在安全范围内，缓解节点压力， 避免全局性的服务降级。 对于动态工作负载与静态配额不匹配，Kora 使用动态配额机制，根据租户带宽消耗调整带宽分配。Kora 设 计配额协调器管理租户间共享配额。例如，租户 A 有 100MB/sec 的总配额，分配给代理 1、2 和 3。节点定期向 配额协调器上报每个租户和每个节点的带宽使用数据和相关的限额信息。如果监测到某个节点上的租户 A 使用 率低，而其他节点该租户的需求高，配额协调器会重新平衡，将未充分利用的配额转移到需求更高的节点，从而优化资源使用效率，并响应租户的动态需求。

3. Redpanda 的性能优势被夸大，其基准测试并不具有普遍意义

Redpanda 的性能优势被夸大，其基准测试并不具有普遍意义。Redpanda 声称由于其每核线程架构、使用 C++编写以及针对高性能 NVMe 驱动器优化的存储设计，其性能优于 Kafka35。但深入分析其基准测试可以发现： ① Redpanda 测试跑分中为自身引入了定制化配置，且对 Kafka 的部分配置并不公平。例如：1）使用 Java 11 而 非 Java 17 运行 Kafka36；2）使用实际生产中较为少用的参数配置，迫使 Kafka 在每个消息批上进行 fsync，导致 Kafka 性能降低；3）对 Redpanda 和 Kafka 分别应用两种不同的偏移量提交策略，没有保持一致。 ② Redpanda 大规模/长期运行场景下性能不稳定。据 Jack Vanlightly，Redpanda 在 50 个生产者时性能明显 下降，表现为延时迅速增加而吞吐量存在 1000MB/s 的瓶颈，与 Redpanda 基准测试相冲突。同时，在运行 12 小 时后，Redpanda 的端到端延时发生抖动，尾部延时大量增加。而 Kafka 的表现更加平稳，且随时间延长，延迟 甚至表现出优化趋势。总体上，Redpanda 性能比 Kafka 更不稳定，对多种因素敏感，例如批量大小不能太小， 高分区工作负载的吞吐量不能太高，驱动器需要充分配置足够的空位，以满足其存储层的随机 IO 性质。

③ 对于很多工作负载支持度不如 Kafka。Jack Vanlightly 发现 Redpanda 在 1GB/s 生产者负载下无法排出积 压的数据。而 Kafka 则能成功处理积压并恢复到低延迟状态。这表明 Redpanda 在处理瞬时或持续高负载冲击时 的弹性不足。此外，对于需要排序的工作负载，使用记录键后 Redpanda 性能明显下降。

总体而言，Redpanda 的性能对工作负载的敏感性高，并非全面优于 Kafka。Redpanda 拥有最强大的端到 端延迟结果，随着增加吞吐量，工作负载的具体情况会对性能产生不成比例的影响。同时，Redpanda 对驱动器 延迟也非常敏感。Kafka 的问题在于页面缓存是一把双刃剑。Kafka 对各种工作负载的性能稳定性好，但会导致 端到端的延迟峰值，从而影响尾部延迟。

竞争分析：Kafka 兼具高吞吐+低延迟，已成为流处理的事实标准

Kafka 成为流处理的事实标准，主要竞争对手大多提供原生 Kakfa/支持 Kakfa 协议的服务。流处理市场包 含 1）原生 Apache Kafka：产品或云服务利用开源框架进行实时消息传递和事件存储。Kafka API 100% 兼容。 不包括 Kafka Streams 和 Kafka Connect；许多供应商排除了这些 Kafka 功能。2）Kafka 协议：产品或云服务 实现自己的代码，但支持 Kafka API。这些产品通常不是 100% 兼容的。通常，Kafka Connect 和 Kafka Streams 通常不属于这些产品。3）流处理：框架和云服务以无状态或有状态的方式关联数据。

Confluent 面临的竞争对手有三类，包括开源 Kafka 用户（即企业内部 IT 团队）、三大云服务商以及传统技术供应商39。对比 CSP： AWS Kinesis 主要负责将数据导入 AWS 数据存储，并由 AWS 其他产品服务满足流数据处理/存储需求， 普遍问题是缺乏系统优化。其余 CSP 如 Azure Event Hub/Google Datflow 均提供类似方案，即提供组件而非完整 解决方案，这种方式的问题在于缺乏系统性优化导致低效率，如 Doordash 2022 年从 Amazon SQS 和 Kinesis 迁 移至 Flink/Kafka。Doordash 指出混合不同类型的数据传输并经历多个消息传递/排队系统，导致数据延迟高、成 本高、运营开销大。引入 Kakfa/Flink 后，Doordash 可增强数据集成能力，如通过 API 或通信范例访问，并且使 用 Confluent Schema Registry 实现模式实施和模式演变的端到端数据治理。

此外，Kinesis 主要被诟病的问题包括成本和数据集成功能。1）成本主要体现在数据扩展后的规模不经济。 Kafka 通过增减 Broker 或调整分区实现灵活扩展，这允许根据需求精细分配虚拟资源，提高了资源使用的灵活 性和效率。相比之下，Kinesis 依赖增加分片来扩展容量，虽然操作简便，但扩展粒度较为固定，可能在某些场 景下影响资源利用率的优化。另外 Kafka 扇出能力40优于 Kinesis，主要由于①采用发布-订阅模式，使得消息能 被多个消费者组并行处理；②内置的消费者组协调确保新消费者无缝加入或退出时任务重新分配，维持系统的 高扇出及稳定性；③分区机制增强并行处理能力。相比之下，Kinesis 通过分片支持多个消费者共享访问，但分 片的吞吐上限限定了其扇出规模，一般情况下扇出能力相对有限；2）数据集成功能有限。Kinesis 并非原生 Kafka， 因此对 Kafka 的核心功能支持度不高，用户需要自行配置或采用 AWS 的其他组件，这引发运维成本提升或供应 商锁定等问题。

AWS MSK Serverless 版本是 Kafka 的托管版，但其功能完整性均存在一定欠缺。Confluent Cloud 集成全 套 Confluent Platform 特性，如 Schema Registry、KSQL，提供高级安全监控和自动化管理。AWS MSK 侧重与 AWS 生态集成，如 Lambda、Glue，但不支持 Kafka Connect/Streams 等功能。一个例证是 Confluent Cloud 用户 可使用开源监控工具如 Kafka UI，而 MSK 用户需手动配置 CloudWatch 或承担额外费用，尤其是对于代理和分 区级的详细监控。MSK Serverless 用户可免费访问基本监控指标，但代理和分区级指标需收费，并且主题-分区 级指标很少41。据 Metricfire，CloudWatch 企业级花费每年可能超过 50,000 美元42。同时 CloudWatch 无法与 Datadog 和 Dynatrace 等第三方监控工具进行原生集成。

Confluent 相比于 MSK 的差异化在于全托管 ksqlDB，降低 TCO，Kinesis 流处理能力弱于 Flink。流处理 方面，Confluent 提供完全托管的 Flink 和 ksqlDB，流处理只需要使用类 SQL 语言即可完成；而 MSK 仅支持自 管理的 ksqlDB，MSK Severless 不支持 ksqlDB。虽然两者都支持 Flink，但 MSK 需要自托管 ksqlDB。ksqlDB 属 于社区许可协议，其他竞争者不允许提供任何 ksqlDBaaS 或其他与 Confluent 有竞争关系的类似服务44。尽管 Kinesis Data Analytics 内置 Flink，其功能相比原生 Flink 可能有所精简，比如缺少自定义操作符和计时器功能。 因此，在处理高度复杂的事件流上，Confluent 提供的 Flink 服务凭借更完整的功能集展现优势。 Azure Event Hubs（AEH）主要负责数据摄取，流处理功能不完整且对 Kafka 协议兼容性有限。Azure Event Hubs45不支持核心 Kafka 功能，如事务、压缩或日志压缩、Kafka Connect 和 Kafka Streams。另外，AEH 并非 100%兼容 Apache Kafka46，而是允许用户调用 Kafka 的部分 API 进行数据处理。

Azure Event Hubs 与 Kafka 底层架构上的不同之处在于：①Kafka 在可用性、一致性、顺序性之间的选择 更加灵活。对于 AEH，如果业务重视可用性，则发送消息时不能传递 Parition Key，消息以轮询方式发送，一个 分区不可用则传递至其他分区，保证可用性但牺牲消息顺序性。如果业务重视顺序性，所有消息只能往一个 Partition 上发送同时指定 Partition Key。当 Partition 不可用则部分业务不可用。②AEH 不支持分区负载再平衡 可能导致扩展性受限。AEH 的分区数在创建后固定，高级和专用层级虽能增加分区但不可减少，影响扩展灵活 性。Kafka 则可通过增加分区调整扩展，并支持工作负载再平衡。 AEH 其他功能上缺点在于： 1）配额过多：AEH 有很多配额限制，官方称是为帮助客户准确配置资源、避 免错误消耗，但实际上给用户带来困扰，例如消息不能超过 256KB（Kafka 以 MB 为单位），命名空间的事件 中心数量限制为 10 个，如需扩大则需更高级版本；2）保留期过短：AEH 基本版保留期仅 1 天，专用版保留期 也有 90 天限制，因而限制历史数据的分析；3）重要功能缺失：AEH 缺少 Kafka Connect 、Kafka Streams、缺 少架构注册表、RBAC、审核日志等，这些功能在众多企业广泛使用。

GCP Pub/Sub 是 Google 基于云的分布式消息传递服务，而并非完整的流处理平台。架构上，主题（Topics） 是作为消息的发布目标；发布者（Publishers）负责向主题发送消息；订阅者（Subscribers）则订阅这些主题以异 步接收消息，支持推（Push）与拉（Pull）两种模式。作为 GCP 的一部分，Pub/Sub 与 Google 的其他服务（如 Dataflow、BigQuery、Cloud Functions 等）有深度集成，便于构建端到端的云解决方案。对于已经使用 GCP 服 务的用户来说，集成更为顺畅。两者架构差异在于：①Kafka 底层架构保证单分区内顺序性，GCP Pub/Sub 需 要额外传输消息键。在 Kafka 中，每个主题可以被划分为多个分区，而每个分区内部的消息是严格有序的，生 产者可利用单分区有序性，将消息发送到同一个分区中，以此保证消息的顺序性。而 GCP Pub/Sub 并未内置消 息的顺序性。虽然可以启用消息键，使用消息排序功能，但消息键产生的额外开销可能会增加消息的延迟。② GCP Pub/Sub 的设计更侧重于可靠性和可扩展性，而非低延迟。GCP Pub/Sub 可以保证消息传递不遗失，具有 高可靠性。然而它的消息传递机制可能引入一定延迟，因此不太适合那些需要即时响应或超低延迟处理的任务， 比如高频交易系统或实时交互应用。

反垄断压力下，CSP 有望逐步消除数据传输费以缓解监管压力。Confluent 作为中立服务提供商的问题在 于传输成本，对于中大型企业而言，数据自数据管道、流处理后导入 Snowflake/Databricks/MongoDB 等存储， 而如果下游存储与流处理层分属不同云服务商/可用区，则客户面临较高数据传输成本，这削弱了重度用户采 用 Confluent Cloud/Platform 的 ROI。但 2024 年以来，Google Cloud 于 1 月宣布面向全球用户取消跨云/本地上 云的数据传输费47，Amazon48、Azure49于 3 月跟进了这一举措，此外 Azure 于 5 月进一步宣布对于同一云厂商 跨可用区的数据传输免费50。尽管 Google51/Amazon52仍然对跨可用区的数据传输收费。

CSP 的举动是对监管的回应，2023 年 4 月英国通信监管机构 Ofcom 提交调查报告54，其认为 AWS/Azure/GCP/Oracle 等对数据传输、迁移收取的费用构成用户切换云服务的障碍，从而限制竞争，建议英国 监管当局对云计算行业启动正式且全面的调查。此外，欧盟数据法案（EU Data Act）于 2024 年 1 月生效，该法 案要求 CSP 消除其自身云服务与竞争云服务之间“有效切换的障碍”，包括商业、合同、技术或组织障碍。我 们认为，监管压力下，数据传输的高昂成本将逐步消除，对于依托云厂商基础设施的 Confluent 等中立服务商， 其成本劣势有望消除。 此外，Confluent 集成能力较为广泛，整合 Flink 后有望提升易用性且保持部分专有连机器的优势。Confluent 在流数据处理市场的竞争优势之一在于其提供的120+预构建的连接器。这些连接器在实践过程中存在一些问题， 例如 1）并非所有连接器都能直接使用，有些需要自行托管；2）在大型企业中，尤其是使用本地系统的企业， 使用云连接器连接到本地数据库时会遇到网络问题。3）数据转换也构成挑战，Kafka Connect 框架只支持基本的 转换，而更复杂的转换则需要使用 ksqlDB。但随着 Flink 的更深入整合到 Confluent Cloud 平台，这些问题有望 得到缓解。Flink 与连接器的结合使用可以实现数据转换，这对于流数据处理来说是一个重要的优势。值得注意 的是，Confluent 拥有一些关键的专有连接器，如 Oracle 和 ServiceNow 连接器，以及适用于物联网用例的 MQTT 连接器。这些专有连接器只能由 Confluent 托管，竞争对手如 Redpanda、MSK 等无法提供类似服务，这使得 Confluent 占据流处理市场的重要地位。

总结来看，CSP 提供的流处理服务组件化明显，核心工作负载往往需要进一步系统优化，AWS / GCP / Azure 在运维自动化及解决方案成熟度方面存在一定差异，其优势主要在于客户主要负载位于云厂商数据库/数据湖/存 储之上，对于非关键任务（流处理）更在意易用性而非性能/稳定性等，因此当前 Confluent 的主要逻辑是 1）业务运行是否必须用流处理？如果非必要，则 Confluent 作为中立解决方案服务商的重要性则会被削弱；2）如果 必要，Confluent 解决方案的核心壁垒是什么？

通常而言，微批处理的延迟在秒级59，而流处理的延迟在毫秒级别。目前看，1）Netflix 等视频平台对于流 处理的需求是显著刚性的，主要由于视频播放延迟直接影响用户体验，因此流处理服务有重要业务价值。2）金 融交易欺诈监测，由于金融欺诈往往具有时效性，欺诈者会快速转移资金或完成非法交易，因此延迟对于风险 管理/损失控制有非常重要的业务价值。3）物联网/自动驾驶，自动驾驶汽车的决策延迟直接影响行驶安全。例 如，紧急制动或避障动作需要在 0.1 秒级内完成。4）本地生活，如 Uber、Yelp、Doordash 等，服务履约的时效 性与用户体验直接相关。5）实时推荐系统，根据用户实时点击行为计算从而进行内容/商品/广告的实时推荐。 6）深度学习，可用于模型的在线推理和离线训练，降低模型推理延迟。对于上述业务而言，流处理显然是必需 品，其延迟对于业务为关键价值/指标，难以通过批处理系统替代。 随着流处理系统在逐步成熟，有望承接更多业务场景。据《A survey on the evolution of stream processing systems》，近年流处理系统在状态管理、容错机制上逐步成熟，如 Flink 的 Checkpoint 机制和与 Kafka 集成实 现端到端仅一次处理语义，它们能更好地保证数据处理的准确性和一致性，这是过去批处理系统的核心优势。 研究认为批处理系统更适合处理有界、静态的大数据集，可以充分利用集群资源进行高度并行化。而流处理系 统则专门为连续到达的无界数据流设计，能够实时处理并生成结果。

流处理增长驱动力是对批处理的替代+模型推理/自动驾驶等新场景的增长。据阿里云开发者公众号，2016 年 Flink 支持阿里双 11 搜索推荐全链路实时化后，2017 年阿里开始将全集团的实时数据业务都迁移到 Flink 平台上。2020 年，Flink 流批一体 SQL/Table API 在双 11 落地60，21 年阿里逐步用 Flink 替代批处理任务场景61。 另一方面，如 OpenAI 推出 GPT 系列大模型，Tesla 24 年年内推进 FSD 上线，这意味着 AI 推理/自动驾驶的需 求显著增长，进而推动对于流处理系统的需求增长。总体来看，2019 年 Flink China 大会，阿里提出当前流处理 需求占比约占所有数据处理需求的不到 10%，而批处理占~70%，OLAP 处理~10%。即便不考虑对批处理的替 代，相比于 OLAP 2023 年 118 亿美元的市场规模，流处理当前的商业化进展也较为落后，Confluent FY2023 收 入 7.77 亿美元，对比 OLAP 龙头 MongoDB （23 年收入 16.8 亿美元）有一定差距。我们认为行业竞争格局并 非导致 Confluent 商业化落后的原因，可以看到 CSP 主要以组件方式提供服务，缺乏系统优化。相反，Confluent 的问题在于 1）Kafka 主要聚焦流存储，而引入 Flink 流计算引擎，Confluent 能够提供更多创造业务价值的用例， 并驱动用户加速部署/迁移。2）流处理在多数企业内部并非关键系统，IT 预算占比较低，在 IT 支出提升后，托 管带来的运维成本节约能够覆盖工程师成本，企业才会转向上云，Confluent 的网络效应才会体现。

Flink：垂直拓展至流计算领域，向流数据处理平台演化

流处理正逐步取代 Lambda 架构，Flink 提供了同类最优选择。大数据的 Lambda 架构主要分为批处理层和 流处理层，批处理层采用 MapReduce、Spark 等技术进行数据批量处理，而流处理层中采用 Storm、Spark Streaming 等技术进行实时处理。由于需要同时维护两个单独的代码库分别进行批处理和流处理，维护和调试复杂性很高， 因此需要一种范式进行流批一体处理。Storm 虽然可以做到低延迟，但是无法实现高吞吐，也不能在故障发生时 准确地处理计算状态。Spark Streaming 通过采用微批处理方法实现了高吞吐和容错性，但是牺牲了低延迟和实 时处理能力。而 Flink 是一种兼具高吞吐、低延迟和高性能的实时流计算框架。

Flink 采用 JobManager 和 TaskManager 的主/从架构。JobManager 是主节点，作为 Flink 集群的控制中心， 负责协调和调度。TaskManager 作为工作节点，负责执行实际的数据处理任务，管理任务的运行状态，并参与检 查点的创建以实现状态的一致性保证。Client 不是运行时和程序执行的一部分，但它用于提交作业到 Flink 集 群。

Flink 使用分布式快照（Distributed Snapshots） 代替微批处理模型，避免高吞吐量以牺牲延迟为代价。传 统快照机制的问题在于：1）需要所有节点停止工作，即暂停整个计算过程，影响到数据处理效率和时效性；2） 需要保存所有节点的操作中的状态以及所有在传输中的数据，消费大量的存储空间。Flink 采用基于 Chandylamport 算法的异步快照方式。Flink 定期对正在运行的流拓扑的状态做快照，在数据流中插入称为 Barrier 的特殊标记，并将这些快照存储到持久存储（例如，存储到 HDFS 或内存中文件系统）。通过状态保存，当系统需 要从故障中恢复时，可利用这些快照迅速回滚到之前的快照生成式时刻重新进行流处理。Flink 仅记录自上一个 检查点以来状态的变化（即增量检查点），而不是整个状态的全量复制，减少了创建检查点所需的时间和存储 空间，降低了对吞吐量的影响。同时检查点的创建与数据处理同步进行，barrier 像业务数据数据管道中流动， 减少了处理延迟，避免了因定期停止处理来创建快照而造成的吞吐下降。对于小状态（例如，计数或其他统计 摘要），这种持久化开销通常可忽略不计，而对于大状态，状态持久化间隔需要在吞吐量和恢复时间之间进行 权衡。

Flink 通过 MicroBatch 访问状态数据实现高吞吐。为保证流计算状态一致性64，流处理系统要将状态数据 存储在状态后端，用来做分布式快照保证容错。但主流的状态后端，如 RocksDB、Niagara 等，成为一个性能瓶 颈：每次读写状态时，数据必须序列化和反序列化，这会消耗 CPU 资源；当状态存储在磁盘上时，涉及磁盘 I/O 操作。Flink 采取的解决方式是当需要访问状态时，缓存一批事件数据后再做批量处理，对于相同 key 的事件只 需对状态进行一次访问操作，减少了状态访问的总次数。在数据中 key 重复率较高的场景下效果更为明显。 Flink 采用有状态的运算实现低延时。在 Flink 中会将算子的中间计算结果/缓存数据保存在内存/文件系统 中，下一个算子可从当前状态获取中间结果进行运算，而无需反复访问外部存储或重新处理所有历史数据，减 少不必要的数据副本，优化系统性能。

Flink 原生迭代运算符使其在图形分析和机器学习场景有优势。Flink 的迭代运算符允许在数据流上直接定 义循环处理逻辑，无需用户手动管理中间状态或数据交换。迭代运算符内部实现了数据的循环流动，直到满足 某个停止条件（如达到指定迭代次数、收敛阈值）为止。这种方式自然适合于需要多次迭代以逐渐逼近结果的 算法，如机器学习模型训练。如机器学习领域的梯度下降法。Flink 的迭代运算符允许模型参数在每轮迭代中自 动更新，同时利用 Flink 的状态管理机制来维护中间结果，简化编程模型实现，减少序列化和网络传输开销而加 快了迭代速度。此外，Flink 的低延迟特性使得模型训练和在线预测更加实时，有利于实时 ML 应用。对于图形 处理，如广度优先搜索、最短路径等图算法往往需要多轮遍历图的节点和边。Flink 的迭代机制天然适配这类问 题，它可以在每次迭代中处理一部分图结构，更新节点状态，然后基于更新状态继续下一轮迭代，直到找到解 或满足终止条件。这比传统批处理方式更高效，因为它能连续处理数据流并在内存中维护状态，减少磁盘 I/O。

最终性能方面，据 Yahoo 早期测试结果，Flink 和 Storm 的性能相似，而 Spark Streaming 延迟更高，但能 够处理更高的吞吐量。据美团，Identity 逻辑下，Flink 吞吐是 Storm 的 3.2x（1 个分区）/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 的延迟较低。总的来说，Flink 适合 Exactly Once +高吞吐+低延迟需要进行状态管理/窗口统计的场景。

Flink 和 Kakfa 的协同如何体现？流处理技术正改变着数据管理与分析的格局。Kafka 擅长处理大规模、高 速的流数据摄入，能自动扩展以适应任意规模的数据流量，确保数据被精准导向所需位置，这是其核心优势之 一。在此基础上，流处理不仅仅是数据摄取，更重要的是对这些实时数据流进行即时转换，包括合并不同数据 源、数据过滤与清洗等操作，这在 ksqlDB 等工具中通过维护状态实现。目前，大多数应用场景集中于数据的即 时摄取阶段，即流摄取，而非流处理本身。数据处理通常发生在数据被导入到 Snowflake 或 Redshift 等数据仓库 之后。然而，随着 Flink 这类技术的集成，流处理的潜力可被进一步挖掘，它使得更多的客户能够在数据流入时 直接进行高级处理，这不仅增加了数据处理的深度和价值，还可能通过数据流的拆分、合并等操作提升处理效 率，进而提高整体吞吐量，例如从每秒 5MB 提升至 8MB。因此，Flink 的加入对于 Confluent 而言，是一个战略 性的补充，预示着从单纯的流数据摄取向更高附加值的流处理转型，有望开启新的增长点，并显著提升其市场 竞争力和客户价值。

成长逻辑：数字原生企业仍具增长空间，Flink 有望驱动用户渗透

基于 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%的收入。

1Q24 大型客户拓客驱动总客户数增长速率提升。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。

目前 Confluent Cloud 客户结构中，25%~30%的客户是由 Confluent Platform 转化而来；约 50%的客户由开 源 Kafka/新用例转化而来；另外 25%的客户是从 AWS Kinesis、AWS MSK、GCP Pub/Sub 或 Azure Event Hubs 等服务中迁移过来。Confluent 最容易获取的客户是内部没有相关专业知识的公司，他们最倾向于购买完全托管 服务。对于开源 Kafka 用户，如果他们在部署和允许中遇到困难，例如集群扩展和工作负载重新平衡，这部分 客户的转化相对容易，大约在 1 个月之内可以完成转化。如果开源 Kafka 用户只是认为部署和运维较为繁重， 大致需要 4~6 个月的销售周期进行转换。 数字原生企业客户仍有较大增长空间。从企业性质上看，Confluent 的客户可分为数字原生公司（DigitalNative Business）和传统企业。数字原生公司使用量较高，达到 GB/s 级使用规模，例如 Pinterest 、Uber、Lyft、 Stripe、Square 等。对于这类企业，流处理在其业务中的重要性高，他们往往拥有自己的 DevOps 团队，更有可 能会选择自己进行流处理，而不是使用简化的 API。主要原因在于对自主控制能力和定制化能力的需求。其他 原因包括对数据隐私和网络传输流量成本的考虑。这部分市场 Confluent 尚未渗透，仍有很大增长空间。对数字 原生公司来说，80%~90%的成本在于网络传输成本，Confluent 的主要策略是采用多种技术避免数据跨区域传输 以降低成本。如前所述，EU/英国反垄断监管压力下微软/谷歌/亚马逊均取消数据迁移费用，未来数据传输费用有望下降。

传统企业方面，高盛、摩根大通、沃尔玛等大型企业使用量较高，但大部分非科技传统企业的使用规模在 1~5MB/s。对他们来讲，90%的成本是计算成本，Confluent 采取的现有策略包括云原生多租户能力，并且根据用 户实际使用的计算能力，而不是固定的节点集群来收费等。

（本文仅供参考，不代表我们的任何投资建议。如需使用相关信息，请参阅报告原文。）