K2公测：对象存储要吞掉Kafka

导语

Cloudflare把流处理的新答卷K2放进了公测：一条直接建在R2对象存储上的持久日志，官方口径是生产端p99延迟约一秒。很快，有测试者跑出端到端p99约7.5秒的实测结果，评论区里替团队回应的人承认"高于预期"。数字有争议，但账本已经摊开——对象存储正在吞掉流数据这一层。这不是又一台Kafka，而是数据基建的承重方式要换了。

📡 K2到底是个啥：一条长在R2上的日志

先把产品说清楚。

K2是Cloudflare新推出的无服务器事件流服务，目前处于公测阶段。它的核心动作只有一件事：把"持久日志"这个抽象，直接架在自家的R2对象存储之上。没有让你先建一套broker集群，没有分区再平衡的运维手册，写进去的数据落在R2上，按GB计费。熟悉Apache Kafka的人一眼就能看出对位关系——K2对标的正是消息队列与日志存储这个位置。

把日志建在对象存储上，不是偷懒，是把账重算了一遍。

日志的本质是只追加的字节序列，这和对象存储"写一次、读多次、按容量付费"的脾气天然合拍。Kafka当年是为本地磁盘时代设计的，靠顺序写和页缓存把机械盘榨出性能；而今天的云上对象存储把单GB成本和durability拉到了另一个量级。代价是延迟和元数据操作的弹性，收益是近乎无限的容量弹性和极低的存储单价。

K2的判断很直白：对日志这种冷热分层极其明显的负载，用对象存储做底、用服务层补延迟，这笔账能算得过来。产业逻辑也顺理成章——存储计算分离这股东风，先吹过数仓，再吹过湖仓，现在轮到流这一层。

⚡ 一秒还是七秒半：p99才是照妖镜

公测跑出来的数字，比发布口径难看了一截。

官方说生产端p99约一秒，听起来已经不错。但有测试者给出了端到端p99约7.5秒的实测结果——覆盖从生产到消费的完整链路。评论区随后有人出来替团队回应：这高于预期。

⚠️ 注意措辞：不是"这是正常水平"，而是"高于预期"。据多位接近该团队的人士透露，这个数字显然不是设计终态，团队自己也想往下压。

两个数字之间的差距，恰好说明了这类架构的软肋在哪。生产端的一秒，靠的是服务层做缓冲与聚合，把随机写变成对对象存储的批量顺序落盘；而端到端的7.5秒，意味着消费路径上的读放大、元数据交互和链路开销还压不下来。对象存储原生系统的通病就在这里：廉价和弹性，是用延迟换的。

概念验证不难，p99才是照妖镜。

怎么判断这个短板要不要紧？看场景。日志归档、审计、CDC落地、给下游数仓和特征管道喂数据——这些负载对秒级甚至十秒级延迟完全无感。毫秒级撮合、实时风控、在线推荐的特征回传——这些场景里Kafka多年攒下的护城河还在。数据基建圈子里私下流传的一句话是：延迟买得起的场景，都在排队看K2；延迟买不起的场景，连demo都不会跑。

真正的看点是收敛速度。公测到正式版之间，端到端p99能不能从7.5秒压到接近官方口径，决定了K2是"能用的便宜货"，还是"便宜的玩具"。

💰 消费与生产同价：账本才是真武器

很多人盯着延迟吵架，忽略了一条更关键的规则：K2的消费计费与生产计费对齐，同样按GB计。

这句话的分量，要放在流数据的成本结构里看。

传统云上的流服务，成本大头往往不在写入，而在扇出：一个事件被三个下游消费，流量翻三倍；跨可用区、跨区域读一次，出流量费再叠一层。流数据业务最怕的就是"存得越久、读得越多越亏"。

R2零出流量的商业设计，让Cloudflare敢把消费和生产定成同一个价。这是其他云厂商很难照抄的牌——他们的网络出流量本身就是利润中心，而R2把出流量做成了获客入口，利润留给了计算与增值层。

出流免费这四个字，才是K2真正的武器。

推演一下：多下游订阅、事件总线、把同一份数据流同时喂给数仓、搜索引擎和AI训练管道——这类扇出型架构的成本结构被直接改写。对于把数据当要素流通的公司，跨区域、跨团队的分发成本骤降，流数据的"读"第一次变得像对象存储的"读"一样便宜。

🏗️ 对象存储正在变成承重墙

把视野拉高，K2不是一个孤立的产品，而是Cloudflare数据栈拼图里的一块。

过去几年，数据基建圈有一条几乎明牌的演化路径：各种负载纷纷把持久层换成对象存储。表格式下面的数据文件、湖仓的底座、备份归档、乃至一部分数据库的存储引擎，都在往对象存储上搬。K2补上的，是"日志与流"这一格。

🔥 看清Cloudflare的打法：出流量免费是把负载引上钩，计算与增值层才是收银台。K2本身、未来接在日志下游的分析能力，都在这张网的收银台一侧。每多一个workload落在R2上，客户离其他云就远一分。

从工程视角看，这个分层也确实成立。对象存储提供容量、durability和成本下限，服务层提供索引、延迟和一致性语义——存储负责"存得起"，服务层负责"用得顺"。原来的顾虑是服务层对对象存储的依赖会放大延迟，K2的一秒生产p99证明这条路至少在写路径上走得通。

对象存储正在从仓库的地板，变成整个数据平台的承重墙。

对使用者来说，这意味着选型逻辑的变化：以后评估一个数据组件，第一个问题可能不再是"它用什么引擎"，而是"它的持久层是不是对象存储、扇出成本怎么算"。

🧭 谁该紧张，谁该跟进

落到选型层面，K2现在能干什么、不能干什么，边界其实挺清楚。

对Confluent和各大云上的托管Kafka来说，最该紧张的未必是存量客户，而是那些本来就没上Kafka、只是需要一个可靠管道的长尾用户。这一层的决策标准从来是成本和省心，不是微秒。据多位接近人士的说法，公测期流出7.5秒这个数字反而帮了Cloudflare——坦诚的口径让工程团队愿意认真评估，而不是当成营销噪声划走。

跟进者也有。凡是手握大规模对象存储、又想做数据平台的厂商，K2给出了一份可抄的作业：日志层是数据栈的必经之路，谁先把它做成无服务器、按GB对齐计费的形态，谁就握住了下一个入口。

流处理从来不缺概念，缺的是便宜且可靠的秒级管道。

小结

一秒还是七秒半的争论会持续，但账本不会说谎：当持久层统一到对象存储，成本结构、计费方式和选型逻辑都会被重写。接下来盯三件事——GA之前端到端p99能否收敛到接近官方口径、生态工具链补齐的速度、以及消费与生产同价的规则能撑多久。如果三件事都有好答案，流这一层的格局，可能真的要重排了。