Spark工程師面試50題：90%候選人栽在這3個坑里

去年某大廠Spark崗位面了127人，通過率11%。HR后來復盤發現，掛掉的候選人里八成不是不懂分布式計算，而是被Scala語言細節絆倒——比如有人把val和var的區別說成"就是個命名習慣"，直接出局。

這篇整理自50道高頻面試題，覆蓋從語法基礎到生產踩坑的全鏈條。不管你是準備跳槽的工程師，還是篩人篩到頭疼的面試官，都能用得上。

第一關：語法基礎——面試官最愛挖坑的5個地方

這5道題看似簡單，但"壞答案"和"好答案"的差距，直接暴露候選人有沒有在生產環境寫過代碼。

第一題：val和var的區別。壞答案說是"兩種創建變量的方式，沒實質區別"；好答案必須點出val的不可變特性在分布式場景的價值——跨執行器共享可變狀態是Spark作業里最隱蔽的bug來源之一。

第二題：模式匹配。很多人答成"加強版switch-case"，但面試官想聽的是解構能力——類型匹配、case class字段提取、嵌套結構處理，以及和密封特質（sealed trait）配合做窮盡檢查。DataFrame轉換里這玩意兒用得極多。

第三題：case class。壞答案說"編譯器讓它變特殊"；好答案要列出生成的5樣東西：equals、hashCode、toString、copy、伴生對象的apply和unapply。再加上不可變默認、易序列化、和Encoder配合做Dataset schema——這才是Spark開發者該有的視角。

第四題：trait vs 抽象類。核心區別在多重繼承和構造參數。Scala 3之前trait不能帶構造參數，抽象類可以。管道代碼里堆疊行為時trait更靈活。

第五題：Option。有人抱怨"讓代碼變長"，但好答案要解釋它如何強制處理空值——在分布式數據流里，null的傳播成本遠高于提前用None顯式標記。

第二關：隱式轉換——從"魔法"到可控的邊界

隱式（implicits）是Scala面試的分水嶺。懂的人覺得順手，不懂的人覺得"這語言怎么到處偷偷改我代碼"。

題目6-10聚焦這塊。典型問法：隱式參數和隱式轉換的區別？隱式解析的優先級規則？為什么Spark SQL的Dataset能自動推斷編碼器？

一個高頻踩坑點：候選人能背出"隱式參數在編譯時注入"，但說不清楚隱式作用域的查找順序——當前作用域、導入的隱式、伴生對象。生產環境里找不到隱式實現的報錯，八成是作用域問題。

另一個考點：隱式轉換的濫用邊界。Spark早期版本大量用隱式增強RDD，但Scala 3開始推given和using顯式化。面試時提到這個演進，能加分。

題目還涉及類型類（type class）模式。這是函數式編程里用隱式實現多態的核心技巧，Spark的Encoder、Ordering都是典型實現。能手繪一個簡化版類型類定義，說明白和Java接口的區別，基本穩過這輪。

第三關：集合與函數式——分布式場景的語法映射

Spark的map、filter、reduce和Scala集合的同名操作，執行模型完全不同，但語法高度相似。面試常考這種"看起來一樣，底層兩回事"的陷阱。

題目11-20覆蓋不可變集合的持久化數據結構、懶加載流（LazyList/Stream）、尾遞歸優化、偏函數、柯里化等。一個經典陷阱：問List和Vector的隨機訪問復雜度，候選人背得出List是O(n)、Vector是O(1)，但追問"Spark shuffle后的數據為什么常用Array而不是Vector"，就卡殼。

答案是內存布局連續性。JVM的Array在堆上連續存儲，配合Tungsten的二進制序列化能直接操作堆外內存；Vector的樹形結構雖然理論復雜度好，但指針跳轉多、緩存不友好。這種"語法層選A，執行層選B"的權衡，是高級崗位的區分度所在。

函數式編程部分，重點考引用透明性和副作用隔離。Spark的閉包清理機制會把任務序列化到執行節點，如果閉包里包了外部可變狀態，序列化要么失敗，要么行為詭異。能舉出var在閉包里引發Task not serializable的具體案例，比背概念管用十倍。

第四關：并發與并行——從JVM到集群的語義斷層

Scala的Future、Promise、Akka Actor和Spark的分布式任務調度，共用"異步"這個詞，但故障模型完全不同。面試常在這里設套。

題目21-30涉及Future的回調地獄vs for-comprehension、ExecutionContext的線程池配置、Actor的消息傳遞保證。關鍵區分點：JVM內的Future失敗會拋異常，Spark的task失敗會觸發重試和推測執行（speculative execution）。

一個進階考點：SparkContext的線程安全性。SparkSession和SparkContext都不是線程安全的，但Dataset的轉換操作是惰性的、線程安全的。能在代碼層面解釋清楚這個設計——為什么提交job的入口要單線程，而定義DAG可以并行——說明真讀過源碼。

題目還覆蓋了volatile、@transient、自定義序列化。Spark的org.apache.spark.serializer接口允許替換Kryo或Java序列化，但case class的@transient字段在executor反序列化后為null，這個行為和被lazy修飾后的區別，是生產debug的常見盲區。

第五關：類型系統與元編程——通往架構師的窄門

最后20題進入深水區：類型邊界、路徑依賴類型、宏（macro）、反射。這部分答不好不扣分，答好了能翻盤。

類型邊界（upper/lower bound）在Spark SQL的Encoder推導里隨處可見。Dataset[T]的T需要滿足Encoder[T]的隱式約束，這個約束本身用到了類型邊界。能解釋清楚:>:和<:在協變/逆變場景的區別，說明類型理論過關。

路徑依賴類型是Scala區別于Java泛型的核心特性。spark.sql.Dataset和spark2.sql.Dataset是不同的類型，即使包結構相同。這種設計讓Spark 2.x到3.x的遷移可以并行維護，但也給反射-based的框架（如某些ORM）帶來麻煩。

元編程部分，題目涉及scala.reflect和Scala 3的inline、quoted。Spark的Dataset的selectExpr用字符串做列選擇，類型不安全；typed select用宏在編譯期生成列引用，犧牲了一點靈活性換取安全。能對比這兩種API的設計取舍，面試基本收尾。

最后一題是開放性的：給定一個生產OOM的Spark作業，如何用Scala的工具鏈定位？期望的答案是組合——jmap看堆直方圖、jstack抓線程、spark-ui看stage劃分，以及用Scala的sys.process或ammonite寫快速腳本分析日志。

這50道題的完整答案集，某硅谷獨角獸的面試官用了三年迭代。他們的反饋是：能完整答對35題以上的候選人，入職后寫出的Spark代碼，review通過率比平均水平高40%。你覺得自己能過哪條線？