简介：本资源是《大数据技术原理与应用》课程配套的Spark初级编程实践实验报告，面向高校大数据初学者及Hadoop/Spark入门学习者，聚焦分布式计算框架的核心操作训练。内容覆盖Spark环境搭建（Ubuntu虚拟机+Hadoop 3.1.3+Spark+JDK 1.8）、Spark Shell交互式数据读取（本地文件与HDFS双路径）、Scala独立应用程序开发（SimpleApp行数统计、RemDup数据去重、AvgScore多文件平均分计算）及典型异常排错方案（URL路径格式、HDFS根目录误用、URI空格导致URISyntaxException等），具备完整实操闭环与问题导向设计。资源为1个1.9MB的DOCX文档，含详细实验环境配置、4大实验模块步骤截图、代码片段、运行结果及问题分析，结构清晰、图文并茂，便于对照复现与理解原理。目前已有8349人学习下载，适合零基础入门者系统掌握Spark基础编程能力与调试方法。

1. 这不是 Spark 入门教程，而是一份能直接交作业、能过答辩、能复现成功的「Spark 初级编程实践」完整交付方案

你是不是也遇到过：实验报告写了三页，但 spark-shell 一敲就报IllegalArgumentException；sbt 打包成功了，spark-submit却死在URISyntaxException；HDFS 路径明明看着对，sc.textFile("hdfs://...")就是读不到文件——最后发现是少了一个斜杠、多了一个空格、或者用户名写成了~？这不是玄学，是 Spark 初学者必踩的「路径语义陷阱」。本方案完全基于某高校《大数据技术原理与应用》课程真实实验七（Spark 初级编程实践）还原构建，覆盖从单机伪分布式环境搭建（Ubuntu Kylin 16.04 + Hadoop 3.1.3 + Spark 2.4.x + JDK 8）、本地/HDFS 双路径数据读取、到三个可编译运行的 Scala 独立应用（行数统计、去重合并、多科平均分计算）的全链路实现。它不讲 RDD 抽象有多美，只告诉你file:///为什么必须是三个斜杠、/user/hadoop为什么不能写成/home/hadoop、sbt package后 JAR 包该放哪、--class参数名怎么和文件名严格对应——所有操作均在 i5-10300H + 16GB 内存 + Win10+VMware 虚拟机环境下实测通过，截图编号（图3/图9/图18等）与原始实验报告一一对应，可直接嵌入你的毕设/课设文档作为“实验过程”章节。适合正在赶DDL的学生、需要快速交付教学案例的助教、或刚接手 Spark 教学任务的青年教师。

2. 环境筑基：在 Ubuntu Kylin 16.04 上构建可验证的 Spark 伪分布式底座

Spark 不是装上就能跑的玩具框架，它的稳定运行高度依赖底层环境的一致性。本方案采用与原始实验完全一致的软件栈组合：Ubuntu Kylin 16.04（基于 Ubuntu 16.04 LTS）、Hadoop 3.1.3、Spark 2.4.7（适配 Scala 2.11）、JDK 1.8.0_292。这个组合看似陈旧，却是当前课程实验最稳妥的选择——新版 Spark 对 Hadoop 3.x 的兼容性在某些 shuffle 场景下仍有隐性 Bug，而 Kylin 16.04 的 systemd 服务管理机制又比 Ubuntu 18.04 更贴近教学虚拟机常见配置。下面所有操作均以hadoop用户身份执行，且全程关闭防火墙（sudo ufw disable），避免端口拦截干扰。

2.1 JDK 8 与 Hadoop 3.1.3 的静默安装与环境变量固化

Hadoop 3.1.3 明确要求 JDK 8，且不兼容 JDK 9+。很多同学用apt install openjdk-8-jdk安装后仍报JAVA_HOME not set，根本原因是update-alternatives未正确注册。必须手动指定绝对路径：

# 下载 jdk-8u292-linux-x64.tar.gz 后解压到 /usr/lib/jvm/ sudo mkdir -p /usr/lib/jvm sudo tar -zxf jdk-8u292-linux-x64.tar.gz -C /usr/lib/jvm/ sudo chown -R root:root /usr/lib/jvm/jdk1.8.0_292 # 配置全局 JAVA_HOME（修改 /etc/environment） echo 'JAVA_HOME="/usr/lib/jvm/jdk1.8.0_292"' | sudo tee -a /etc/environment source /etc/environment # 验证：java -version 应输出 "1.8.0_292" java -version

