Spark ML分类模型实践：朴素贝叶斯与线性SVM的对比与调参要点

在 Spark 机器学习库（ML）里做分类模型，真正值得花大力气研究的往往不是算法公式本身，而是特征工程、模型创建和参数搜索之间的协作方式。bayes 和 svm 这两类分类模型我在实际业务里都跑过不少轮次，朴素贝叶斯轻快，适合高维稀疏的离散特征；线性 SVM 在二分类任务中往往会比逻辑回归体现出更稳定、更干净的边界，尤其在样本量不大、特征已经标准化的情况下。你正准备在 Spark 里落地分类模型，或者已经跑了几版但效果一直不温不火，这篇应该能帮你少走不少弯路。

项目 X 的背景并不复杂：我们手头有一张用户行为特征表，大概 20 多万行，每行代表一个用户在某个时间窗口内的行为聚合，字段包含登录次数、操作类型计数、访问时长、设备类型编号、来源渠道编号等。业务目标是把用户分成两类：风险用户和正常用户。这是一个典型的二分类问题，正负样本比例大概在 1:9 左右，类别不平衡。数据规模并没有大到必须靠分布式计算硬扛，但数据量大到单机工具已经跑得吃力，而且特征字段分散在多张源表里，用 Spark 做特征加工和模型训练在工程上更顺手。

决定用 Spark ML 而不是跨平台系统里的其他组件，主要还是因为 ML 库的 Pipeline 机制很干净：特征列选择、归一化、索引化、模型训练和预测可以串成一条流水线，后续上线预测时只需要把同一个 Pipeline 模型持久化，再对线上表做 transform，不需要重新拼接特征逻辑。这一点在做分类模型迭代时特别重要，因为特征逻辑和模型参数是绑在一起的，分开维护容易出问题。

1. 项目背景与分类模型选型思路

先聊结论：在 Spark ML 里，朴素贝叶斯（NaiveBayes）和线性 SVM（LinearSVC）表面上都属于分类模型，但它们的适用场景差别很大。朴素贝叶斯的核心是贝叶斯定理加上特征条件独立假设。这个假设在真实数据里通常不完全成立，但正因为有了它，模型只需要估计每个特征在每个类别下的条件概率，复杂度低、训练速度快，对高维稀疏数据尤其友好。我们的特征表里有大量离散计数类字段，比如近 7 天登录次数、近 7 天支付失败次数这样的计数变量，也有设备类型、来源渠道这样的类别变量，天然适合朴素贝叶斯的分布假设。

线性 SVM 的思路完全不同，它试图找到一个超平面，让两类样本的间隔最大化。在特征维度中等，比如几十到几百维，样本量在几万到几十万这个量级时，线性 SVM 的分类边界通常比逻辑回归更稳健，因为 SVM 的损失函数对分类边界附近的样本更敏感，而不是对所有样本一视同仁。当数据噪声较多时，SVM 往往能给出更干净的分割结果，这一点在项目 X 的评估阶段体现得很明显。

一个项目里同时引入这两个模型还有一个好处：它们是很好的对照基准。朴素贝叶斯提供了一个非常强的下限，只要特征选得好，乱调参也能得到一个不差的基线；SVM 则用来验证如果提升分隔边界质量后，分数还能涨多少。所以后面的实操会把两个模型放在同一套特征集上对比，确保结论公平。

1.1 为什么选 bayes 和 svm 作为主力模型

我在不少分类任务里总结出的经验是：选模型的顺序不是看哪个算法听起来高级，而是看数据长什么样。项目 X 的特征构成可以分为三类：第一类是计数型特征，比如登录次数、失败次数，取值是非负整数；第二类是连续型特征，比如平均访问时长，分布严重右偏；第三类是低基数的类别特征，比如设备类型、来源渠道。这三类特征混在一起，对模型的假设要求各不相同。

朴素贝叶斯最舒服的场景是“高维度、稀疏、离散”，文本分类就是典型例子。项目 X 里的计数特征虽然也是离散的，但分布并不符合多项式分布那么理想的形态，所以预期它的效果会中等偏上，不会特别惊艳。不过它训练速度极快，10 万级别的样本只需要十几秒就能完成训练，非常适合作为数据链路验证模型。

