Spark字符串特征转向量：稀疏与稠密向量方案详析

我记得刚开始用Spark做用户画像特征时，最常遇到的一件事就是：表里一堆字符串标签，比如城市、渠道、品类，要送给LR或者树模型去训练，但算法根本不认“北京”“上海”这种文本，得先转成数值甚至向量。很多新手第一反应是直接手写一个字典映射，把“北京”换成1、“上海”换成2，跑通一遍之后线下没问题，结果一上线上数据就翻车。后来我把Spark里跟字符串特征相关的组件彻底摸了一遍，才发现从String到稀疏向量、稠密向量这条链路，看着简单，里面全是细节。这篇就把我的完整思路、三种实现方案和排查经验一次性说清楚，尤其适合刚接触Spark MLlib、或者正在折腾特征工程的同学参考。

1. 为什么要做“字符串 → 向量”转换：先说清楚这步的底层逻辑

1.1 字符串不能直接喂给模型，但也不是随便编号就行

机器学习模型本质上只能处理数值。字符串列直接进模型框架，要么被忽略，要么被隐式当成离散编号处理。问题就出在这个“隐式编号”上：如果某个字段是“高/中/低”这类本身有序的标签，编号成0、1、2还算合理，树模型可以通过阈值划分学到序关系；但如果字段是“红色/蓝色/绿色”这种纯类别，你编号成1、2、3，模型就会强行学到“红色小于蓝色小于绿色”这种根本不存在的序关系。

一旦进入线性模型或计算距离的模型，这种假序关系会直接污染特征权重。所以才需要把类别重新表达成one-hot形式的向量：类别之间彼此正交，不引入额外序关系。而Spark里这个向量的落点，就是MLlib的SparseVector和DenseVector两种结构。

1.2 稀疏向量与稠密向量的本质区别：存储形态与计算代价

可以拿班级点名表类比。稠密向量是一张全班30人每天都要点名的表，每个位置都得填状态，哪怕28个人没来也要写“缺席”。稀疏向量则像一张只登记“谁来了”的签到纸，只记录到场人的学号和姓名，没来的人干脆不出现。相当于用空间换遍历成本。

Spark的实现里，DenseVector就是一个普通的Array[Double]，每个特征位置都存储，即使值为0也占内存。SparseVector则只保存两个数组：indices（非零位置）和values（对应值），外加一个size表示总维度。假设某个类别字段有10000个取值，one-hot展开后每个样本只有一个位置是1，其余9999个位置全是0。用DenseVector存，每个向量要消耗近80KB内存（10000个double）；用SparseVector存，只需要存1个索引加1个值，内存差距接近万倍。所以Spark里OneHotEncoder默认输出稀疏格式，这不是随意设计，而是对高维离散特征的基本尊重。

1.3 完整决策路径：什么时候用稀疏，什么时候用稠密

稀疏一定比稠密好？也不是。如果特征维度很小，比如性别只有2到3个取值，SparseVector保存indices和values的数组反而多了一层对象开销和寻址开销，这时候DenseVector更干脆。如果特征向量里大部分位置是非零的，比如短文本的TF-IDF或者某些归一化后的连续特征组合，稀疏存储就完全没有优势，甚至因为要维护索引结构而更慢。

我个人的判断规则有三条：第一，类别特征总数超过30个，同时每个样本实际命中的特征数远小于总维度，走稀疏；第二，特征总数少、或者多数位置非零，走稠密；第三，要看下游承接方，部分深度学习框架的输入层不接受SparseVector，必须转成稠密数组，这时候就得额外权衡转换成本，别为了省内存给下游添堵。

2. Spark里的官方机制与取值坑：从String到索引的必经之路

2.1 StringIndexer索引顺序的隐藏逻辑：按频率而不是字母序

想把字符串转成向量，第一步往往不是直接转向量，而是先转成索引。Spark为此提供了StringIndexer。很多人在这一步就第一次踩坑——它默认的排序规则不是字典序，也不是你写数据的顺序，而是“出现频率从高到低”。出现次数最多的字符串，索引是0，其次才是1、2、3。

