大数据分析实验全流程：Hadoop+Spark环境搭建与MLlib算法实践

简介：大数据分析实验报告（全英文）来自燕山大学，面向正在学习Hadoop、Spark及MLlib机器学习实战的高校学生和自学者，可用作课程实验参考或算法复现模板。报告包含四个完整实验：Hadoop与Spark环境构建及WordCount应用开发、基于MLlib的线性回归、支持向量机（SVM）与K-means聚类算法实现，其中SVM部分给出了Precision、Recall、F1-score与Accuracy等评估指标。整个资源打包为1个doc文档，体积约762KB，内容排版完整、代码与运行结果均有截图，适合直接对照练习或作为实验报告写作范例。目前已有303人学习下载，对于需要快速上手Spark MLlib并理解分类回归评估方法的学习者，具有较强的参考价值。

1. 大数据分析实验报告在动手前最该看清的东西

这份燕山大学大数据分析实验报告不是什么“高级算法合集”，它的价值恰恰在于朴素：Hadoop 2.7.7 与 Spark 2.4.4 的部署组合、WordCount 从本机文件读到结果、Spark MLlib 里线性回归、SVM、K-means 三个算法各跑一遍完整闭环，全部落在 Ubuntu 14.04 虚拟机里，不需要云资源。如果你正在补大数据实验课的完整流程，或者拿到公司环境不敢乱动、想先在虚拟机里把 Spark 跑熟，这份资源可以直接当作业模板抄；四个实验的代码、数据集路径、UI 端口和评估结论都齐，能省掉大量在网上翻帖的时间。围绕“hadoop 数据分析”这条主线，下面我把每一处能落地和容易翻车的细节都拆开讲。

2. 实验环境版本组合：为什么是这套“六件套”

2.1 版本矩阵与兼容关系

报告里的实验环境一共有六个关键组件，我先把它们列成一张对照表，后面所有踩坑都在这张表的范围里发生。

这里最关键的是 Spark 发行包命名里那个“hadoop2.7”。它表示这份 Spark 二进制是针对 Hadoop 2.7 的 API 编译的，也就是说在运行时它会用 Hadoop 2.7 的客户端协议去读写 HDFS。如果机器里装的是 Hadoop 3.x，直接跑这个 Spark 包，最常见的表现是连上 HDFS 后能列目录但读写文件时抛协议版本不兼容的异常。课程实验把这五个版本锁死不是随便选的，而是一套经过验证的组合，照着装最省事。

2.2 三处与环境强相关的关键路径

报告里出现过三个路径，这三个路径决定了你复现时能不能一次跑通。

第一处是 WordCount 实验里的file:/home/liqing/桌面/input.txt。这个路径是报告作者机器的本机路径，里面带了中文目录“桌面”，如果照着抄，读者机器上必然报文件不存在。正确做法是换成自己的绝对路径，我一般会单独建一个/home/你的用户名/sparkdata之类不带中文和空格的目录，把 input.txt 放进去。

第二处是线性回归实验里的DATA_PATH，定义成了/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/ridge-data/lpsa.data。这个路径指向 Spark 安装目录下的示例数据，如果你把 Spark 解压到了其他目录，比如/opt/spark，那么整条路径都要跟着改。很多同学直接跑报错，第一反应是代码有问题，实际上只是路径没对齐。

第三处是 Spark 安装目录本身。SVM 实验里加载file:/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/sample_libsvm_data.txt，K-means 实验里加载file:/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/sample_kmeans_data.txt，两个路径共用同一个 Spark 根目录。我的习惯是先在终端里执行echo $SPARK_HOME确认实际安装位置，再决定要不要改代码里的路径常量，而不是盲改成报告里的原路径。

2.3 硬件分配与部署形态

在开始搭建之前，先想清楚虚拟机的资源分配。Hadoop 的 NameNode 和 DataNode 各占一部分内存，Spark 的 Executor 又要吃内存，如果虚拟机只给 2GB，启动完 Hadoop 再启动 Spark，系统会频繁触发内存交换，表现为 UI 页面打不开、WordCount 运行极慢甚至进程被 kill。我的经验是虚拟机至少给 4GB 内存，CPU 给 2 核以上，磁盘给 30GB 以上。报告里的环境是 VMware Workstation Pro 16，NAT 模式下虚拟机 IP 固定，方便后面访问 50070 和 8080 两个界面端口。

