2025年Confluent公司研究报告：下半年有望启动新一轮产品周期，当前估值隐含低迷预期

平台深化：从数据管道到企业神经中枢

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

更通俗地理解，Kafka 兼顾 1）信息传输和 2）数据处理的职责。消息系统可以类比于物流调度中心，主要 解耦生产端和消费端，例如顾客只管下单不在于履约，商家只需要备货并向物流承运商下单，物流承运商专职 负责物流承运商，过去的消息系统从设计哲学上就面向单点消息处理，例如 ActiveMQ 采用主从结构，天然扩 展性不足，RabiitMQ 允许分片但专注于精细化管理，高吞吐情况下性能开销巨大。 从性能/瓶颈来看，过往消息系统主要在 I/O 瓶颈和内存方面存在设计问题，队列的核心是对单个消息的生 命周期负责，它必须精确地追踪每一条消息是“可用”、“被锁定”还是“已被消费”。消息被消费后，必须 从队列中移除，为后续消息腾出空间，并确保它不会被再次消费。传统队列（如 RabbitMQ/ActiveMQ）在本质 上就像一个动态的、需要不断擦写的待办事项清单。假设这个待办清单非常长，有数百万条。当你完成第 500 条任务和第 10000 条任务时，你需要在笔记本的两个完全不同的位置进行“擦除”操作。随着时间推移，笔记 本上会布满被擦除后留下的“空洞”（磁盘碎片）。这种“就地更新”和“删除”的行为，在磁盘层面就是不 连续的、跳跃式的读写，即随机 I/O。 Kafka 的日志模型则完全不同，它就像一部只能追加、永不修改的历史档案。因为“日志”的核心是忠实 地记录所有发生过的数据流，它不关心这些数据“是否被处理”。数据一旦写入，就永远不会被修改或删除（只会在过期后被整个旧文件段删除）。因此在磁盘层面采用顺序 I/O。 内存使用方面，传统消息系统由于采用复杂的协议、支持状态管理，本质上是支持复杂的功能，类似一个 功能复杂的人工收费站，而 Kafka 功能简单，只识别主题-分区，其余复杂功能均在端侧实现（消费端/生产端）， 因此最大限度采用零拷贝，降低对 CPU 内存的占用，从而提升吞吐量。 以上特性实现了 Kafka 在实时性方面的优势，另外则是低成本。在大规模业务场景下使用根本诉求或者应 用的最大障碍就是成本，并非所有功能都能创造收入，大多数模块都是成本模块的情况下，尽可能优化成本是 核心诉求。 Kakfa 在性能优化方面主要采用批处理+压缩，核心思想都是避免处理大量、零碎的单个操作，转而处理少 量、规整的批量操作。批处理本质上减少网络请求（TCP 连接和握手）和磁盘 I/O 的次数。相比于为 1000 条消 息进行 1000 次网络请求和磁盘写入，将其打包成一次请求和写入，开销会急剧下降。批处理在事实上牺牲了一 定的延迟（实时性）以换取吞吐量，底层思考还是绝大多数业务场景对于延迟的要求并非极致，而是在合理的 成本限度内尽可能低延迟。Kafka 更进一步地引入压缩，由于批量数据中通常包含大量重复信息（比如 JSON 的 字段名、日志格式等）。把它们放在一起压缩，算法能找到并消除更多冗余，从而获得更高的压缩比。这一技 术进一步提升吞吐量，但代价就是生产端/消费端需要消耗 CPU 资源解压缩，会产生毫秒级别的延迟。

产品周期：Kora+WrapStream 驱动客户迁移，Flink 整合扩大 AI 敞 口

Kora 引擎：推出云原生架构 Kora 解决存算一体造成的成本/性能问题

