Spark-shell 使用注意项记录

！！！直接杀进程的时候强烈建议提醒你自己你知道自己在做什么，为什么要这么做，不然，一个kill 命令下去一堆问题出现。

退出spark-shell请使用quit 进行退出，不要直接ctrl+z, ctrl+c 

不要无脑直接杀进程，不要无脑直接杀进程

在开发过程中会使用Spark-shell进行调试，这里记录下遇到的坑。

在开发中没养成良好的退出习惯，每次ctrl+z就直接强制退出了，却不知在Yarn的application还处于等待消息接受状态中，后面发现多个端口都被占用后，无法启动Spark-shell，看了网上描述的最简单的是端口占用原因，直接杀掉端口对应进程。首先要说明这种方式很愚蠢，很不可取。当然我在实际中确实这么做了趟了这个坑。

采用了如下命令查看spark-shell的进程

ps -ef |grep spark-shell

如我所料，果然有多个进程显示用了./bin/spark-shell，满怀期待的kill -9 进程号

再次调用spark-shell 问题依旧存在，反复找原因，最后到spark ui页面去查看自己的application状态都是挂起状态，spark-submit提交Jar包运行也是等到接收状态，大惊失色，然后又去看到通过yarn命令去看当前的yarn下的application。

yarn application -list

果然看到多个applicationId 的State显示为accepted，但是final-state居然是undifined，恩，果断采用如下命令清掉僵尸application

（之所以采用命令是因为在Spark UI 界面的kill application都已经没有任何反应了）

yarn application -kill applicationId号

继续进入，依旧不行，后面自己琢磨大概就是yarn和hdfs,spark这一套集群之间消息同步机制有问题，有些同步文件应该被锁住了，再去查看yarn 给刚启动的spark-shell分配的时候，发现一直没有给它分配内存和CPU，所以想着应该是yarn scheduler这里的资源更新有问题，导致application manager来进行轮询申领资源的时候无返回，所以果断重启了yarn,hdfs,spark，然后在次进入，成功进入。

这次事件充分说明了无脑杀进程多可怕，杀成了僵尸进程看有的解答直接暴力给出了重启服务器的操作，拜托，平常服务器哪能随便就重启，只能说以后少被误导，多了解点原理为什么还是有好处的，至少知道大概运行流程与思路。