部署形态上要区分一下 local 模式与集群模式。报告里每个 Spark 代码都写了.setMaster("local[*]")，这说明 Spark 应用程序本身是在本地进程里跑的，不依赖 Spark standalone 集群。但报告中又访问了192.168.37.146:8080，这是 Spark Master 的 Web UI，说明课堂环境里还额外启动过 standalone 集群。这里常见的误区是互相矛盾：代码用 local 模式时，8080 端口根本没有 Master 进程在监听。我的做法是先start-dfs.sh把 HDFS 起起来，再用start-master.sh和start-slave.sh spark://localhost:7077构造完整的 standalone 集群，这样 50070 和 8080 都能访问，代码里的local[*]也能正常跑通。

3. 环境搭建与 WordCount 落地：从零跑到第一个 Spark 程序

3.1 一步步把 Hadoop 和 Spark 跑起来

环境搭建是整个实验中最容易出现玄学问题的环节，我按照课堂实验的常见顺序整理出一个可直接复制的操作流程。

先做 SSH 免密登录。Hadoop 的启动脚本会通过 ssh 连接 localhost 来拉起 DataNode 进程，如果不配免密，启动过程中会卡在密码输入上，看起来像脚本挂死。在 Ubuntu 终端里依次执行：

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost

第一步的-P ''表示生成密钥时不设置口令，这样后续 ssh 连接不需要交互输入密码。第二步把公钥追加到授权列表，第三步修正权限，第四步验证是否真的免密。如果ssh localhost后还能免密进入，说明配置成功。

接着配置 Java 和 Hadoop 的环境变量，编辑~/.bashrc：

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_HOME=/usr/local/hadoop export SPARK_HOME=/usr/local/spark/spark-2.4.4-bin-hadoop2.7 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$SPARK_HOME/bin

三行环境变量分别指向 JDK、Hadoop、Spark 的安装目录。JAVA_HOME 的路径要根据你实际安装的 JDK 位置改，如果echo $JAVA_HOME输出为空，一般就是没写入或者没执行source ~/.bashrc。把 Spark 的灵魂目录记清楚，后面所有示例数据都是从这个目录里读的。

启动顺序有讲究。先启动 HDFS，再启动 Spark 的 Master 和 Worker：

hdfs namenode -format start-dfs.sh $SPARK_HOME/sbin/start-master.sh $SPARK_HOME/sbin/start-slaves.sh

hdfs namenode -format只在第一次部署时执行，反复执行会导致 NameNode 的 namespace ID 不一致，DataNode 启动后会被拒绝注册。启动完成后用jps命令检查 Java 进程，正常情况下能看到 NameNode、DataNode、SecondaryNameNode，以及 Spark 的 Master 进程。少任何一个进程都先看对应日志，不要盲目重启整个集群。

3.2 WordCount 代码拆解与运行

WordCount 是整个 Spark 入门实验里的“hello world”，报告里的核心代码如下：

import org.apache.spark.SparkConf import org.apache.spark.SparkContext import org.apache.log4j.{Level, Logger} object WordCount { def main(args: Array[String]): Unit = { Logger.getLogger("org").setLevel(Level.OFF) val conf = new SparkConf().setAppName("WordCount").setMaster("local[*]") val sc = new SparkContext(conf) val input = sc.textFile("file:/home/liqing/桌面/input.txt") val words = input.flatMap(line => line.split(" ")) val wordCounts = words.map(word => (word, 1)).reduceByKey(_ + _) val result = wordCounts.collect() result.foreach(println) sc.stop() } }

这份代码的逻辑链路非常清晰：textFile读取文件内容，flatMap把每行按空格拆成词并摊平，map把每个词映射成(word, 1)的键值对，reduceByKey(_ + _)把相同词的计数累加，最后collect()把分布在各分区的结果拉回 Driver 端打印。Logger.getLogger("org").setLevel(Level.OFF)的作用是关掉 INFO 级别日志，否则控制台会被大量状态日志刷屏，导致结果淹没在其中。

几个参数值得单独说。setMaster("local[*]")表示用本地模式运行，星号表示使用本机所有 CPU 核心；如果机器核心很多而你只想要 2 核，可以写成local[2]。textFile的路径前缀是file:表示读本地文件系统，如果改成hdfs://192.168.37.146:9000/input.txt就会去读 HDFS 上的文件。初学时最容易踩的就是路径前缀搞错，以及照抄作者的路径。我建议在正式运行前先执行cat 你的路径/input.txt确认文件真实存在。

