函数编程中的reduce和foldLeft / fold之间的区别（尤其是Scala和Scala API）？

为什么Scala和Spark和Scalding等框架同时具有reduce和foldLeft？那么，reduce和之间有什么区别fold？

减少vs折叠

与该主题相关的任何其他stackoverflow答案中均未明确提及的一个很大的不同之处在于，reduce应该给其赋予可交换的monoid，即既可交换又可关联的操作。这意味着操作可以并行化。

这种区别对于大数据/ MPP /分布式计算非常重要，这reduce甚至说明了其存在的全部原因。可以将集合切碎，并且reduce可以对每个块进行操作，然后可以对每个块reduce的结果进行操作-实际上，分块的级别不必深陷一个级别。我们也可以切碎每个块。这就是为什么在给定无限数量的CPU的情况下将列表中的整数相加为O（log N）的原因。

如果你只是看签名，没有理由reduce存在，因为你可以做到的一切，你可以reduce用foldLeft。的功能foldLeft大于的功能reduce。

但是您不能并行化foldLeft，因此它的运行时间始终为O（N）（即使您输入可交换的monoid）。这是因为它假定该操作不是可交换的Monoid，因此将通过一系列顺序聚合来计算累积值。

foldLeft不假定可交换性或关联性。它具有关联性，可以对集合进行分解，而可交换性则使得累加变得容易，因为顺序并不重要（因此，从哪个顺序汇总每个块中的每个结果都没有关系）。严格来说，可交换性对于并行化不是必需的，例如分布式排序算法，它只是使逻辑变得更容易，因为您不需要给块排序。

如果查看一下Spark文档，reduce它会专门说“ ...交换和关联二进制运算符”

http://spark.apache.org/docs/1.0.0/api/scala/index.html#org.apache.spark.rdd.RDD

这证明reduce不只是以下情况的特例foldLeft

scala> val intParList: ParSeq[Int] = (1 to 100000).map(_ => scala.util.Random.nextInt()).par

scala> timeMany(1000, intParList.reduce(_ + _))
Took 462.395867 milli seconds

scala> timeMany(1000, intParList.foldLeft(0)(_ + _))
Took 2589.363031 milli seconds

减少对折

现在，这里离FP /数学根更近了，并且解释起来有些棘手。Reduce正式定义为MapReduce范式的一部分，该范式处理无序集合（多集），而Fold则以递归形式正式定义（请参见目录化），因此假定集合的结构/序列。

fold在Scalding中没有方法，因为在（严格的）Map Reduce编程模型下我们无法定义，fold因为块没有排序，fold只需要关联性，而不需要可交换性。

简而言之，reduce没有累积顺序的作品，fold需要累积的顺序，正是累积的顺序需要零值，而不是存在区分它们的零值。严格来说，reduce 应该对一个空集合起作用，因为它的零值可以通过取任意值x然后求解来推导x op y = x，但这不适用于非交换运算，因为可以存在一个左，右零值，它们是不同的（即x op y != y op x）。当然，Scala不会费心找出这个零值是什么，因为这需要做一些数学运算（这可能是不可计算的），因此只抛出一个异常。

似乎（在词源学中经常是这种情况）这种原始的数学意义已经丢失，因为编程中唯一明显的区别就是签名。结果是，它reduce已成为的同义词fold，而不是保留MapReduce的原始含义。现在，这些术语通常可以互换使用，并且在大多数实现中的行为相同（忽略空集合）。我们现在将要解决的特性（例如Spark中的特性）加剧了怪异。

因此，Spark 确实有一个fold，但是组合子结果（每个分区一个）（在编写本文时）的顺序与完成任务的顺序相同-因此不确定。由于@CafeFeed为指出fold的用途runJob，其中通过阅读代码后，我意识到，它的不确定性。Spark产生一个进一步的混乱，treeReduce但没有treeFold。

结论

之间存在差异reduce和fold甚至应用于非空序列时。前者被定义为MapReduce编程范式的一部分，该范式是关于具有任意顺序的集合（http://theory.stanford.edu/~sergei/papers/soda10-mrc.pdf），其中一个应该假定运算符除了是可交换的以外关联给出确定性结果。后者是根据同构定义的，并且要求集合具有序列的概念（或像链表一样递归定义），因此不需要可交换的运算符。