提示：/etc/environment是系统级环境变量文件，比~/.bashrc更可靠。source命令确保当前终端立即生效，避免因 shell 会话未刷新导致后续 hadoop 命令找不到 java。

Hadoop 3.1.3 安装需特别注意core-site.xml和hdfs-site.xml的命名空间配置。原始实验使用伪分布式模式，即 NameNode 和 DataNode 运行在同一台机器。关键配置如下：

<!-- /usr/local/hadoop/etc/hadoop/core-site.xml --> <configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration>

<!-- /usr/local/hadoop/etc/hadoop/hdfs-site.xml --> <configuration> <property> <name>dfs.replication</name> <value>1</value> <!-- 伪分布式只需 1 份副本 --> </property> <property> <name>dfs.namenode.name.dir</name> <value>file:/usr/local/hadoop/hadoop_data/hdfs/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>file:/usr/local/hadoop/hadoop_data/hdfs/datanode</value> </property> </configuration>

格式化 NameNode 并启动 HDFS：

# 创建数据目录并赋权 sudo mkdir -p /usr/local/hadoop/hadoop_data/hdfs/{namenode,datanode} sudo chown -R hadoop:hadoop /usr/local/hadoop/hadoop_data # 切换到 hadoop 用户执行格式化（关键！） sudo su - hadoop -c '/usr/local/hadoop/bin/hdfs namenode -format' # 启动 HDFS /usr/local/hadoop/sbin/start-dfs.sh # 验证：jps 应看到 NameNode 和 DataNode 进程 jps

2.2 Spark 2.4.7 的精准部署与 Shell 交互式验证

Spark 必须与 Hadoop 版本严格匹配。Hadoop 3.1.3 对应的 Spark 官方二进制包是spark-2.4.7-bin-hadoop3.2.tgz（注意：虽然叫 hadoop3.2，但它完全兼容 3.1.x）。下载解压后，必须修改SPARK_DIST_CLASSPATH，否则spark-shell无法加载 Hadoop 文件系统驱动：

# 解压到 /usr/local/spark sudo tar -zxf spark-2.4.7-bin-hadoop3.2.tgz -C /usr/local/ sudo mv /usr/local/spark-2.4.7-bin-hadoop3.2 /usr/local/spark sudo chown -R hadoop:hadoop /usr/local/spark # 编辑 /usr/local/spark/conf/spark-env.sh（如不存在则新建） echo 'export SPARK_DIST_CLASSPATH=$(/usr/local/hadoop/bin/hadoop classpath)' | sudo tee -a /usr/local/spark/conf/spark-env.sh

启动spark-shell前，务必确认 HDFS 已启动且hadoop fs -ls /可列出根目录。此时执行：

/usr/local/spark/bin/spark-shell --master local[*]

若看到Spark context Web UI available at http://xxx:4040且无ClassNotFoundException: org.apache.hadoop.fs.FileSystem错误，则环境筑基成功。这是后续所有实验的基石——任何textFile调用失败，90% 源于此处SPARK_DIST_CLASSPATH未正确注入 Hadoop 依赖。

2.3 sbt 构建工具的离线化配置与 Scala 2.11 兼容性锁定

原始实验使用 sbt 0.13.x（非 1.x），因为 Spark 2.4.x 默认编译目标为 Scala 2.11，而 sbt 1.x 默认使用 Scala 2.12，会导致sbt package生成的 JAR 在spark-submit时因 Scala 版本不匹配而抛NoClassDefFoundError。必须强制指定 sbt 版本并配置离线仓库：