SVM 最舒服的场景是“样本量可控、特征维度不高、类别边界有一定线性可分性”。项目 X 的用户行为矩阵在做了 one-hot 之后，维度能到 100 到 200 之间，训练样本十几万。这个规模对线性 SVM 来说不算压力，而且风险用户和正常用户的行为模式本身就有比较明显的分界，只是被部分噪声样本干扰。线性 SVM 的 max-margin 特性恰好能把噪声的干扰控制在一定范围内。

1.2 理解 Spark ML 的 DataFrame API 与 Pipeline

现在的 Spark 机器学习库（ML）已经全面转向基于 DataFrame 的 API，早期那种基于 RDD 的 MLlib 接口基本不推荐新项目使用。DataFrame 的好处是表结构和 schema 清晰，特征工程中的每一步都有明确的输入输出列名，调试起来非常直观。

Pipeline 机制可以理解成把一系列 Transformer 和 Estimator 串成工作流。Transformer 负责做特征加工，比如 VectorAssembler 把多列数值特征合并成一个特征向量列，StringIndexer 把字符串类别映射成数字索引，StandardScaler 对特征做标准化；Estimator 则是模型本身，比如 NaiveBayes、LinearSVC，调用 fit 方法就得到训练好的 Transformer。

我强烈建议从刚开始就养成写 Pipeline 的习惯，而不是手动先跑特征工程、再手动 split、再手动训练。原因很简单：线下训练和线上预测用的必须是一套完全相同的变换逻辑。一旦你手动在 DataFrame 上做了 normalization，到了线上预测时很容易漏掉同样一步，最终导致特征分布不一致，模型效果崩了还找不到原因。在项目 X 中，我的 Pipeline 是这样安排的：先读入原始训练表，用 StringIndexer 处理分类型特征，用 OneHotEncoder 展开类别向量，用 VectorAssembler 聚合所有特征；然后根据模型需求决定是否接 StandardScaler 或 MinMaxScaler；最后接模型。后续如果要加特征，只需要往 VectorAssembler 的输入列里追加字段，模型训练和预测代码完全不用改。

2. 朴素贝叶斯分类模型实操

这一节开始写代码。为了方便演示，我用 Scala 写法展示核心片段，生产环境用 Python 也没问题，逻辑完全相同。原始数据已经加载成训练表 trainDF，字段如下：

2.1 数据准备与特征向量组装

第一步是把原始字段加工成模型能吃的特征向量。数值字段直接进 VectorAssembler，类别字段先用 StringIndexer 转成数值索引，再用 OneHotEncoder 展开成 0/1 向量，然后一起塞进 VectorAssembler。这里有一个细节：StringIndexer 默认按频率排序，出现最多的类别映射为 0，这对树模型没什么影响，但对线性模型来说，如果直接把类别编码后的数字当数值使用，会让模型学到不存在的顺序关系。

为了避免这个坑，项目 X 里针对 channel_id 和 device_type 做了 StringIndexer 之后再接 OneHotEncoder。这样类别特征变成稀疏的 0/1 向量，不会给模型引入错误的大小关系，数值特征则保持原始值进入后续流程。

import org.apache.spark.ml.feature.{StringIndexer, OneHotEncoder, VectorAssembler} val channelIndexer = new StringIndexer() .setInputCol("channel_id") .setOutputCol("channel_idx") .setHandleInvalid("skip") val deviceIndexer = new StringIndexer() .setInputCol("device_type") .setOutputCol("device_idx") .setHandleInvalid("skip") val encoder = new OneHotEncoder() .setInputCols(Array("channel_idx", "device_idx")) .setOutputCols(Array("channel_vec", "device_vec")) val assembler = new VectorAssembler() .setInputCols(Array("feature_login_cnt", "feature_fail_cnt", "feature_duration", "channel_vec", "device_vec")) .setOutputCol("raw_features")