在实践中，由于编程的unmathematical性质，reduce并fold趋向于在相同的行为方式，无论是正确（如在Scala中）或不正确（如在火花）。

额外：我对Spark API的看法

我的观点是，如果fold在Spark中完全删除该术语的使用，将避免混淆。至少spark在其文档中确实有注释：

这与以Scala之类的功能语言为非分布式集合实现的折叠操作有些不同。

如果我没记错的话，即使Spark API不需要它，折叠也需要f是可交换的。因为不能保证分区聚合的顺序。例如，在以下代码中，仅对第一个打印输出进行排序：

import org.apache.spark.{SparkConf, SparkContext}

object FoldExample extends App{

  val conf = new SparkConf()
    .setMaster("local[*]")
    .setAppName("Simple Application")
  implicit val sc = new SparkContext(conf)

  val range = ('a' to 'z').map(_.toString)
  val rdd = sc.parallelize(range)

  println(range.reduce(_ + _))
  println(rdd.reduce(_ + _))
  println(rdd.fold("")(_ + _))
}  

打印：

abcdefghijklmnopqrstuvwxyz

abcghituvjklmwxyzqrsdefnop

defghinopjklmqrstuvabcwxyz

foldApache Spark中的内容与fold未分发的集合中的内容不同。实际上，它需要交换函数才能产生确定性的结果：

这与以Scala之类的功能语言为非分布式集合实现的折叠操作有些不同。该折叠操作可以单独应用于分区，然后将那些结果折叠为最终结果，而不是以某些定义的顺序将折叠应用于每个元素。对于非交换函数，结果可能与应用于非分布式集合的折叠结果不同。

Mishael Rosenthal 已证明了这一点，Make42在其评论中建议了这一点。

有人建议观察到的行为与HashPartitioner何时parallelize不洗牌和不使用有关HashPartitioner。

import org.apache.spark.sql.SparkSession

/* Note: standalone (non-local) mode */
val master = "spark://...:7077"  

val spark = SparkSession.builder.master(master).getOrCreate()

/* Note: deterministic order */
val rdd = sc.parallelize(Seq("a", "b", "c", "d"), 4).sortBy(identity[String])
require(rdd.collect.sliding(2).forall { case Array(x, y) => x < y })

/* Note: all posible permutations */
require(Seq.fill(1000)(rdd.fold("")(_ + _)).toSet.size == 24)

解释：

foldRDD的结构

def fold(zeroValue: T)(op: (T, T) => T): T = withScope {
  var jobResult: T
  val cleanOp: (T, T) => T
  val foldPartition = Iterator[T] => T
  val mergeResult: (Int, T) => Unit
  sc.runJob(this, foldPartition, mergeResult)
  jobResult
}

与RDD的结构reduce相同：

def reduce(f: (T, T) => T): T = withScope {
  val cleanF: (T, T) => T
  val reducePartition: Iterator[T] => Option[T]
  var jobResult: Option[T]
  val mergeResult =  (Int, Option[T]) => Unit
  sc.runJob(this, reducePartition, mergeResult)
  jobResult.getOrElse(throw new UnsupportedOperationException("empty collection"))
}

在runJob不考虑分区顺序的情况下执行，导致需要交换功能。

foldPartition并且reducePartition在处理顺序上有效，reduceLeft并且foldLeft在上有效执行（通过继承和委派）TraversableOnce。

结论：fold在RDD上不能依赖于块的顺序，而是需要可交换性和关联性。

扩展的另一个不同之处是在Hadoop中使用组合器。

想象一下，您的操作是可交换的monoid，通过reduce将其应用于地图端，而不是将所有数据改组/排序到reducer。使用foldLeft并非如此。

pipe.groupBy('product) {
   _.reduce('price -> 'total){ (sum: Double, price: Double) => sum + price }
   // reduce is .mapReduceMap in disguise
}

pipe.groupBy('product) {
   _.foldLeft('price -> 'total)(0.0){ (sum: Double, price: Double) => sum + price }
}

在Scalding中将操作定义为monoid始终是一个好习惯。