2026年1月9日，Spark 4.1.1正式發(fā)布。同一天，Uber的數(shù)據(jù)團(tuán)隊(duì)里有人重跑了一段5年前的舊代碼——結(jié)果CPU占用掉了40%。沒改業(yè)務(wù)邏輯，沒換集群配置，只升級(jí)了版本。這背后藏著一個(gè)被誤解了10年的設(shè)計(jì)：你的代碼，其實(shí)什么都沒做。

四行代碼，零字節(jié)執(zhí)行

看這段典型代碼：

df = spark.read.parquet('s3://uber/trips/') filtered = df.filter(col('country') == 'US') joined = filtered.join(drivers_df, on='driver_id') result = joined.groupBy('city').agg(sum('fare').alias('revenue'))

四行寫完，如果你此刻去監(jiān)控集群，會(huì)看到詭異畫面：網(wǎng)絡(luò)流量為零，磁盤IO為零，Executor內(nèi)存紋絲不動(dòng)。你的代碼像一封沒寄出的信，靜靜躺在Driver的內(nèi)存里。

直到你寫下result.show(20)或result.write.parquet(...)——這些叫Action的操作——整個(gè)集群才突然蘇醒。Spark把這個(gè)設(shè)計(jì)叫Lazy Evaluation（惰性求值）。翻譯成人話：先記賬，后買單。

2012年Matei Zaharia在伯克利寫Spark論文時(shí)，這個(gè)選擇曾引發(fā)爭議。同期的MapReduce是即時(shí)執(zhí)行，寫一行跑一行，像老式收銀機(jī)咔噠咔噠響。Spark的賬本模式更像信用卡：攢夠一筆，統(tǒng)一結(jié)算。代價(jià)是延遲反饋，收益是全局優(yōu)化。

DAG：Spark的記賬本長什么樣

那四行代碼在內(nèi)存里變成一棵樹。根節(jié)點(diǎn)是讀取Parquet，葉子節(jié)點(diǎn)是按城市聚合。中間分叉：過濾、關(guān)聯(lián)、分組。這棵樹叫DAG，有向無環(huán)圖（Directed Acyclic Graph）。

DAG的妙處在于，Spark能看到完整劇本。它發(fā)現(xiàn)你在關(guān)聯(lián)前先過濾了國家，于是把過濾器推到數(shù)據(jù)源——S3只返回美國數(shù)據(jù)，而不是全量拉取再過濾。它發(fā)現(xiàn)你的三個(gè)窄變換（filter、select、withColumn）可以串成一條流水線，一次內(nèi)存遍歷完成，不需要落盤。

2016年Spark 2.0統(tǒng)一了DataFrame和SQL引擎，DAG的優(yōu)化能力第一次完整釋放。當(dāng)時(shí)Databricks內(nèi)部測試顯示，同樣的TPC-DS查詢，手工調(diào)優(yōu)的RDD代碼被自動(dòng)優(yōu)化后的SQL反超30%。很多老工程師至今記得那個(gè)屈辱的周一晨會(huì)。

但DAG是靜態(tài)的。它基于你寫的代碼生成，運(yùn)行前鎖定。如果數(shù)據(jù)分布和假設(shè)不符——比如某個(gè)城市的司機(jī)ID異常集中——計(jì)劃不會(huì)變。這就是Spark 3.0要解決的問題。

Catalyst：會(huì)進(jìn)化的賬本

Catalyst優(yōu)化器2015年隨Spark 1.3登場，是DAG之上的第二層大腦。它的工作分四步：分析（解析列名、類型）、優(yōu)化（應(yīng)用規(guī)則）、物理計(jì)劃（選擇算法）、代碼生成（把邏輯翻譯成JVM字節(jié)碼）。

最狠的是代碼生成。傳統(tǒng)數(shù)據(jù)庫用解釋器執(zhí)行，每行數(shù)據(jù)都要走一遍虛函數(shù)調(diào)用。Catalyst把整個(gè)查詢編譯成單條JVM方法，循環(huán)展開、SIMD向量化、分支預(yù)測友好。2016年Databricks的測試，代碼生成讓過濾操作快了10倍。

但Catalyst仍是編譯期優(yōu)化。它不知道運(yùn)行時(shí)數(shù)據(jù)長什么樣。2019年Spark 3.0引入AQE（Adaptive Query Execution，自適應(yīng)查詢執(zhí)行），賬本終于能改。

