凌晨四点，“味界”中央厨房的灯亮了。你作为主厨，要指挥几百号厨师，把刚卸下的三卡车食材，变成全城一百家餐厅上午要用的半成品。这活儿最怕什么？怕每个人各切各的，怕传送带堵在半路，怕切好的菜又被回锅改刀。 这门叫Scala的“厨师语言”，就是你手里那份标准操作手册：食材处理有统一流程，每个工位只专注一环，切完送下一站，绝不回头。而那套叫Spark的“中央调度系统”，负责让几百号人各就各位、传送带永不停歇——它把食材变成一条流水线，每站完成一件小事，最后汇集成各家餐厅需要的成品。 作为大数据工程师，你要做的，就是用这套手册指挥这个系统。你会学到：怎么把原始食材分到不同工位、怎么用标准菜谱卡让每道菜可追溯、怎么保证工序之间不互相干扰、怎么让厨房在饭点高峰期不堵车。 这篇实战课，就是带你用这门语言，把这座“大数据中央厨房”开起来。

岗位关联

掌握用Scala开发Spark的技能，意味着你能用类型安全、可维护的代码写出真正扛得住海量数据的分布式应用，成为团队里最值得信赖的大数据核心工程师。

目录
  1. 可视化演示
  2. Scala语言基础
  3. RDD编程模型
  4. DataFrame与SQL
  5. 函数式编程技巧
  6. 隐式转换与类型类
  7. 性能调优方法
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

交互展示Spark用Scala开发大数据应用的核心概念：RDD分布式数据操作、DataFrame API和分布式计算流水线。

本节配有交互动效（进入视口后自动加载，约 3KB）。

RDD操作：分布式数据集 RDD是Spark的基本抽象，不可变分布式集合 Transformation惰性求值，Action触发计算 rdd.map(f).filter(g).collect() Scala函数式风格让RDD操作简洁优雅

Scala语言基础

中央厨房开工第一件事，不是炒菜，而是定规矩。每个岗位的厨师都必须掌握标准的持刀手势和切菜尺寸：丝要切多细、丁要切多大，全部写进《基础刀工手册》。这本手册，就是Scala语言。你可能会问：都要开发Spark了，为什么还要先学一门新语言？因为Spark本身就是用Scala写的，Scala的语法风格与Spark的API设计一脉相承。用Scala写Spark，就像厨房里所有人都说同一种口令，配合起来行云流水。

Scala给开发者最直观的感受，是“少写一半代码”。它把“值”和“变量”分得很清：用val定义的值一旦初始化就不可变，像已经切好的萝卜丝，送出去就不再回改；var才允许重新赋值。更贴心的是类型推断——你写val x = 42，编译器自动知道x是Int，不用像Java那样啰嗦地写int x = 42。这一大一小的设计，让代码既简洁又安全。

这背后是Scala“表达式驱动”的设计哲学：几乎所有结构都是表达式，都有返回值。if有返回值，match有返回值，for推导式可以生成新集合。同时Scala融合了面向对象和函数式两大范式：class和trait让你组织大型工程，而函数可以像普通值一样被传来传去。基础集合List、Map默认不可变，配合map、filter这些高阶函数，写数据处理逻辑就像搭积木。

Scala的不可变风格，就像厨房里“每道工序只产出新半成品、不动原始材料”的纪律。切好的菜不会跟没切的混在一起，任何工位出错都能顺着供应链往回查——这正是分布式环境里最需要的安全感。所有代码都是你写给团队看的“操作手册”，越规范，大家配合越省心。