注意 setHandleInvalid("skip") 这个参数。当线上数据里出现训练时没见过的类别，如果不设置，训练阶段可能不报错，但 predict 阶段会直接抛异常。设置成 skip 可以在遇到未知类别时跳过这条记录，虽然会造成少量样本丢失，但对稳定性非常有帮助。实际业务里新渠道、新设备类型是常态，这个参数几乎是必填项。

2.2 构建 NaiveBayes 模型 Pipeline

朴素贝叶斯在 Spark 里对应的类是 NaiveBayes，主要参数有三个：modelType、smoothing、thresholds。modelType 默认是 "multinomial"，适用于非负特征的计数数据；还有一个 "bernoulli" 类型，适用于 0/1 特征。

项目 X 的特征里混着计数型字段和连续型字段。multinomial 朴素贝叶斯要求特征非负，所以我没有对特征做均值方差标准化，而是用 MinMaxScaler 把整个特征向量缩放到 0 到 1 区间。这样既能保留计数特征的相对大小关系，又能满足朴素贝叶斯的非负约束。

import org.apache.spark.ml.feature.MinMaxScaler import org.apache.spark.ml.classification.NaiveBayes import org.apache.spark.ml.Pipeline val minMaxScaler = new MinMaxScaler() .setInputCol("raw_features") .setOutputCol("nb_features") val nb = new NaiveBayes() .setModelType("multinomial") .setSmoothing(1.0) .setLabelCol("label") .setFeaturesCol("nb_features") val nbPipeline = new Pipeline() .setStages(Array(channelIndexer, deviceIndexer, encoder, assembler, minMaxScaler, nb))

smoothing 是拉普拉斯平滑系数。默认值是 1.0，作用是防止某个特征在某一类别下出现概率为 0。实际调参时我会在 0.5 到 2.0 之间扫一遍。如果特征维度特别高、样本量少，smoothing 稍大一点能明显提升泛化能力；如果样本量很大，smoothing 对结果的影响就很小。项目 X 用了 1.0 作为起始值，网格搜索结果显示 0.8 附近分数略好一些，但差异不到 0.005，基本可以忽略。

2.3 训练、预测与概率输出

Pipeline 训练很简单，直接 fit 原表。这里需要注意：fit 返回的 PipelineModel 里已经包含了所有特征处理逻辑，预测时只需要调用 transform。

val trainDF = spark.table("train_table") val nbModel = nbPipeline.fit(trainDF) val predictionDF = nbModel.transform(testDF) predictionDF.select("user_id", "label", "prediction", "probability").show(5, false)

probability 列是一个向量，第一个元素是类别 0 的概率，第二个是类别 1 的概率。在业务里我对风险用户判定有严格的比例要求，所以通常不是只看 0.5 的阈值，而是基于 probability 列再做一次阈值调整。朴素贝叶斯输出的概率校准程度一般，但在排序场景下够用，我会基于训练集上的 precision-recall 曲线选择一个更合理的业务阈值。

还有一个常见操作：把预测结果写回业务表。我习惯用 predictionDF.write.mode("overwrite").saveAsTable("pred_result")，相当于把特征、真实标签、预测标签和概率一起落盘，后面做误差分析非常方便。误差分析时重点关注那些概率接近阈值边界的样本，比如概率在 0.4 到 0.6 之间的记录，这些样本往往能暴露出特征区分度不够的问题。

3. SVM分类模型实操

Spark 的 SVM 和你在教科书里见到的“核技巧 SVM”不完全一样。Spark ML 里实现的是线性 SVM，类名是 LinearSVC，它背后是使用线性核的优化器，不直接支持 RBF 核。如果需要非线性分类，Spark 本身不是最合适的选择，通常的做法是先做特征工程把非线性信息显式地表达出来，再交给线性模型。

3.1 LinearSVC 与逻辑回归的关系

很多初学者搞不懂 LinearSVC 和 LogisticRegression 的区别，简单来说两者都是线性分类器，主要差异在损失函数。逻辑回归用对数损失，对所有样本的预测置信度都敏感；SVM 用 hinge loss，只对落在间隔带附近的支持向量敏感。反应到实际效果上，SVM 的决策边界受“难分类样本”影响更大，当两类数据存在部分重叠时，SVM 往往能找到一个比逻辑回归更居中的边界。

