Uber砍掉Spark批处理：25%算力省下来

一家日活过亿的公司，把数据管道的"心跳"从每小时一次改成实时跳动。代价是25%的算力开销，收益是分析师不用再等第二天早上才能看到昨天的数据。

Uber工程师最近完成了代号为IngestionNext的重构——不是小修小补，是把整个数据湖 ingestion（数据摄取）平台的底层逻辑从"批处理优先"翻成"流处理优先"。

旧系统像定时送水的卡车，新系统像自来水管。

以前Uber的数据管道跑在Apache Spark上，按小时或按天调度批处理任务。数据从产生到进湖，延迟以小时计。分析师做A/B测试，实验结果第二天才能看；机器学习工程师想迭代模型，得等数据攒够一批。

Spark不是不能用。它能扛住PB级数据，生态成熟，Uber用了多年。但批处理的本质决定了它的天花板：你再怎么优化调度，数据也得等"满一车"才发走。

IngestionNext的解法是把管道拆开重建。事件流先进Apache Kafka，Flink作业实时消费处理，写进Hudi表。Hudi提供事务提交、回滚和时间旅行——这些原本是数仓才有的能力，现在直接搭在数据湖上。

流优先不是"更快"，是重新定义数据质量

Confluent全球技术布道师Kai Waehner在LinkedIn上评论这个项目时，点出了一个容易被忽略的角度：「数据新鲜度正在成为数据质量的一个关键维度。」

这句话值得拆开看。传统数据质量看完整性、准确性、一致性，新鲜度是"锦上添花"。但当业务决策节奏从"周"压缩到"小时"，新鲜度就从nice-to-have变成must-have。

Uber的业务场景对此很敏感。动态定价、路线规划、司机调度——这些功能背后的模型，喂进去的数据越新鲜，输出越准。延迟从小时降到分钟，意味着模型能捕捉到更当下的供需波动。

技术实现上，IngestionNext用Flink替换了Spark Streaming（注意不是Spark批处理，是Spark的流式组件）。Flink的checkpoint机制和exactly-once语义，让"流"也能保证"批"级别的数据一致性。

Hudi的选择也有讲究。它支持增量处理，避免每次全表扫描；时间旅行功能让数据版本可追溯，出问题时能回滚到特定时间点。这些特性把数据湖往"湖仓一体"的方向推了一步。

25%的算力是怎么省下来的

Uber官方给出的数字是：延迟降低的同时，计算资源减少25%。

这个反直觉的结果来自两个因素。一是流处理的"增量"特性——数据来了就处理，不用等攒够一批再启动大规模计算。二是资源利用率的提升：批处理有明显的峰谷，流处理更平稳，集群不用为峰值预留冗余。

但省资源不是免费的。流系统对延迟更敏感，对故障恢复要求更高，运维复杂度会上一个台阶。Uber没公开讲这部分成本，但业内做类似迁移的公司普遍反馈：省的是机器钱，花的是人钱。

另一个隐性成本是数据治理。流数据源源不断进来，schema变更、数据漂移、乱序事件——这些问题在批处理里可以"隔夜修复"，流场景下必须实时处理。Hudi的事务能力在这里派上用场，但配置和调优需要专门的经验。

从Uber到行业：流优先正在成为默认选项

Uber不是第一个这么做的。Netflix、LinkedIn、Airbnb早几年就陆续把核心管道切到流架构。但Uber的体量让这次迁移有标杆意义——日均万亿级事件，数万张表，数百PB存储。

更关键的是时机。2024-2025年，Flink和Hudi的生态成熟度刚好跨过"能用"到"好用"的门槛。早年流处理被诟病的一致性、可观测性、成本问题，现在有了相对成熟的解法。

对国内公司的参考价值在于：流优先不是"大厂炫技"，而是业务倒逼的技术债偿还。当你的分析师开始抱怨"数据太慢"，当你的实时看板变成"准实时"看板，这个拐点可能已经到了。

当然，迁移路径要量力而行。Uber的做法是"重构"而非"渐进式改造"——直接上新平台，老平台并行运行直到完全切换。这种"掀桌"式升级需要组织决心，也需要业务能容忍短期的双轨运维成本。

一个值得注意的细节：IngestionNext的指标监控里，新鲜度（freshness）和完整性（completeness）是并列的。这意味着系统设计上就把"多快"和"多全"当成同等重要的目标，而不是牺牲一方换另一方。

Uber没有公布下一步计划，但数据平台的演进方向已经清晰：批处理不会消失，但会退到"兜底"位置——流处理搞不定的场景，才用批处理补一刀。这个分工比例，三年前可能是七三开，现在正往三七开走。