我是靠谱客的博主 单身小蜜蜂,最近开发中收集的这篇文章主要介绍Spark Web UI 监控,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

日常铺垫

本人最终用于大数据集测试的集群中包含4个节点,每个节点是一个worker,每个worker上启动一个Executor,其中Driver也跑在master上。每个Executor可使用的核数为2,可用的内存为2g,集群中所有Executor最大可用核数为8。
conf/spark-defaults.conf 部分参数配置如下:


spark.master
spark://Master:7077
spark.executor.memory
2g
spark.executor.cores
2
spark.cores.max
8

本人把master,executor的对应参数写死在default中,这样在提交jar包运行时省去写参数的麻烦,但若你想同时在集群中跑两个或以上spark应用,不建议把参数写死。而是选择在提交jar包的时,按照需求分配executor的核数和memory数给不同的应用。若某个应用占用了所有的核和内存,剩下的应用只能等待这个程序执行完毕释放资源后才可执行。

conf/spark-env.sh 部分参数配置如下:

export SPARK_WORKER_CORES=2
export SPARK_WORDER_INSTANCES=1
export SPARK_WORKER_MEMORY=2g

遇到过的问题:

启动了四个节点,但是在处理数据的时候负载不均衡,只有两个节点的使用率很高。推测与分区数有关,测试数据集为267MB,hdfs中默认的数据分片大小为128MB,约有两个分区。推测只有两个分区能拿到数据进行计算,所以将hdfs的数据分片大小改为64MB,这样约有4个分区,与集群中的Executor数目相符。经测试证明,负载不均衡的问题得到解决。参考:分区小结

修改配置文件hdfs-site.xml,将block size设置为64MB

 <property>
<name>dfs.block.size</name>
<value>67108864</value>
说明:64M=64*1024*1024
</property>

进入正题

8080

当我们成功启动spark后,通过http://localhost:8080即可访问master的监控界面,此端口号默认是8080,若此端口不可用,也可通过修改配置文件conf/spark-env.sh进行修改

这里写图片描述
如上图所示,此页面自上而下包括:
spark版本信息,spark master 的URL(worker用来连接此master的URL)
worker的数量:4
所有worker节点中可用和在用的core(查看资源的使用情况,参考是否适合再启动一个应用等)
所有worker节点中可用和在用的memory(如上)
正在运行和已经完成的应用数量
master当前状态

workers部分
-展示集群中每个worker的位置,到当前状态,内核使用情况,内存使用情况
(通过查看内核和内存的用量情况确定是否足够运行一个新的应用)
-点击workerID进入worker的detail页面会显示与该worker更详细的信息
(理想情况下,所有worker节点使用的内核数和内存应该是相同的,如果出现使用率不同的情况,说明集群资源未平均分配,应用未最佳化运行,需停止所有应用重新启动集群)

Running/Completed Application部分
-分别展示在运行和已经运行完的应用信息,包括名称,获得的资源,开始时间,所有者,已运行时间,目前状态(RUNNING/FINISHED/结束原因)
(若state显示WAITING,则说明Spark对于应用没有足够的内存或内核,将保持等待直到有足够资源可用,有几种情况,一是直到已经在运行的一个应用完成运行,而是增加分配给spark worker的资源,三是将少应用的请求资源)
-点击ApplicationID进入detail页面会显示看到关于该应用运行时的详细信息,包括参与的worker/使用的资源数/日志等
(如果一个任务失败或抛出了异常,可以查看stderr文件来调试问题)

4040

localhost:4040(当应用在运行中的时候可以访问,一旦应用执行结束该端口关闭不可访问)
如下图,显示基本的运行时间,调度模式(FIFO为先进先出),不状态中作业的统计量,并显示正在运行/已经完成/运行失败的spark作业较为详细的信息列表,例如,Job的提交时间/运行时间/目前为止每个Job完成的Stage和Task数量等
(从运行时间项可以观察到,若某一个Job花费时间异常,可以把问题缩小到该Job下的Stage或者Task)
这里写图片描述

点击某JobID,进入detail页面显示如下信息:
该Job当前状态
活跃/延迟/已完成的Stage数量
该Job的事件时间线
[spark为该Job生成的DAG的可视化呈现]

表格部分的信息有助于定位性能问题,检查Duration列是否存在运行时间异常的Stage,Tasks表明一个Stage内的并行量(根据集群大小,太少或太多可能导致性能问题)。数据Shufflehaiku应用性能造成负面影响,所以要最小化Shuffle Read和Write数量。
这里写图片描述

DGA可视化
这里写图片描述

Stage
这里写图片描述

点击某Stage,进入detail页面显示如下信息。
Summary 部分:
若任务持续时间在任一个四分位处过高,则说明有问题。可能是分开太大,也可能是数据Shuffle的负面效应。也可以检查GC活动是否影响性能。

Executor的聚合信息部分:
可以有效找出处理缓慢的任务,检查GC时间
Locality Level(数据的区域级别):标明任务所处理的数据是缓存在内存中的(PROCESS_LOCAL),还是本地读取(NODE_LOCAL),还是来自于集群中的任意节点(ANY)。以PROCESS_LOCAL级别处理数据是极快的。
这里写图片描述

事件时间线监控,显示了每个worker节点上并行运行了多少个任务,已经增加任务完成所需的总时间
这里写图片描述

Storage页显示Spark应用缓存在内存或硬盘中的数据量,提供每一个持久化RDD的信息。(可以是以Hive表格或者是RDD的形式缓存在内存中)
Storage Level展示数据集如何缓存,以及所缓存数据的副本数量。
这里写图片描述

点击具体的RDDID,进入detail页。包括:
缓存RDD的概要信息
在不同EXecutor上的分布(每个Executor上需要的内存)
分块信息,如存储级别/位置/每个缓存RDD分块大小
这里写图片描述

Enviroment页面显示不同环境和配置变量的值:
这里写图片描述

Executor显示Spark为该应用创建的执行者的概要信息:
Storage Memory表示缓存数据所预留的和所使用的内存量(若内存小于正在尝试缓存的数据,则会出现性能问题)
Shuffle的读写都是昂贵的,如果这两个值过大,应该重构应用代码或者调整Spark参数减少Shuffling
这里写图片描述

18080

localhost:18080(spark的历史管理中心,包含所有已经运行完成的Application及其详细信息)
这里写图片描述

点击具体的APP ID 展现的页面结构与4040相同

50070

-master:50070 访问namenode的hdfs web UI监控页面
(理想情况下,Summary下的表格右边是有正常数据的而不是0)
这里写图片描述
-查看已经启动的datanode信息
这里写图片描述

-查看文件目录
这里写图片描述

参考:《Spark大数据分析》


最后

以上就是单身小蜜蜂为你收集整理的Spark Web UI 监控的全部内容,希望文章能够帮你解决Spark Web UI 监控所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(41)

评论列表共有 0 条评论

立即
投稿
返回
顶部