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