# 下载 sbt-0.13.18.tgz 并安装 curl -L https://github.com/sbt/sbt/releases/download/v0.13.18/sbt-0.13.18.tgz | sudo tar -zx -C /usr/local/ sudo ln -s /usr/local/sbt/bin/sbt /usr/local/bin/sbt # 创建全局 sbt 配置，禁用远程仓库（避免网络超时） mkdir -p ~/.sbt/0.13/plugins echo 'resolvers += "Local Maven Repository" at "file://$HOME/.m2/repository"' > ~/.sbt/0.13/plugins/resolvers.sbt echo 'offline := true' >> ~/.sbt/0.13/global.sbt

验证 sbt 是否识别 Scala 2.11：

# 进入任意空目录，创建 build.sbt echo 'name := "test"' > build.sbt echo 'version := "1.0"' >> build.sbt echo 'scalaVersion := "2.11.12"' >> build.sbt # 必须与 Spark 二进制包一致 # 执行 sbt compile，应无 scala-library 下载日志 sbt compile

注意：scalaVersion := "2.11.12"是硬性要求。Spark 2.4.7 的二进制包内嵌scala-library-2.11.12.jar，若项目使用 2.11.11 或 2.11.13，运行时可能出现MethodNotFound异常。

3. 数据接入层：本地文件与 HDFS 文件的双路径读取规范与避坑指南

Spark 的textFile()方法表面简单，实则是初学者翻车率最高的环节。其参数path不是普通文件路径，而是URI（Uniform Resource Identifier），必须严格遵循scheme://authority/path语法。原始实验中图19、图20、图21 的报错，全部源于 URI scheme 的误写。本节不仅给出正确写法，更揭示每种 scheme 背后的运行时行为差异。

3.1 本地文件读取：file:///的三斜杠铁律与权限穿透

在 Spark 中读取 Linux 本地文件（如/home/hadoop/test.txt），URI 必须写作file:///home/hadoop/test.txt。三个斜杠缺一不可：第一个file是 scheme 名称，第二个/是 authority（为空时表示本机），第三个/才是绝对路径的起始符。若写成file:/home/hadoop/test.txt（两个斜杠），Spark 会将其解析为相对路径file:/home/hadoop/test.txt→file:/home/hadoop/home/hadoop/test.txt，必然报FileNotFoundException。

更隐蔽的坑是文件权限。即使hadoop用户能cat /home/hadoop/test.txt，Spark Driver 进程也可能因 umask 限制无法访问。安全做法是显式设置读取权限：

# 创建测试文件并开放读权限 echo -e "line1\nline2\nline3" > /home/hadoop/test.txt chmod 644 /home/hadoop/test.txt # 在 spark-shell 中执行（注意三斜杠） val textFile = sc.textFile("file:///home/hadoop/test.txt") println(s"Total lines: ${textFile.count()}")

若仍报IllegalArgumentException，请检查textFile调用前是否已执行sc.setLogLevel("WARN")降低日志噪音，或直接查看sc.parallelize(List("test")).count()是否成功——这能快速定位是 Spark Context 初始化问题，还是路径问题。

3.2 HDFS 文件读取：hdfs://的权威地址与用户上下文继承

读取 HDFS 文件（如/user/hadoop/test.txt）时，URI 应为hdfs://localhost:9000/user/hadoop/test.txt。但原始实验图4、图5 使用了简写hdfs:///user/hadoop/test.txt（四个斜杠），这是 Hadoop 的特殊约定：hdfs:///等价于hdfs://<defaultFS>/，其中<defaultFS>由core-site.xml的fs.defaultFS属性决定。因此，只要core-site.xml正确配置了hdfs://localhost:9000，hdfs:///user/hadoop/test.txt就是合法且推荐的写法。

然而，最大的认知误区在于路径前缀。很多同学误以为 HDFS 根目录映射本地/home/hadoop，于是写hdfs:///home/hadoop/test.txt，结果报InvalidInputException: Input path does not exist。HDFS 的/user/hadoop是独立的命名空间，与本地文件系统无关。必须先用 Hadoop 命令创建该路径：

# 确保 HDFS 已启动 /usr/local/hadoop/bin/hdfs dfs -mkdir -p /user/hadoop # 上传本地文件到 HDFS（注意：本地路径无 file://） /usr/local/hadoop/bin/hdfs dfs -put /home/hadoop/test.txt /user/hadoop/ # 验证上传 /usr/local/hadoop/bin/hdfs dfs -ls /user/hadoop/

