JAVA高级面试进阶训练营视频教程

admin

目录

• 1.数据倾斜
• 2.TopN
• 3.Join优化
  • 预排序的join
  • cross join
  • 考虑Join顺序
• 4.根据HashMap、DF等数据集进行filter
• 5.Join去掉重复的列
• 6.展开NestedDF
• 7.计算session/组内时间差
• 8.用flatMap替代map + filter
• 9.分层抽样
• 10.SQL与DF API
• 11.Shuffle后的分区
• 12.多维分析的优化

1.数据倾斜

来源：读取数据之后，包括从数据源读取和shuffle后读取

后果：大部分task和小部分task完成时间相差很大、OOM（也有可能时异常数据的问题，需要完善代码）。

分析：用sample + countBykey -> 除以count判断key的分布情况。

解决方法：

1. 采用map-side聚合的算子
2. 提高并行度repartition
3. 先估计分布，确定哪些key导致倾斜，如果单个key数据不是太大，可以自定义partition为其分区；如果单个key数据很大，就多key进行改造。
4. join类倾斜：
   • 过滤掉业务无关null再join
   • 其中一个表小时，广播join
   • 倾斜数据分离：分离出倾斜部分的表，这个表通常不大，此时再广播join
   • 如果单个key过大，那只能对该key进行改造了，即为key添加一个随机后序，如0、1、2中的一个，而另一个表则要扩大3倍，每条数据的key分别加上0、1、2的后缀（为保证所有key都被分配0后缀，从而另一个表没有足够的数据join）。这里可以自定义一些UDF来实现对数据分布的估计和改造key中n，即打散程度，的选择。
5. 数据源：尽量用可分割文件保存数据、repartition

2.TopN

TopN问题可分为4种

• 已有可比较数据的总体TopN。例如从一个班的语文成绩表中找前5名的学生，只是这个表的数据在不同的节点上。
  • DF转pairRDD后用takeOrdered()。优点：不需要全排；缺点：结果为聚合到Driver的Array，所以不适合N较大的情况。
  • DF -> sort -> rdd -> zipWithIndex -> filter(index < n) 。优点：适合N较大的情况，结果仍然是分布式的；缺点：全排，N较小时比上面慢
  • DF的sort后take。优点：简单；缺点：全排，N较大时很慢，甚至会OOM（take会将结果都shuffle到一个partition中）
• 已有可比较数据分组TopN。例如从两个班的语文成绩表中找各班前5名的学生。
  • Aggragator。优点：快；缺点：较复杂
  • window function。优点：简单，适合N较大或者数据量较小；缺点：数据量大时稍慢（window function并不进行map-side聚合，所以shuffle量较大）
• 未有可比较数据，需要分组聚合后才能比较的总体TopN。例如一个班每名学生各科成绩都在一个表上，求总分前5名的学生。
  • DF.groupBy().agg()然后接上面的“总体TopN”
• 未有可比较数据，需要分组聚合后才能比较的分组TopN。例如两个班每名学生各科成绩都在一个表上，求各班总分前5名的学生。
  • DF.groupBy().agg()然后使用windowFunction。因为经过前面的groupBy的shuffle后，数据已经有了partitioner。所以此处的windowfunc操作并不会shuffle

// Aggragator例子
class TopNAggregator[K1: TypeTag, K2: TypeTag, V: TypeTag](num: Int, ord: Ordering[(K2, V)])
  extends Aggregator[(K1, K2, V), mutable.PriorityQueue[(K2, V)], Array[(K2, V)]] {

  override def zero: mutable.PriorityQueue[(K2, V)] = new mutable.PriorityQueue[(K2, V)]()(ord)

  override def reduce(q: mutable.PriorityQueue[(K2, V)],
                       a: (K1, K2, V)): mutable.PriorityQueue[(K2, V)] = {
    if (q.size < num) {
      q += ((a._2, a._3))
    } else {
      q += ord.min((a._2, a._3), q.dequeue)
    }
  }

  override def merge(q1: mutable.PriorityQueue[(K2, V)],
                      q2: mutable.PriorityQueue[(K2, V)]): mutable.PriorityQueue[(K2, V)] = {
    q1 ++= q2
    while (q1.length > num) {
      q1.dequeue()
    }
    q1
  }

  override def finish(r: mutable.PriorityQueue[(K2, V)]): Array[(K2, V)] = {
    r.toArray.sorted(ord.reverse)
  }

  override def bufferEncoder: Encoder[mutable.PriorityQueue[(K2, V)]] = {
    Encoders.kryo[mutable.PriorityQueue[(K2, V)]]
  }

  override def outputEncoder: Encoder[Array[(K2, V)]] = ExpressionEncoder[Array[(K2, V)]]()
}

