Spark Listener & Spark on Yarn

目前掌握了
作业运行中的监控,4040。
运行结束的HistoryServer,18080。也可以根据Api自己开发。

作业运行中的监控也可以有API自己开发。

继承SparkListenerInterface，实现作业开始前、后等需要做的操作。
直接实现SparkListener，覆写需要的方法就可以。

override def onTaskEnd(taskEnd: SparkListenerTaskEnd): Unit = {
    val metrics = taskEnd.taskMetrics  //通过metrics可以拿到很多信息

    val taskMetricsMap = scala.collection.mutable.HashMap(
      "executorDeserializeTime" -> metrics.executorDeserializeTime, //executor的反序列化时间
      "executorDeserializeCpuTime" -> metrics.executorDeserializeCpuTime, //executor的反序列化的 cpu时间
      "executorRunTime" -> metrics.executorRunTime, //executoor的运行时间
      "resultSize" -> metrics.resultSize, //结果集大小
      "jvmGCTime" -> metrics.jvmGCTime,
      "resultSerializationTime" -> metrics.resultSerializationTime,
      "memoryBytesSpilled" -> metrics.memoryBytesSpilled,
      "diskBytesSpilled" -> metrics.diskBytesSpilled,
      "peakExecutionMemory" -> metrics.peakExecutionMemory //executor的最大内存
    )
  // ....
}

然后在SparkConf中set自定义的SparkListener监听器。

new SparkConf().set("spark.extraListeners","com.gargantua.listener.MySparkListener")

在配置文件中指定的话，对所有作业都监听。

http://gargantua:9870/jmx 可以拿到hdfs的json格式的运行信息
同理，yarn的json也可以获取http://gargantua:8123/jmx

于是可以带参数的http请求查询指定的信息
http://gargantua:9870/jmx?qry=…
可以定时调度去获取信息，再记录到DB，在由UI展示、邮件或短信电话告警

MR、Spark、Flink on Yarn 都是因为有实现了对应的ApplicationMaster才能跑作业
MRAM、SparkAM、FlinkAM

不然会报错的

export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop

Spark on Yarn 可以 client提交yarn，可以spark集群提交yarn

spark-shell 可以直接在本地启动，也可以提交jar到yarn，也可以on Yarn 启动。

spark-shell 
--master yarn 
--deploy-mode client 
--class org.apache.spark.examples.SparkPi 
/home/hadoop/app/spark-3.2.0-bin-hadoop3.2/examples/jars/spark-examples*.jar 
10

scala>

client提交yarn后有如下进程

12039 SparkSubmit        // spark-shell  driver
12231 ExecutorLauncher   // 其实就是ApplicationMaster,只为区分 cluster-mode还是 client-mode
12298 YarnCoarseGrainedExecutorBackend   // executer
12330 YarnCoarseGrainedExecutorBackend   // executer

不能再用spark-shell，spark集群只需要提交就行，没有、没法打开终端

spark-submit 
--master yarn 
--deploy-mode cluster 
--class org.apache.spark.examples.SparkPi 
/home/hadoop/app/spark-3.2.0-bin-hadoop3.2/examples/jars/spark-examples*.jar 
10

提交后有如下进程

16185 SparkSubmit
16323 ApplicationMaster
16488 YarnCoarseGrainedExecutorBackend
16539 YarnCoarseGrainedExecutorBackend

client

	driver是运行在提交的机器的 + 调度、分发作业（本机终端不能退出，不然driver和所有的executor关系就断了）
	AM: 从YARN上申请资源
	pi：在driver端是看的到日志输出的

cluster

	driver是运行在am里面的（毕竟现在集群下有多个spark，总不能让driver是运行在每个提交的机器）
	AM: 从YARN上申请资源 + 调度、分发作业
	pi：日志在终端上是看不到的，你的去container里面找

对于client模式来说，提交的机器可以是集群外的。
在这个条件下才有一个说法，少用client模式，因为driver与executer的交互网络开销会非常大。对于提交机器是属于集群内一台机器而言，cluster模式和client模式区别不大。

cluster模式下，driver与executer仍然避免不了网络交互，只不过都在一个集群内（局域网内、同机架内）。

其实区别不大，但生产还是推荐cluster模式；自测可以client，方便查日志。

ps -ef | grep [pid]
僵尸进程就把他父进程也杀掉，父进程的pid在他pid的后面。

主要是用于提交编译并打包好的Jar包到集群环境中来运行，和hadoop中的hadoop jar命令很类似，hadoop jar是提交一个MR-task,而spark-submit是提交一个spark任务。

相对于spark-shell来讲它不具有REPL(交互式的编程环境)，在运行前需要指定应用的启动类，jar包路径、参数等内容。可以设置不同的Spark所支持的集群管理和部署模式。

这个命令启动一个可给用户输入spark命令的shell，是一个REPL环境。指定master时通过spark-submit提交作业，不指定master时会启动一个SparkSubmit进程来模拟Spark运行环境。

通过查看spark-shell源码可以发现在主main中他会调用spark-submit 的类的入口。运行spark-shell提交任务后最终还是由spark-submit来完成。