map(f)(S)={f(x)∣x∈S}\text{map}(f)(S) = \{f(x) \mid x \in S\}
这个公式描述Scala里最常用的map操作：对集合S里的每一个元素x都施加函数f，把所有结果收集成新的集合。它像一条流水线的工序卡——同一个动作，对每一件食材做一遍，产出新的一批半成品。
  1. 集合S一篮子待处理的原始食材，比如一筐土豆，每个土豆是一个元素。
    S={x1,x2,…,xn}S = \{x_1, x_2, \ldots, x_n\}
  2. 映射函数f对每个食材执行的动作，比如“去皮”。Scala里它是匿名函数(x: Int) => x * 2这样的表达式。
    f:T→Uf: T \to U
  3. 花括号与竖线$\{ \mid \}$表示“把所有满足条件的元素收集起来”，竖线后面是产生新元素的规则。
    {f(x)∣x∈S}\{f(x) \mid x \in S\}
  4. 遍历每个x$x \in S$表示x依次取自S中的每个元素，相当于流水线逐件处理，处理完所有食材为止。
    x1,x2,…,xnx_1, x_2, \ldots, x_n

RDD编程模型

清晨五点，三卡车食材到货。中央厨房的调度员不会让食材堆在门口，而是第一时间把它们分成若干筐，分别送上五条并行传送带。每条传送带上的食材，就是一个“分区”；整条由分区构成的食材流，就是Spark里的RDD——全称“弹性分布式数据集”，是Spark最核心的抽象。

RDD有两大招牌特点：惰性和血缘。惰性是指，切菜工在传送带上贴出“切成丁”“去掉虫眼”等指令卡片，但传送带并不会立刻执行——只有到了“装车出货”那一刻才真正启动。血缘则是每条食材都有“来源记录”，哪一步出了问题，可以顺着记录追溯并重算，而不是让整条流水线瘫痪。

RDD的算子分两类。转换算子（如map、filter、flatMap）定义“每个食材要做什么变化”，只形成新的RDD，不实际执行；行动算子（如count、collect、reduce）才会触发全流程执行，并把结果带回Driver端。你会发现，这些算子的写法和Scala集合的高阶函数几乎一模一样，这正体现了Scala和Spark的血缘关系。

RDD的惰性机制像极了后厨的“看板管理”——各工位只贴出指令卡片，不催不动；一旦出货指令下达，所有环节一次性跑起来。这种设计让Spark能把一连串操作合并优化，避免每一步都重新读盘。你在代码里写的一长串转换，Spark会耐心地攒成一张完整的工艺图，等到最后一刻才交给所有工位全力开跑。

count(w)=∣{di∈D∣di=w}∣\text{count}(w) = |\{d_i \in D \mid d_i = w\}|
这是WordCount（单词计数）的数学表达：给定一批文档D，统计与单词w完全相等的文档有多少条。Spark里经典的词频统计，就是这样一条一条地筛选、计数。
  1. 数据集D一批文档，比如一天的所有订单备注，共m条。
    D={d1,d2,…,dm}D = \{d_1, d_2, \ldots, d_m\}
  2. 元素$d_i$其中第i条文档，对应传送带上的一筐食材。
    di∈Dd_i \in D
  3. 竖线与条件$\mid d_i = w$从所有文档中筛选出与单词w相等的那些，相当于filter。
    {di∈D∣di=w}\{d_i \in D \mid d_i = w\}
  4. 外层绝对值$|\cdot|$集合的基数，也就是“符合条件的元素有多少个”，完成计数动作。
    ∣{d1,d2,d5}∣=3|\{d_1, d_2, d_5\}| = 3

DataFrame与SQL

如果RDD是“自由发挥的传送带”，那DataFrame就是“标准菜谱卡”。中央厨房从某天起不再靠老师傅口传心授，每道菜都有一张卡片：配料名称、用量、做法，写得清清楚楚。Spark拿到这张卡，能自动判断每个环节有没有更优的做法。相对于RDD的“任君发挥”，DataFrame多了结构化的约束，反而换来更大的优化空间。

DataFrame本质上是一张“带Schema的表”，每一列都有名字和类型。df.select("city").filter("amount > 100")这样的链式API，读起来几乎像英语句子。更进一步，Dataset[T]在Scala里提供了编译期类型安全：列名写错、类型不匹配，编译时就报错，而不是作业跑到凌晨三点才失败。