// 使用
val topNAggregator = new TopNAggregator[Int, Int, Float](10, Ordering.by(-_._2))
df.groupByKey()
  .agg(topNAggregator.toColumn)

3.Join优化

预排序的join

针对SortMergeJoinExec，在mapper端提前sort。原代码在Reducer端进行排序，但reducer端的数据不及mapper端均匀，所以排序工作量不一，会导致尾部延迟放大。Map阶段会按照key的哈希值对数据进行重分区并按key排序。Reducer只需对来自不同Mapper的数据进行归并排序。这种机制相当于把Reducer排序的任务分流给Mapper。而由于Mapper的数据量往往是比较均匀的，所以排序的性能会优于Reducer。

待考证：如果直接处理RDD，对两个需要join的RDD调用 repartitionAndSortWithinPartitions 然后join

cross join

当每条数据都需要和其余的每条数据进行计算时，例如计算相似度矩阵，下面的方法进行crossjoin能够大大减小其中间结果。实验时直接crossjoin能产生3G以上的数据，应用此方法则只有几十M。

val ready2Crossjoin = movieFeatures.as[(Int, Array[Float])]
  .mapPartitions(_.grouped(4096))

    implicit val ordering = new Ordering[(Int, Float)] {
      def compare(x: (Int, Float), y: (Int, Float)): Int = {
        val compare2 = x._2.compareTo(y._2)
        if (compare2 != 0) return -compare2
        0
      }
    }

val ratings = ready2Crossjoin.crossJoin(ready2Crossjoin)
  .as[(Seq[(Int, Array[Float])], Seq[(Int, Array[Float])])]
  .flatMap {
    case (mf1Iter, mf2Iter) =>
      val m1 = mf1Iter.size
      val m2 = math.min(mf2Iter.size, 100)
      var i = 0
      val output = new Array[(Int, Int, Float)](m1 * m2)
      val pq = mutable.PriorityQueue[(Int, Float)]()
      val vectorOp = new F2jBLAS
      mf1Iter.foreach { case (m1Id, mf1Factor) =>
        mf2Iter.foreach { case (m2Id, mf2Factor) =>
          if (m1Id == m2Id) {
            // do nothing
          } else {
            val simScore = consinSim(ALSRank, vectorOp, mf1Factor, mf2Factor)
            if (pq.length < m2) {
              pq.enqueue((m2Id, simScore))
            } else {
              val temp = pq.dequeue()
              pq += (if (temp._2 > simScore) temp else (m2Id, simScore))
            }
          }
        }
        pq.foreach { case (mf2Id, score) =>
          output(i) = (m1Id, mf2Id, score)
          i += 1
        }
        pq.clear()
      }
      output.toSeq
  }

private def consinSim(rank: Int, operator: F2jBLAS, movie1: Array[Float], movie2: Array[Float]): Float = {
    operator.sdot(rank, movie1,1, movie2, 1) / operator.snrm2(rank, movie1,1) * operator.snrm2(rank, movie2,1)
}

考虑Join顺序

Spark SQL的CBO尚未成熟，不能对SQL中的join的顺序做智能调整。顺序的确定需要对数据表的分布有所了解，从而推断某些顺序能够产生更少的中间数据，进而提高效率。

4.根据HashMap、DF等数据集进行filter

在HashMap、DF等数据集较小的情况下：

