cache

本例中，首先计算出一个baseRDD，然后对其进行cache，后续启动三个子任务基于cache进行后续计算。

对于5分钟小数据量，采用StorageLevel.MEMORY_ONLY，而对于大数据下我们直接采用了StorageLevel.DISK_ONLY。DISK_ONLY_2相较DISK_ONLY具有2备份，cache的稳定性更高，但同时开销更大，cache除了在executor本地进行存储外，还需走网络传输至其他节点。后续我们的优化，会保证executor的稳定性，故没有必要采用DISK_ONLY_2。实时上，如果优化的不好，我们发现executor也会大面积挂掉，这时候即便DISK_ONLY_2，也是然并卵，所以保证executor的稳定性才是保证cache稳定性的关键。

cache是lazy执行的，这点很容易犯错，例如：

val raw = sc.textFile(file)
val baseRDD = raw.map(...).filter(...)
baseRDD.cache()
val threadList = new Array(
  new Thread(new SubTaskThead1(baseRDD)),
  new Thread(new SubTaskThead2(baseRDD)),
  new Thread(new SubTaskThead3(baseRDD))
)
threadList.map(_.start())
threadList.map(_.join())

这个例子在三个子线程开始并行执行的时候，baseRDD由于lazy执行，还没被cache，这时候三个线程会同时进行baseRDD的计算，cache的功能形同虚设。可以在baseRDD.cache()后增加baseRDD.count()，显式的触发cache，当然count()是一个action，本身会触发一个job。

再举一个错误的例子：

val raw = sc.textFile(file)
val pvLog = raw.filter(isPV(_))
val clLog = raw.filter(isCL(_))
val baseRDD = pvLog.union(clLog)
val baseRDD.count()

由于textFile()也是lazy执行的，故本例会进行两次相同的hdfs文件的读取，效率较差。解决办法，是对pvLog和clLog共同的父RDD进行cache。

Partition

一个stage由若干partition并行执行，partition数是一个很重要的优化点。

本例中，一天的日志由6000个小文件组成，加上后续复杂的统计操作，某个stage的parition数达到了100w。parition过多会有很多问题，比如所有task返回给driver的MapStatus都已经很大了，超过spark.driver.maxResultSize（默认1G），导致driver挂掉。虽然spark启动task的速度很快，但是每个task执行的计算量太少，有一半多的时间都在进行task序列化，造成了浪费，另外shuffle过程的网络消耗也会增加。

对于reduceByKey()，如果不加参数，生成的rdd与父rdd的parition数相同，否则与参数相同。还可以使用coalesce()和repartition()降低parition数。例如，本例中由于有6000个小文件，导致baseRDD有6000个parition，可以使用coalesce()降低parition数，这样parition数会减少，每个task会读取多个小文件。

1
2
3

val raw = sc.textFile(file).coalesce(300)
val baseRDD = raw.map(...).filter(...)
baseRDD.cache()

那么对于每个stage设置多大的partition数合适那？当然不同的程度的复杂度不同，这个数值需要不断进行调试，本例中经测试保证每个parition的输入数据量在1G以内即可，如果parition数过少，每个parition读入的数据量变大，会增加内存的压力。例如，我们的某一个stage的ShuffleRead达到了3T，我设置parition数为6000，平均每个parition读取500M数据。

1 2	val bigRDD = ... bigRDD.coalesce(6000).reduceBy(...)

最后，一般我们的原始日志很大，但是计算结果很小，在saveAsTextFile前，可以减少结果rdd的parition数目，这样会计算hdfs上的结果文件数，降低小文件数会降低hdfs namenode的压力，也会减少最后我们收集结果文件的时间。

1 2	val resultRDD = ... resultRDD.repartition(1).saveAsTextFile(output)

这里使用repartition()不使用coalesce()，是为了不降低resultRDD计算的并发量，通过再做一次shuffle将结果进行汇总。

repartition和coalesce的区别

1 2	repartition(numPartitions:Int):RDD[T] coalesce(numPartitions:Int，shuffle:Boolean=false):RDD[T]

他们两个都是RDD的分区进行重新划分，repartition只是coalesce接口中shuffle为true的简易实现，（假设RDD有N个分区，需要重新划分成M个分区）

1）、N<M。一般情况下N个分区有数据分布不均匀的状况，利用HashPartitioner函数将数据重新分区为M个，这时需要将shuffle设置为true。

2）如果N>M并且N和M相差不多，(假如N是1000，M是100)那么就可以将N个分区中的若干个分区合并成一个新的分区，最终合并为M个分区，这时可以将shuff设置为false，在shuffl为false的情况下，如果M>N时，coalesce为无效的，不进行shuffle过程，父RDD和子RDD之间是窄依赖关系。

3）如果N>M并且两者相差悬殊，这时如果将shuffle设置为false，父子ＲＤＤ是窄依赖关系，他们同处在一个Ｓｔａｇｅ中，就可能造成spark程序的并行度不够，从而影响性能，如果在M为1的时候，为了使coalesce之前的操作有更好的并行度，可以讲shuffle设置为true。

总之：如果shuff为false时，如果传入的参数大于现有的分区数目，RDD的分区数不变，也就是说不经过shuffle，是无法将RDDde分区数变多的。

http://www.cnblogs.com/jiangxiaoxian/p/9539760.html