A-Deeper-Understanding-of-Spark-Internals（Spark内核深入理解）

这篇文章是对Spark Submit 2014会议上Aaron Davidson做的报告的PPT内容的整理，报告主要讲了Spark中对一个统计各个字母开头的名字的个数的代码做的优化。

对此PPT做了下简单整理，加入一些自己的理解。

 

Goal: Understanding how Spark runs, focus on performance

• Major core components:

– Execution Model

– The Shuffle

– Caching

 

 

Why understand internals?

Goal: Find number of distinct names per “first letter”

sc.textFile(“hdfs:/names”)

.map(name => (name.charAt(0), name))

.groupByKey()

.mapValues(names => names.toSet.size)

.collect()

 

RDD中元素转换过程

 

Spark Execution Model

1. Create DAG of RDDs to represent computation

2. Create logical execution plan for DAG

3. Schedule and execute individual tasks

 

在一本书上对要进行shuffle的原因的解释我感觉很有道理：之所以需要shuffle，还是因为具有某种共同特征的一类数据需要最终汇聚到一个计算节点上进行计算。

 

另外之前有一个误区是看到文章中提到的Spark基于内存计算，就认为Spark作计算的时候真的只是纯内存计算，然而现在发现自己真是幼稚的可以，道路阻且长啊。通过阅读相关书籍并结合本ppt，可以知道，在Spark 0.8以后，Shuffle Write会将数据持久化到硬盘，也就是shuffle过程依然是要读写硬盘的，存在性能瓶颈，然后自己现在有点搞不清Spark和Hadoop的区别了。

 

What went wrong?

• Too few partitions to get good concurrency

• Large per-key groupBy()

• Shipped all data across the cluster

 

Common issue checklist

1. Ensure enough partitions for concurrency

2. Minimize memory consumption (esp. of sorting and large keys in groupBys)

3. Minimize amount of data shuffled

4. Know the standard library

1 & 2 are about tuning number of partitions!

 

Importance of Partition Tuning

• Main issue: too few partitions

– Less concurrency

– More susceptible to data skew

– Increased memory pressure for groupBy,reduceByKey, sortByKey, etc.

• Secondary issue: too many partitions

• Need “reasonable number” of partitions

– Commonly between 100 and 10,000 partitions

– Lower bound: At least ~2x number of cores in cluster

– Upper bound: Ensure tasks take at least 100m

 

Memory Problems

• Symptoms:

– Inexplicably bad performance

– Inexplicable executor/machine failures"

(can indicate too many shuffle files too)

• Diagnosis:

– Set spark.executor.extraJavaOptions to include

• -XX:+PrintGCDetails

• -XX:+HeapDumpOnOutOfMemoryError

– Check dmesg for oom-killer logs

• Resolution:

– Increase spark.executor.memory

– Increase number of partitions

– Re-evaluate program structure (!)

 

了解了我们的程序存在什么问题，以及Spark中出现问题的诊断方法及部分解决方案，我们可以对之前的程序作出修改。

 

下面是原始程序代码

 

下面是修改后的代码：

前面有提到对shuffle的优化，但是目前对shuffle的具体过程还不是很了解，PPT也没有详细解释哪一步是对shuffle的优化，通过另一篇文章中的内容，初步判断是将groupByKey改为reduceByKey，此步中含有对shuffle的优化。