spark 资源配置与性能

       在spark开发过程中，会遇到给中各样的问题。主要原因是对spark机制误解导致的。

        学习spark之初，走了很多很多弯路。甚至一度对spark官方文档产生了怀疑，最终又回到spark官方文档和源码。比如，最早让我产生怀疑的是executor到底是一个进程还是一个线程。官方表示executor是一个进程，但是在正在运行作业的集群上输入（Linux命令：jps）却没法显示相应的进程，市面上有些书也在说executor是个线程。所以就对spark官网产生了怀疑。后来回想起大学时学习操作系统时，在操作系统级别能分配资源的最小单位是进程，也只有进程能够对立做资源限制。调度的最小单位才是线程。突然想到这点就释然了，因为在spark里executor可以分配资源并作资源限制。

        今天就来说一下spark的资源分配，excutor就是一个进程，换句话说一个executor就是一个Jvm进程。那么，分配的memory-excutor到底是executor的对内存大小，还是Jvm总内存大小呢？当然是总内存大小！

        在资源分配过程中，可能会认为在资源充足的情况下cpu core分配的是不是越多就会越好，计算就会越快。答案是否定的！分配过多的cpu有可能会导致内存溢出。spark官方对于内存和cpu core有一个推荐比例memory(Gb):core = 3:1。这是经过很多工程实现得出来的，在实际生产中这个比例也是比较有效的，当然可以根据具体场景在做调整，比如每个RDD分区数据比较均匀且每个分区数据量不大，可以通过提高cpu比例提高计算速度。

        那么，为什么cpu分多了会导致内存溢出？一个excutor就是一个Jvm进程，cpu个数就是一次执行task任务的个数，也是一次加载paritition的个数。在同等内存情况下当然是cpu个数越多，加载的partition个数越多，溢出的风险就会越高。但是加载的数据太少，又会导致堆内存闲置造成资源浪费。当然，在内存溢出情况下，增大分区个数也能降低溢出的风险，这是从每个任务加载的数据量的角度去考虑的。最终都是一个期望：降低一个批次加载的数据量。

        在开发过程中，可能很多人也有疑问。在同等资源量，executor的个数到底是多一点好还是少一点好。这个没有固定答案，也是根据业务场景来调整的。这个问题就是我们常说的大容器和x小容器之争。小容器好处就是，对于频繁读写的应用性能比较好。可以利用更多台节点的IO,不用因为同节点需要读取的数据太多导致数据加载花费的时间太久，其次就是当任务读取的数据块很多很不到集群的各个节点上，当executor很少是就会导致需要发生跨节点拉去的数据块会很多。最后就是由于每个executor比较小，GC的停顿时间就会相对较短。当然小容器也有缺陷，对shuffle不太友好。说完小容积，就来说说大容器。同等总资源的情况下，大容积的好处就是shuffle比较又优势。最极端的例子：比如只有一个executor,那么shuffle是数据压根不需要跨节点传输，当只有两个executor是，只需要启动一次IO就可以了，以此类推容器越小shuffle需要的时间就会越多。其次就是GC,大容器一次GC停顿时间会相对较长。其次大容器对数据倾斜有一定的抗性。