大数据面试实战：用Spark 3.x破解两个经典数据处理难题
当面试官在技术面抛出Spark相关问题时，他们真正想考察的往往不是代码本身，而是你解决问题的思维方式和对分布式计算本质的理解。本文将带你深入两个高频面试题——数据关联与二次排序，从面试官视角拆解问题本质，用Spark 3.x给出工业级解决方案，并揭示那些面试官不会明说但暗自期待的技术细节。
1. 电影评分分析：Join操作的实战与陷阱
"请用Spark统计每部电影的平均评分，并筛选出评分高于4.0的电影及其名称"——这类关联查询问题在大数据面试中出现频率高达73%（根据2023年大数据岗位面试题统计）。表面看是简单的聚合+过滤，实则暗藏多个考察点：
// Spark 3.x优化后的实现 val ratings = spark.read.option("delimiter", "::").csv("ratings.dat") .select($"_c1".as("movieId").cast("int"), $"_c2".as("rating").cast("double")) val avgRatings = ratings.groupBy("movieId") .agg(avg("rating").as("avgRating")) .filter($"avgRating" > 4.0)1.1 性能优化关键点
面试官追问："如果movies表有10TB，ratings表只有1GB，该如何优化？"
- 广播变量方案：当小表足够小时（<1GB），广播是最佳选择
val movies = spark.read.option("delimiter", "::").csv("movies.dat") .select($"_c0".as("movieId").cast("int"), $"_c1".as("title")) val result = avgRatings.join(broadcast(movies), "movieId")- 分区策略调整：对于中等规模数据，可预先对两个表按join key重分区
val repartitionedRatings = avgRatings.repartition(200, $"movieId") val repartitionedMovies = movies.repartition(200, $"movieId") repartitionedRatings.join(repartitionedMovies, "movieId")1.2 数据倾斜处理实战
当某些电影的评分数据异常多时（比如《肖申克的救赎》有百万条评分），常规groupBy会导致严重倾斜。这时需要展示你的实战经验：
// 采样检测倾斜key val skewThreshold = 1000000 val skewedMovies = ratings.sample(0.1) .groupBy("movieId").count() .filter($"count" > skewThreshold) .collect() // 分治处理方案 if (skewedMovies.nonEmpty) { val normalRatings = ratings.filter(!$"movieId".isin(skewedMovies:_*)) val skewedRatings = ratings.filter($"movieId".isin(skewedMovies:_*)) // 分别处理后union normalRatings.join(movies, "movieId") .union(skewedRatings.join(broadcast(movies), "movieId")) }2. 二次排序：从基础实现到性能对决
"对包含多字段的数据集，如何实现先按第一字段升序，再按第二字段降序排列？"——这类排序问题考察的是对Spark核心抽象的理解深度。
2.1 经典实现方案
case class SortKey(first: Int, second: Int) extends Ordered[SortKey] { override def compare(that: SortKey): Int = { val primary = this.first - that.first if (primary != 0) primary else that.second - this.second // 降序 } } val data = spark.sparkContext.parallelize(Seq( "1 5", "2 3", "1 3", "3 1", "2 1" )) val sorted = data.map { line => val parts = line.split(" ") (SortKey(parts(0).toInt, parts(1).toInt), line) }.sortByKey() .map(_._2)2.2 性能优化方案对比
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 自定义排序类 | 逻辑清晰 | 需创建大量对象 | 数据量中等(<1TB) |
| 元组+隐式排序 | 代码简洁 | 灵活性差 | 简单排序需求 |
| 预处理+二次排序 | 内存消耗低 | 需多次shuffle | 超大规模数据 |
// 元组方案示例（Spark SQL风格） val df = data.map(line => { val arr = line.split(" ") (arr(0).toInt, arr(1).toInt, line) }).toDF("first", "second", "original") df.orderBy($"first".asc, $"second".desc)2.3 内存优化技巧
当处理海量数据时，排序可能成为性能瓶颈。这时可以展示你对执行计划的理解：
// 查看执行计划 sorted.explain() // 优化建议： // 1. 增加分区数：.repartition(1000) // 2. 调整序列化：conf.set("spark.serializer", "org.apache.spark.serializer.KryoSerializer") // 3. 预排序：.sortWithinPartitions()3. 面试官最爱的扩展问题
准备以下问题的回答能让你的表现提升一个档次：
Shuffle原理："能解释下sortByKey底层是如何工作的吗？"
- 涉及HashShuffle vs SortShuffle演变
- Spark 3.x的优化点：AQE（自适应查询执行）
稳定性考量："你的方案在集群节点故障时如何保证结果正确？"
- Checkpoint机制
- 累加器的使用场景
API选择："为什么不用DataFrame而用RDD？"
- 性能对比：Catalyst优化器 vs 手动优化
- 类型安全与灵活性的权衡
4. 真实场景避坑指南
在电商平台实际项目中，曾遇到二次排序导致作业卡死的情况。最终发现是自定义排序类没有正确实现Serializable接口——这种实战经验会让面试官眼前一亮。
// 错误示例（会导致任务失败） class FaultySortKey(val first: Int, val second: Int) extends Ordered[FaultySortKey] { // 缺少Serializable实现 ... } // 正确做法 class CorrectSortKey(...) extends Ordered[...] with Serializable { ... }另一个常见陷阱是在join操作后忘记及时persist结果，导致重复计算。在面试中提及这些细节，能展现你的工程素养。