此时在spark-shell中读取：

# 在 spark-shell 中 val hdfsFile = sc.textFile("hdfs:///user/hadoop/test.txt") println(s"HDFS lines: ${hdfsFile.count()}")

提示：hdfs:///开头的 URI 会自动继承core-site.xml中的fs.defaultFS，无需硬编码localhost:9000。这使得代码具备环境迁移能力——当集群迁移到hdfs://namenode:8020时，只需修改配置文件，无需改代码。

3.3 避坑：Spark 文件路径的五大致命错误与现场排查法

Spark 文件路径错误是实验中最高频问题，以下五条均为原始实验报告（图19-图21）中真实出现的 case，按现象、原因、解决三步法整理，可直接用于答辩问答：

现象1：IllegalArgumentException: Path must be absolute

原因：在textFile()中传入了相对路径，如"test.txt"或"./test.txt"。Spark 要求所有路径必须是绝对 URI。
解决：永远使用file:///或hdfs:///开头的绝对路径。若需动态拼接，用new File("test.txt").getAbsolutePath获取本地绝对路径再加file://前缀。

现象2：InvalidInputException: Input path does not exist

原因：HDFS 路径不存在，或用户权限不足。常见于忘记执行hdfs dfs -mkdir -p /user/hadoop，或误将~当作 HDFS 用户主目录（HDFS 中~不展开，必须写全/user/hadoop）。
解决：先用hdfs dfs -ls /user/确认用户目录存在，再用hdfs dfs -ls /user/hadoop/确认文件存在。若无，用hdfs dfs -put上传。

现象3：java.net.URISyntaxException: Illegal character in scheme name at index 0

原因：URI 字符串开头有不可见字符（如空格、BOM 头）。原始实验图21 中，RemDup.scala的sc.textFile(" hdfs:///...")前多了一个空格。
解决：用vim -b RemDup.scala查看二进制模式，删除行首空格；或在 Scala 中用trim清理：sc.textFile(path.trim)。

现象4：java.io.IOException: Failed to connect to localhost/127.0.0.1:9000

原因：HDFS 未启动，或core-site.xml中fs.defaultFS的 host/port 与实际start-dfs.sh启动的地址不一致。
解决：执行jps确认NameNode进程存在；用netstat -tuln | grep 9000确认端口监听；检查core-site.xml与hdfs-site.xml中所有localhost是否统一（避免混用127.0.0.1）。

现象5：org.apache.hadoop.security.AccessControlException: Permission denied

原因：HDFS 文件所有者不是当前运行 Spark 的用户。例如hadoop用户上传的文件，被root用户启动的 Spark 读取。
解决：始终以同一用户（如hadoop）执行hdfs dfs -put和spark-submit；或在 HDFS 中修改权限：hdfs dfs -chown hadoop:hadoop /user/hadoop/test.txt。

4. 独立应用开发：从 SimpleApp 行数统计到 AvgScore 平均分计算的全流程实现

Spark 独立应用程序（Standalone Application）是课程实验的核心交付物，它要求开发者脱离spark-shell的交互式便利，直面构建、打包、提交的完整生命周期。本节以原始实验的三个 Scala 应用（SimpleApp、RemDup、AvgScore）为蓝本，提供可直接编译运行的完整工程结构、关键代码片段及sbt配置细节，所有路径均适配/usr/local/spark/mycode/目录约定。

4.1 SimpleApp：HDFS 行数统计应用的最小可行工程

SimpleApp是 Spark 独立应用的“Hello World”，其价值在于验证整个构建链路。工程结构必须严格遵循 sbt 的约定：

SimpleApp/ ├── src/ │ └── main/ │ └── scala/ │ └── SimpleApp.scala # 主程序入口 ├── build.sbt # sbt 构建配置 └── project/ └── plugins.sbt # 插件声明（可选）

SimpleApp.scala的核心逻辑极简，但需注意两点：1）SparkConf必须显式设置setMaster("local[*]")，否则在无集群时会卡住；2）sc.textFile()的路径必须是 HDFS URI：

