spark任务提交产生的问题，以及livy解决问题

spark任务提交
spark目前提供python shell和scala shell两种交互式命令行运行Python Shell ./bin/pyspark
运行Scala Shell./bin/spark-shell
比如用户使用spark-shell或是pyspark脚本启动Spark应用程序，伴随应用程序启动的同时Spark会在当前终端启动REPL（Read–Eval–Print Loop）来接收用户的代码输入，并将其编译成Spark作业提交到集群上去执行
批处理：一种是使用spark自带的spark-submit工具提交示例如下：./spark-submit –class com.learn.spark.SimpleApp –master yarn –deploy-mode client –driver-memory 2g –executor-memory 2g –executor-cores 3 ../spark-demo.jar另一种是以javaAPI的方式进行提交，spark提供了以sparkLauncher作为唯一入口的API来实现官网示例： http://spark.apache.org/docs/latest/api/java/index.html?org/apache/spark/launcher/package-summary.html官网的样例不好使，这个网页的demohttps://www.cnblogs.com/lyy-blog/p/8522616.htmlhttps://www.cnblogs.com/lyy-blog/p/8522616.html

造成的问题：两种处理交互方式虽然看起来完全不一样，但是都需要用户登录到Gateway节点上通过脚本启动Spark进程。这样的方式会有什么问题吗？
1. 首先将资源的使用和故障发生的可能性集中到了这些Gateway节点。由于所有的Spark进程都是在Gateway节点上启动的，这势必会增加Gateway节点的资源使用负担和故障发生的可能性，同时Gateway节点的故障会带来单点问题，造成Spark程序的失败。
2. 其次难以管理、审计以及与已有的权限管理工具的集成。由于Spark采用脚本的方式启动应用程序，因此相比于Web方式少了许多管理、审计的便利性，同时也难以与已有的工具结合，如Apache Knox。
3. 同时也将Gateway节点上的部署细节以及配置不可避免地暴露给了登陆用户。

LIVYLivy是一个基于Spark的开源REST服务，它能够通过REST的方式将代码片段或是序列化的二进制代码提交到Spark集群中去执行。它提供了以下这些基本功能：
1. 提交Scala、Python或是R代码片段到远端的Spark集群上执行；
2. 提交Java、Scala、Python所编写的Spark作业到远端的Spark集群上执行；
3. 提交批处理应用在集群中运行。

基本架构：