数据栈开始挤泡沫：逻辑正搬回引擎里

数据栈还在拼命往上加层，内核里却在发生相反的事：事务提交逻辑下沉成SQL视图，裁决压到约30毫秒[^1]；Timely Dataflow 的进度跟踪提速约百倍[^2]；Apache Doris 4.1把真实用户身份逐个转发给 Apache Polaris[^3]。三件事凑在一起，至少指向同一个观察——这一轮数据基础设施的竞争焦点，可能正在从控制面转向数据面。

🧱 控制面加层十年，热路径被谁拖慢了

控制面适合拍板，数据面适合干活——但过去十年，大家把拍板的人塞进了流水线。

过去十年，数据基础设施的主流叙事是「往上加」。调度被抽成编排层，流量治理被抽成服务网格，湖仓把元数据抽成Catalog，治理平台再把这些Catalog包一层。每一层单看都有充分的理由，叠加的结果却是：一个查询从发出到执行，要在控制面和数据面之间来回穿好几次。

最夸张的是，热路径也被搬了上去。事务提交这种每秒成千上万次的操作，在一些系统里要先在控制面排队、逐笔裁决、再落回数据面。这正是[^1]那份基准报告反复强调的痛点：协调层的网络往返，构成了尾时延的主要来源——「钱都花在跑腿上了」。

[^1]披露的第一件事给了一个漂亮的反例：把事务提交逻辑直接写成SQL视图，让数据库内核自己解析、自己裁决。据其官方基准测试报告，该方案的吞吐量反超控制面方案；而借助增量视图维护，每次裁决的耗时能压到约30毫秒——这是交互式系统可以接受的量级[^1]。

产业逻辑很朴素：控制面的价值在低频决策，数据面的价值在高频执行。把高频动作留在数据面，把网络往返和上下文切换省掉，这笔账任何架构师都算得清。只是在前几年「加层即先进」的氛围里，没人愿意先做减法。

⚡ 三十毫秒的底气，是只算变化的部分 🚀

快从来不是堆机器堆出来的，是把不必要的工作省出来的。

第二件事发生在流处理侧。流处理里真正难的活，不是把数据算完，而是知道「什么时候算完了」——也就是进度跟踪。下游要回答一个问题：某个时间窗口的数据，是不是都到齐了？大多数流处理器用粗粒度的水位线，或者让算子之间频繁握手，进度信息本身变成了一大笔开销。

Timely Dataflow 的做法是把进度跟踪变成一套严格的数学结构，算子之间的进度交换既精确又低成本。据维护者 Frank McSherry 在项目官方博客披露的优化与基准数据，这一次进度跟踪的开销降低了约两个数量级——同样一批数据处理，别的引擎还在协调，它已经干完了[^2]。

有意思的是，这件事和第一件事共享同一个底层思想：把「每次从头算一遍」换成「只算变化的那部分」。增量视图维护之于事务裁决，正如差分数据流之于实时计算——变化量通常远小于全量，谁抓住了这一点，谁就更有可能在交互式时延上把对手甩开一个数量级。

我的判断：流处理的竞争或许已经越过表面阶段，API好不好看、SQL支不支持，未必是决定性的。更关键的差距可能在内核里——进度跟踪的效率、调度的开销、内存的布局。这些事不性感，但百倍就是这么来的。

🔐 一个共享账号，卡住了湖仓的治理梦

看不见用户的数据链路，谈不上治理。

第三件事来自湖仓侧，也是企业客户抱怨最多的老问题。Apache Doris 一直可以借助 Apache Polaris——Iceberg 的REST Catalog——直接查询湖里的表。但过去默认的路由方式，是所有查询都走一个共享服务账号。Polaris看到的永远是同一个「超级用户」：到底是谁在看这张表？是财务分析师还是实习生？Catalog不知道，自然谈不上细粒度授权、审计和计费[^3]。

Apache Doris 4.1的逐用户身份模式（per-user identity mode）把这件事掰直了：每个真实用户的身份被逐个转发到Polaris，权限判断从「这个服务账号能不能过」，变成「这个具体的人能不能过」[^3]。

改动不大，产业含义不小。数据要素流通、跨部门共享、合规审计，前提都是「谁能看什么」能被精确表达、精确执行、事后可查。共享账号模式下，湖仓只能做粗放式管理——要么给，要么不给。逐用户身份打通之后，行级、列级、按角色的策略才真正有了落脚点。事实上，Apache Polaris 官方文档一直把细粒度授权与审计列为核心设计目标，多家湖仓厂商的治理白皮书也把权限治理列为生产落地的关键前提——在湖仓选型中，权限治理的成熟度很可能已经悄悄排到了性能前面[^3]。

我的判断：湖仓要承接生产级、合规级的负载，身份打通大概率是门票。谁先把「身份下沉」这种不起眼的事做扎实，谁可能就更容易拿到企业客户的信任。

💡 挤泡沫时代，内核工程师的胜利

泡沫挤出去的时候，省下的每一跳网络、每一毫秒，都是真金白银 💰。

把三件事放在一起看，趋势相当清晰——它们都在做减法。

第一件，把高频的事务裁决从控制面搬回SQL视图；第二件，把进度跟踪做到比同行低约两个数量级；第三件，把身份从共享账号换成真实用户——少一层转发，多一份可审计。

这不完全是偶然。AI时代对数据基础设施的要求更苛刻了：训练和推理管道要更大的吞吐、更低的时延，但预算未必同步增长。省下的每一层，都是实打实的机器、运维和人。

控制面不会消失。调度、版本、策略这类低频决策，留在控制面是对的。但「控制面加层＝先进」的时代或许确实在结束。接下来两年的数据栈叙事，更可能围绕内核优化和「少一层」展开——听起来不如新概念性感，落地时却句句省钱、句句提速。

小结

三件事，同一个方向：数据基础设施可能正在从「往上加层」转向「向内挖潜」。事务裁决回到数据面只要约30毫秒[^1]，Timely Dataflow靠进度跟踪拉出约百倍改善[^2]，Doris 4.1让每个用户身份直达Catalog[^3]。下一轮竞争或许不只看架构图有几层，也看内核里省下多少毫秒和跳数。留给中间层的泡沫，可能不多了。

信源注释：

[^1]: 该实时数仓项目官方技术博客发布的基准测试报告（事务裁决时延约30毫秒、吞吐对比数据）。原文素材未注明项目名称与报告链接，正式发布前建议补注具体出处。

[^2]: Timely Dataflow 维护者 Frank McSherry 在项目官方博客（及 TimelyDataflow 仓库变更记录）披露的进度跟踪优化与基准数据。

[^3]: Apache Doris 4.1 官方发布公告及 Release Note 中关于 Polaris per-user identity mode 的说明；另参 Apache Polaris 官方文档中关于细粒度授权与审计的设计目标。