DataFrame还背靠Spark SQL引擎，支持标准SQL查询。你可以在Spark里建临时视图，然后用spark.sql("SELECT city, COUNT(*) FROM orders GROUP BY city")完成聚合。SQL语句会被Catalyst优化器解析成逻辑执行计划，再优化为物理执行计划，自动完成谓词下推、列剪枝等优化——相当于厨房统筹大师默默把所有能提前的准备都做了。

有了菜谱卡，厨房不再靠“经验”而是靠“流程”运行。Spark的Catalyst优化器就像厨房里的统筹大师，默默帮你把重复的准备工作合并、把能提前的步骤前移——你要做的，只是把菜谱卡写对。写DataFrame代码时不用操心底层怎么跑，Catalyst这座“总厨大脑”会替你安排好一切。

GroupBy(orders,city)→{(c,nc)∣c∈cities}\text{GroupBy}(\text{orders}, \text{city}) \to \{(c, n_c) \mid c \in \text{cities}\}
这条公式描述SQL中的GROUP BY city：把订单表按城市分组，每个城市输出一个“（城市，订单数）”对。这就是从原始流水账到聚合报表的核心一步。
  1. GroupBy操作按某个维度对数据进行分组，是数据处理里最常见的聚合手段。
    GroupBy(T,key)\text{GroupBy}(T, \text{key})
  2. orders表要被分析的数据集，即菜谱卡里记录的每一笔订单。
    orders\text{orders}
  3. 元组$(c, n_c)$每个城市c和它的订单数$n_c$，一组成对的输出。
    (c,nc)(c, n_c)
  4. 城市集合citiesc遍历表中所有出现过的城市，每个城市都产出一对。
    c∈citiesc \in \text{cities}

函数式编程技巧

老主厨定下一条铁律：任何工位都不许回头改刀。备好的菜送到下一站，这一站绝不回头修修补补；要调整，就基于当前半成品再产出一份新的。这条铁律，就是函数式编程里的“不可变性”。在多台机器同时处理数据的分布式世界里，这条铁律尤其宝贵——谁也不用担心别人偷偷改了自己的食材。

Scala的高阶函数让这种风格特别自然：map对每个元素做变换、flatMap先映射再压平、filter按条件筛选、foldLeft累积归约。你会发现，写数据处理逻辑几乎不用写for循环，全部用这些“积木”拼出来，代码可读性大幅提升。Spark的RDD算子就是照着这套函数式API设计的，二者无缝衔接。

模式匹配是Scala的另一大利器。它像一个智能分拣员，根据数据的结构自动分发到不同处理路径：case Some(v) => ...、case None => ...，让空值和异常情况不再需要一堆if-else。柯里化（currying）和部分应用则让你先固定某些参数，生成一个专用函数——比如先准备好“加盐”的规则，再批量化地应用到不同食材上。

不回头改刀，意味着每个环节都可复现、可回滚。大数据作业跑一半挂了，从断点继续而不是从头再来，正是这种风格带来的可靠性。你的代码因此更像一条清晰的流水线，而不是一团剪不断理还乱的毛线。函数式编程不是花架子，它是让海量数据作业稳定运行的底仓。

foldLeft(acc0,f)(S)=f(f(f(acc0,x1),x2),…,xn)\text{foldLeft}(acc_0, f)(S) = f(f(f(acc_0, x_1), x_2), \dots, x_n)
foldLeft是Scala中最强大的归约函数：从一个初始值出发，把集合里的元素挨个“叠”进累积结果里。就像炖汤，先把底汤下锅，再把配菜一道一道加进去，最终成一锅好汤。
  1. 初始值$acc_0$累积的起点，比如第一锅底汤，在求和场景中就是0。
    acc0acc_0
  2. 累积函数f把新元素与当前累积值合并，比如“把新的菜倒入锅中翻炒”。
    f(acc,x)f(acc, x)
  3. 从左到右$x_1, x_2, \dots, x_n$集合元素依次进入，顺序不能乱。
    x1→x2→⋯→xnx_1 \to x_2 \to \dots \to x_n
  4. 嵌套调用每一层的结果作为下一层的输入，最终收敛为一个值。
    f(f(f(acc0,x1),x2),…,xn)f(f(f(acc_0, x_1), x_2), \dots, x_n)

