摘要：Spark Streaming，yarn，Streaming Statistics，Active Batches，Completed Batches
总结一下Spark Streaming Application在yarn上的WebUI的查看和使用
查看Application
打开首页，可以直接看到所有在yarn集群上运行的任务，使用右上角search可以定位到想查看的应用，application的name和SparkConf的上下文的setAppName保持一致。每一个应用记录了ID，user，应用名称，应用类型（Spark应用就是Spark），开始时间，结束时间，状态（ACCEPTED,RUNNING,FINISHED,FAILED,KILLED等），最终状态，跟踪UI地址等。
查看Streaming
使用yarn调度的application，application信息通过application WebUI暴露出来。对于spark而言，application WebUI是通过driver暴露出来的，而driver跑在ApplicationMaster上，所以直接打开首页application的ApplicationMaster链接即可。也可以点击进入application，在进入页点开ApplicationMaster。
查看batch
对于spark streaming而言，每个application是按照一个一个batch执行的，每一个batch可能有多个job，每个job也存在多个stage，所以最顶层的应该是batch。 通过点击streaming标签可以查看所有batch列表。
batch列表分成两块：
- Active：正在执行或者排队执行的batch
- Complete：已经完成的batch
由此可见当前application的Batch间隔是2s，从下到上时间越来越近，其中Active的最下面一个batch是正在运行的的batch，有12条数据，延迟10s，如果当前没有要处理的数据则Active为空。Active会实时记录和当前时间同步的每隔2s辣的数据数。
查看job
从batch列表中，选择一个batch打开，可以看到batch的详情，可以看到此batch分成了2个job。
两个job都是
foreachRDD输出操作，和代码中两个foreachRDD的行数一致，同时还记录了当前batch的数据来源于Kafka10个分区每隔分区的offset范围，10个分区的offset的差值相加等于整个batch的数据165条。
查看stage
点开jobid可以查看stage
可见这个stage是从Kafka的
DStream先做mapPartition转化为新RDD，在做forEachRDD操作，forEachRDD操作内部是rdd map成HBase接受的形式写入Hbase。
查看task
点击stage列表的下面一个链接可以查看task信息
可以看到有10个task，相当于有10个partition，也和Kafka的partition数量一致。
查看Streaming Statistics
总览
Running batches of 2 seconds for 1 day 20 hours 48 minutes since 2020/11/11 19:44:47 (80451 completed batches, 416502 records)
-
2 seconds: batch间隔2s -
1 day 20 hours 48 minutes: streaming application已经运行了1 day 20 hours 48 minutes -
since 2020/11/11 19:44:47: application从2020/11/11 19:44:47开始运行 -
80451 completed batches: 已经完成了80451 batches，每隔2秒增长一个batch，无论这个batch是否由数据 -
416502 records:已经处理完成的数据和正在处理的数据总计416502条
（1）completed batches * batch time + delay time = application time, 80451 * 2 / 60 + 7.21(当下batch延迟) + 执行时间(当下batch执行时间，忽略) = (1.0 * 80451 * 2 / 60 + 7.21) / 60 = 44.82（小时）
1 day 20 hours 48 minutes = 24 + 20 + 48 / 60 = 44.8（小时）
（2）416502 records 代表所有complete batches的数据和最下面一个Active batches的总数据量
详情图
详情图横轴分为 Input Rate， Scheduling Delay， Processing Time， Total Delay，分别是数据输入速率，延迟时间，处理时间，总延迟，纵轴分为Timeines，Histgrams，分别代表最近的时间线和数据分布直方图。其中Timeines为Last 1217 batches, 217 active, 1000 completed和下面的Active Batches和Completed Batches的行数一致，表明在这个最近时间段一共提交了1217个batches，其中1000已经完成，217还未完成，1个正在运行，216个在排队。
Input Rate（Avg 2.32 records/sec）
反应Streaming输入数据的速率，单位秒，每秒的平均输入数据量，如果batch time是2秒，则为这个batch的数据量除以2。显示最近一段时间的情况，从零点（15:53:10）到当下点（16:33:42）的数据输入情况，鼠标悬停在右边的直方图，显示1004 batches （82.5%） between 0.0 and 3.2 records/sec ，说明82.5%的batch都在每秒0～3.2条数据的水平，大概每个batch6.5条数据。在最近一段时间内平均每秒2.32条输入数据。
Scheduling Delay （调度延迟 Avg 7 minutes 24 seconds）
延迟由两方面造成，一方面是数据积压导致的等待延迟，一方面是数据处理需要的时间造成延迟。Scheduling Delay是调度延迟，即当下的Batch从提交submit开始（被DStream拉到）到这个Batch中第一个job开始运行所需要的时间。
横坐标代表batch time，显示每隔batch time 2秒即每个batch的延迟，在16:12:14这个对应的batch，真正开始处理的时间比这个batch被提交的时间点晚了9.7minutes。
横坐标和Input Rate的横坐标对应，Input Rate显示该Batch的输入，Scheduling Delay显示该Batch的处理，如果Scheduling Delay的时间线比Input Rate的时间线短，说明残缺的Batch已经提交到Active Batches，但是还没有开始处理在积压，两条时间线的差也就是当前Batch的延迟时间，也就是说16:26:30的Batch刚开始调度运行，但是当下时间点和Batch已经走到了16::33，延迟7.21minutes。
从横轴来看是有两条时间线，其中代表Spark Streaming开始处理Batch的时间线在追赶提交Batch的时间线，两个时间线的差映射到纵轴上，因此Scheduling Delay的
时间线长度和延迟时间呈对应关系，时间线越长越接近Input Rate，则延迟越低，时间线越短越远离Input Rate，延迟越高。一个健康的Scheduling Delay 时间线，在刚启动时由于存在数据挤压需要处理延迟较高，后续挤压的数据减少，慢慢追上呈现出向右下降最后和Input Rate重合接近的形态。
Processing Time （Avg 2seconds 336ms）
代表平均每隔批次处理时间是2seconds 336ms，和Scheduling Delay呈正向相关关系，前一个Batch处理时间长，则下一Batch延迟时间高，总体趋势来看，处理时间高，对应延迟也高，延迟线上升，处理时间低，延迟线向右下方下降。
16:04:28的延迟相比于16:04:26的延迟上升了2分钟，由于16:04:26的处理时间达到一个高点，由此可见Batch的处理时间会直接影响下一个Batch的延迟的时间，数据积压的越多，Batch的数据量越多处理时间越长，后续延迟越高。
Total Delay （Avg 7minutes 26 seconds）
总延迟时间是调度延迟时间+数据处理延迟时间，是这批数据处理好和真实期望的时间差，即数据一发送出去就处理好入库，其中因为数据等待和处理等待造成延迟。Total Delay的图也是Scheduling Delay图和Processing Time图相加的结果，没有追上Input Rate的部分表示后续的Batch已提交但是在等待没有消费。