运行方式可以选择用spark-submit，也可以直接在 IDE 里执行 main 方法。课堂实验里更常见的是spark-submit --class WordCount，但 IDE 执行省去了打包环节。如果选择 IDE，要在项目里把 Spark 的 jars 加入依赖；如果选择spark-submit，则必须先把 Scala 代码编译打包成 jar：

sbt package /usr/local/spark/spark-2.4.4-bin-hadoop2.7/bin/spark-submit \ --class WordCount \ --master local[*] \ target/scala-2.12/wordcount_2.12-1.0.jar

spark-submit的--class指定主类名，--master指定运行模式，最后是 jar 路径。这一步容易忽略的是 Scala 版本匹配，如果打包时的 Scala 版本是 2.11，而 Spark 是 2.12 编译的，会抛NoSuchMethodError这类运行期异常。

3.3 界面验证：50070 与 8080 各看什么

实验报告里提到访问192.168.37.146:50070和192.168.37.146:8080，这两个端口对应完全不同的服务。50070 是 Hadoop HDFS 的 NameNode Web UI，能看到 DataNode 列表、HDFS 存储容量、文件块分布情况；8080 是 Spark Master 的 Web UI，能看到当前注册的 Worker、以及已经跑完的 application 列表。

第一次访问时最容易遇到的问题是把 IP 换成自己的虚拟机 IP 后还是打不开。原因通常有三种：一是服务没启动，用jps确认进程是否存在；二是虚拟机防火墙没放行端口，执行sudo ufw disable关闭防火墙再试；三是 Windows 宿主机和 Ubuntu 虚拟机不在同一网段，NAT 模式下一般不会有这个问题，但如果是桥接模式就要仔细检查 IP 是否在同一网段。

访问 50070 时，重点看 “Datanodes” 标签页，确认 live nodes 数量大于 0。如果显示 0 个 live node，多半是hdfs namenode -format执行了多次导致 cluster ID 不一致，需要删除 namenode 和 datanode 的存储目录重新格式化。访问 8080 时，看 “Workers” 里是否有可用 Worker，如果没有，Spark standalone 集群就没有真正起来，应用提交后只能靠 local 模式硬跑。

4. 避坑记录：四个实验中容易翻车的 5 个典型问题

4.1 SSH 免密失效：反复输密码且 DataNode 起不来

现象：执行start-dfs.sh后，命令行反复提示输入密码，DataNode 一直在启动日志里循环报错，jps看不到 DataNode 进程。

原因：Hadoop 脚本通过 ssh 连接 localhost 拉起远程进程，~/.ssh/authorized_keys里没有公钥，或者文件权限不正确。有些同学在 Windows 下编辑过 authorized_keys，文件换行符变成 CRLF，也会导致 ssh 解析失败。

解决：重新生成密钥并严格重置权限，关键是要按ssh-keygen -t rsa -P ''生成无口令密钥，然后用chmod 700 ~/.ssh、chmod 600 ~/.ssh/authorized_keys修正权限。如果还是不行，在~/.ssh/config里加上StrictHostKeyChecking no跳过主机指纹确认。

4.2 数据路径带着中文与你无关：凌晨一点在“桌面”上翻车

现象：WordCount 代码照抄报告里的路径后，运行直接报InvalidInputException: Input path does not exist。

原因：报告作者写的路径是file:/home/liqing/桌面/input.txt，读者机器上既没有liqing这个用户，也没有“桌面”这个目录。中文目录在编码上也容易出问题。

解决：在/tmp/spark_test或/home/当前用户名/sparkdata下创建文件，把代码路径改为file:/home/你的用户名/sparkdata/input.txt。我一般会在代码里去掉file:前缀写法，改成sc.textFile("/home/你的用户名/sparkdata/input.txt")，这样踩坑概率更低。

4.3 lpsa.data 解析失败：空格和逗号里藏着空值

现象：线性回归实验运行时抛NumberFormatException，定位到parts(1).split(" ").map(_.toDouble)这一行。

原因：lpsa.data每行格式是标签和特征以逗号分隔，特征之间用空格分隔。但如果部分行末尾有尾随空格，split(" ")会产生空字符串，toDouble无法解析空字符串直接崩溃。