隐式转换与类型类

中央厨房有一条不成文的规矩：每锅汤出锅前自动撒一撮盐。主厨不需要每次喊“加盐”，后厨的调味机自动完成——厨师只管做菜，时间省了一大半。Scala里的隐式转换，就是这台“自动调味机”：编译器在适当的时候，自动帮你补上那些“人人都知道要做”的步骤。

隐式参数（implicit parameter）允许你声明一个参数“由编译器自动从作用域里找”。比如Spark的Encoder、Akka的ExecutionContext，都是通过隐式参数在背后默默传递的。这样你的代码里不用每次都写一串长长的上下文参数，调用方只管传业务参数，剩下的交给编译器。

隐式转换（implicit def）则能在编译器发现类型不匹配时，自动调用你定义的转换函数。依托这个机制，Scala还发展出“类型类”模式（type class）和Enrichment模式：你可以在不修改已有类的前提下给它“扩展新方法”。比如给Spark的RDD写一个隐式类，让rdd.myCustomOp()直接可用，这让第三方库的扩展变得极其优雅，也让Spark的API生态非常丰富。

自动调味机虽好，但也要克制：调料太多会毁了一锅菜。隐式转换同样如此——滥用会让代码晦涩难懂，调试时“它怎么突然变成另一个类型了”的困惑会层出不穷。Scala社区总结出的最佳实践是：优先用隐式参数传递上下文，用Enrichment扩展方法，少做无节制的类型自动转换。

T⇒UT \Rightarrow U
这条公式表示类型T到类型U的隐式转换。平时你不用在代码里写“把T变成U”，只要在作用域里定义了这条转换规则，编译器就会在你需要U的地方自动调用它。
  1. 类型T原始类型，比如一个普通字符串。
    TT
  2. 类型U目标类型，比如一个自定义的“带单位的金额”类。
    UU
  3. 双线箭头$\Rightarrow$表示隐式转换的方向，由编译器自动调用，不需要显式写出来。
    T⇒UT \Rightarrow U
  4. implicit关键字这个转换被标记为“随时待命”，编译器遇到类型不符时会优先寻找它。
    implicit\text{implicit}

性能调优方法

晚上六点，订单高峰。中央厨房最怕的不是食材不够，而是传送带堵车：某个工位积压如山，其他工位空闲看戏。Spark作业跑得慢，十有八九也是这个原因——数据倾斜、分区不合理、Shuffle太大。调优的目标，就是让每个工位都刚好忙碌而不拥挤。

第一招，分区优化。repartition(n)可以增加分区数，适合数据越来越大的场景；coalesce(n)可以减少分区数，适合聚合后缩小数据集的场景。但分区数不是越多越好：每个分区对应一个Task，Task太多，调度开销反而拖慢速度。第二招，广播变量。当Driver端一个小表要和1TB的大表Join时，把“小字典”广播到每个Executor，能在本地直接查字典，省掉一次全量Shuffle。

第三招，Shuffle调优。spark.sql.shuffle.partitions控制Join和聚合后产生多少个分区，默认200。数据量小时宜调低，数据量大时宜调高，没有绝对正确的值，要看实际负载。第四招，内存管理。合理设置spark.executor.memory和spark.executor.cores，利用StorageLevel.MEMORY_AND_DISK让持久化数据在内存放不下时优雅落盘，而不是直接OOM。Spark UI里的每个Stage耗时、每个Task处理时间，都是你调优的“仪表盘”。

调优的本质，是“让厨房里每个人都刚好忙碌而不拥挤”。多观察Spark UI里每个Stage的耗时、每个Executor的处理量，把积压的工位拆开、把空闲的工位合并，高峰期自然一路顺畅。记住，性能调优不是玄学，而是一套有章可循的厨房管理学问。