过去 Kafka 框架的一大技术债务是 Kraft 协议，而 Confluent 通过推出云原生引擎 Kora 和移除 ZooKeeper 依赖的 KRaft 协议，在架构方面重新取得优势。为了理解 Kora 的价值，我们仍然有必要简要回顾 Kafka 引入 Zookeeper 的背景。 在 Kafka 的早期设计中，集成 ZooKeeper 是一个务实且必要的选择。它扮演着 Kafka 集群的分布式协调服 务角色，负责处理一系列关键任务，包括在集群中选举唯一的“控制器”Broker、存储并同步所有集群元数据 （如主题、分区、配置信息、访问控制列表 ACLs），以及追踪所有 Broker 的在线状态。将这些复杂的共识问 题外包给一个成熟的、经过验证的系统，使得 Kafka 的创始团队能够集中精力解决其核心的数据平面挑战，即 日志结构化存储以及高效的生产者/消费者协议。 随着 Kafka 应用规模的爆炸式增长，最初的明智之选逐渐演变为阻碍其发展的技术债务。这主要体现在以 下几个方面：1）运维的二元性与复杂性。对开发者和运维团队而言，最直接的痛点在于必须同时运行和维护两 个独立且复杂的分布式系统。这意味着需要为 Kafka 和 ZooKeeper 分别配置专门的技术专长、监控告警、补丁 更新、安全加固和基础设施。这种二元性不仅显著增加了总拥有成本（TCO），也扩大了潜在故障的攻击面， 使系统整体的稳定性管理变得异常复杂。 2）难以逾越的可扩展性上限。当 Kafka 集群的规模扩展至极限时，ZooKeeper 作为元数据存储的瓶颈效应 便暴露无遗。当集群中的主题和分区数量增长到数十万甚至更高时，ZooKeeper 便成为制约系统进一步扩展的短板。其技术瓶颈在于，作为集群大脑的单一控制器模型，其所有元数据操作都必须通过 ZooKeeper 来协调和 持久化。当一个集群需要支持数百万个分区时，元数据更新（如 Leader 选举、分区重分配）的绝对数量会急剧 增加。这些海量的更新请求涌向单一的控制器，控制器需要串行化处理这些请求，并与外部的 ZooKeeper 系统 进行多次网络交互来完成提交。这个过程引入了显著的延迟，从根本上限制了整个集群的管理吞吐能力和动态 性。因此，Kafka 的扩展性并非受限于其卓越的数据平面，而是被其依赖 ZooKeeper 的元数据控制平面所束缚。 3）高延迟的故障转移与可用性窗口。ZooKeeper 依赖在关键故障场景下暴露其缺陷。当现任控制器 Broker 意外崩溃时，集群必须通过 ZooKeeper 选举出一个新的控制器。然而，新当选的控制器在能正式接管工作前， 必须执行一个极其耗时的操作：从 ZooKeeper 中加载整个集群的全部元数据状态。在这个漫长的恢复窗口期内， 集群的管理功能被冻结，无法处理任何管理类请求（如创建主题）或从其他故障中恢复。对于运行关键业务的 系统而言，这种长达数分钟甚至更久的“不可用窗口”是完全无法接受的 。这直接影响了 Kafka 作为高可用系统 的可靠性承诺。

简单来讲，ZooKeeper 的扩展性较弱，一方面由于外部存储嫁接在 Kafka 系统外，带来存储/通信瓶颈，另 一方面 ZooKeeper 自身存储扩展性弱，规模提升带来运维成本/复杂度非线性提升。KRaft 协议（Kora 引擎的核 心部分）通过将元数据管理内化到 Kafka 自身，从根本上解决了上述问题： 1）架构统一，消除外部依赖：KRaft 模式彻底移除 ZooKeeper，将元数据管理变成 Kafka 内部的事务。 它不再需要与外部系统通信，而是将所有元数据变更作为消息，追加到一个高可用的、内部的、名为“元数据 日志”的特殊 Kafka 主题中。这利用了 Kafka 自身极其高效的日志追加和复制机制，大大简化了架构。 2）近乎瞬时的故障转移：这是 KRaft 带来的最大性能飞跃。元数据日志通过 Raft 共识协议，在多个“仲 裁控制器”节点之间实时同步。如果当前的控制器失效，任何一个仲裁控制器都可以几乎立即接管。因为它本 地已经拥有了完整的、最新的元数据日志副本，完全不需要从任何外部系统加载状态。这使得控制器故障转移 的时间从分钟级缩短到几乎可以忽略不计，极大地提升了系统的可用性和稳定性。 3）扩展性提升：由于元数据管理变得极其高效，KRaft 模式下的 Kafka 集群可以平滑地扩展至数百万个分 区，相比 ZooKeeper 模式，分区数量上限大幅提升。这使得 Kafka 能够从容应对更大规模的业务场景。

Kora 在 Confluent Cloud 中采用率已经达到 100%，WarpStream吸引客户转向 Kora 架构