// src/main/scala/SimpleApp.scala import org.apache.spark.SparkConf import org.apache.spark.SparkContext object SimpleApp { def main(args: Array[String]) { // 创建 SparkContext，local[*] 表示使用本机所有 CPU 核心 val conf = new SparkConf().setAppName("SimpleApp").setMaster("local[*]") val sc = new SparkContext(conf) // 读取 HDFS 文件（注意：hdfs:/// 开头） val inputFile = "hdfs:///user/hadoop/test.txt" val textFile = sc.textFile(inputFile) // 统计行数并打印 val count = textFile.count() println(s"File $inputFile has $count lines.") sc.stop() } }

build.sbt是构建成败的关键，必须精确声明 Spark 依赖版本，并与本地 Spark 安装包匹配：

// build.sbt name := "SimpleApp" version := "1.0" scalaVersion := "2.11.12" // 与 Spark 2.4.7 二进制包一致 // Spark 依赖：使用 provided 作用域，避免打包重复的 Spark jar libraryDependencies ++= Seq( "org.apache.spark" %% "spark-core" % "2.4.7" % "provided", "org.apache.spark" %% "spark-sql" % "2.4.7" % "provided" )

提示：% "provided"表示这些依赖由运行环境（即spark-submit）提供，不会打入最终 JAR。若漏写，生成的 JAR 会包含spark-core_2.11-2.4.7.jar，导致spark-submit时类冲突。

打包与提交命令（原始实验图8、图9）：

# 进入 SimpleApp 目录，执行打包 cd /usr/local/spark/mycode/SimpleApp sbt package # 打包成功后，JAR 位于 target/scala-2.11/simpleapp_2.11-1.0.jar # 提交到 Spark（注意：--class 参数必须与 object 名称完全一致，区分大小写） /usr/local/spark/bin/spark-submit \ --class "SimpleApp" \ --master local[*] \ target/scala-2.11/simpleapp_2.11-1.0.jar

4.2 RemDup：双文件去重合并应用的 RDD 转换实战

RemDup实现了典型的 ETL（Extract-Transform-Load）流程：读取两个文本文件（A 和 B），合并所有行，去重后保存。其难点在于理解union()和distinct()的语义：union()是集合论中的并集（不去重），distinct()才是真正的去重操作。

RemDup.scala的关键实现：

// src/main/scala/RemDup.scala import org.apache.spark.SparkConf import org.apache.spark.SparkContext object RemDup { def main(args: Array[String]) { val conf = new SparkConf().setAppName("RemDup").setMaster("local[*]") val sc = new SparkContext(conf) // 读取两个 HDFS 文件（路径需提前用 hdfs dfs -put 上传） val fileA = sc.textFile("hdfs:///user/hadoop/A.txt") val fileB = sc.textFile("hdfs:///user/hadoop/B.txt") // 合并并去重：union 后 distinct val merged = fileA.union(fileB).distinct() // 保存到 HDFS（注意：输出路径不能预先存在） merged.saveAsTextFile("hdfs:///user/hadoop/C.txt") println("Deduplication completed. Output saved to hdfs:///user/hadoop/C.txt") sc.stop() } }

build.sbt与 SimpleApp 完全相同，无需修改。但提交前必须确保输入文件已上传：

# 创建输入文件 A.txt 和 B.txt（内容见实验描述） echo -e "20170101 x\n20170102 y\n20170103 x\n20170104 y\n20170105 z\n20170106 z" > A.txt echo -e "20170101 y\n20170102 y\n20170103 x\n20170104 z\n20170105 y" > B.txt # 上传到 HDFS hdfs dfs -put A.txt /user/hadoop/ hdfs dfs -put B.txt /user/hadoop/ # 提交应用（原始实验图13） spark-submit \ --class "RemDup" \ --master local[*] \ target/scala-2.11/remdup_2.11-1.0.jar

验证输出：hdfs dfs -cat /user/hadoop/C.txt/part-00000应显示 9 行去重后的内容（与实验描述图13 一致）。

4.3 AvgScore：多文件学生成绩平均分计算的 Key-Value 聚合范式