这种设计不是为了刁难人，而是有考量的：高频类别在模型训练中承担更多样本，应该占据更稳定、靠前的索引位置，这在后续做正则化、特征筛选时有实际好处。但如果你在业务上对索引顺序有固定要求，比如希望某个兜底类别固定在第0位，那就不能直接依赖StringIndexer的默认行为，要么提前把列排序好再fit，要么fit之后从StringIndexerModel里拿出labelsArray(0)，自己重新构建映射关系。

2.2 OneHotEncoder与维度爆炸：高基数类别如何收场

索引转向量，正统路径是OneHotEncoder。这里要提醒版本差异：老版本Spark里有一个OneHotEncoder只能处理单列，后来推出了OneHotEncoderEstimator支持多列，再后来在Spark 3.x又统称为OneHotEncoder。名字换来换去，核心参数基本没变，其中最关键的是setDropLast，也就是是否丢弃最后一个类别。

为什么要丢弃最后一列？在线性模型里，如果所有类别位都保留，多个哑变量之间会存在完全共线性，影响模型可解释性和稳定性。丢掉一列之后，被丢掉的那个类别可以通过“其他位置全是0”来表达，信息并没有丢失。这个细节在处理稀疏输出时尤其重要，因为你可以少维护一个维度，同时避免模型训练中的数值问题。

真正让人头疼的是高基数类别，比如“城市”字段有几百个取值，或者用户标签有几千个独立值，直接one-hot会让特征列爆炸，训练速度、存储成本全都会失控。遇到这种情况，常规思路是砍低频：统计每个类别的出现次数，把频次低于阈值的统一归并到“其他”，再进入one-hot流程。如果你手里有目标列，还可以考虑目标编码，用类别对应的目标均值去替换整个类别特征，但这属于有监督技巧，操作不当容易过拟合，需要配合交叉验证使用。

2.3 训练与预测一致性：handleInvalid和metadata为什么关键

字符串转向量这条链路里，训练集和线上预测的数据分布往往是不同的。训练集里见过的字符串，线上可能不出现；线上可能冒出来训练集里完全没有的新值。StringIndexer针对“未知值”提供了三种策略，通过setHandleInvalid配置：error是遇到未知值直接抛异常，skip是直接把这一行过滤掉，keep是把未知值统一映射到一个新索引。

真正隐蔽的坑不是这个参数，而是metadata。StringIndexer fit之后，会在输出的索引列上记录一份属性元数据，说明每个索引对应哪个字符串。OneHotEncoder读取这份metadata来做维度推断。如果你自己写UDF做转换，或者中间经过了某种不保留metadata的操作，后续组件就无法自动感知特征的名称和含义。自定义UDF得到的Vector虽然结构正确，但它就像一个没有标签的储物柜，你只知道里面放着东西，却不知道每格放的是什么。

3. 实操：三种可落地的转换方案，从Pipeline到UDF

3.1 方案A：Pipeline标准流水线，稳定可靠

最推荐、也最不容易出错的方案，是直接用Spark ML Pipeline，把StringIndexer和OneHotEncoder串起来。整条链路fit一次，之后transform所有训练集、测试集、线上数据，状态完全统一。

import org.apache.spark.ml.feature.{StringIndexer, OneHotEncoder} import org.apache.spark.ml.Pipeline val df = Seq( ("用户A", "北京"), ("用户B", "上海"), ("用户C", "北京"), ("用户D", "广州"), ("用户E", "上海") ).toDF("user", "city") val indexer = new StringIndexer() .setInputCol("city") .setOutputCol("city_index") .setHandleInvalid("keep") val encoder = new OneHotEncoder() .setInputCol("city_index") .setOutputCol("city_vec") .setDropLast(false) val pipeline = new Pipeline().setStages(Array(indexer, encoder)) val model = pipeline.fit(df) val result = model.transform(df) result.show(false)

