優(yōu)實戰(zhàn)全解析)
1. 為什么Spark面試題翻來覆去就這26個點做大數(shù)據(jù)開發(fā)這幾年我前后參與過不少團隊的技術(shù)面試也幫朋友做過模擬面試。一個很直觀的感受是Spark相關(guān)的問題看似千變?nèi)f化但真正高頻的核心考點其實非常集中。網(wǎng)上流傳的各種面經(jīng)匯總動輒上百題但大部分題目背后的考察點都是重復的本質(zhì)就是那么二三十個。這篇文章把我在面試中被問到過、也實際問過別人的26個Spark高頻考點整理了出來。它們不按難度機械排序而是按“從基礎(chǔ)原理到實踐調(diào)優(yōu)再到源碼級理解”的邏輯展開涵蓋了RDD、Shuffle、Spark SQL、流處理、內(nèi)存管理、故障恢復、調(diào)優(yōu)工具這幾個核心模塊。如果你正在準備大數(shù)據(jù)開發(fā)崗位的面試這篇文章可以直接當作復習提綱。每一個考點我都會先說明面試官問它的動機再拆解底層原理最后補充實際工作中容易踩坑的地方。文章里的很多結(jié)論不是單純從文檔里抄來的而是我在真實任務(wù)中驗證過的——比如某些配置參數(shù)改了之后的效果和官方文檔描述存在明顯差異。先說一個重要建議不要背題。Spark的面試題幾乎沒有標準答案面試官更看重你推導結(jié)論的過程。比如問到“為什么Spark比MapReduce快”如果你能順著“DAG計算引擎、內(nèi)存計算、Task調(diào)度粒度、Shuffle機制”這幾個層次逐步展開效果遠比背一段結(jié)論好得多。2. 從RDD到DAG先搞清楚Spark的骨架2.1 RDD的五大屬性為什么是面試第一問幾乎所有Spark面試的第一題都會落在RDD上。面試官想通過這個問題確認你到底是背過概念還是真的理解Spark的底層設(shè)計邏輯。RDD彈性分布式數(shù)據(jù)集有五個核心屬性這五個屬性不是隨便定的它們分別回答了RDD的五個關(guān)鍵問題分區(qū)列表數(shù)據(jù)被切分成了多少片這是并行計算的基礎(chǔ)。分區(qū)數(shù)決定了Task數(shù)量也就決定了并行度。分區(qū)計算函數(shù)每個分區(qū)如何被計算出來對應(yīng)RDD的compute方法。依賴關(guān)系RDD之間的血緣關(guān)系分為窄依賴和寬依賴這是容錯和調(diào)度的基礎(chǔ)。分區(qū)器數(shù)據(jù)如何被劃分到不同分區(qū)常見的有HashPartitioner和RangePartitioner。首選位置計算某個分區(qū)時優(yōu)先調(diào)度到哪個節(jié)點這是數(shù)據(jù)本地性的基礎(chǔ)。我在面試中經(jīng)常追問RDD的五個屬性里哪個對容錯最重要答案其實是依賴關(guān)系。因為血緣關(guān)系讓RDD可以在部分分區(qū)丟失時只重新計算丟失的分區(qū)而不是整個數(shù)據(jù)集。這也是Spark相比Hadoop的一個核心優(yōu)勢。實際工作中有一個容易忽略的點RDD的五個屬性對普通開發(fā)者來說是透明的你在寫業(yè)務(wù)代碼時基本感知不到它們。但一旦遇到性能問題比如數(shù)據(jù)傾斜、Task執(zhí)行不均勻回到分區(qū)和依賴關(guān)系去分析往往能直接定位根因。2.2 DAG調(diào)度流程從代碼提交到Task執(zhí)行要經(jīng)過幾道工序理解了RDD下一步一定是DAG。DAG是Spark對計算邏輯的抽象表達但面試官真正想聽的通常是一段Spark代碼從提交到執(zhí)行到底經(jīng)歷了什么。完整流程如下用戶代碼創(chuàng)建RDD通過Transformation操作構(gòu)建DAG圖。Action操作觸發(fā)Job提交交給DAGScheduler。DAGScheduler將DAG按照寬依賴切分成多個Stage。Stage內(nèi)部生成一組Task提交給TaskScheduler。TaskScheduler將Task分配到Executor上執(zhí)行。這里有個面試高頻追問點Stage的劃分依據(jù)是什么答案是寬依賴。因為寬依賴意味著需要Shuffle數(shù)據(jù)要從一個Stage的所有分區(qū)流向另一個Stage的所有分區(qū)必須在邊界處等待所有上游任務(wù)完成所以天然是Stage的分界線。而窄依賴不需要Shuffle可以放在同一個Stage里做流水線式執(zhí)行。關(guān)于Stage我還有一條實際經(jīng)驗很多人以為Stage數(shù)量等于Shuffle次數(shù)加一這個說法基本正確但不完全準確。因為某些窄依賴算子組合比如map后跟filter會被合并到同一個Stage而某些特殊情況比如repartition雖然不是Shuffle算子但也會觸發(fā)新的Stage。歸根結(jié)底判斷標準只有一個——是否產(chǎn)生了寬依賴。2.3 Transformation和Action的本質(zhì)區(qū)別RDD算子分為Transformation和Action兩大類。Transformation是懶執(zhí)行的只記錄計算邏輯不真正觸發(fā)計算Action才是真正觸發(fā)作業(yè)執(zhí)行的入口。這個區(qū)別很大所以我在面試中一般會安排一個簡短追問Spark為什么不在一開始就把所有計算執(zhí)行完讓我給出更好的答案。這里的關(guān)鍵是惰性計算。如果每次Transformation都立即執(zhí)行Spark就失去了對整個DAG做全局優(yōu)化的機會——它可以把多個算子合并、調(diào)整執(zhí)行順序、減少Shuffle這些優(yōu)化只有在完整了解計算邏輯后才能做到。另一個高頻追問是Spark為什么不是所有Transformation都返回RDD其實所有Transformation確實都返回RDD但某些Transformation改變了RDD的分區(qū)數(shù)、依賴類型甚至數(shù)據(jù)類型比如map返回MappedRDDreduceByKey返回ShuffledRDD。能說出算子返回的具體RDD類型在面試中會顯得你對源碼有了解。實際開發(fā)中我見過不少人犯一個低級錯誤在循環(huán)里多次調(diào)用Action操作導致Driver和Executor之間反復同步結(jié)果性能急劇下降。正確做法是盡量在一次Action中完成計算或者使用累加器來聚合結(jié)果。3. 面試必考的寬窄依賴與Shuffle真相3.1 窄依賴和寬依賴的判定標準及面試答法窄依賴和寬依賴的判定表面上是看父RDD的每個分區(qū)被子RDD的多少個分區(qū)使用實際上要回到依賴的抽象實現(xiàn)上。窄依賴NarrowDependency包括OneToOneDependency和RangeDependency父RDD每個分區(qū)最多被一個子分區(qū)使用典型算子有map、flatMap、filter、union、coalesce不涉及Shuffle時。寬依賴ShuffleDependency父RDD每一個分區(qū)可能被多個子分區(qū)使用典型算子有g(shù)roupByKey、reduceByKey、join、distinct、repartition。寬依賴一定伴隨Shuffle過程。面試時我的建議是不要停留在定義上立刻補充一句“窄依賴可以進行Pipeline計算因為父RDD的分區(qū)數(shù)據(jù)可以直接傳給子RDD無需等待寬依賴需要Shuffle數(shù)據(jù)要經(jīng)過網(wǎng)絡(luò)傳輸這是Spark性能瓶頸的最大來源之一。”還有一個考點容易被忽視join操作一定是寬依賴嗎答案是未必。如果兩個RDD分區(qū)器相同且分區(qū)數(shù)相同join可以在分區(qū)內(nèi)完成不需要Shuffle。這在面試里是一道很好的加分題說明你對分區(qū)器的理解不只是停留在表面。3.2 Shuffle的整個生命周期寫盤、拉取、聚合Shuffle是Spark面試的核心考點也是實際調(diào)優(yōu)的主戰(zhàn)場。面試官在Shuffle這里通常想聽三個階段的完整鏈路Shuffle Write、Shuffle Read和中間的聚合。Shuffle Write發(fā)生在Map端。在舊版本Hash Shuffle中每個Map任務(wù)會為每個Reduce分區(qū)生成一個文件文件數(shù)爆炸性問題嚴重。Sort Shuffle引入了合并機制每個Map任務(wù)只生成一個文件并在寫盤前按分區(qū)排序這就是為什么Sort Shuffle在默認配置下是首選。Shuffle Read發(fā)生在Reduce端。Reduce任務(wù)從各個Map任務(wù)的文件中拉取屬于自己的數(shù)據(jù)塊拉取方式從早期的BlockStore拉取演變?yōu)镹etty傳輸。這里面試官常問一個問題Shuffle Read階段數(shù)據(jù)是邊拉邊聚合還是全部拉完再聚合實際上reduceByKey在讀取每個分區(qū)的數(shù)據(jù)時會先在Map端做一次combine局部聚合減少網(wǎng)絡(luò)傳輸量Reduce端再做最終聚合。這就是combine操作的價值。關(guān)于Shuffle還要知道一個調(diào)優(yōu)參數(shù)spark.shuffle.file.buffer默認32K它控制Shuffle Write時輸出文件的緩沖大小spark.reducer.maxSizeInFlight默認48M用于控制Reduce端拉取數(shù)據(jù)的內(nèi)存上限。實際工作中我遇到過不少因為這兩個參數(shù)設(shè)置不當導致的OOM或網(wǎng)絡(luò)擁塞問題。必須提一個容易踩的坑Shuffle不只在顯式的groupByKey、join時發(fā)生。很多看似不起眼的操作比如distinct、sortByKey、repartitionAndSortWithinPartitions內(nèi)部都會觸發(fā)Shuffle。單獨看沒問題一旦在循環(huán)里使用Shuffle次數(shù)會成倍增長性能災難就是這么來的。3.3 groupByKey vs reduceByKey經(jīng)典送命題的全面拆解這大概是Spark面經(jīng)里出現(xiàn)頻率最高的一題但大部分人的回答只停留在“reduceByKey有combinegroupByKey沒有”。面試官愿意深挖的話會繼續(xù)問兩者最終結(jié)果是否一致什么時候必須用groupByKey我在實際項目中給出的結(jié)論是reduceByKey適合做聚合類計算比如求和、計數(shù)、求最大值因為它能在Map端先做局部聚合大幅減少Shuffle數(shù)據(jù)量。groupByKey適合需要拿到完整分組后進行自定義處理的場景比如一個key對應(yīng)一個List后續(xù)需要對這個List做復雜迭代計算而不是簡單聚合。如果兩種方式都能實現(xiàn)需求優(yōu)先用reduceByKey性能差距在數(shù)據(jù)量大時可以到數(shù)倍。我再多說一層groupByKey在Map端不聚合意味著相同key的數(shù)據(jù)會原樣寫出如果某個key的數(shù)據(jù)量很大會造成嚴重的數(shù)據(jù)傾斜。而reduceByKey在Map端已經(jīng)把同key數(shù)據(jù)合并了傾斜程度會小很多。所以“用groupByKey導致傾斜”在面試中也是一個很常見的連環(huán)問題。4. 持久化、血緣與Checkpoint容錯機制的三個層次4.1 cache、persist底層邏輯和StorageLevel怎么選RDD持久化是面試?？秃芏嗳酥纁ache和persist的語法差異但深入問StorageLevel的選擇就答不上來。在用詞方面兩者幾乎相同cache()默認使用MEMORY_ONLY級別persist()可以自定義StorageLevel。兩者在物理上并沒有本質(zhì)區(qū)別都是把計算結(jié)果緩存在Executor內(nèi)存或磁盤上用于后續(xù)復用。StorageLevel的各個級別實際由三個維度組合而來存儲介質(zhì)內(nèi)存還是磁盤。副本數(shù)是否保存多份以減少節(jié)點故障帶來的重算成本。是否序列化序列化省內(nèi)存但消耗CPU反序列化方便但占內(nèi)存。實際選型時我有幾條經(jīng)驗如果數(shù)據(jù)量不大且內(nèi)存足夠用MEMORY_ONLY不序列化訪問速度最快。如果內(nèi)存緊張用MEMORY_ONLY_SER序列化后省內(nèi)存但要留意序列化和反序列化的CPU開銷。如果有節(jié)點故障風險且重算代價高用帶副本的級別_2后綴比如MEMORY_AND_DISK_2。DISK_ONLY一般不推薦因為把RDD讀回內(nèi)存仍然要走磁盤IO除非數(shù)據(jù)大到完全無法放內(nèi)存且重復使用頻率極高。另一個高頻追問是cache的數(shù)據(jù)是存在哪里的很多人回答“Executors內(nèi)存”這個沒錯但更準確地說是存在Executor中的BlockManager里。BlockManager負責管理Block的存儲、讀寫和復制是Spark存儲體系的核心。如果能把BlockManager的作用說出來這場面試的檔次會明顯不一樣。此外只有遇到真的會被復用兩次以上的RDD才值得cache。如果只用一次就cache反而是純浪費這恰恰是實際工作中最常見的錯誤之一。4.2 血緣Lineage機制和Checkpoint的區(qū)別血緣機制是Spark容錯的根本保障。DAG記錄了每個RDD的父RDD以及生成它的算子當某個分區(qū)的數(shù)據(jù)丟失時Spark可以沿著血緣重新計算。這里有一個面試官愛問的細節(jié)重算只會發(fā)生在丟失的分區(qū)上還是整個RDD都要重算答案是只重算丟失的分區(qū)并且只執(zhí)行與該分區(qū)相關(guān)的血緣鏈條。這就是窄依賴的價值——某個分區(qū)的丟失不會波及其他分區(qū)但如果丟失的RDD依賴鏈條很長重算代價依然很高。Checkpoint是血緣機制的補充。它把RDD數(shù)據(jù)保存到可靠的存儲通常是HDFS上同時切斷血緣關(guān)系。Cache和Checkpoint的區(qū)別是面試中常見的對比題Cache保存數(shù)據(jù)但不切斷血緣節(jié)點故障導致緩存丟失時可以重算。Checkpoint保存數(shù)據(jù)并切斷血緣節(jié)點故障時直接從檢查點恢復不需要重算。Cache的存儲介質(zhì)是Executor內(nèi)存/磁盤速度快但不絕對可靠Checkpoint的存儲介質(zhì)是HDFS等分布式文件系統(tǒng)可靠性高但速度慢。我個人的實用建議是當某個RDD的血緣鏈特別長、重復計算代價極大、且后續(xù)會被多次使用時先cache再checkpoint。注意這里有個執(zhí)行的順序問題——只有先cachecheckpoint才能在內(nèi)存中直接快照數(shù)據(jù)否則checkpoint會重新計算整個RDD得不償失。4.3 閉包序列化為什么總是報Task not serializable這個報錯幾乎每個Spark開發(fā)都遇到過。很多初學者不知道Spark中定義在Driver端的變量和方法如果要在Executor端使用必須能被序列化并傳輸?shù)礁鱾€節(jié)點上。如果引用了一個不可序列化的對象就會拋出Task not serializable異常。面試中這個問題通常以報錯場景出現(xiàn)面試官會問你如何排查。我的排查鏈路是檢查是否在算子內(nèi)部引用了Driver端定義的大對象比如自定義類實例。檢查該類是否實現(xiàn)了Serializable接口。檢查該類內(nèi)部是否包含不可序列化的字段比如數(shù)據(jù)庫連接、某些第三方工具類實例。如果只是需要一個參數(shù)盡量改用基本類型或簡單類型傳遞不要傳整個對象。如果確實需要傳遞復雜對象使用廣播變量。補充一句經(jīng)驗之談我在踩過這個坑后養(yǎng)成了一個習慣——在定義被算子引用的輔助類時任何包含連接池、文件句柄的字段都用transient注解標記并在Executor端按需重新初始化。這比反復改Serializable要省事得多。5. 內(nèi)存管理、數(shù)據(jù)傾斜與Spark SQL高頻題5.1 Spark統(tǒng)一內(nèi)存管理模型Execution和Storage到底怎么劃分Spark 1.6之后引入了統(tǒng)一內(nèi)存管理Unified Memory這是面試中區(qū)分“會用Spark”和“理解Spark”的一個分水嶺。很多人背了spark.memory.fraction0.6、spark.memory.storageFraction0.5但不知道這兩個參數(shù)背后的分配邏輯。統(tǒng)一內(nèi)存把Executor堆內(nèi)存劃分為以下幾塊Execution內(nèi)存用于Shuffle、Join、Aggregation等計算過程中的臨時數(shù)據(jù)。Storage內(nèi)存用于緩存RDD、廣播變量等。保留內(nèi)存系統(tǒng)預留默認300M用于Spark內(nèi)部對象創(chuàng)建。用戶內(nèi)存用于用戶代碼中創(chuàng)建的對象通過spark.memory.fraction之外的0.4比例分配。統(tǒng)一內(nèi)存的關(guān)鍵在于Execution和Storage之間可以互相借用。當Storage有富余而Execution不足時Execution可以借用Storage的內(nèi)存借用的內(nèi)存可以在Storage需要時被強制回收。反過來也一樣。我實際調(diào)優(yōu)中遇到過很多OOM最后發(fā)現(xiàn)都和這個模型有關(guān)。比如某個任務(wù)Shuffle量巨大Execution內(nèi)存被占滿但同時又有一個很大的RDD被cache在Storage里導致互相爭搶。這時需要根據(jù)業(yè)務(wù)決定是減少并行度來控制Shuffle內(nèi)存還是減少cache數(shù)據(jù)量或者調(diào)整spark.memory.storageFraction讓Storage保留更多。要知道OOM不一定是內(nèi)存總量不夠更常見的是內(nèi)存劃分不合理。5.2 數(shù)據(jù)傾斜的定位方法與四類解決方案數(shù)據(jù)傾斜是Spark面試的“壓軸題”每個面試官都會問每個實際項目也大概率會遇到。先把現(xiàn)象說清楚某個Stage的Task執(zhí)行時間明顯高于其他Task甚至有個別Task一直跑不完而Spark UI的Stage頁面上能看到極不均勻的Task耗時柱狀圖。定位傾斜的思路是在Spark UI的Stage頁面找到耗時最大的Task。查看該Task的Shuffle Read大小和記錄數(shù)如果某幾個Task的數(shù)據(jù)量明顯高于平均值基本可以判定傾斜。結(jié)合業(yè)務(wù)代碼推斷是哪個key導致的數(shù)據(jù)分布不均。解決方案按由簡到繁排序如下過濾異常key如果傾斜的key本身是臟數(shù)據(jù)或業(yè)務(wù)上可丟棄的數(shù)據(jù)直接過濾掉。提高Shuffle并行度增大spark.sql.shuffle.partitions或spark.default.parallelism讓每個key分發(fā)到更多分區(qū)緩解單個分區(qū)壓力。這只能緩解不能根治。兩階段聚合加隨機前綴做局部聚合再去掉前綴做全局聚合適用于Key本身需要保留的情況。map端join代替reduce端join如果傾斜的是一張大表和一張小表的join用Broadcast把小表廣播到每個Executor避免Shuffle。自定義分區(qū)器針對業(yè)務(wù)key做更均勻的分區(qū)。拆分key再join將傾斜key拆成多份分別和不同子集join后再union是徹底解決的辦法但實現(xiàn)復雜。我自己的經(jīng)驗是實際項目里70%的傾斜都能通過“過濾異常key提高并行度”解決只有少數(shù)核心場景需要兩階段聚合或拆分join。先用最簡單的手段一上來就寫復雜方案反而容易引入新問題。5.3 Spark SQL的執(zhí)行流程從SQL到RDD的完整轉(zhuǎn)化Spark SQL也是必考方向面試官喜歡把Spark SQL當作考察對Spark整體理解的一個窗口。實際上Spark SQL的執(zhí)行流程是Catalyst優(yōu)化器和Tungsten執(zhí)行引擎的組合。流程如下SQL語句經(jīng)過SqlParser解析成邏輯計劃Unresolved LogicalPlan。Analyzer結(jié)合Catalog信息將邏輯計劃綁定為Resolved LogicalPlan。Catalyst優(yōu)化器進行規(guī)則優(yōu)化包括謂詞下推、列裁剪、常量折疊等生成Optimized LogicalPlan。優(yōu)化后的邏輯計劃被轉(zhuǎn)換成物理計劃經(jīng)過成本模型選出最優(yōu)執(zhí)行方案。最終生成RDD DAG并交給Spark執(zhí)行引擎運行。高頻考點是至少能說清楚“謂詞下推”和“列裁剪”。謂詞下推是把過濾條件下推到數(shù)據(jù)源端減少讀取的數(shù)據(jù)量列裁剪是只讀取需要的列減少IO。這兩者實際等同于讓Spark SQL少干活幾乎所有的SQL性能調(diào)優(yōu)都離不開它們。這里還有一個常見的考試話題DataFrame和RDD的區(qū)別。DataFrame有Schema信息Catalyst能對它進行優(yōu)化而RDD沒有Schema無法做同樣的優(yōu)化。所以能用DataFrame API就別用RDD API這也是團隊代碼規(guī)范里比較常見的一條約定。5.4 三大Join類型在Spark中的實現(xiàn)機制Spark SQL中的Join類型和實現(xiàn)機制是面試中很具體的考核點需要理解得不只是語法。Shuffle Hash Join適用于一張表很小、能被哈希表容納的場景。它會把大表和小表都按照Join key分區(qū)然后每個分區(qū)內(nèi)用哈希表匹配。實現(xiàn)上和普通Hash Join一致只是多了Shuffle。Broadcast Hash Join當小表尺寸低于spark.sql.autoBroadcastJoinThreshold默認10M時Spark自動采用廣播方式把小表廣播到所有Executor大表無需Shuffle。這是最快的Join方式。Sort Merge Join適用于大表join大表。兩邊數(shù)據(jù)都按Join key排序然后歸并匹配。這也是Spark 2.x之后默認的大表Join實現(xiàn)。面試中常問的優(yōu)化方向如何把大表join變成Broadcast Hash Join一是調(diào)整spark.sql.autoBroadcastJoinThreshold閾值但這有風險廣播過大的表會導致Driver和Executor內(nèi)存爆炸二是預先對小表做過濾和聚合讓它小于閾值。實踐上我傾向于先做數(shù)據(jù)裁剪而不是盲目調(diào)大閾值。是非題也常常出現(xiàn)Broadcast Join一定比Shuffle Join快嗎不一定。如果廣播的表太大傳輸和存儲開銷會超過Shuffle的開銷。在小表確實很小的前提下它才是更優(yōu)解。6. Structured Streaming、性能調(diào)優(yōu)與故障排查6.1 Structured Streaming和Spark Streaming的本質(zhì)差別流處理方向的問題近幾年考得越來越多。面試官一般會先問Spark Streaming再問Structured Streaming考察你是否跟上了Spark演進的方向。Spark Streaming是基于微批Micro-batch的流處理框架將實時數(shù)據(jù)流切成一個個小批次每個批次當作RDD來處理。它能復用Spark批處理的能力但延遲一般在秒級做不到毫秒級響應(yīng)。Structured Streaming在Spark 2.0之后引入提供了基于DataFrame/DataSet API的流處理核心思想是把實時流看作“不斷追加的一張無限表”。用戶可以用SQL來寫流處理邏輯支持事件時間處理、水位線、窗口聚合等高級特性。它還引入了Continuous Processing模式理論上可以做到毫秒級延遲但實際生產(chǎn)中使用不多。面試題“兩者的關(guān)鍵區(qū)別”可以參考這幾個維度API層面一個是RDD DStream一個是DataFrame/DataSet。時間語義Structured Streaming支持事件時間和水印Spark Streaming主要依賴處理時間。容錯與一致性兩者都支持exactly-once配合WAL和冪等輸出但實現(xiàn)機制不同。延遲與吞吐Structured Streaming的吞吐通常更高代碼表達也更簡潔。實際工作中我的建議很直白新項目直接用Structured Streaming不要再用老一套的DStream API了。至于能不能用continuous模式要謹慎目前生產(chǎn)環(huán)境里它以實驗性質(zhì)為主穩(wěn)定性不如微批。6.2 寫出高效Spark任務(wù)的七條實戰(zhàn)紀律性能調(diào)優(yōu)題往往是面試的收尾大菜考察綜合能力。面試官不會指望你背出幾十個參數(shù)而是希望聽到你有一套完整的調(diào)優(yōu)思路。我這里總結(jié)實際項目中沉淀下來的七條紀律基本可以作為面試作答框架提前過濾數(shù)據(jù)。在源頭把不需要的數(shù)據(jù)過濾掉減少全鏈路的數(shù)據(jù)量。謂詞下推加上手動過濾雙保險。避免不必要的Shuffle。能在一個Stage里完成的就不要拆成兩個能用map join就盡量不要reduce join。優(yōu)先用DataFrame/DataSet API。讓Catalyst優(yōu)化比手寫RDD算子更快且更穩(wěn)。合理設(shè)置并行度。spark.sql.shuffle.partitions要結(jié)合數(shù)據(jù)量和集群核數(shù)設(shè)置而不是永遠默認200。減少Driver端和Executor端之間的大對象傳輸。能用廣播變量傳遞的數(shù)據(jù)就讀廣播不要反復序列化傳遞大對象。監(jiān)控和度量。Spark UI一定要用起來Stage耗時、Shuffle量、GC時間、Executor內(nèi)存使用都要有數(shù)。控制數(shù)據(jù)本地性。本地性不好任務(wù)會把大量時間耗在網(wǎng)絡(luò)傳輸上必要時調(diào)整spark.locality.wait。完成這些整理后我還要強調(diào)一個細節(jié)調(diào)優(yōu)從不是改變一個參數(shù)就結(jié)束而是在調(diào)整之后做一輪完整回歸觀察指標是否真的改善同時判斷是否引入了新的問題。所有盲目改參數(shù)的調(diào)優(yōu)都是耍流氓。6.3 Executor OOM的排查鏈路與防護套路Executor OOM是生產(chǎn)環(huán)境里最常見的報錯之一但它的根因可能完全不同。面試官特別喜歡用這個題來考察你是否有真正的故障處理經(jīng)驗。我總結(jié)的排查鏈路是這樣的先看OOM發(fā)生在哪個階段。如果是Shuffle Read階段多半是拉取的數(shù)據(jù)量超過內(nèi)存限制優(yōu)先檢查是否存在數(shù)據(jù)傾斜或者spark.reducer.maxSizeInFlight、spark.shuffle.spill.compress相關(guān)配置。如果是執(zhí)行聚合操作時OOM優(yōu)先檢查并行度和數(shù)據(jù)分布。某些key的數(shù)據(jù)量過大會導致單個Executor內(nèi)存壓力爆炸。如果是緩存RDD后出現(xiàn)OOM檢查StorageLevel是否合理或者是否緩存了本不需要緩存的大數(shù)據(jù)集。如果是Driver OOM再檢查Driver端是否收集了過多結(jié)果數(shù)據(jù)或者廣播變量是不是太大了。防護措施我認為排第一位的是“預分區(qū)設(shè)計”從數(shù)據(jù)源寫入時就設(shè)計好合理的分區(qū)策略讓數(shù)據(jù)分布均勻。在此基礎(chǔ)上再做執(zhí)行計劃優(yōu)化、并行度調(diào)整、監(jiān)控告警。OLTP和OLAP場景不一樣不能一套參數(shù)打天下。6.4 從實際故障中總結(jié)的Spark UI排查技巧最后分享一個面試high-level的問題如何定位一個Spark作業(yè)的運行瓶頸這個問題的標準答法就是“用Spark UI”。但如果你能說得比“看Stage耗時”更細會在面試中留下很不一樣的印象。我實際看UI的順序是Jobs頁面確認總共幾個Job、哪些Job成功哪些失敗、每個Job的耗時。Stage頁面看每個Stage的Duration分布。如果某個Stage里的Task時間線極不均勻優(yōu)先懷疑數(shù)據(jù)傾斜如果所有Task時間都長考慮是不是資源不足或數(shù)據(jù)量大。Executors頁面看每個Executor的Storage Memory、Shuffle Write、GC時間。某個Executor的GC時間異常說明內(nèi)存壓力大。SQL頁面看物理計劃里每個算子的實際過濾行數(shù)、輸出行數(shù)。如果某個Filter之后的行數(shù)變化異常及時發(fā)現(xiàn)問題。Event Timeline看Task的調(diào)度延遲和計算時間。調(diào)度延遲高說明資源不夠計算時間高說明任務(wù)本身重。在一次真實故障排查里我的整個分析就靠這套順序定位到了問題源頭某個運行15分鐘的Job耗時集中在第4個Stage且只有極少數(shù)Task的數(shù)據(jù)量遠遠大于眾數(shù)。后續(xù)再對比業(yè)務(wù)日志確認是特定用戶ID的數(shù)據(jù)量暴漲導致的傾斜。整個過程代碼一行未改只是加了一個過濾條件配合重新分區(qū)Job耗時從15分鐘降到了4分鐘。如果你在面試時能把這個排查鏈路完整講出來這不止是展示能力更是告訴面試官你是個真正會解決實際問題的人而不是只會在網(wǎng)上看面經(jīng)背答案的候選人。 Spark面試26個高頻考點：從RDD原理到調(diào)優(yōu)實戰(zhàn)全解析
1. 為什么Spark面試題翻來覆去就這26個點做大數(shù)據(jù)開發(fā)這幾年我前后參與過不少團隊的技術(shù)面試也幫朋友做過模擬面試。一個很直觀的感受是Spark相關(guān)的問題看似千變?nèi)f化但真正高頻的核心考點其實非常集中。網(wǎng)上流傳的各種面經(jīng)匯總動輒上百題但大部分題目背后的考察點都是重復的本質(zhì)就是那么二三十個。這篇文章把我在面試中被問到過、也實際問過別人的26個Spark高頻考點整理了出來。它們不按難度機械排序而是按“從基礎(chǔ)原理到實踐調(diào)優(yōu)再到源碼級理解”的邏輯展開涵蓋了RDD、Shuffle、Spark SQL、流處理、內(nèi)存管理、故障恢復、調(diào)優(yōu)工具這幾個核心模塊。如果你正在準備大數(shù)據(jù)開發(fā)崗位的面試這篇文章可以直接當作復習提綱。每一個考點我都會先說明面試官問它的動機再拆解底層原理最后補充實際工作中容易踩坑的地方。文章里的很多結(jié)論不是單純從文檔里抄來的而是我在真實任務(wù)中驗證過的——比如某些配置參數(shù)改了之后的效果和官方文檔描述存在明顯差異。先說一個重要建議不要背題。Spark的面試題幾乎沒有標準答案面試官更看重你推導結(jié)論的過程。比如問到“為什么Spark比MapReduce快”如果你能順著“DAG計算引擎、內(nèi)存計算、Task調(diào)度粒度、Shuffle機制”這幾個層次逐步展開效果遠比背一段結(jié)論好得多。2. 從RDD到DAG先搞清楚Spark的骨架2.1 RDD的五大屬性為什么是面試第一問幾乎所有Spark面試的第一題都會落在RDD上。面試官想通過這個問題確認你到底是背過概念還是真的理解Spark的底層設(shè)計邏輯。RDD彈性分布式數(shù)據(jù)集有五個核心屬性這五個屬性不是隨便定的它們分別回答了RDD的五個關(guān)鍵問題分區(qū)列表數(shù)據(jù)被切分成了多少片這是并行計算的基礎(chǔ)。分區(qū)數(shù)決定了Task數(shù)量也就決定了并行度。分區(qū)計算函數(shù)每個分區(qū)如何被計算出來對應(yīng)RDD的compute方法。依賴關(guān)系RDD之間的血緣關(guān)系分為窄依賴和寬依賴這是容錯和調(diào)度的基礎(chǔ)。分區(qū)器數(shù)據(jù)如何被劃分到不同分區(qū)常見的有HashPartitioner和RangePartitioner。首選位置計算某個分區(qū)時優(yōu)先調(diào)度到哪個節(jié)點這是數(shù)據(jù)本地性的基礎(chǔ)。我在面試中經(jīng)常追問RDD的五個屬性里哪個對容錯最重要答案其實是依賴關(guān)系。因為血緣關(guān)系讓RDD可以在部分分區(qū)丟失時只重新計算丟失的分區(qū)而不是整個數(shù)據(jù)集。這也是Spark相比Hadoop的一個核心優(yōu)勢。實際工作中有一個容易忽略的點RDD的五個屬性對普通開發(fā)者來說是透明的你在寫業(yè)務(wù)代碼時基本感知不到它們。但一旦遇到性能問題比如數(shù)據(jù)傾斜、Task執(zhí)行不均勻回到分區(qū)和依賴關(guān)系去分析往往能直接定位根因。2.2 DAG調(diào)度流程從代碼提交到Task執(zhí)行要經(jīng)過幾道工序理解了RDD下一步一定是DAG。DAG是Spark對計算邏輯的抽象表達但面試官真正想聽的通常是一段Spark代碼從提交到執(zhí)行到底經(jīng)歷了什么。完整流程如下用戶代碼創(chuàng)建RDD通過Transformation操作構(gòu)建DAG圖。Action操作觸發(fā)Job提交交給DAGScheduler。DAGScheduler將DAG按照寬依賴切分成多個Stage。Stage內(nèi)部生成一組Task提交給TaskScheduler。TaskScheduler將Task分配到Executor上執(zhí)行。這里有個面試高頻追問點Stage的劃分依據(jù)是什么答案是寬依賴。因為寬依賴意味著需要Shuffle數(shù)據(jù)要從一個Stage的所有分區(qū)流向另一個Stage的所有分區(qū)必須在邊界處等待所有上游任務(wù)完成所以天然是Stage的分界線。而窄依賴不需要Shuffle可以放在同一個Stage里做流水線式執(zhí)行。關(guān)于Stage我還有一條實際經(jīng)驗很多人以為Stage數(shù)量等于Shuffle次數(shù)加一這個說法基本正確但不完全準確。因為某些窄依賴算子組合比如map后跟filter會被合并到同一個Stage而某些特殊情況比如repartition雖然不是Shuffle算子但也會觸發(fā)新的Stage。歸根結(jié)底判斷標準只有一個——是否產(chǎn)生了寬依賴。2.3 Transformation和Action的本質(zhì)區(qū)別RDD算子分為Transformation和Action兩大類。Transformation是懶執(zhí)行的只記錄計算邏輯不真正觸發(fā)計算Action才是真正觸發(fā)作業(yè)執(zhí)行的入口。這個區(qū)別很大所以我在面試中一般會安排一個簡短追問Spark為什么不在一開始就把所有計算執(zhí)行完讓我給出更好的答案。這里的關(guān)鍵是惰性計算。如果每次Transformation都立即執(zhí)行Spark就失去了對整個DAG做全局優(yōu)化的機會——它可以把多個算子合并、調(diào)整執(zhí)行順序、減少Shuffle這些優(yōu)化只有在完整了解計算邏輯后才能做到。另一個高頻追問是Spark為什么不是所有Transformation都返回RDD其實所有Transformation確實都返回RDD但某些Transformation改變了RDD的分區(qū)數(shù)、依賴類型甚至數(shù)據(jù)類型比如map返回MappedRDDreduceByKey返回ShuffledRDD。能說出算子返回的具體RDD類型在面試中會顯得你對源碼有了解。實際開發(fā)中我見過不少人犯一個低級錯誤在循環(huán)里多次調(diào)用Action操作導致Driver和Executor之間反復同步結(jié)果性能急劇下降。正確做法是盡量在一次Action中完成計算或者使用累加器來聚合結(jié)果。3. 面試必考的寬窄依賴與Shuffle真相3.1 窄依賴和寬依賴的判定標準及面試答法窄依賴和寬依賴的判定表面上是看父RDD的每個分區(qū)被子RDD的多少個分區(qū)使用實際上要回到依賴的抽象實現(xiàn)上。窄依賴NarrowDependency包括OneToOneDependency和RangeDependency父RDD每個分區(qū)最多被一個子分區(qū)使用典型算子有map、flatMap、filter、union、coalesce不涉及Shuffle時。寬依賴ShuffleDependency父RDD每一個分區(qū)可能被多個子分區(qū)使用典型算子有g(shù)roupByKey、reduceByKey、join、distinct、repartition。寬依賴一定伴隨Shuffle過程。面試時我的建議是不要停留在定義上立刻補充一句“窄依賴可以進行Pipeline計算因為父RDD的分區(qū)數(shù)據(jù)可以直接傳給子RDD無需等待寬依賴需要Shuffle數(shù)據(jù)要經(jīng)過網(wǎng)絡(luò)傳輸這是Spark性能瓶頸的最大來源之一。”還有一個考點容易被忽視join操作一定是寬依賴嗎答案是未必。如果兩個RDD分區(qū)器相同且分區(qū)數(shù)相同join可以在分區(qū)內(nèi)完成不需要Shuffle。這在面試里是一道很好的加分題說明你對分區(qū)器的理解不只是停留在表面。3.2 Shuffle的整個生命周期寫盤、拉取、聚合Shuffle是Spark面試的核心考點也是實際調(diào)優(yōu)的主戰(zhàn)場。面試官在Shuffle這里通常想聽三個階段的完整鏈路Shuffle Write、Shuffle Read和中間的聚合。Shuffle Write發(fā)生在Map端。在舊版本Hash Shuffle中每個Map任務(wù)會為每個Reduce分區(qū)生成一個文件文件數(shù)爆炸性問題嚴重。Sort Shuffle引入了合并機制每個Map任務(wù)只生成一個文件并在寫盤前按分區(qū)排序這就是為什么Sort Shuffle在默認配置下是首選。Shuffle Read發(fā)生在Reduce端。Reduce任務(wù)從各個Map任務(wù)的文件中拉取屬于自己的數(shù)據(jù)塊拉取方式從早期的BlockStore拉取演變?yōu)镹etty傳輸。這里面試官常問一個問題Shuffle Read階段數(shù)據(jù)是邊拉邊聚合還是全部拉完再聚合實際上reduceByKey在讀取每個分區(qū)的數(shù)據(jù)時會先在Map端做一次combine局部聚合減少網(wǎng)絡(luò)傳輸量Reduce端再做最終聚合。這就是combine操作的價值。關(guān)于Shuffle還要知道一個調(diào)優(yōu)參數(shù)spark.shuffle.file.buffer默認32K它控制Shuffle Write時輸出文件的緩沖大小spark.reducer.maxSizeInFlight默認48M用于控制Reduce端拉取數(shù)據(jù)的內(nèi)存上限。實際工作中我遇到過不少因為這兩個參數(shù)設(shè)置不當導致的OOM或網(wǎng)絡(luò)擁塞問題。必須提一個容易踩的坑Shuffle不只在顯式的groupByKey、join時發(fā)生。很多看似不起眼的操作比如distinct、sortByKey、repartitionAndSortWithinPartitions內(nèi)部都會觸發(fā)Shuffle。單獨看沒問題一旦在循環(huán)里使用Shuffle次數(shù)會成倍增長性能災難就是這么來的。3.3 groupByKey vs reduceByKey經(jīng)典送命題的全面拆解這大概是Spark面經(jīng)里出現(xiàn)頻率最高的一題但大部分人的回答只停留在“reduceByKey有combinegroupByKey沒有”。面試官愿意深挖的話會繼續(xù)問兩者最終結(jié)果是否一致什么時候必須用groupByKey我在實際項目中給出的結(jié)論是reduceByKey適合做聚合類計算比如求和、計數(shù)、求最大值因為它能在Map端先做局部聚合大幅減少Shuffle數(shù)據(jù)量。groupByKey適合需要拿到完整分組后進行自定義處理的場景比如一個key對應(yīng)一個List后續(xù)需要對這個List做復雜迭代計算而不是簡單聚合。如果兩種方式都能實現(xiàn)需求優(yōu)先用reduceByKey性能差距在數(shù)據(jù)量大時可以到數(shù)倍。我再多說一層groupByKey在Map端不聚合意味著相同key的數(shù)據(jù)會原樣寫出如果某個key的數(shù)據(jù)量很大會造成嚴重的數(shù)據(jù)傾斜。而reduceByKey在Map端已經(jīng)把同key數(shù)據(jù)合并了傾斜程度會小很多。所以“用groupByKey導致傾斜”在面試中也是一個很常見的連環(huán)問題。4. 持久化、血緣與Checkpoint容錯機制的三個層次4.1 cache、persist底層邏輯和StorageLevel怎么選RDD持久化是面試?？秃芏嗳酥纁ache和persist的語法差異但深入問StorageLevel的選擇就答不上來。在用詞方面兩者幾乎相同cache()默認使用MEMORY_ONLY級別persist()可以自定義StorageLevel。兩者在物理上并沒有本質(zhì)區(qū)別都是把計算結(jié)果緩存在Executor內(nèi)存或磁盤上用于后續(xù)復用。StorageLevel的各個級別實際由三個維度組合而來存儲介質(zhì)內(nèi)存還是磁盤。副本數(shù)是否保存多份以減少節(jié)點故障帶來的重算成本。是否序列化序列化省內(nèi)存但消耗CPU反序列化方便但占內(nèi)存。實際選型時我有幾條經(jīng)驗如果數(shù)據(jù)量不大且內(nèi)存足夠用MEMORY_ONLY不序列化訪問速度最快。如果內(nèi)存緊張用MEMORY_ONLY_SER序列化后省內(nèi)存但要留意序列化和反序列化的CPU開銷。如果有節(jié)點故障風險且重算代價高用帶副本的級別_2后綴比如MEMORY_AND_DISK_2。DISK_ONLY一般不推薦因為把RDD讀回內(nèi)存仍然要走磁盤IO除非數(shù)據(jù)大到完全無法放內(nèi)存且重復使用頻率極高。另一個高頻追問是cache的數(shù)據(jù)是存在哪里的很多人回答“Executors內(nèi)存”這個沒錯但更準確地說是存在Executor中的BlockManager里。BlockManager負責管理Block的存儲、讀寫和復制是Spark存儲體系的核心。如果能把BlockManager的作用說出來這場面試的檔次會明顯不一樣。此外只有遇到真的會被復用兩次以上的RDD才值得cache。如果只用一次就cache反而是純浪費這恰恰是實際工作中最常見的錯誤之一。4.2 血緣Lineage機制和Checkpoint的區(qū)別血緣機制是Spark容錯的根本保障。DAG記錄了每個RDD的父RDD以及生成它的算子當某個分區(qū)的數(shù)據(jù)丟失時Spark可以沿著血緣重新計算。這里有一個面試官愛問的細節(jié)重算只會發(fā)生在丟失的分區(qū)上還是整個RDD都要重算答案是只重算丟失的分區(qū)并且只執(zhí)行與該分區(qū)相關(guān)的血緣鏈條。這就是窄依賴的價值——某個分區(qū)的丟失不會波及其他分區(qū)但如果丟失的RDD依賴鏈條很長重算代價依然很高。Checkpoint是血緣機制的補充。它把RDD數(shù)據(jù)保存到可靠的存儲通常是HDFS上同時切斷血緣關(guān)系。Cache和Checkpoint的區(qū)別是面試中常見的對比題Cache保存數(shù)據(jù)但不切斷血緣節(jié)點故障導致緩存丟失時可以重算。Checkpoint保存數(shù)據(jù)并切斷血緣節(jié)點故障時直接從檢查點恢復不需要重算。Cache的存儲介質(zhì)是Executor內(nèi)存/磁盤速度快但不絕對可靠Checkpoint的存儲介質(zhì)是HDFS等分布式文件系統(tǒng)可靠性高但速度慢。我個人的實用建議是當某個RDD的血緣鏈特別長、重復計算代價極大、且后續(xù)會被多次使用時先cache再checkpoint。注意這里有個執(zhí)行的順序問題——只有先cachecheckpoint才能在內(nèi)存中直接快照數(shù)據(jù)否則checkpoint會重新計算整個RDD得不償失。4.3 閉包序列化為什么總是報Task not serializable這個報錯幾乎每個Spark開發(fā)都遇到過。很多初學者不知道Spark中定義在Driver端的變量和方法如果要在Executor端使用必須能被序列化并傳輸?shù)礁鱾€節(jié)點上。如果引用了一個不可序列化的對象就會拋出Task not serializable異常。面試中這個問題通常以報錯場景出現(xiàn)面試官會問你如何排查。我的排查鏈路是檢查是否在算子內(nèi)部引用了Driver端定義的大對象比如自定義類實例。檢查該類是否實現(xiàn)了Serializable接口。檢查該類內(nèi)部是否包含不可序列化的字段比如數(shù)據(jù)庫連接、某些第三方工具類實例。如果只是需要一個參數(shù)盡量改用基本類型或簡單類型傳遞不要傳整個對象。如果確實需要傳遞復雜對象使用廣播變量。補充一句經(jīng)驗之談我在踩過這個坑后養(yǎng)成了一個習慣——在定義被算子引用的輔助類時任何包含連接池、文件句柄的字段都用transient注解標記并在Executor端按需重新初始化。這比反復改Serializable要省事得多。5. 內(nèi)存管理、數(shù)據(jù)傾斜與Spark SQL高頻題5.1 Spark統(tǒng)一內(nèi)存管理模型Execution和Storage到底怎么劃分Spark 1.6之后引入了統(tǒng)一內(nèi)存管理Unified Memory這是面試中區(qū)分“會用Spark”和“理解Spark”的一個分水嶺。很多人背了spark.memory.fraction0.6、spark.memory.storageFraction0.5但不知道這兩個參數(shù)背后的分配邏輯。統(tǒng)一內(nèi)存把Executor堆內(nèi)存劃分為以下幾塊Execution內(nèi)存用于Shuffle、Join、Aggregation等計算過程中的臨時數(shù)據(jù)。Storage內(nèi)存用于緩存RDD、廣播變量等。保留內(nèi)存系統(tǒng)預留默認300M用于Spark內(nèi)部對象創(chuàng)建。用戶內(nèi)存用于用戶代碼中創(chuàng)建的對象通過spark.memory.fraction之外的0.4比例分配。統(tǒng)一內(nèi)存的關(guān)鍵在于Execution和Storage之間可以互相借用。當Storage有富余而Execution不足時Execution可以借用Storage的內(nèi)存借用的內(nèi)存可以在Storage需要時被強制回收。反過來也一樣。我實際調(diào)優(yōu)中遇到過很多OOM最后發(fā)現(xiàn)都和這個模型有關(guān)。比如某個任務(wù)Shuffle量巨大Execution內(nèi)存被占滿但同時又有一個很大的RDD被cache在Storage里導致互相爭搶。這時需要根據(jù)業(yè)務(wù)決定是減少并行度來控制Shuffle內(nèi)存還是減少cache數(shù)據(jù)量或者調(diào)整spark.memory.storageFraction讓Storage保留更多。要知道OOM不一定是內(nèi)存總量不夠更常見的是內(nèi)存劃分不合理。5.2 數(shù)據(jù)傾斜的定位方法與四類解決方案數(shù)據(jù)傾斜是Spark面試的“壓軸題”每個面試官都會問每個實際項目也大概率會遇到。先把現(xiàn)象說清楚某個Stage的Task執(zhí)行時間明顯高于其他Task甚至有個別Task一直跑不完而Spark UI的Stage頁面上能看到極不均勻的Task耗時柱狀圖。定位傾斜的思路是在Spark UI的Stage頁面找到耗時最大的Task。查看該Task的Shuffle Read大小和記錄數(shù)如果某幾個Task的數(shù)據(jù)量明顯高于平均值基本可以判定傾斜。結(jié)合業(yè)務(wù)代碼推斷是哪個key導致的數(shù)據(jù)分布不均。解決方案按由簡到繁排序如下過濾異常key如果傾斜的key本身是臟數(shù)據(jù)或業(yè)務(wù)上可丟棄的數(shù)據(jù)直接過濾掉。提高Shuffle并行度增大spark.sql.shuffle.partitions或spark.default.parallelism讓每個key分發(fā)到更多分區(qū)緩解單個分區(qū)壓力。這只能緩解不能根治。兩階段聚合加隨機前綴做局部聚合再去掉前綴做全局聚合適用于Key本身需要保留的情況。map端join代替reduce端join如果傾斜的是一張大表和一張小表的join用Broadcast把小表廣播到每個Executor避免Shuffle。自定義分區(qū)器針對業(yè)務(wù)key做更均勻的分區(qū)。拆分key再join將傾斜key拆成多份分別和不同子集join后再union是徹底解決的辦法但實現(xiàn)復雜。我自己的經(jīng)驗是實際項目里70%的傾斜都能通過“過濾異常key提高并行度”解決只有少數(shù)核心場景需要兩階段聚合或拆分join。先用最簡單的手段一上來就寫復雜方案反而容易引入新問題。5.3 Spark SQL的執(zhí)行流程從SQL到RDD的完整轉(zhuǎn)化Spark SQL也是必考方向面試官喜歡把Spark SQL當作考察對Spark整體理解的一個窗口。實際上Spark SQL的執(zhí)行流程是Catalyst優(yōu)化器和Tungsten執(zhí)行引擎的組合。流程如下SQL語句經(jīng)過SqlParser解析成邏輯計劃Unresolved LogicalPlan。Analyzer結(jié)合Catalog信息將邏輯計劃綁定為Resolved LogicalPlan。Catalyst優(yōu)化器進行規(guī)則優(yōu)化包括謂詞下推、列裁剪、常量折疊等生成Optimized LogicalPlan。優(yōu)化后的邏輯計劃被轉(zhuǎn)換成物理計劃經(jīng)過成本模型選出最優(yōu)執(zhí)行方案。最終生成RDD DAG并交給Spark執(zhí)行引擎運行。高頻考點是至少能說清楚“謂詞下推”和“列裁剪”。謂詞下推是把過濾條件下推到數(shù)據(jù)源端減少讀取的數(shù)據(jù)量列裁剪是只讀取需要的列減少IO。這兩者實際等同于讓Spark SQL少干活幾乎所有的SQL性能調(diào)優(yōu)都離不開它們。這里還有一個常見的考試話題DataFrame和RDD的區(qū)別。DataFrame有Schema信息Catalyst能對它進行優(yōu)化而RDD沒有Schema無法做同樣的優(yōu)化。所以能用DataFrame API就別用RDD API這也是團隊代碼規(guī)范里比較常見的一條約定。5.4 三大Join類型在Spark中的實現(xiàn)機制Spark SQL中的Join類型和實現(xiàn)機制是面試中很具體的考核點需要理解得不只是語法。Shuffle Hash Join適用于一張表很小、能被哈希表容納的場景。它會把大表和小表都按照Join key分區(qū)然后每個分區(qū)內(nèi)用哈希表匹配。實現(xiàn)上和普通Hash Join一致只是多了Shuffle。Broadcast Hash Join當小表尺寸低于spark.sql.autoBroadcastJoinThreshold默認10M時Spark自動采用廣播方式把小表廣播到所有Executor大表無需Shuffle。這是最快的Join方式。Sort Merge Join適用于大表join大表。兩邊數(shù)據(jù)都按Join key排序然后歸并匹配。這也是Spark 2.x之后默認的大表Join實現(xiàn)。面試中常問的優(yōu)化方向如何把大表join變成Broadcast Hash Join一是調(diào)整spark.sql.autoBroadcastJoinThreshold閾值但這有風險廣播過大的表會導致Driver和Executor內(nèi)存爆炸二是預先對小表做過濾和聚合讓它小于閾值。實踐上我傾向于先做數(shù)據(jù)裁剪而不是盲目調(diào)大閾值。是非題也常常出現(xiàn)Broadcast Join一定比Shuffle Join快嗎不一定。如果廣播的表太大傳輸和存儲開銷會超過Shuffle的開銷。在小表確實很小的前提下它才是更優(yōu)解。6. Structured Streaming、性能調(diào)優(yōu)與故障排查6.1 Structured Streaming和Spark Streaming的本質(zhì)差別流處理方向的問題近幾年考得越來越多。面試官一般會先問Spark Streaming再問Structured Streaming考察你是否跟上了Spark演進的方向。Spark Streaming是基于微批Micro-batch的流處理框架將實時數(shù)據(jù)流切成一個個小批次每個批次當作RDD來處理。它能復用Spark批處理的能力但延遲一般在秒級做不到毫秒級響應(yīng)。Structured Streaming在Spark 2.0之后引入提供了基于DataFrame/DataSet API的流處理核心思想是把實時流看作“不斷追加的一張無限表”。用戶可以用SQL來寫流處理邏輯支持事件時間處理、水位線、窗口聚合等高級特性。它還引入了Continuous Processing模式理論上可以做到毫秒級延遲但實際生產(chǎn)中使用不多。面試題“兩者的關(guān)鍵區(qū)別”可以參考這幾個維度API層面一個是RDD DStream一個是DataFrame/DataSet。時間語義Structured Streaming支持事件時間和水印Spark Streaming主要依賴處理時間。容錯與一致性兩者都支持exactly-once配合WAL和冪等輸出但實現(xiàn)機制不同。延遲與吞吐Structured Streaming的吞吐通常更高代碼表達也更簡潔。實際工作中我的建議很直白新項目直接用Structured Streaming不要再用老一套的DStream API了。至于能不能用continuous模式要謹慎目前生產(chǎn)環(huán)境里它以實驗性質(zhì)為主穩(wěn)定性不如微批。6.2 寫出高效Spark任務(wù)的七條實戰(zhàn)紀律性能調(diào)優(yōu)題往往是面試的收尾大菜考察綜合能力。面試官不會指望你背出幾十個參數(shù)而是希望聽到你有一套完整的調(diào)優(yōu)思路。我這里總結(jié)實際項目中沉淀下來的七條紀律基本可以作為面試作答框架提前過濾數(shù)據(jù)。在源頭把不需要的數(shù)據(jù)過濾掉減少全鏈路的數(shù)據(jù)量。謂詞下推加上手動過濾雙保險。避免不必要的Shuffle。能在一個Stage里完成的就不要拆成兩個能用map join就盡量不要reduce join。優(yōu)先用DataFrame/DataSet API。讓Catalyst優(yōu)化比手寫RDD算子更快且更穩(wěn)。合理設(shè)置并行度。spark.sql.shuffle.partitions要結(jié)合數(shù)據(jù)量和集群核數(shù)設(shè)置而不是永遠默認200。減少Driver端和Executor端之間的大對象傳輸。能用廣播變量傳遞的數(shù)據(jù)就讀廣播不要反復序列化傳遞大對象。監(jiān)控和度量。Spark UI一定要用起來Stage耗時、Shuffle量、GC時間、Executor內(nèi)存使用都要有數(shù)。控制數(shù)據(jù)本地性。本地性不好任務(wù)會把大量時間耗在網(wǎng)絡(luò)傳輸上必要時調(diào)整spark.locality.wait。完成這些整理后我還要強調(diào)一個細節(jié)調(diào)優(yōu)從不是改變一個參數(shù)就結(jié)束而是在調(diào)整之后做一輪完整回歸觀察指標是否真的改善同時判斷是否引入了新的問題。所有盲目改參數(shù)的調(diào)優(yōu)都是耍流氓。6.3 Executor OOM的排查鏈路與防護套路Executor OOM是生產(chǎn)環(huán)境里最常見的報錯之一但它的根因可能完全不同。面試官特別喜歡用這個題來考察你是否有真正的故障處理經(jīng)驗。我總結(jié)的排查鏈路是這樣的先看OOM發(fā)生在哪個階段。如果是Shuffle Read階段多半是拉取的數(shù)據(jù)量超過內(nèi)存限制優(yōu)先檢查是否存在數(shù)據(jù)傾斜或者spark.reducer.maxSizeInFlight、spark.shuffle.spill.compress相關(guān)配置。如果是執(zhí)行聚合操作時OOM優(yōu)先檢查并行度和數(shù)據(jù)分布。某些key的數(shù)據(jù)量過大會導致單個Executor內(nèi)存壓力爆炸。如果是緩存RDD后出現(xiàn)OOM檢查StorageLevel是否合理或者是否緩存了本不需要緩存的大數(shù)據(jù)集。如果是Driver OOM再檢查Driver端是否收集了過多結(jié)果數(shù)據(jù)或者廣播變量是不是太大了。防護措施我認為排第一位的是“預分區(qū)設(shè)計”從數(shù)據(jù)源寫入時就設(shè)計好合理的分區(qū)策略讓數(shù)據(jù)分布均勻。在此基礎(chǔ)上再做執(zhí)行計劃優(yōu)化、并行度調(diào)整、監(jiān)控告警。OLTP和OLAP場景不一樣不能一套參數(shù)打天下。6.4 從實際故障中總結(jié)的Spark UI排查技巧最后分享一個面試high-level的問題如何定位一個Spark作業(yè)的運行瓶頸這個問題的標準答法就是“用Spark UI”。但如果你能說得比“看Stage耗時”更細會在面試中留下很不一樣的印象。我實際看UI的順序是Jobs頁面確認總共幾個Job、哪些Job成功哪些失敗、每個Job的耗時。Stage頁面看每個Stage的Duration分布。如果某個Stage里的Task時間線極不均勻優(yōu)先懷疑數(shù)據(jù)傾斜如果所有Task時間都長考慮是不是資源不足或數(shù)據(jù)量大。Executors頁面看每個Executor的Storage Memory、Shuffle Write、GC時間。某個Executor的GC時間異常說明內(nèi)存壓力大。SQL頁面看物理計劃里每個算子的實際過濾行數(shù)、輸出行數(shù)。如果某個Filter之后的行數(shù)變化異常及時發(fā)現(xiàn)問題。Event Timeline看Task的調(diào)度延遲和計算時間。調(diào)度延遲高說明資源不夠計算時間高說明任務(wù)本身重。在一次真實故障排查里我的整個分析就靠這套順序定位到了問題源頭某個運行15分鐘的Job耗時集中在第4個Stage且只有極少數(shù)Task的數(shù)據(jù)量遠遠大于眾數(shù)。后續(xù)再對比業(yè)務(wù)日志確認是特定用戶ID的數(shù)據(jù)量暴漲導致的傾斜。整個過程代碼一行未改只是加了一個過濾條件配合重新分區(qū)Job耗時從15分鐘降到了4分鐘。如果你在面試時能把這個排查鏈路完整講出來這不止是展示能力更是告訴面試官你是個真正會解決實際問題的人而不是只會在網(wǎng)上看面經(jīng)背答案的候選人。