在项目 X 中，对比下来 LinearSVC 比逻辑回归的效果略好一点。差异主要来自特征中存在一些噪声特别大的用户。逻辑回归为了拟合这些极端样本会把整个边界拉偏，而 SVM 对这些噪声点相对宽容，只要支持向量没有被噪声污染太多，边界就很稳定。当然这个优势不是绝对的，如果噪声点恰好落在间隔带内部，SVM 一样会被带偏。

3.2 Pipeline 搭建与特征标准化

SVM 对特征尺度非常敏感，这一点和朴素贝叶斯完全不同。如果某个特征取值范围是 0 到 10000，另一个是 0 到 1，那么 SVM 的间隔计算会被大尺度特征主导，模型基本忽略小尺度特征。所以 LinearSVC 前面必须接 StandardScaler，这是我在项目里反复强调的一条经验。

import org.apache.spark.ml.feature.StandardScaler import org.apache.spark.ml.classification.LinearSVC val scaler = new StandardScaler() .setInputCol("raw_features") .setOutputCol("scaled_features") .setWithStd(true) .setWithMean(true) val svm = new LinearSVC() .setMaxIter(100) .setRegParam(0.1) .setLabelCol("label") .setFeaturesCol("scaled_features") val svmPipeline = new Pipeline() .setStages(Array(channelIndexer, deviceIndexer, encoder, assembler, scaler, svm))

setWithMean(true) 会把特征中心化，也就是减去均值。这里有一个性能上的注意点：StandardScaler 在分布式环境下计算均值需要对数据做一次聚合扫描，所以 Pipeline 里设置了 scaler 之后 fit 阶段会多一个 job。数据量非常大时，这一步的开销不能忽略。另一个细节是，如果原始特征是比较稀疏的 one-hot 向量，开启 withMean 之后会把稀疏向量变成稠密向量，内存开销成倍上涨。所以当特征里 one-hot 占大头时，我通常只 setWithStd(true)，也就是做方差缩放，不做均值中心化。

3.3 关键参数解析：regParam、maxIter、tol

LinearSVC 有三个参数需要重点关注。regParam 是正则化系数，默认 0.0，但在生产环境我一般至少设到 0.01 到 0.1。正则化太大，模型会偏向简单边界，容易欠拟合；太小，模型容易在边界附近抖动，并且对噪声敏感。maxIter 是最大迭代次数，默认 100。线性 SVM 的优化是迭代式的，当数据量大、维度高时，100 次不一定收敛，建议设到 500 或者结合 tol 判断。tol 是迭代收敛容忍度，默认 1e-4。如果训练日志里每次都到达 maxIter 还没收敛，说明 tol 设置太小，或者数据真的很难分。可以把 tol 放宽到 1e-3，对最终结果影响通常很小，但训练速度能快不少。

我见过一个典型场景：某次业务跑一个 30 万样本、200 维特征的任务，用默认参数跑了一个多小时还没结束，看日志总是 reached max iterations，后来把 maxIter 从 100 提到 200，tol 从 1e-4 放宽到 5e-4，结果时间没有继续增加，反而模型效果更稳定了。原因就是默认迭代次数不够，提前停止导致边界在最优解附近来回震荡。所以如果发现 SVM 训练时间异常高，第一步不是加资源，而是先检查收敛日志。

3.4 SVM 的训练与预测验证

用 PipelineModel 做预测，代码和朴素贝叶斯几乎一样，只是模型换成了 LinearSVC。这里有一个容易忽略的地方：LinearSVC 默认没有 probability 列，只有 rawPrediction 和 prediction。rawPrediction 是间隔值，可以把它理解为距离决策边界的带符号距离，正数代表预测为正类，负数代表预测为负类，绝对值越大说明置信度越高。

如果业务需要概率，一种做法是把 rawPrediction 值经过 sigmoid 映射得到伪概率；更规范的做法是直接用逻辑回归，因为逻辑回归天生输出校准概率。我们在项目 X 里使用 SVM 主要是为了拿一个更强的分类边界结果，所以没有强需求做概率校准，只要 prediction 列就够了。