根据 Confluent 官方博客2，2024 年 10 月 Confluent Cloud 目前已经 100%采用 Kraft 协议（Kora 架构），即 100%移除 ZooKeeper 架构。一个关键的转折点是 2025 年 3 月 18 日3发布的 Apache Kafka 4.0 版本，该版本完全 移除了对 ZooKeeper 的支持，并默认以 KRaft 模式运行。2025 年 6 月 24 日4发布的 Confluent Platform 8.0 也采 取了同样的策略，强制所有本地部署和自管理 Kafka 的用户从 ZooKeeper 迁移到 KRaft。这确保 KRaft 将在未来 一段时间内在整个生态系统中得到普遍采纳。

结合 Apache Kakfa 的更新，3.5 版之后正式弃用 ZooKeeper，因此真正迁移至 Kraft 是从 2023 年 10 月开始， 至今不足 2 年，考虑到本地/自托管模式的迁移周期，目前我们预估绝大多数（90%+）客户仍然采用 ZooKeerper 架构，未来需要 Confluent 不断推动类似 WarpStream 方案承接价格敏感度高的客户，同时降低迁移复杂度和周 期的工具。这一点是 Confluent 不断将开源框架用户转移成 Confluent 付费用户的关键。

如果我们对比 Databricks、MongoDB、Elasticsearch 三者的开源转化策略，我们注意到对 Confluent 的战略 启示：1）超越“更好的 Kafka”，成为“数据流平台”：Confluent 的核心价值主张不应仅仅是提供一个更易于 管理的 Kafka。其真正的护城河在于集成了 Flink、Connect 和数据治理的数据流平台（DSP）。KRaft 迁移工具 应被定位为通往这个更强大、更智能平台的技术路径，是帮助客户降低技术债务、全面拥抱现代数据流架构的 关键一步，而非终点。 2）聚焦“关键任务”的存量用户 (借鉴 MongoDB)：Confluent 最大的机会在于那超过 90%仍在使用 ZooKeeper 架构的庞大用户群。这些用户的 Kafka 集群大多已承载着“关键任务”。将 KRaft 迁移定位为解决其现有痛点 （如运维复杂性、恢复速度慢）并提升稳定性和安全性的必然路径，将是说服他们为 Confluent Platform 或 Confluent Cloud 付费的关键。 3）将迁移工具和低成本方案作为商业漏斗的入口(综合三者)：一个强大、易用的迁移工具，不仅能解决客 户的燃眉之急，更是展示 Confluent 技术实力、引导用户体验其付费平台价值的最佳入口。同时，一个有竞争力 的低成本方案（如 Confluent 最近收购的 WarpStream 所代表的 BYOC 模式）可以有效吸引价格敏感型客户进入付费生态系统，从而扩大整个商业漏斗的顶部。

沿着上述思路，Confluent 过去一年整合 Apache Flink，收购 WarpStream，推出 TableFlow、Freight Clusters 等产品，推动从单点工具向端到端解决方案转型，我们逐步进行针对性分析。

Flink 催化剂：向 AI 价值链上游移动

Confluent 整合 Apache Flink 标志着重大的战略演进，即从流存储（Kafka）领域的领导者，转变为一个完整 的流处理平台。这是从提供“管道”到成为改造管道中数据的“工厂”的转变。Flink 作为有状态流处理的事实 标准，其高吞吐、低延迟和精确一次处理（exactly-once）的语义，在许多实时场景中优于 Spark Streaming 等替 代方案。

由 Flink 驱动、面向 AI的新功能： Flink 原生推理 (Flink Native Inference)：允许用户在 Flink SQL 中直接运行开源或微调的 AI 模型（如 Llama 系列）。这是一个巨大的简化，它将敏感数据保留在 Confluent Cloud 内部，并消除了调用外部 模型 API 所产生的出口费用。 Flink 搜索 (Flink Search)：提供了一个统一的接口，从 Flink 内部查询向量数据库（如 Pinecone、 MongoDB）。这是构建实时检索增强生成（RAG）应用的关键组件，通过用最新数据丰富提示词来 提高 AI 模型的准确性。Tableflow：通过将 Kafka 主题物化为 Apache Iceberg 等开放表格式，弥合了运营（流式）和分析（批 处理）世界之间的鸿沟。这使得 AI/分析平台（如 Databricks、Snowflake）能够查询实时、可信的数 据，而无需复杂的 ETL管道。

