Spark MLlib Word2Vec处理2G数据集训练慢及BLAS警告问题求助

你碰到的这个问题其实挺常见的——Word2Vec本身就是计算密集型的活儿，再加上BLAS原生库没生效，性能直接打折扣。我给你梳理几个关键的解决方向，一步步来排查：

1. 先搞定BLAS原生库加载的问题 #

你收到的BLAS警告，本质是Spark默认用的纯Java版线性代数库，速度远不如OpenBLAS或者MKL这种原生实现。哪怕你打了fat jar，大概率是库的路径没指对，或者Spark压根没找到它们。

• 启动spark-shell时指定原生库路径：
  把spark.executor.extraLibraryPath和spark.driver.extraLibraryPath指向你的BLAS/MKL库所在的目录，举个Linux的例子：

  spark-shell --conf spark.executor.extraLibraryPath=/usr/lib/openblas-base/ \
              --conf spark.driver.extraLibraryPath=/usr/lib/openblas-base/ \
              --executor-memory 8G \
              --num-executors 6 \
              --driver-memory 6G \
              --executor-cores 4
  

  注意不同系统路径不一样，Mac可能是/usr/local/lib/，Windows的话得找对应的.dll文件路径。

• 验证原生库是否真的加载成功：
  进了spark-shell之后，跑这段代码看看：

  import org.apache.spark.mllib.util.NativeBLAS
  println(NativeBLAS.isLoaded())
  

  如果输出true，说明成了；要是false，要么路径错了，要么系统里没装原生库（比如Ubuntu可以用sudo apt install libopenblas-dev装OpenBLAS）。

2. 调优Word2Vec的训练参数 #

2GB的数据不算超大，但参数没设好也会拖垮速度：

• 降低向量维度（vectorSize）：默认是100，要是业务上不需要这么高的维度，降到50或者60就行，计算量能少一大截。
• 减少迭代次数（maxIter）：默认10次，其实5-8次的效果差不了多少，但训练速度能提不少。
• 控制窗口大小（windowSize）：窗口越大，计算量线性增长，除非必须，保持默认5或者更小。
• 过滤低频词（minCount）：把出现次数太少的词过滤掉，比如设成5，减少词汇量，训练起来更快。

给你个参数调整的例子：

import org.apache.spark.ml.feature.Word2Vec

val word2Vec = new Word2Vec()
  .setInputCol("tokens")
  .setOutputCol("word2vec")
  .setVectorSize(50)    // 降低维度
  .setMaxIter(7)        // 减少迭代
  .setMinCount(5)       // 过滤低频词
  .setWindowSize(3)     // 缩小窗口

3. 优化Spark资源配置 #

你已经设了6个executor和6GB driver内存，但还有几个细节要注意：

• 给executor足够的内存+内存 overhead：每个executor给6-8GB内存，同时设置spark.executor.memoryOverhead为executor内存的10%-20%，防止OOM还能给JVM留足空间。比如--executor-memory 8G --conf spark.executor.memoryOverhead=1638（1.6GB）。
• 给executor分配足够的CPU核：每个executor配4-6核（--executor-cores 4），Word2Vec是能并行计算的，核数太少浪费资源。
• 调整数据分区数：把输入数据的分区数设成executor总核数的2-3倍，比如6个executor每个4核，就把数据repartition成6*4*2=48个分区，减少shuffle的开销。

4. 预处理阶段的小优化 #

• 持久化分词后的数据：预处理分词之后，把数据持久化到内存+磁盘，避免训练时重复分词：

  val tokenizedData = rawData.select(...) // 你的分词逻辑
  tokenizedData.persist(org.apache.spark.storage.StorageLevel.MEMORY_AND_DISK_SER)
  

  这一步能省不少重复计算的时间。
• 避免不必要的shuffle：如果你的预处理过程中有shuffle，尽量提前完成，别留到训练阶段。

5. 关于Fat Jar的坑 #

如果你自己打Fat Jar，要注意两个点：

• 别把Java版的BLAS库（比如net.sourceforge.f2j:arpack_combined_all）打包进去，不然Spark会优先用Java版，原生库就白搭了。
• 原生库要对应平台，Linux打包.so，Mac打包.dylib，跨平台的话得做不同版本的Jar。

建议你先从验证BLAS原生库是否加载成功开始，这一步性能提升最明显，然后再慢慢调参数和资源配置，应该就能解决训练慢的问题了。

内容的提问来源于stack exchange，提问作者saadoune