Npart=⌈dataSizetargetSize⌉N_{\text{part}} = \left\lceil \frac{\text{dataSize}}{\text{targetSize}} \right\rceil
分区数估算公式：把总数据量除以每个分区目标数据量，再向上取整。比如10GB数据、每个分区目标2GB，就分5个区；如果是10.1GB，就分6个区，多出来的零头单独一个区。
  1. dataSize总数据量当前Stage需要处理的数据总量，单位可以是GB。
    dataSize\text{dataSize}
  2. targetSize目标分区大小你希望每个分区承载的数据量，一般取128MB到1GB之间。
    targetSize\text{targetSize}
  3. 除法用总量除以单区容量，算出需要的分区数量。
    dataSizetargetSize\frac{\text{dataSize}}{\text{targetSize}}
  4. 向上取整$\lceil \cdot \rceil$除不尽的零头也要单独开一个分区，保证所有数据都有地方放。
    ⌈5.1⌉=6\lceil 5.1 \rceil = 6

AI 应用场景

日志异常分析平台

阶段：数据清洗与特征提取

解决的问题：传统方案用grep和awk在几十台服务器上手工排查日志，效率低且容易漏。用Scala+Spark可以把日志处理变成流水线：RDD做格式清洗，DataFrame做聚合查询，几分钟扫完一天TB级日志。

具体案例：某电商平台的订单日志每天约2TB。数据团队用Scala写Spark作业，先通过RDD的filter和flatMap清洗出有效字段，再用Spark SQL统计各接口错误率和P99耗时，半小时出报表，自动标注异常时段。

用户行为特征工程

阶段：特征工程

解决的问题：机器学习模型需要特征，但用户点击流数据量大、字段杂，传统Python脚本逐行处理要跑好几个小时。用DataFrame API做窗口函数和分组聚合，可以批量生成用户行为特征。

具体案例：推荐系统团队用Scala写Spark作业，对7天点击流做窗口计算，按用户ID分组聚合出“近7天点击次数、停留时长、品类偏好”等特征表，直接供后续模型训练使用。

实时数仓离线分层

阶段：数据仓库构建

解决的问题：数仓分层（ODS/DWD/DWS）有大量ETL作业，用Python脚本难维护、难复用。用Scala开发统一的处理函数，类型安全、可测试，让整个数仓的加工逻辑像中央厨房的菜谱卡一样标准化。

具体案例：将订单明细经过“清洗→宽表拼接→汇总”三层加工，每天定时跑批。引入Scala+Spark后，任务成功率从90%提升到99%，新需求的开发时间也从两天缩短到半天。

Python 演示

python28 行
from pyspark import SparkContext, SparkConffrom operator import add  def create_context(app_name):    conf = SparkConf().setAppName(app_name).setMaster("local[*]")    return SparkContext(conf=conf)  def word_count(sc, lines_rdd):    words = lines_rdd.flatMap(lambda line: line.split(" "))    pairs = words.map(lambda word: (word, 1))    counts = pairs.reduceByKey(add)    return counts  def main():    sc = create_context("WordCountDemo")    data = ["hello spark", "hello scala", "spark is fast"]    lines = sc.parallelize(data, 2)    result = word_count(sc, lines)    for word, cnt in result.collect():        print(f"{word}: {cnt}")    sc.stop()  if __name__ == "__main__":    main()
目的：这段代码用PySpark实现经典的WordCount，与Scala版Spark的RDD编程模型完全同构——都是“并行化数据→转换算子→行动算子”的流水线。看懂它，你就理解了Scala写Spark的核心思想。
  1. from pyspark import SparkContext, SparkConf导入Spark的入口类，它们是连接集群的大门。
  2. conf = SparkConf().setAppName(app_name).setMaster("local[*]")配置应用名，local[*]表示本地多线程模拟集群。
  3. return SparkContext(conf=conf)SparkContext是Spark应用的“总开关”，所有RDD都从它产生。
  4. lines = sc.parallelize(data, 2)把本地数据并行化为2个分区，相当于把食材分成两队送上流水线。
  5. words = lines_rdd.flatMap(lambda line: line.split(" "))flatMap先把每行拆成单词列表，再压平为一个个单词。
  6. pairs = words.map(lambda word: (word, 1))每个单词变成（单词，1）键值对，就像给每片食材贴上标签。
  7. counts = pairs.reduceByKey(add)按单词做累加，等价于分组计数，是WordCount的核心。
  8. result.collect()行动操作，触发真正计算并把结果拉到驱动端打印。