Confluent 的 Flink 战略为构建下一代实时 AI 和代理（Agentic）应用提供了切实的架构基础， Confluent 的 发布内容具体而技术化：Flink 原生推理、用于 RAG 的 Flink 搜索、用于分析的 Tableflow。公司 CEO 的评论强 调，生成式 AI 需要新的数据架构，以避免“混乱的机器”基于过时数据做出决策。竞争对手 Redpanda 也推出 了“代理 AI”平台，这验证了该领域已成为新的竞争焦点。Confluent 并未自己构建 AI 模型，而是构建了不可 或缺的数据层，为这些模型实时提供新鲜、可靠且富含上下文的数据。Flink 搜索与 Flink 原生推理的组合，本 质上是一个预打包的 RAG 管道。这是一个更具防御性且平台中立的策略。Flink 将 Confluent 的叙事从数据基础 设施提供商转变为 AI 革命的受益者，这极大地提升了其在企业 IT 预算中的战略重要性，并提供了一个能够重新加速业务增长的强大新动力。

数据流平台（Data Streaming Platform, DSP），该平台不仅创造了强大的技术壁垒，也构筑了深厚的商业护 城河。Confluent 的 DSP 战略围绕四大核心能力构建： Stream（流）：以云原生引擎 Kora 驱动的 Kafka 为核心，提供可靠、可扩展、高性能的事件传输。 Connect（连接）：通过 Kafka Connect 生态，无缝连接数百个数据源，打破数据孤岛。  Process（处理）：深度集成 Apache Flink 和 ksqlDB，提供强大的实时流处理能力，让数据在流动过程中 就能被转换、丰富和分析。 Govern（治理）：通过 Schema Registry、数据目录（Data Portal）和数据质量规则，确保数据在流动中的 可信、安全与合规。 这一体化平台战略的威力在于，它为客户提供了一站式的解决方案，极大地降低了技术栈的复杂性和集成 成本。财报数据显示，DSP 相关组件的消费增长速度“远超整体云业务的增长”，证明了客户对这一完整平台 价值的高度认可。4Q24 业绩会 Confluent 披露 Connect, Process, 和 Govern 这三个组件的消费总和，约占其云 业务（Confluent Cloud）收入的 13%，1Q24 为 10%。DSP Products = Connect + Process + Govern + TableFlow， 25 年 Flink + TableFlow 占比提升，随着此前 POC 项目相继部署，预计增速会持续高于 Cloud，拉动整体收入增 速回升，FY25H2/FY26 有望实现整体增速触底回升。

竞争格局：相比 CSP 和初创公司 Win Rate 仍然稳定在 90%+

与 CSP 的竞争：基于完整性与中立性的护城河

AWS MSK、Azure Event Hubs 和 GCP Pub/Sub 为那些已深度投入单一云生态系统的客户提供了便利性和深 度集成。它们的主要吸引力在于采购的简便性以及与其它原生服务的集成。 Confluent 的差异化价值： 平台完整性：CSP 的产品通常是“作为组件的 Kafka”，缺乏使 Confluent 成为一个平台的完整工具套件。 这包括对 Kafka Connect、Kafka Streams、ksqlDB 和全面治理套件的支持缺失或有限。Doordash 因复 杂性和成本而从 Kinesis 迁移出来的案例，是一个有力的证明。 多云中立性：Confluent 在 AWS、Azure 和 GCP 上提供一致的体验，这对于追求多云战略以避免厂商 锁定或利用不同云的最佳服务的企业至关重要。 专业知识与支持：Confluent 雇佣 Kafka 的大部分创建者和顶级贡献者，能提供通用 CSP 支持团队无 法比拟的专家级支持。 在监管压力下，2024 年开始行业范围内云数据出口费用陆续降低和豁免6，目前看客户将数据从云厂商迁移 出去的费用仅按照成本支付，2027 年 1 月 12 日起则不允许云服务商针对数据迁移收费，直接缓解 Confluent 多 云战略历史上最显著的摩擦点之一。历史上，反对 Confluent 等多云服务的一个主要论点，就是跨云移动数据（例 如，从 Azure 的应用通过 Confluent Cloud 处理数据，最终存入 AWS 上的数据仓库）所带来的惩罚性成本。这 种成本是 CSP 厂商锁定的有力工具。Confluent 也指出，对于数字原生公司，80-90%的成本可能与网络相关。 随着这些出口费用的减少，选择像 Confluent 这样的中立多云平台而非 CSP 原生服务的经济惩罚显著降低。这 一长期趋势从根本上强化了 Confluent 的核心价值主张，使其“同类最佳、多云”的论点对更广泛的客户群体具 有经济可行性，从而削弱 CSP 的锁定成本。

