spark ALS源码余弦向量问题分析

训练迭代求解部分暂未研究，本次只分析推荐计算得分排序部分，即主要的推荐函数recommendForAll，先看代码（红色是源码计算得分，蓝色是我改的计算得分方式，注BLAS.f2jBLAS是private的用不了，退一步用了blas.sdot）：
def recommendForAll(
                    srcFactors: DataFrame,
                    dstFactors: DataFrame,
                    srcOutputColumn: String,
                    dstOutputColumn: String,
                    num: Int): DataFrame = {
    import srcFactors.sparkSession.implicits._
...
    val score = BLAS.f2jBLAS.sdot(rank, srcFactor, 1, dstFactor, 1)
    val r=10
    val score1 = blas.sdot(r, srcFactor, 1, dstFactor, 1) / Math.pow( blas.sdot(r, srcFactor, 1, srcFactor, 1)*blas.sdot(r, dstFactor, 1, dstFactor, 1) ,0.5)
    val score2 = Math.sqrt( sum( srcFactor.zip(dstFactor).map(x=> (Math.pow(x._1-x._2 ,2) ) ) ) )
...
  }

分析：

 一. 源码直接用的向量內积得分排序，我测的用余弦距离效果更好。

1. 然后我在score1 把分母给加上去了，在只有三万用户推荐的时候，推荐效果直观看起来好了很多，但是当有十万以上的用户推荐的时候，产生了不少极小的向量，非常接近0向量，然后计算向量模由于float精度有限，导致分母直接返回0，score1 变成了正/负无穷，后面也就无法比较大小排序了。

2. 于是又想到用欧式距离来计算，于是就计算了score2 ，但是源码排序是从高分到低分排序截取的，欧式距离则是从近距离到远距离，此时要改源码两个类，第一个BoundedPriorityQueue类，将：

private val underlying = new JPriorityQueue[A](maxSize, ord1)

改成：

//  private val underlying = new JPriorityQueue[A](maxSize, ord.reverse) //欧式距离直接这样不行，会缺数据，有点坑
  val ord1=ord.reverse
  private val underlying = new JPriorityQueue[A](maxSize, ord1)
后面的maybeReplaceLowest(a: A)函数也有个ord替换也别晚了

第二个类TopByKeyAggregator类，将finish函数的r.toArray.sorted(ord.reverse)改成r.toArray.sorted(ord)

二. 当数据量较大的时候，在笛卡尔积中new了很多小对象，导致GC问题明显，改用广播后解决了GC问题，但是推荐量比较小的时候发现广播的性能弱与源码的笛卡尔积关联。