val svmModel = svmPipeline.fit(trainDF) val svmDF = svmModel.transform(testDF) svmDF.select("user_id", "label", "prediction", "rawPrediction").show(5, false)

4. 模型评估与调参比较

模型训练出来不能只看准确率，尤其在类别不平衡的场景下，准确率会骗人。假设负样本占 90%，一个什么都不干的模型把所有样本判为负类，准确率也有 90%，这显然没有意义。所以必须引入精确率、召回率、F1 和 AUC。

4.1 评估指标怎么选

针对项目 X 的风险用户识别，我主要看三块：精确率，也就是预测为风险用户的人里，真的有多少比例是风险用户，这个指标决定业务误伤多少正常用户；召回率，也就是所有真正的风险用户里，我们抓到了多少比例，这个指标决定业务风险覆盖率；AUC，也就是 ROC 曲线下的面积，用来衡量排序能力。AUC 高说明模型能把高风险用户排到前面，具体阈值可以事后调整。

用 Spark 自带的 BinaryClassificationEvaluator 能得到 AUC，用 MulticlassClassificationEvaluator 能得到精确率、召回率、F1。大概代码如下：

import org.apache.spark.ml.evaluation.{BinaryClassificationEvaluator, MulticlassClassificationEvaluator} val binaryEvaluator = new BinaryClassificationEvaluator() .setMetricName("areaUnderROC") .setLabelCol("label") .setRawPredictionCol("rawPrediction") val auc = binaryEvaluator.evaluate(svmDF) val mcEvaluator = new MulticlassClassificationEvaluator() .setMetricName("f1") .setLabelCol("label") .setPredictionCol("prediction") val f1 = mcEvaluator.evaluate(svmDF)

注意 BinaryClassificationEvaluator 需要的是 rawPrediction 列而不是 probability 列。如果用朴素贝叶斯，它输出的是 probability，此时需要把 evaluator 的 rawPredictionCol 改成 probabilityCol，或者直接用 prediction 列算其他指标。

4.2 用 CrossValidator 做网格搜索

Pipeline 的好处在这里完全体现出来。我们不需要手动循环训练几十个模型，只需要定义参数网格和评估器，CrossValidator 会自动完成 K 折交叉验证并选出最优模型。K 我一般设 3，因为 5 折在分布式集群上会让训练成本变为原来的 5 倍，而 Spark 的 K 折还涉及多次重新拟合 Pipeline，实际开销比想象中大。

import org.apache.spark.ml.tuning.{ParamGridBuilder, CrossValidator} val paramGrid = new ParamGridBuilder() .addGrid(svm.regParam, Array(0.01, 0.05, 0.1)) .addGrid(svm.maxIter, Array(100, 300)) .build() val cv = new CrossValidator() .setEstimator(svmPipeline) .setEvaluator(binaryEvaluator) .setEstimatorParamMaps(paramGrid) .setNumFolds(3) .setParallelism(2) val cvModel = cv.fit(trainDF)

setParallelism(2) 在这里很关键。CrossValidator 默认是串行跑，数据量大时非常慢；但也不要一味调大 parallelism，因为每个并行任务会复制一份 Pipeline 及其依赖，内存占用会翻倍。服务器资源有限的情况下，并行度设成 2 到 4 是比较均衡的选择。

4.3 对比实验结果

我在项目 X 中使用同一份训练集、同一套特征，对比了 NaiveBayes、LinearSVC、逻辑回归。特征包含 30 个数值字段和 15 个类别字段，训练样本 18 万，测试样本 4 万，结果如下：

这个结果基本符合预期。LinearSVC 在 AUC 和精确率上都有优势，朴素贝叶斯训练最快但分数垫底。在风险识别的业务里，我们更看中精确率和召回率的平衡，所以最终选择了 LinearSVC 作为主模型，同时保留 NaiveBayes 作为快速基线，用于每次特征变更后的快速回归检查。