注意两点：第一，setHandleInvalid("keep")一定要配好，否则上线遇到新类别，任务直接崩溃；第二，如果你希望向量维度覆盖所有类别，setDropLast(false)就别省。默认情况下OneHotEncoder会丢弃最后一个类别，这在大多数线性模型中没问题，但如果后续想要拿到完整的维度信息，或者有强一致性的维度要求，改成false更直观。

从开发效率上看，Pipeline最大的好处是“一次fit，到处transform”。你不需要关心中间产生了几列、索引如何映射、metadata是否完整，PipelineModel会把这些全部固化。线上部署时直接加载同一个模型文件，新的字符串进来自动归一，训练和预测之间的缝隙被彻底抹平。

3.2 方案B：自定义UDF，完全掌控映射

如果你的映射字典来自业务本身，例如已经有一张固定的城市编码表，不需要Spark再学一遍，那直接用UDF会更灵活。

import org.apache.spark.ml.linalg.Vectors import org.apache.spark.sql.functions.udf val dict = Map("北京" -> 0, "上海" -> 1, "广州" -> 2, "深圳" -> 3) // 转换为稀疏向量 val toSparseUDF = udf { city: String => val idx = dict.getOrElse(city, dict.size) Vectors.sparse(dict.size + 1, Array(idx), Array(1.0)) } // 转换为稠密向量 val toDenseUDF = udf { city: String => val arr = Array.fill(dict.size + 1)(0.0) arr(dict.getOrElse(city, dict.size)) = 1.0 Vectors.dense(arr) } df.withColumn("city_sparse", toSparseUDF($"city")) .withColumn("city_dense", toDenseUDF($"city")) .show(false)

这份代码里最关键的细节是兜底索引：dict.getOrElse(city, dict.size)确保任何不在字典里的字符串都会被映射到最后一个新槽位，而不是抛异常。这样即使线上来了新城市，最多是归入“其他”，不会让整个任务失败。

UDF方案的优点是可控性强，你想让“北京”永远是第0位、想怎么调整维度都可以。缺点是性能。UDF在Spark里走的是序列化和反序列化的通道，数据量一旦上亿，大量的对象转换开销会让作业慢得想砸电脑。我通常只在数据量可控、或者必须使用存量字典时才会用UDF，数据量特别大的场景，会考虑用mapPartitions在分区内做批量转换，减少单行开销。

3.3 方案C：RFormula快速验证，以及Assembler收口

如果你手里不止一个字符串列，还有数值列、布尔列，想一次性合并成一个特征向量，最快的是RFormula。它用类似R语言公式的方式写表达式，例如"city + age + gender + label"，Spark会自动对字符串列做one-hot编码，对数值列做直通处理，最终生成一个统一的特征向量列。

import org.apache.spark.ml.feature.RFormula val rFormula = new RFormula() .setFormula("city + age + gender ~ label") .setFeaturesCol("features") val rModel = rFormula.fit(df) val rResult = rModel.transform(df)

RFormula把很多底层的StringIndexer、OneHotEncoder逻辑封装在内部，开发效率极高，适合探索性建模阶段快速验证。但它的控制粒度也确实粗：你想自定义索引顺序，它不暴露；你想设置dropLast，它也遮遮掩掩。所以我只在路演和基线模型阶段用RFormula，真正进入正式训练管线，还是会拆回StringIndexer加OneHotEncoder的组合。

这里顺便提一下VectorAssembler的收口作用。无论你用哪种方式得到向量列，最终都要把所有特征合成一列，VectorAssembler就是干这个的。它能接收多个数值列和向量列，把它们拼成一个大的特征向量。值得注意的是，VectorAssembler对输入列顺序敏感，拼出来的向量每一维对应什么特征，完全取决于你传入的列顺序，自己组装时一定要保持顺序一致。

3.4 三种方案对比与选型建议，一张表说清楚

选型就一句话：线上正规军走Pipeline，探索性分析用RFormula，存量字典项目用UDF。三种方案我都实际跑过，如果你问我哪一种最省心，答案永远是第一种。

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

4.1 索引顺序与预期不符，怎么排查