解决：解析前做一层防呆处理。常见做法是把line.split(",")改成先 trim 再 split，特征部分用split("\\s+")替换split(" ")，正则写法能匹配多个连续空格和制表符，容错性明显更好。修改后的核心行如下：

val parts = line.trim.split(",") LabeledPoint(parts(0).toDouble, Vectors.dense(parts(1).trim.split("\\s+").map(_.toDouble)))

4.4 8080 端口打不开：不是 IP 错了，是服务没启动

现象：浏览器访问192.168.37.146:8080超时，换成自己虚拟机的 IP 依然超时。

原因：Spark 应用代码里用的是local[*]，本地模式不会启动 Spark Master 进程，因此 8080 端口根本没有监听。另一个常见情况是 standalone 集群启动了，但防火墙默认拦截。

解决：先用netstat -tlnp | grep 8080看端口是否有进程监听。没有监听就去启动start-master.sh；有监听却打不开，则执行sudo ufw disable或放行端口 8080、50070、9000。IP 方面用ifconfig查看虚拟机实际 IP 再访问，不要赌报告里的地址和你的环境一致。

4.5 WordCount 结果把标点算进词里：数据清洗没做

现象：WordCount 输出的统计结果里，spark,和spark被当成两个词，the.与the也分别计数。

原因：代码里只有split(" ")，没有做标点清理。英文文本中逗号、句号紧贴单词，导致切出来的词带标点。

解决：在 split 之前用正则把非字母字符替换掉。我一般在flatMap前加一行：

val clean = line.replaceAll("[^a-zA-Z ]", " ") val words = clean.split("\\s+").filter(_.nonEmpty)

第一行把所有非字母字符替换成空格，第二行按空白切分并过滤空字符串。这样统计结果更干净，也与“数据分析”场景里的预处理步骤对得上。

5. Spark MLlib 三大算法实验：线性回归、SVM、K-means 的代码与评估

5.1 线性回归：MSE 高就怪模型？先看数据集

线性回归实验的代码很短，但信息密度很高：

import org.apache.log4j.{Level, Logger} import org.apache.spark.mllib.linalg.Vectors import org.apache.spark.mllib.regression.{LabeledPoint, LinearRegressionWithSGD} import org.apache.spark.{SparkConf, SparkContext} object LinearRegressionExample { val DATA_PATH = "/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/ridge-data/lpsa.data" def main(args: Array[String]): Unit = { Logger.getLogger("org").setLevel(Level.OFF) val conf = new SparkConf().setAppName("LinearRegressionExample").setMaster("local[*]") val sc = new SparkContext(conf) val data = sc.textFile(DATA_PATH) val parsedData = data.map { line => val parts = line.split(",") LabeledPoint(parts(0).toDouble, Vectors.dense(parts(1).split(" ").map(_.toDouble))) } val numIterations = 100 val model = LinearRegressionWithSGD.train(parsedData, numIterations) val valuesAndPreds = parsedData.map { point => val prediction = model.predict(point.features) (point.label, prediction) } val MSE = valuesAndPreds.map { case (v, p) => math.pow(v - p, 2) } .reduce(_ + _) / valuesAndPreds.count() println(MSE) } }

代码里先把每行数据解析成LabeledPoint，它由标签parts(0).toDouble和特征向量Vectors.dense(...)组成。lpsa.data数据集每行是一个病人的前列腺特异性抗原指标，标签是 log 后的 PSA 值，特征向量包含 8 个指标。LinearRegressionWithSGD.train是训练入口，numIterations是迭代次数 100，注意这里没显式设置步长，MLlib 的 SGD 默认步长是 1.0。这个默认值在实践中经常偏大，导致损失函数在最优解附近震荡。

最后一部分计算 MSE，用预测值减真实值后平方求平均。报告里这个实验的 MSE=6.207597210613578，这个数字本身不代表模型“差”，而是说明特征与目标之间大概率不是线性关系。报告给出的解释是数据包含噪声或特征非线性，几个判断方向都对。更合理的处理路径是标准化特征、降低步长、增加迭代次数，以及尝试引入多项式特征。

调参时我习惯这样改：

val algo = new LinearRegressionWithSGD() .setIntercept(true) .setValidateData(true) algo.optimizer.setStepSize(0.1).setNumIterations(1000) val model = algo.run(parsedData)