需要说明的是，这里朴素贝叶斯的召回率低并不代表模型差，原因是它内部概率假设对特征分布的要求比较高，我们的特征混合了计数和连续变量，本来就不是最理想的使用场景。如果换成纯文本 TF-IDF 特征，朴素贝叶斯的表现通常能有很大提升。

5. 常见问题与排查技巧实录

这一段是实战中沉淀下来的东西，前前后后在 Spark ML 上踩过不少坑，挑几个有代表性的写出来。

5.1 类别特征出现空值或未知值

这是最常见的坑。StringIndexer 在训练时只会记住见过的类别，预测时遇到新值会默认抛异常。解决方案有两个：第一个是训练前对类别列做清洗，把低频类别合并成 other；第二个是像我前面那样在 StringIndexer 里设置 setHandleInvalid("skip")。低频类别合并有时更有效，因为可以让模型学到“罕见类别”这个含义，而不是简单跳过。项目 X 里的渠道字段确实出现过这种情况，某次上线后渠道表新增了一个 ID，当时如果没设置 skip，整个线上预测任务会直接失败。

5.2 朴素贝叶斯报 requirement failed: Naive Bayes requires nonnegative feature values

这个错误基本都会遇到。原因就是某个特征列存在负数。解决办法有三个：第一，改用 MinMaxScaler 把连续特征缩放到 0 到 1；第二，去掉 StandardScaler，保留原始非负计数；第三，如果业务允许，对计数类特征做 log1p 变换，也能保持非负并且压缩长尾。千万不要为了强行使用某个模型而忽略特征本身的业务含义。项目 X 第一版 NB 流水线就踩了这个坑，原因是前一个版本用了 StandardScaler 做特征标准化，切到 NB 时没改回来，训练直接报错。

5.3 SVM 训练耗时异常高

有段时间我发现相同数据量下 SVM 比逻辑回归慢非常多，排查之后发现是 maxIter 到达上限、每次都没有收敛。本来 200 次迭代就能收敛的数据，由于特征没有标准化，某些维度上梯度消失，导致迭代一直不下降。加上 StandardScaler 之后，同样的 maxIter 下很快就收敛了。所以如果 SVM 训练很慢，第一步先确认特征标准化有没有做好，第二步再看 tol 和 maxIter 是否匹配。

5.4 类别不平衡导致评估失真

项目 X 的正负样本比是 1:9，直接训练会导致模型几乎把所有样本判为负类。有两个处理方式：一是对训练集做过采样或者对样本加权，Spark 的分类器通常支持样本权重，对于 DataFrame API 来说一般通过构造权重列来传入；二是调整分类阈值，在朴素贝叶斯中可以设置 thresholds 数组。SVM 没有直接调阈值接口，只能在预测后对 rawPrediction 做二次筛选。

另外，评估时不要只看 accuracy，要综合看 AUC 和不同阈值下的 precision-recall 曲线。我们当时把判定阈值从 0.5 降到 0.3 之后，召回率从 0.53 提升到 0.71，精确率只牺牲了 0.06，这正是阈值调整带来的收益。

5.5 Pipeline 持久化与加载

最后提醒一句：训练完成的 PipelineModel 一定要用 save 方法保存到分布式存储上，上线服务时用 PipelineModel.load 加载，再对线上特征表做 transform。别把特征处理步骤也写在预测代码里，那样就违背了 Pipeline 的初衷。

svmModel.write.overwrite().save("hdfs:///models/project_x_svm_model") val loadedModel = PipelineModel.load("hdfs:///models/project_x_svm_model")

我个人在实际项目里养成的习惯是，任何一次模型迭代都必须同时跑两个基线模型：一个最轻量的，比如朴素贝叶斯，用来快速验证数据链路是否通了；一个最强力的，比如线性 SVM，用来衡量优化上限。这个习惯帮我节省了大量排查时间，因为很多数据问题会同步影响所有模型，但不同模型对问题的敏感度不一样，一对比就能快速定位是特征的问题还是模型的问题。如果后续你需要在这个框架里加入更多分类器，比如树模型或者集成模型，Pipeline 结构基本不用动，只替换最后的 Estimator 就可以了。