常见误区

误区RDD和DataFrame不都是数据集吗？哪个顺手用哪个呗，反正都能做map和filter。

正解区别很大。DataFrame带Schema（列名和类型），Catalyst优化器能自动优化执行计划；RDD是任意对象的集合，操作灵活但无法自动优化。就像“带菜谱卡的标准流程”和“大厨自由发挥”的区别：前者稳定可优化，后者灵活但全靠个人能力。大数据量、结构化场景优先用DataFrame。

为何常见：新手看到两者的API都有map和filter，以为只是写法不同，没意识到DataFrame背后的自动优化能力。

误区所有变量都用`val`不可变，每次操作都产生新对象，会不会比Java的可变对象慢很多？

正解JVM对短生命周期对象的分配和回收非常高效（逃逸分析、栈上分配），而且不可变让分布式环境天然安全——不需要担心并发修改。Spark的RDD本身就是不可变的，这是分布式计算的“护身符”，不是负担。

为何常见：习惯了Java的setter和可变集合，总觉得“不能修改就没法干活”，没体会到不可变带来的并发安全性。

误区Spark作业慢，一定是集群内存不够，加内存就完事了。

正解很多时候慢是因为Shuffle太大、分区不均、数据倾斜。盲目加内存可能只解决了1%的问题。正确做法是看Spark UI，检查是否有不必要的Shuffle、是否该用广播变量、分区数是否合理。

为何常见：Spark主打“内存计算”，出了问题第一反应就是“内存不够”，这也是最直观的解释。

误区`collect()`能把结果打印出来看，调试的时候多方便，我经常用。

正解collect()会把所有数据拉到Driver端，一旦数据集大，直接内存溢出（OOM）。相当于让全城餐厅把食材都送回中央厨房检查，物流必然崩溃。大结果集应该用take(n)取前几条，或者写出去到文件系统。

为何常见：写小Demo时数据量小，collect()毫无压力，上了生产才发现数据量完全不同。

误区隐式转换让代码变得难懂，最好全都显式写明，离它越远越好。

正解隐式参数和类型类是Scala表达力的核心，Spark的Encoder、各种框架的ExecutionContext都依赖它。正确态度是“克制地使用”：用隐式参数传上下文、用Enrichment加方法，避免无节制类型转换。完全不用的团队，等于放弃了Scala最大的优势。

为何常见：调试时隐式转换不好追踪，初学者觉得它像“魔法”，索性一刀切禁用。

面试题

Q1. Scala中val x = 42与var x = 42的主要区别是什么？

单选题 · easy

  • A.val是运行期变量，var是编译期常量
  • B.val初始化后不可变，var可重新赋值← 正确答案
  • C.var初始化后不可变，val可重新赋值
  • D.val和var在语义上没有任何区别

答案：B。val创建不可变引用，一旦初始化不能再赋值；var允许后续重新赋值。在分布式环境里，不可变引用让数据更安全、更易并发处理。A选项把两者说反了，C把特点对调，D完全错误。

Q2. 下面哪个是Spark的转换操作（transformation）？

单选题 · easy

  • A.count() 计算元素个数
  • B.collect() 收集全部结果
  • C.map() 对每个元素做映射← 正确答案
  • D.saveAsTextFile() 写入文件

答案：C。map是惰性转换操作，只定义新RDD，不会立刻执行；count、collect、saveAsTextFile都是行动操作，会触发真正的计算。转换像“给流水线加一道工序说明”，但机器不会立刻开工。

Q3. RDD的cache()和persist()的关系是什么？

单选题 · mid

  • A.cache()用默认级别，persist()可自定义← 正确答案
  • B.persist()用默认级别，cache()可自定义
  • C.cache()和persist()完全等价没有区别
  • D.cache()存磁盘，persist()存内存