几乎所有人都遇到过：StringIndexer输出索引后，发现跟自己预想的字典序完全不一样。这不是Bug，是梁频率排序的正常表现。排查时先看StringIndexerModel.labels，也就是fit出来的标签数组，把顺序打出来跟业务预期核对一遍。如果业务上确实需要固定顺序，可以在fit之前对DataFrame的对应列做排序，或者fit之后根据labels手动构造字典，再走自定义UDF转换。

有一个习惯值得养成：不要在实际训练中对原始字符串列直接做replace或硬编码改值。你看着省事，一旦后续有新的类别字符串出现，所有手动编码逻辑全部悬空，排查起来非常痛苦。

4.2 UDF返回的Vector丢了特征元数据，怎么补

自定义UDF构造出的Vector，Spark只知道它是一个向量，但不知道每个维度对应的特征名。这在Pipeline里可能看不出来，一旦你要用ChiSqSelector做特征筛选，或者想把模型导出到支持特征名说明的预测服务里，缺失metadata就会导致无法映射特征含义。

解决办法是手动设置列的AttributeGroup。给输出列写一份元数据，把特征维度数量和名称都标注上去：

import org.apache.spark.ml.attribute.{Attribute, AttributeGroup} import org.apache.spark.sql.types.StructType val field = result.schema("city_sparse") val attrs = Array.tabulate(dict.size + 1)(i => Attribute.nominal(i.toString)) val group = new AttributeGroup("city_sparse", attrs) val newSchema = result.schema.add(field.copy(metadata = group.toMetadata()))

这个细节虽然麻烦，但值得补上。否则后面的特征分析工具拿不到字段语义，在半路就断了线索。

4.3 稀疏转稠密导致内存暴涨，如何避免

某次在构建用户画像特征时，我用OneHotEncoder生成了近5万维的稀疏向量，单分区内存本来很健康。结果有同事为了方便可视化，调用了toArray把稀疏向量转成了稠密数组，执行器堆内存瞬间飙满，整个作业被OOM中断。

这类隐含OOM最坑的是，你只看到内存曲线暴涨，日志里却没有明显报错指向具体代码。排查方式只能通过降采样数据、分析调用栈逐步缩小范围。最好是规定：所有稀疏向量保持稀疏输出到最后一刻，任何可视化、统计工作都只在抽样数据上进行，不要对全量数据做转换。

4.4 分批数据schema漂移，怎么保证统一

当数据源被切成多个批次单独处理，每批都用同一个PipelineModel去transform，一般不会出问题。但如果你在批次之间自己手动拼vector列，或者用了unionByName合并，极易遇到schema不匹配的坑——不是类型不对，就是metadata缺失导致下游Stage报错。

对策是强制定规矩：所有需要进入模型的特征列，必须在同一个PipelineModel上完成transform，再用VectorAssembler统一收口。不要在数据生产链路里手工拼凑向量，否则每次数据源微调，schema都可能悄悄漂移，而错误要到最后训练阶段才暴露。

4.5 几条老手习惯，少走弯路的经验

• 停靠字符串特征，优先走StringIndexer加OneHotEncoder，不要在业务代码里硬编码映射。
• 高基数类别先做频次统计，再决定是归一化到“其他”还是转embedding。
• 自定义UDF一定要有兜底索引，未知值归到最后一个槽位，保证任务不挂。
• 调试阶段不要collect全量结果，抽样几百行看清indices和values是否符合预期。
• 进入模型前全部特征统一交给VectorAssembler合并，列顺序保持一致。

我在实际项目里踩得最多的，其实还不是编码本身，而是训练和上线的“一致性”。PipelineModel像一个黑盒子把标签映射关系固化下来了，只要你在同一个模型上transform，线上的字符串顺序、未知类别的归位都不会出差错。相比之下，手动字典方案每改一次标签集合就得同步改线上代码，遗漏一两个字符串，最后模型输出就会莫名其妙少一行或者错位。所以我现在的习惯是：能用Pipeline就绝不用手写映射；实在要手写，也会顺手把字典版本号和模型版本号一起打出来，避免后台模型和前端字典错位。希望这套思路和代码能帮你在Spark字符串转向量的路上少踩几个坑。