AQE在Shuffle邊界插入檢查點(diǎn)。第一階段跑完，Spark看一眼實(shí)際數(shù)據(jù)量：預(yù)估100萬行的表實(shí)際只有5萬？把Sort-Merge Join換成Broadcast Join，小表直接廣播到各節(jié)點(diǎn)，省去Shuffle。某個(gè)分區(qū)異常膨脹？動(dòng)態(tài)拆分，避免單點(diǎn)拖垮全局。

Netflix 2021年的生產(chǎn)案例：一個(gè)ETL作業(yè)因數(shù)據(jù)傾斜卡在99%三小時(shí)，開啟AQE后降到12分鐘。不是工程師調(diào)優(yōu)了，是Spark在運(yùn)行時(shí)自己改了計(jì)劃。

Spark 4.x：賬本系統(tǒng)的第三次革命

2024年Spark 4.0預(yù)覽版流出時(shí)，內(nèi)部代號(hào)叫"Catalyst 2.0"。正式文檔里沒這說法，但架構(gòu)確實(shí)重構(gòu)了。核心變化：優(yōu)化器從批處理變成增量式，計(jì)劃可以邊執(zhí)行邊調(diào)整，不再依賴Shuffle邊界。

更隱蔽的改動(dòng)在內(nèi)存管理。Spark 3.x的內(nèi)存模型分Execution和Storage兩塊，動(dòng)態(tài)借用機(jī)制復(fù)雜且容易OOM。4.0引入統(tǒng)一內(nèi)存池，用類似JVM G1的Region設(shè)計(jì)，GC停頓時(shí)間從秒級(jí)降到毫秒級(jí)。Databricks基準(zhǔn)測試顯示，交互式查詢的P99延遲下降了60%。

2026年1月的4.1.1是穩(wěn)定版。官方發(fā)布說明里有一句容易被忽略：「改進(jìn)Python UDF的向量化執(zhí)行，Pandas UDF開銷降低至原生Scala的1.2倍」。這意味著PySpark——被詬病多年的性能短板——終于追上第一梯隊(duì)。

一個(gè)細(xì)節(jié)：4.x的Spark UI重寫了SQL標(biāo)簽頁。以前看計(jì)劃圖要瞇眼找瓶頸，現(xiàn)在時(shí)間軸直接標(biāo)紅慢算子，像Profiler的熱力圖。產(chǎn)品經(jīng)理出身的工程師會(huì)懂這個(gè)改動(dòng)：降低觀測成本，比優(yōu)化執(zhí)行本身更能提升效率。

為什么現(xiàn)在必須理解這些

2025年Gartner報(bào)告顯示，73%的企業(yè)數(shù)據(jù)平臺(tái)基于Spark或其商業(yè)發(fā)行版。但調(diào)研同時(shí)暴露一個(gè)斷層：只有12%的工程師能解釋Lazy Evaluation和AQE的交互原理。大多數(shù)人停留在「Spark很快」的模糊認(rèn)知，遇到性能問題時(shí)盲目調(diào)參，或干脆加機(jī)器。

這種認(rèn)知稅在云時(shí)代更貴。AWS EMR和Databricks按秒計(jì)費(fèi)，一個(gè)未觸發(fā)剪枝的全表掃描，可能讓本可10美元解決的作業(yè)燒掉800美元。2024年某金融科技公司的賬單審計(jì)發(fā)現(xiàn)，31%的Spark開銷源于「過早物化」——工程師在調(diào)試時(shí)反復(fù)調(diào)用.count()或.show()，每次都在集群上完整跑一遍計(jì)劃。

理解賬本系統(tǒng)的運(yùn)作，本質(zhì)是理解「延遲」的價(jià)值。不是拖延，是等待信息完備。Spark 4.x把這條原則推到極致：不僅延遲執(zhí)行，還延遲決策，讓優(yōu)化器在最后一刻擁有最多信息。

回到Uber那個(gè)案例。升級(jí)4.1.1后降了40% CPU，不是因?yàn)樾鹿δ埽且驗(yàn)锳QE的增強(qiáng)版更激進(jìn)地選擇了Broadcast Join——而他們的數(shù)據(jù)分布恰好符合觸發(fā)條件。同樣的版本，數(shù)據(jù)特征不同的公司可能毫無感知。

這引出一個(gè)尷尬事實(shí)：Spark的性能是概率性的。同樣的代碼，不同的數(shù)據(jù)，不同的表現(xiàn)。4.x沒有消除這種不確定性，只是讓系統(tǒng)更善于應(yīng)對它。

你的集群上周有沒有出現(xiàn)「計(jì)劃選擇正確但執(zhí)行緩慢」的查詢？Spark UI里那個(gè)標(biāo)紅的Exchange算子，是數(shù)據(jù)傾斜還是預(yù)估偏差——你分得清嗎？