• HashMap：广播map，然后根据contain来filter。适合数据集较小的情况。

• DF：提取相应的列后，然后用left_anti。适合比上面数据集稍大的情况。

当数据集很大时，同样利用上面DF的方法，但去掉broadcast，然Spark自行决定如何join。

// HashMap filter
val BCMap = sc.broadcast(mapForFilter)
val filteredDF = df.filter($"col_name" isin (BCMap.value: _*))

// DF filter
val DFForFilter = df1.select("id")
val filteredDF = df0.join(broadcast(filteredDF), Seq("id"), "left_anti"))

5.Join去掉重复的列

val df = left.join(right, Seq("name"))

6.展开NestedDF

+---+-----------+
| _1|         _2|
+---+-----------+
|  1|[2, [3, 4]]|
+---+-----------+

+---+-----+--------+--------+
| _1|_2._1|_2._2._1|_2._2._2|
+---+-----+--------+--------+
|  1|    2|       3|       4|
+---+-----+--------+--------+

implicit class DataFrameFlattener(df: DataFrame) {
  def flattenSchema: DataFrame = {
    df.select(flatten(Nil, df.schema): _*)
  }

  protected def flatten(path: Seq[String], schema: DataType): Seq[Column] = schema match {
    case s: StructType => s.fields.flatMap(f => flatten(path :+ f.name, f.dataType))
    case other => col(path.map(n => s"`$n`").mkString(".")).as(path.mkString(".")) :: Nil
  }
}

veryNestedDF.flattenSchema.show()

7.计算session/组内时间差

val timeFmt = "yyyy-MM-dd HH:mm:ss"
val sessionid2ActionsRDD2 = UserVisitActionDF
  .withColumn("action_time", unix_timestamp($"action_time", timeFmt))
  .groupBy("session_id")
  .agg(min("action_time") as "start",
    max("action_time") as "end",
  .withColumn("visitLength", $"start" - $"end")

8.用flatMap替代map + filter

df.flatMap(if (filter_condition) Some(result) else None)

9.分层抽样

// 各种类型抽取10%
val fractions = HashMap(
  TYPE1 -> 0.1,
  TYPE2 -> 0.1,
  TYPE3 -> 0.1
)
val randomSeed = 2L
df.stat.sampleBy("col_name", fractions, randomSeed)

// 如果col_name的数据种类未知，用下面方式得出fractions
df.select("time_period")
  .distinct
  .map(x=> (x, 0.1))
  .collectAsMap

10.SQL与DF API

SQL作为声明式语言，即只需要指定所需数据的模式就能得到结果。这种语言的编程思路容易让人忽略代码的执行顺序，从而写出一些执行效率低的代码。尽管Spark有Optimizer优化，但尚未完全成熟，部分SQL语句无法实现filter、aggregation等下推。

DF API是一种函数式的语言，能让编程者注意到执行顺序，减小写出低效代码的可能。

11.Shuffle后的分区

使用DF时，开启自动分区。

如果适用RDD，则有些shuffle是可以输入partitioner参数的，这就可以控制shuffle后的分区数，一些情况还能避免shuffle。如下面代码，rdd2执行reduceByKey的shuffle时使用rdd1的partitioner，那么之后的rdd3和rdd1的join就不需要shuffle了。

val rdd1Partitioner = rdd1.partitioner match {
  case Some(p) => p
  case None => new HashPartitioner(rdd1.partitions.length)
}
val rdd3 = rdd2.reduceByKey(rdd1Partitioner, (x, y) => if (x > y) x else y)
rdd3.join(rdd1)

12.多维分析的优化

多维分析，如rollup、cube等的算子，在Spark内置的是Expand方式，根据选用的算子一次性开辟足够的内存。如果实现Union方式的二次开发，即读取一次计算一个维度的结果，然后不断union这些结果，能在某些情况提升效率。

总体来说，Expand方式适合维度小的多维分析，Union方式适合维度大的多维分析。这是因为Expand方式读取数据的次数只有一次，但数据会膨胀2n倍，而Union方式会读取数据2n次。