Redpanda 的挑战：速度与广度的对决

Redpanda 的论点是：与 Kafka 兼容，但更简单（单一二进制，无 ZK/JVM）、更快（C++架构）、更便宜 （硬件占用更少）。2025 年 1 月 Snowflake 有意以高达 15 亿美元的估值收购 Redpanda，但后续该交易并未达 成。Redpanda 在 2025 年 4 月宣布完成了由 GV（谷歌风投）领投的 1 亿美元 D 轮融资，公司估值达到了 10 亿 美元。此前《福布斯》报道，Redpanda 在 2023 年的年收入约为 2000 万美元，而 Redpanda 在 2024 年 2 月提到 其 2024 财年实现了 300%的收入增长，如果假设 2024 年全年维持 300%增长，对应 24 年 8000 万美元的收入（存 在财年/自然年间隔导致的一定误差）。如此对应 Redpanda 最新一轮估值对应约 12.5x TTM EV/Rev。考虑到 Confluent 目前收入规模对应 Repanda 10 倍以上，且估值比 Redpanda 折价（溢价对应 Redpanda 维持高增速到 Confluent 这个体量），此次收购实际上为 Confluent 估值提供支撑。

定位与市场进入策略 (GTM)：Redpanda 以性能和简单性为卖点，目标客户是开发者。其新的“代理 AI”平台和“自带云”（BYOC）模式，旨在满足现代、对延迟敏感的工作负载以及需要数据主权的客户。他 们拥有如 Activision 和 Vodafone 等令人印象深刻的客户案例。

性能基准测试：这是一个争议点。Redpanda 自己的基准测试声称延迟低 10 倍。然而，由 Confluent 委托的测试显示，在许多场景下，特别是在稳定、高吞吐的工作负载下，Kafka 的性能优于 Redpanda。现 实情况可能取决于具体的工作负载。Redpanda 可能在特定的低延迟、小批量场景中表现出色，而 Kafka/Kora 则为高吞吐、大规模的企业级稳定性进行了优化。

Confluent 的反制定位：Confluent 对抗 Redpanda 的护城河并非原始的单节点性能，而是平台的广度和 企业级成熟度。

生态系统：Confluent 拥有一个远为成熟的生态系统，包括 120 多个预构建、完全托管的连接器、 流治理套件，以及现在完全集成的 Flink 服务（ksqlDB 也是其专有优势）。Redpanda 的连接器支持有 限，且没有原生的 Flink/Streams 等价物。

企业级功能：Confluent 提供更强大的安全功能（RBAC、审计日志）、服务等级协议（SLA），以及在最大、最复杂的企业部署中得到验证的良好记录。

Pulsar：没有看到显著的采用率提升

一些观点认为 pulsar 在开发者采用侧快速追进乃至超越 kafka，但其援引的依据并不足以支持论点，例如上 图来自 StreamNative（引用 apiseven.com），首先是来源问题，APIseven 是一家专注于 API 网关的软件公司， 基于 Apache APISIX 进行分析/管理，但 APIseven 可能无法统计到 CSP 的云网关数据，因此从统计样本上存在 一定的缺漏，例如 APIseven 网站披露的代表性客户包括 Zoom、腾讯、海尔、Lotus 汽车、海信、Vivo、荣耀、 爱奇艺、雪球等，相当大比例都是中国客户，从地域分布上似乎多元化不够，我们认为代表性存在一定欠缺。 其次，纵轴的单位上，月度活跃开发者的单位数数十个，30-60 个开发者的波动引发曲线较大波动，我们认为开 发者社区的活跃度从采用者角度看更合适，即以 Github Stars 的趋势，本身样本统计足够广泛，且针对需求方而 非供给侧。 从 Github Stars 角度看，Apache Kafka 相比于 Redpanda、Pulsar 的差距并未缩小，而是继续扩大了，因此我 们认为现阶段不足以认为 Redpanda、Pulsar 对 Kafka 构成较大竞争压力。

