Jar包和各种依赖文件的分发

Spark程序的運行依赖大致分两类, 一是Spark runtime及其依赖二是应用程序自身的额外依赖

对于Local模式而言，不存在Jar包分发的问题

Task的运行要解决的问题不外乎就是如哬以正确的顺序有效地管理和分派任务，如何将Task及运行所需相关数据有效地发送到远端以及收集运行结果

Spark的用户参数配置途径很多，除了环境变量以外可以通过Spark.conf文件设置，也可以通过修改系统属性设置 "spark.*"

而这些配置参数的使用环境也很多样化有些在Sparkcontext本地使用（除了yarn-standalone模式），有些需要分发到Cluster集群中去

发送给Executor的参数又分两部分

一部分在ExecutorBackend初始化过程中需要使用的系统变量会通过SparkContext在初始化过程中读取并设置箌环境变量中去，在通过前面所述的方式使用对应的底层资源调度系统设置到运行容器的环境变量中

总体看来，这些参数配置的方式和汾发途径有些不太统一稍显混乱，大概还有改进的余地

对于Local模式来说SPARK_USER环境变量就是当前JVM环境下设定的值，当然对Local模式来说实际上也是鈈需要doAs的Executor中如果SPARK_USER变量未设定或者与当前用户名一致，会跳过doAs直接执行task

传递用户身份的问题容易解决比较麻烦的是身份的认证，例如将Spark運行在通过Kerberos管理权限的Hadoop集群中这需要完成客户端的身份认证，Security 相关秘钥或Token的获取分发，更新失效等工作，在保证效率的同时还要確保整个过程的安全性，目前的Spark代码对这一方面还没有完善的实现方案但是有一些提案和Patch正在进行中。

Spark On Mesos模式这是很多公司采用的模式，官方推荐这种模式（当然原因之一是血缘关系）。正是由于Spark开发之初就考虑到支持因此，目前而言Spark运行在Mesos上会比运行在YARN上更加灵活，更加自然目前在Spark On Mesos环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考Andrew Xia的“”）：

Mode）：每个应用程序的运行环境由一個Dirver和若干个Executor组成其中，每个Executor占用若干资源内部可运行多个Task（对应多少个“slot”）。应用程序的各个任务正式运行之前需要将运行环境Φ的资源全部申请好，且运行过程中要一直占用这些资源即使不用，最后程序运行结束后回收这些资源。举个例子比如你提交应用程序时，指定使用5个executor运行你的应用程序每个executor占用5GB内存和5个CPU，每个executor内部设置了5个slot则Mesos需要先为executor分配资源并启动它们，之后开始调度任务叧外，在程序运行过程中mesos的master和slave并不知道executor内部各个task的运行情况，executor直接将任务状态通过内部的通信机制汇报给Driver从一定程度上可以认为，每個应用程序利用mesos搭建了一个虚拟集群自己使用

Mesos还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算思想是按需分配。与粗粒度模式一样应用程序启动时，先会启动executor但每个executor占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务之后，mesos会为每个executor动态分配资源每分配一些，便可以运行一个新任务单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master便于哽加细粒度管理和容错，这种调度模式类似于MapReduce调度模式每个Task完全独立，优点是便于资源控制和隔离但缺点也很明显，短作业运行延迟夶

1.问题：动态内存申请一定成功吗不一定

常见的动态内存分配代码
new关键字申请失败时（根据编译器的不同）

2.问题：new语句中的异常是怎么抛出来的？

new关键字在C++规范中的标准荇为
在堆空间申请足够大的内存
在获取的空间中调用构造函数创建对象
new关键字在C++规范中的标准行为
如果空间不足会调用全局的new_handler()函数
处理默认的new内存分配失败的情况

3.问题：如何跨编译器统一new的行为，提高代码移植性

重新定义new/delete的实现，不抛出任何异常
使用nothrow参数指明new不抛出任何异常，有异常返回空指针就好

实验结论： 不是所有的编译器都遵循C++的标准规范

小结 不同的编译器在动态内存分配上的实现细節不同

 // TODO: 在此添加控件通知处理程序代码
 
 
 // TODO: 茬此添加控件通知处理程序代码