spark&yarn&storm的资源管理分配对并发性的考量

　　在常用的计算框架中，无论是spark、storm、yarn，如何提高并发量，提高集群的整体吞吐量是需要考虑的问题，其中资源容量规划和资源申请，对APP任务的并行执行方面有比较多的影响，下面罗列一下以上计算框架在资源规划和资源申请方面的一些类比：

　　对于整个集群的处理能力来讲总是有限的，这个在很多资源管理调度框架中都有相应的总体容量的规划，每个APP或者JOB在申请资源执行时，也是需要提出多少资源的申请，集群再依照当前可用的资源，依据资源管理任务调度机制进行资源的分配和任务执行。资源的规划和申请一般都是以CPU和Core为单位。

　　对于Spark来讲，在standalone模式下，集群的整体处理能力依赖于每个节点的SPARK_WORKER_INSTANCES以及每个Instance的SPARK_WORKER_CORES、SPARK_WORKER_MEMORY，当然在配置各节点资源时需要留出足够的空间给系统使用;在APP进行资源申请(spark-submit)的时，可以以total-executor-cores指定executor使用的总的核数，以及用每个executor使用的内存executor-memory;这样集群节点从当前可用的work中划分资源给App，若不指定申请的总核数量，在没有申请最大额度的限制下，则会占用当前集群所有的剩余cores，直到App运行完成。

　　Spark是一个core运行一个task，所以增加App申请的cores可以增加task的并行执行能力，但是也要综合平衡每个task的可用内存满足需求。

　　下图是spark 应用在standalone模式下的执行流程，

　　对于Yarn来讲，集群的整体处理能力依赖于NodeManager的资源配置，NodeManager可用的核数nodemanager.cpu-vcores，以及可用的内存nodemanager.memory-mb;在yarn中是以container为单位进行资源调度的，任务的资源申请都不能超过container的限制，包括container最大内存scheduler.maxinum-allocation-mb，最小内存限制scheduler.mininum-allocation-mb

　　，最大核数限制scheduler.maxinum-allocation-vcores，最小核数限制scheduler.mininum-allocation-vcores。

　　Yarn是一种资源管理任务调度框架，在container中支持MapReduce、Spark的计算;

　　MapReduce运算，可以设置map和reduce的内存以及core的使用量， mapreduce.map.memory.mb，mapreduce.map.cpu.vcores，mapreduce.reduce.memory.mb，mapreduce.reduce.cpu.vcores。

　　Spark的yarn部署方式下，在提交App时，可以通过spark-submit声明需要的executors 数量num-executors(SPARK_EXECUTOR_INSTANCES)，以及每个executor的核数executor-cores(SPARK_EXECUTOR_CORES)和内存大小executor-memory。executor是在container中启动的进程实例，区别于MR的container资源在每个task结束后，就进行回收释放，spark中的Container的占用一直到APP运行结束后再进行回收。

　　对于Storm来讲，并行处理能力依赖于拓扑topology的Work数量(每个work都属于一个特征的topology)、executor数量、task数量，每个Supervisor可以运行多个work，每个work对应单独的端口。Executor是产生于work进程内部的线程，执行同一个component的一个或多个task，而task用于进行实际的数据处理，在Topology的生命周期中，每个组件的task数目是不会发生变化的，而executor的数目却不一定，executor数目小于等于task的数目，默认情况下，二者是相等的。可以有很多地方来设置。因此提高并发量，主要从Topology的work、executor、task数量上来考虑，来增加并发性。