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%的降幅是階段性的，但"數據新鮮度=數據質量"這個等式，一旦寫進工程文化，就再也回不去了。

你的數據湖還在用批處理嗎？延遲的每一分每一秒，都在悄悄定義你的業務能跑多快。