setIntercept(true)让模型拟合带截距的直线，setStepSize(0.1)把步长缩小到默认值的十分之一，setNumIterations(1000)给足迭代空间。改完这三个参数，同样的 lpsa.data 通常能得到更低的 MSE。这是代码里没写但实验室里一定会碰到的调参点。

5.2 SVM：Precision=1.0 的高分幻觉

SVM 实验涉及分类模型的完整评估链路，代码相对完整：

import org.apache.spark.{SparkConf, SparkContext} import org.apache.spark.mllib.classification.{SVMModel, SVMWithSGD} import org.apache.spark.mllib.evaluation.BinaryClassificationMetrics import org.apache.spark.mllib.util.MLUtils import org.apache.log4j.{Level, Logger} import org.apache.spark.mllib.optimization.L1Updater object SVMWithSGDExample { def main(args: Array[String]): Unit = { Logger.getLogger("org").setLevel(Level.OFF) val conf = new SparkConf().setAppName("SVMWithSGDExample").setMaster("local[*]") val sc = new SparkContext(conf) val data = MLUtils.loadLibSVMFile(sc, "file:/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/sample_libsvm_data.txt") val splits = data.randomSplit(Array(0.6, 0.4), seed = 11L) val training = splits(0).cache() val test = splits(1).cache() val numIterations = 100 val model = SVMWithSGD.train(training, numIterations) val scoreAndLabels = test.map { point => val score = model.predict(point.features) (score, point.label) } val accuracy = 1.0 * scoreAndLabels.filter(x => x._1 == x._2).count() / test.count() val tp = scoreAndLabels.filter(x => x._1 == 1.0 && x._2 == 1.0).count().toDouble val fp = scoreAndLabels.filter(x => x._1 == 1.0 && x._2 == 0.0).count().toDouble val fn = scoreAndLabels.filter(x => x._1 == 0.0 && x._2 == 1.0).count().toDouble val precision = tp / (tp + fp) val recall = tp / (tp + fn) val f1Score = 2 * (precision * recall) / (precision + recall) println(s"Accuracy: $accuracy") println(s"Precision: $precision") println(s"Recall: $recall") println(s"F1-score: $f1Score") sc.stop() } }

MLUtils.loadLibSVMFile读取 LIBSVM 格式的数据文件，这种格式每行是“标签 特征索引:特征值”的结构，分类模型的标准输入格式之一。randomSplit(Array(0.6, 0.4), seed=11L)把数据按 6:4 切成训练集和测试集，固定随机种子 11 保证每次划分结果一致，这样复现实验能得到同样的指标。SVMWithSGD.train接收训练数据和迭代次数，默认使用 L2 正则化。

四个评估指标都是手动计算的。Accuracy 是预测正确的样本占总样本的比例；Precision 表示被预测为正类的样本中有多少是真的正类；Recall 表示真正的正类中有多少被查出来了；F1 是两者的调和平均。报告里四个指标分别是 Accuracy=0.9767、Precision=1.0、Recall=0.9565、F1=0.9778，看起来非常漂亮，但 Precision=1.0 意味着fp=0，也就是模型没有把任何一个负例误判成正例。

这个结果背后不是模型有多强，而是数据分布给力。sample_libsvm_data.txt是 Spark 发行包里的演示数据，类别分布不像真实业务数据那么纠结，正负样本在特征空间里拉得比较开，线性 SVM 很容易就能分开。做实验时可以多跑几组不同比例的训练集切分，看看指标波动，就能感受到数据对评估结果的影响。另外代码里有一处容易忽略的冗余：import org.apache.spark.mllib.optimization.L1Updater被引入了，但训练时并没有使用它。如果你想用 L1 正则做特征稀疏化，需要显式构造SVMWithSGD实例并调用optimizer.setUpdater(new L1Updater)，否则这个 import 不会产生任何效果。

5.3 K-means：Silhouette 接近 1 是数据集帮了忙

K-means 实验和前面两个回归、分类实验形态不太一样，用的是 ML 包而不是 MLlib，入口也换成了 SparkSession：