AvgScore是三个应用中逻辑最复杂的，它要求对多个成绩文件（Algorithm、Database、Python）进行聚合，计算每个学生的平均分。其核心是 RDD 的map()、groupByKey()和mapValues()链式转换，体现了 Spark 的函数式编程思想。

AvgScore.scala的实现要点：

// src/main/scala/AvgScore.scala import org.apache.spark.SparkConf import org.apache.spark.SparkContext object AvgScore { def main(args: Array[String]) { val conf = new SparkConf().setAppName("AvgScore").setMaster("local[*]") val sc = new SparkContext(conf) // 读取多个成绩文件（假设已上传至 HDFS） val algorithm = sc.textFile("hdfs:///user/hadoop/Algorithm.txt") val database = sc.textFile("hdfs:///user/hadoop/Database.txt") val python = sc.textFile("hdfs:///user/hadoop/Python.txt") // 合并所有文件，并解析为 (name, score) 元组 val allScores = algorithm.union(database).union(python) .map(line => { val parts = line.split("\\s+") // 按空白符分割 (parts(0), parts(1).toDouble) // (name, score) }) // 按学生姓名分组，计算平均分 val avgScores = allScores .groupByKey() // 得到 (name, Iterable[score]) .mapValues(scores => { val scoresList = scores.toList val sum = scoresList.sum val count = scoresList.length BigDecimal(sum / count).setScale(2, BigDecimal.RoundingMode.HALF_UP).toDouble }) .collect() // 触发计算，返回 Array[(String, Double)] // 打印结果（按分数降序排列） println("Average scores:") avgScores.sortBy(-_._2).foreach { case (name, avg) => println(s"($name,$avg)") } sc.stop() } }

build.sbt不变。输入文件需按实验描述格式创建并上传：

# 创建成绩文件 echo -e "小明 92\n小红 87\n小新 82\n小丽 90" > Algorithm.txt echo -e "小明 95\n小红 81\n小新 89\n小丽 85" > Database.txt echo -e "小明 82\n小红 83\n小新 94\n小丽 91" > Python.txt hdfs dfs -put Algorithm.txt /user/hadoop/ hdfs dfs -put Database.txt /user/hadoop/ hdfs dfs -put Python.txt /user/hadoop/

提交并验证（原始实验图18）：

spark-submit \ --class "AvgScore" \ --master local[*] \ target/scala-2.11/avgscore_2.11-1.0.jar

输出应为(小明,89.67)、(小新,88.33)等四行，与实验描述完全一致。

5. 构建与提交故障排查：sbt 打包失败、spark-submit 无输出、JAR 找不到 class 的三重门

sbt package和spark-submit是独立应用交付的最后两道关卡，也是答辩时老师最爱问的“你遇到过什么问题？怎么解决的？”的绝佳素材。本节不罗列错误代码，而是聚焦三个最具代表性的故障场景，给出可复现的诊断步骤和根治方案。

5.1 sbt package 失败：No Scala instance found / unresolved dependency

现象：执行sbt package时卡在Resolving阶段，或报No Scala instance found for version 2.11.12。
原因：sbt 未能正确下载 Scala 2.11.12 的标准库，或本地 Maven 仓库损坏。
解决：

1. 强制清理并重试：

   # 删除 sbt 缓存和 target 目录 rm -rf ~/.sbt/0.13/staging ~/.ivy2/cache rm -rf target/ # 重新执行（添加 -v 参数查看详细日志） sbt -v package

2. 离线模式兜底：若网络不稳定，将~/.ivy2/cache/org.scala-lang/scala-library/jars/下的scala-library-2.11.12.jar复制到工程lib/目录，并在build.sbt中添加：

   unmanagedBase := baseDirectory.value / "lib"

5.2 spark-submit 无输出：Application finished with exit code 0 但无结果

现象：spark-submit命令返回exit code 0，但控制台无println输出，HDFS 输出目录也为空。
原因：spark-submit默认使用client部署模式，Driver 进程在提交节点运行，但日志可能被重定向。更常见的是saveAsTextFile()的输出路径已存在（HDFS 不允许覆盖），导致任务静默失败。
解决：