答案：A。cache()本质上是persist(StorageLevel.MEMORY_ONLY)的简写；persist()可自定义MEMORY_ONLY、MEMORY_AND_DISK等存储级别。默认级别下两者相同，但persist更灵活，适合内存不足时的策略选择。

Q4. 关于DataFrame和RDD，下列说法正确的是？

单选题 · mid

  • A.RDD自带Schema结构信息
  • B.DataFrame带Schema且Catalyst可优化← 正确答案
  • C.DataFrame只支持SQL查询
  • D.RDD性能总是比DataFrame差

答案：B。DataFrame是带Schema的分布式表结构，Catalyst优化器能自动优化执行计划；RDD是任意对象的集合，灵活但难以自动优化。C选项错误，DataFrame也支持函数式操作；D选项过于绝对。

Q5. 在Scala中，隐式转换最合理的应用场景是？

单选题 · hard

  • A.在两个无关类型间强行转换
  • B.为已有库类型扩展新方法← 正确答案
  • C.隐藏所有错误让程序通过编译
  • D.替代所有函数参数的传参方式

答案：B。隐式转换最实用的场景是Enrichment模式——给已有类型扩展新方法，以及隐式参数传递上下文（如ExecutionContext）。A选项会造成不可控的魔法；C是误解；D会滥用隐式参数。

Q6. 下列哪项不属于Spark性能调优的常用手段？

单选题 · hard

  • A.增加Shuffle分区数量以缓解倾斜
  • B.用广播变量减少大表Join的Shuffle
  • C.用collect()把结果打印到控制台← 正确答案
  • D.合理设置Executor内存和并行度

答案：C。collect()把全量数据拉回Driver端，大数据集会OOM，不属于调优手段。A可缓解数据倾斜，B是大表与小表Join的优化，D是资源维度的调优，三者都是正道。

Q7. Scala的foldLeft操作的作用是？

单选题 · easy

  • A.将集合元素进行倒序排列
  • B.从左到右累积元素得到一个值← 正确答案
  • C.从集合中随机抽取一个元素
  • D.把集合拆分为多个互不重叠子集

答案：B。foldLeft(initial)(f)从左到右把每个元素与累积值做一次f运算，最终得到一个值。比如求和可以写foldLeft(0)(_ + _)。A是reverse，C是随机，D是groupBy。

Q8. Spark中哪些操作会触发真正的作业计算？

多选题 · mid

  • A.count() 统计元素总数← 正确答案
  • B.map() 对每个元素施加转换
  • C.collect() 拉回全部结果← 正确答案
  • D.reduce() 两两合并得一个结果← 正确答案

答案：ACD。行动操作包括count、collect、reduce、save等，它们触发实际执行并返回结果；map、filter、flatMap只是定义新RDD，惰性执行。记住一个口诀：会“要结果”的是行动，只“说改法”的是转换。

Q9. 关于Spark的数据分区，下列说法正确的是？

多选题 · mid

  • A.分区数越多运行性能一定越好
  • B.可用repartition增加分区数量← 正确答案
  • C.可用coalesce减少分区数量← 正确答案
  • D.分区不均衡会导致数据倾斜← 正确答案

答案：BCD。分区数并非越多越好——过多会增加Task调度开销；repartition和coalesce分别用于增加和减少分区；数据分布不均会产生倾斜，少数Task拖着整体变慢。A的说法太绝对，不成立。

Q10. Scala中的隐式参数（implicit parameter）具备哪些能力？

多选题 · hard

  • A.编译器自动查找匹配的隐式值传入← 正确答案
  • B.让函数在大数据环境自动并行计算
  • C.常用来传递上下文对象如ExecutionContext← 正确答案
  • D.隐式参数无法在测试中被覆盖

答案：AC。隐式参数由编译器自动从作用域查找匹配值传入，特别适合传递上下文对象（如Spark的Encoder、Akka的ExecutionContext）。它也可以显式传值覆盖，所以D错误。B选项与并行计算无关，是错误联系。