import org.apache.spark.ml.clustering.KMeans import org.apache.spark.ml.evaluation.ClusteringEvaluator import org.apache.spark.sql.SparkSession import org.apache.log4j.{Level, Logger} object KMeansExample { def main(args: Array[String]): Unit = { Logger.getLogger("org").setLevel(Level.OFF) val spark = SparkSession.builder() .appName("KMeansExample") .master("local[*]") .getOrCreate() val dataset = spark.read.format("libsvm").load("file:/usr/local/spark/spark-2.4.4-bin-hadoop2.7/data/mllib/sample_kmeans_data.txt") val kmeans = new KMeans() .setK(2) .setSeed(1L) val model = kmeans.fit(dataset) val predictions = model.transform(dataset) val evaluator = new ClusteringEvaluator() val silhouette = evaluator.evaluate(predictions) println(s"Silhouette with squared euclidean distance = $silhouette") println("Cluster Centers: ") model.clusterCenters.foreach(println) spark.stop() } }

这段代码用 SparkSession 读取 LIBSVM 格式数据，KMeans().setK(2)设定聚类数为 2，setSeed(1L)固定随机种子，保证每次聚类中心初始位置一致。transform方法给每个样本打上预测的簇标签，ClusteringEvaluator默认以平方欧氏距离计算轮廓系数。

轮廓系数（Silhouette Score）的取值范围是 -1 到 1，越接近 1 说明样本与自身簇内样本的距离远小于与最近邻簇样本的距离。报告实验结果里 silhouette=0.99975，基本接近理论上限，这个数字不是模型调参调出来的，而是sample_kmeans_data.txt这个演示数据本身分布得非常整齐，两簇样本几乎天然分开。真正做聚类分析时，这个指标能到 0.7 就已经很理想了。所以看到这种接近 1 的得分，第一反应应该是检查数据是不是课堂演示数据，而不是觉得自己的聚类模型“练到家了”。

5.4 路径与数据格式对照表

四个实验用的数据集不同，格式不同，加载方式也不同，容易混。我把它们整理成一张对照表，复现时直接对着看。

三个数据集都在 Spark 安装目录的data/mllib子目录下，线性回归用的是ridge-data/lpsa.data，SVM 和 K-means 分别用两个 sample 文件。如果下载的 Spark 版本不是 2.4.4，文件路径也可能不同，比如 Spark 2.2 里 K-means 示例文件放在data/mllib/sample_kmeans_data.txt但内容语法略有差别。复现时先ls -l确认文件存在和大小，再动手改代码路径。

6. 验证与进阶：让实验报告经得起查验的三条硬办法

6.1 用 collect 结果反推数据规模

实验报告写完了，但怎么确认 WordCount 的结果是真的而不是 mock 的？一个硬办法是把collect()的结果和源文件字数对一遍。在 Linux 终端里执行wc -w input.txt统计总词数，再对比 WordCount 所有词频求和的结果，两边应该一致。如果对不上，说明数据清洗的正则把某些词过滤掉了，这正是我要的效果；如果完全相等，反而要怀疑 split 时没处理标点。这个反推过程能让实验报告里的截图不再只是“看起来跑通了”。

6.2 换数据验证泛化：三个替换路径

用 Spark 自带的示例数据做实验，结果永远带着“演示光环”。想确认算法代码本身没问题，我建议把数据换掉再跑一次。线性回归换 Boston Housing 数据集的 CSV 版本，解析时注意逗号分隔和特征索引；SVM 换 UCI 的 Iris 数据转成 LIBSVM 格式，MLUtils.loadLibSVMFile要求特征索引从 1 开始且按升序排列；K-means 可以自己写一个程序生成双高斯分布的样本点，文本格式每行在data/mllib里任意建一个.txt文件即可。换数据后你会发现，SVM 的 Precision 不再稳定停在 1.0，K-means 的 silhouette 也会有明显波动，这才是真实数据集该有的表现。

6.3 从 MLlib 到 ML 的代码演进提示

这份报告里的线性回归和 SVM 用的是spark.mllib包，K-means 用的是spark.ml包，两个包在 Spark 3.x 里已经有明显分化，spark.mllib的回归和分类算法大多进入维护模式。如果你的项目要往生产走，建议关注spark.ml里的LinearRegression和LinearSVC，它们基于 DataFrame API，Pipeline 集成度高，调参方式也更统一。报告里的实验代码作为理解和复现经典算法的底子非常合适，但不要把它当成生产代码的样板。从那以后，我每次拿到一份实验报告，都会强制走一遍“环境版本比对 → 路径重设 → 指标反推 → 换数据验证”四条检查线，确认代码脱离原机器也能跑才放心共享出去。希望帮到你。

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