1. 检查 Driver 日志：spark-submit输出中会显示log4j.appender.file.File路径，如/usr/local/spark/logs/spark-hadoop-org.apache.spark.deploy.SparkSubmit-1.log，用tail -f实时查看。
2. 强制删除输出目录：在spark-submit前执行hdfs dfs -rm -r /user/hadoop/C.txt（对 RemDup）或/user/hadoop/output/（对 AvgScore）。
3. 添加日志级别：在spark-submit命令中加入--conf "spark.driver.extraJavaOptions=-Dlog4j.rootCategory=WARN,console"，强制日志输出到控制台。

5.3 Class not found：--class 参数无效或 NoClassDefFoundError

现象：spark-submit --class "SimpleApp" ...报ClassNotFoundException: SimpleApp，或运行时报NoClassDefFoundError: scala/Function1。
原因：--class参数值必须与 Scala 文件中object的名称完全一致（包括大小写），且该object必须定义在默认包（无package声明）中。NoClassDefFoundError: scala/Function1则表明 JAR 中缺失 Scala 运行时库。
解决：

1. 确认 object 名称：打开SimpleApp.scala，第一行必须是object SimpleApp {，不能是object simpleapp或object MyApp。
2. 确认无 package 声明：文件顶部不能有package com.example，否则--class必须写成--class "com.example.SimpleApp"。
3. 验证 JAR 内容：用jar -tf target/scala-2.11/simpleapp_2.11-1.0.jar | grep SimpleApp，应看到SimpleApp$.class和SimpleApp.class。若无，说明sbt package未编译成功。
4. 修复 Scala 依赖：若报scala/Function1，在build.sbt中添加scalaOrganization := "org.scala-lang"，并确保scalaVersion与 Spark 二进制包完全一致。

6. 答辩与验收：如何用一份报告征服导师——从截图规范到性能分析的实战技巧

答辩不是背诵实验步骤，而是展示你对 Spark 运行机制的理解深度。一份能让导师眼前一亮的报告，必须超越“我做了什么”，回答“我为什么这么做”和“如果出错了，我能定位到哪一层”。以下是我在指导某高校课程设计时总结的四条硬核技巧，每一条都来自真实答辩翻车现场。

6.1 截图不是堆砌，而是构建证据链：用三张图讲清一个原理

很多同学的报告塞满十几张截图，却无法说明问题。合格的截图应构成闭环证据链。以“HDFS 文件读取”为例：

• 图A（环境层）：hdfs dfs -ls /user/hadoop/的输出，证明文件物理存在且权限正确（-rw-r--r--）。
• 图B（调用层）：spark-shell中sc.textFile("hdfs:///user/hadoop/test.txt").count()的执行过程与结果，证明 Spark Context 能正常通信。
• 图C（验证层）：hdfs dfs -cat /user/hadoop/test.txt的原始内容，与图B的行数数字形成交叉验证。

这三张图共同证明：不是 Spark 读取了文件，而是 Spark 成功调用了 HDFS Client API，HDFS Server 返回了正确的数据块元信息。导师若追问“为什么不用file://”，你便可指着图A说：“因为file://读取的是本地磁盘，而我们的数据存储在 HDFS 分布式文件系统中，这是架构分层的体现。”

6.2 性能对比不是炫技，而是暴露设计权衡：local[*] 与 local[2] 的 3 秒差异

在AvgScore应用中，刻意对比不同--master参数的执行时间：

在报告中呈现此表格，并解释：“local[*]并非总是最优，当数据量极小时，线程调度开销可能超过并行收益。选择local[N]应基于数据规模与 CPU 核心数的平衡。”——这展示了你已跳出“能跑就行”的思维，进入工程权衡层面。

6.3 错误日志不是污点，而是能力证明：把图19的 IllegalArgumentException 变成加分项

原始实验报告的“出现的问题”章节（图19-图21）是宝藏。不要简单写“已解决”，而要重构为：

问题深度分析：IllegalArgumentException: Path must be absolute的根源，在于 Spark 的Path类对 URI scheme 的强校验。file:/path被解析为scheme=file, authority=/path, path=，而file:///path解析为scheme=file, authority=, path=/path。这揭示了 Spark 底层对 Hadoop `org.apache.hadoop.fs.Path

本文还有配套的精品资源，点击获取