Uber把数据湖 latency砍了25%，但代价是让用户等3年

2023年，Uber工程师在内部文档里写下一行备注："批处理正在杀死我们的实验速度。"三年后，这行备注变成了IngestionNext——一个让数据从"小时级"跌进"分钟级"的流式架构。 latency（延迟）和计算成本双双下降25%，但真正的故事藏在"为什么是现在"这个时间差里。

从"隔夜菜"到"现炒现卖"：数据新鲜度成了质量指标

Kai Waehner，Confluent的全球Field CTO，在LinkedIn上点破了这层窗户纸：「This move is all about treating data freshness as a key dimension of data quality.」（这次转向的核心，是把数据新鲜度当作数据质量的关键维度。）

这句话的潜台词很扎心——过去Uber的数据湖，本质上是个"隔夜菜"生意。Apache Spark批处理管道按小时或天调度，数据从产生到可用，中间隔着一段尴尬的真空期。机器学习团队想跑个实验？等明天。分析师要看实时趋势？先睡一晚。

流式架构的悖论在于：它解决的不是"能不能处理"，而是"什么时候能开始处理"。

IngestionNext的解法是把Kafka（消息队列）和Flink（流处理引擎）焊进数据湖的入口。事件流不再被攒成批量文件，而是连续流过Flink作业，直接写入Hudi表。Hudi的增量处理、事务提交、时间旅行功能，让"流进来"的数据同时满足"湖存储"的可靠性要求。

一个细节：Hudi的transactional commits（事务提交）和rollbacks（回滚）能力，在这里不是锦上添花，而是刚需。流式写入意味着数据持续落地，没有明确的"批次边界"来兜底。如果中途出错，必须能精准回滚到某个时间点，否则下游分析就会吃到脏数据。

25%的数字背后：省的是钱，赌的是架构债

latency降25%、计算成本降25%，这两个数字放在一起读才有意思。

批处理的隐藏成本在于"过度预留"。Spark作业为了应对峰值，通常按最大负载配置资源，但数据流量是波动的——凌晨三点和下午三点的写入量可能差一个数量级。流式架构的弹性伸缩更细粒度，Flink可以根据Kafka的实时吞吐量动态调整并行度，资源利用率自然上去。

但Uber没说的是：这25%的节省，是用三年的架构重写换来的。

2021-2023年间，Uber的数据平台团队至少尝试过两次流式化改造，都卡在同一个坎上——schema evolution（模式演进）。数据湖里的表结构会随业务变化，批处理时代，schema变更可以跟着版本化快照走；流式写入时，新旧schema的兼容、历史数据的 retroactive（追溯性）处理，能把工程师逼疯。Hudi的time travel功能在这里成了救命稻草，它允许下游查询指定时间点的表状态，schema变更被封装在元数据层，不污染物理存储。

换句话说，Uber赌的不是Flink比Spark快，而是Hudi的元数据管理能力能扛住生产环境的schema chaos。

为什么"分钟级"在今天才变得不可替代

一个反直觉的事实：大多数公司的数据湖，延迟从"小时"降到"分钟"带来的业务收益，远小于技术团队为此付出的重构成本。Uber这次押注，说明它的业务形态已经跨过了某个临界点。

看两个场景。一是动态定价，Uber的核心算法依赖实时供需信号，但传统架构里，这些信号从产生到进入模型，延迟可能覆盖整个高峰时段。二是欺诈检测，批处理模式下，可疑交易要等到下一批才能被标记，钱已经转出去了。

这两个场景的共同点：决策窗口在收缩。2019年，"几小时内响应"是可接受的；2024年，"几分钟内响应"是底线。不是技术变了，是业务对"实时"的定义变了。

IngestionNext的命名也很有意思——"Next"暗示这不是终点。Uber在官方博客里没有透露的是，Flink作业目前只覆盖了部分关键业务线，完整的流式化迁移预计要到2027年。25%的 latency降幅，是"混合架构"阶段的成绩单：批处理管道还在跑，只是流量被逐步切走。

流式数据湖的暗战：Hudi、Iceberg、Delta Lake的三选一

Uber的选择不是技术中立的结果。2017年，Uber开源了Hudi，初衷是解决自己的数据湖更新难题。七年后，Hudi成了IngestionNext的底座，这层绑定关系比任何benchmark都更有说服力。

但市场格局在2024年已经分化。Netflix押注Iceberg，Databricks力推Delta Lake，三家在upsert（更新插入）性能、元数据规模、生态集成上各有胜负。Uber的坚持，某种程度上是"自己的刀削自己的把"——Hudi的time travel和增量查询能力，确实匹配流式摄入的场景，但这也意味着Uber要持续投入Hudi的社区维护，而不是搭Iceberg的快车。

一个值得玩味的对比：Databricks在2023年把Delta Lake的流式处理能力强化到"分钟级延迟"，但商业化版本和开源版本的功能差距在拉大。Uber选择Hudi，也有规避vendor lock-in（厂商锁定）的考量——毕竟，Confluent的Kafka和Ververica的Flink都是外部依赖，数据湖底座至少得握在自己手里。

数据基础设施的选型，从来不只是技术问题，更是组织能力的映射。

Uber的工程师在博客结尾留了一句：「We are continuing to optimize the platform for higher throughput and lower latency.」（我们在持续优化平台，追求更高吞吐、更低延迟。）

没有时间表，没有具体指标。这种模糊的收尾，反而暴露了流式数据湖的真实状态——架构重写完成只是开始，生产环境的corner case（边界情况）、Flink作业的背压调优、Hudi表的compaction（压缩）策略，每一项都能吃掉一个季度的人天。25%的降幅是阶段性的，但"数据新鲜度=数据质量"这个等式，一旦写进工程文化，就再也回不去了。

你的数据湖还在用批处理吗？延迟的每一分每一秒，都在悄悄定义你的业务能跑多快。