Spark为什么只有在调用action时才会触发任务执行呢（附算子优化和使用示例）？

Spark算子主要划分为两类：transformation和action，并且只有action算子触发的时候才会真正执行任务。还记得之前的文章《Spark RDD详解》中提到，Spark RDD的缓存和checkpoint是懒加载操作，只有action触发的时候才会真正执行，其实不仅是Spark RDD，在Spark其他组件如SparkStreaming中也是如此，这是Spark的一个特性之一。像我们常用的算子map、flatMap、filter都是transformation算子，而collect、count、saveAsTextFile、countByKey、foreach则为action算子。

但初学Spark的人往往都会有这样的疑惑，为什么Spark任务只有在调用action算子的时候，才会真正执行呢？咱们来假设一种情况：假如Spark中transformation直接触发Spark任务！那么会产生什么结果呢？

1. 导致map执行完了要立即输出，数据也必然要落地（内存和磁盘）
2. map任务的生成、调度、执行，以及彼此之间的rpc通信等等，当牵扯到大量任务、大数据量时，会很影响性能

看到这两点是不是很容易联想到MapReduce的计算模型，MapReduce因为中间结果需要落地，导致性能相对Spark较低下，这也是MapReduce广为诟病的原因之一。所以Spark采用只有调用action算子时才会真正执行任务，这是相对于MapReduce的优化点之一。

但是每个Spark RDD中连续调用多个map类算子，Spark任务是对数据在一次循环遍历中完成还是每个map算子都进行一次循环遍历呢？
答案很确定：不需要对每个map算子都进行循环遍历。Spark会将多个map算子pipeline起来应用到RDD分区的每个数据元素上（后续将要介绍的SparkSQL中的Dataset/DataFrame也是如此）

下面说几个算子的优化，这也是面试中经常问的问题：

在我们实际的业务场景中经常会使用到根据key进行分组聚合的操作，当然熟悉Spark算子使用的都知道像reduceByKey、groupByKey、aggregateByKey、combineByKey大多都能满足需求。但是笔者在这里还是要重点说一下，因为很多人想到分组聚合往往第一个想到的算子就是groupByKey，但是groupByKey相对其他算子性能低并且处理不好的情况下，容易发生数据倾斜。所以我们能用其他算子比如reduceByKey替代groupByKey实现满足我们业务需求的，就一律不用groupByKey。当然reduceByKey在某些场景下性能会比aggregateByKey低，具体算子的替换要结合实际业务需求场景来定。

这里主要说明一下reduceByKey和groupByKey的对比，以及几个算子替代的场景示例：
1．首先这几个“ByKey”的算子会触发shullfe，这里强调一点，对于分布式任务，如果存在聚合操作的话往往都是要进行shuffle的
2．相对于reduceByKey，groupByKey没有预先聚合，而是直接将相同