动态跟踪框架：目前指引保守，下半年 NDR 有望回升

财务与 GTM 动能：1Q25 Callback 指引隐含客户收入增速周期触底不反弹，下半年 NDR 预计 触底后回升

Digital Native Customer 收入增速呈现周期性，当前指引隐含周期触底，通常周期触底会迎来反弹，这是企 业从 PoC 推向部署前的常规优化动作。公司 1Q Callback 提到不认为是宏观因素导致放缓，也并非竞争因素导 致，而是个别 Top 20-25 客户预算优化导致（推测是 24Q1 签约的 OpenAI，同期 Datadog 也出现类似情况）。 目前预期有所修复，但校正幅度不及 DDOG，DDOG 较 2 月高点下跌 11%，CFLT 下跌 30%+。

另一方面，参考 NDR，3Q24 受益于一次性大额合同，3Q25 预计 NDR 可能是全年低点，26 年则回归常态 至 120%以上。考虑到此前提到的 WarpStream、Flink、TableFlow 等产品陆续 GA，客户逐步采用预计推动此数 据走高。 客户获取方面，宏观环境紧张，叠加 4Q23 渠道策略调整，2023 年下半年以来 Confluent 在年消费额>$100K以上客户的获取方面进度放缓，弱于三年平均水平，但 1Q25 看到在大客户获取方面超于过去季节性平均水平， 结合此前与 Databricks 的合作，后续预计能看到在客户获取效率、稳定性方面的提升。

产品发布里程碑：Flink 推理/搜索/ML 函数发布有望推动客户采用，关注 Freight Clusters 在 Azure/GCP GA 催化

我们注意到 2025 年以来关键 Flink 功能的正式发布（GA）节奏明显加快，如原生推理、搜索、新的 ML 函 数。 Flink ML Library 相关里程碑:Flink ML API 发布 (2022 年 1 月): 提供了构建 ML 管道的 API. 高性能 Flink ML 基础设施发布 (2022 年 7 月): 提供了运行 Flink ML 作业的基础设施7 . 特征工程算法和多版本 Flink 支持 (2023 年 4 月和 6 月): 进一步增强了 Flink ML 的能力8 . Confluent Cloud for Apache Flink GA (2024 年 5 月)：Confluent Cloud 上 Apache Flink 的托管服务正式可用。 该服务现在支持 AI 模型推理，允许用户使用熟悉的 SQL 语法与 AI/ML 模型直接交互，从而简化 AI 应用 程序的开发。 Apache Flink 新增原生推理、搜索和内置 ML 函数 (2025 年 3 月):Flink Native Inference: Flink Native Inference 允许团队在 Confluent Cloud 中直接运行任何开源 AI 模型，从而简化复杂的工作流程10。 Tableflow for Apache Iceberg (2025 年 4 月): Confluent Cloud 的 Tableflow 正式支持 Apache Iceberg，允许 将 Apache Kafka 主题转换为 Iceberg 表，简化数据集成11。

Flink Search (2025 年 6 月): Flink Search 统一了跨多个向量数据库的数据访问，简化了发现和检索12。

除自身产品迭代以外，Confluent 在对外构建战略合作伙伴关系方面 2024 年以来也有所加速，例如与 Databricks、Snowflake 以及关键向量数据库提供商（如 Pinecone）的深度集成。这些合作关系验证了 Confluent 作为中立连接组织的角色。

潜在催化：10-K 修订高管遣散福利计划，可能成为并购的相关性信号之一

我们注意到，Confluent 2月经历了一次重要程序性变更，2025/2/18 Confluent 提交了 10-K，关键附件为 Exhibit 10.16，即《Confluent, Inc.高管控制权变更/遣散福利计划》（Change-In-Control）福利条款，CIC 安排的首要目 的是确保公司高层管理人员能够专注于寻求并执行符合股东最佳利益的公司交易，而不必担心这些交易可能导 致其个人失业。这些通常被称为“黄金降落伞”的条款，旨在中和高管在并购过程中的个人财务风险，使他们 能够客观地评估收购要约。次要目的是留住核心人才，潜在或实际的并购交易所带来的不确定性，可能会分散 关键员工的注意力，甚至导致他们寻求其他工作机会。一个健全的遣散计划可以有效降低这种人才流失的风险。

编辑：火腿肠