如何使用X-Pack Spark的YarnUI、SparkUI、Spark日志、任务运行状况的分析

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 概述 X-Pack Spark目前是通过Yarn管理资源,在提交Spark 任务后我们经常需要知道任务的运行状况,例如在哪里看日志、怎么查看每个Executor的运行状态、每个task的运行状态,性能瓶颈点在哪里等信息。

概述

X-Pack Spark目前是通过Yarn管理资源。在提交Spark 任务后我们经常需要知道任务的运行状况,例如任务失败了在哪里看日志、怎么查看每个Executor的运行状态、每个task的运行状态,性能瓶颈点在哪里等信息。
本文主要介绍如何使用X-Pack Spark的Yarn UI 和Spark Job UI来获取上述的信息。

Yarn 基础知识介绍

Yarn 是hadoop体系中的一个资源管理和调度的组件。网上搜索Spark on Yarn有很多学习资料,这里只做简单入门级介绍:Spark作业的运行是向Yarn提交一个任务,Yarn拿到任务后分配、调度资源,然后调研Spark集群跑任务。过程如下图所示:
image
关于Yarn的官网资料可参考:Apache Hadoop Yarn

X-Pack Spark 作业管理链接介绍

X-Pack Spark提供了作业管理,可以提交Spark任务(后台逻辑是提交到Yarn,Yarn再调度Spark集群)。任务运行的状态有如下几个链接:
Snip20191022_2
如上图有四个链接:日志,Spark UI,Yarn UI,详情,停止。

  1. 日志
    这里的日志点进去是控制台提交任务的日志,对应后台Livy的日志。主要显示Livy 与 Spark交换的日志。
  2. Spark UI
    Spark UI是Spark job 运行的详细信息,下面会详细介绍。
  3. Yarn UI
    Yarn UI 点击进去是Yarn的管理界面,下面会详细介绍。
  4. 详情
    任务提交的参数详情
  5. 停止
    点击可以停止此次任务。

常用的就是Spark UI 和 Yarn UI, 通过Yarn UI 和 Spark UI 可以查看Spark 运行的日志,包括Driver的日志和Executor的日志。具体的使用方法下面详情介绍。

Yarn UI的介绍

Yarn UI入口

X-Pack Yarn UI入口有两个。

1、从X-Pack Spark集群明细界面入口。如下图,点击“YARN”,进入Yarn UI。

注意:请先阅读“UI访问说明”
Snip20190619_24

2、从“作业管理”中每个作业的运行结果状态显示栏入口。如下图:

注意:请先阅读上图的“UI访问说明”
Snip20190619_27

Yarn UI功能介绍

进入YarnUI后可以看到如下的界面:
Snip20190621_30
界面主要分三个区域。区域1:导航栏;区域2:集群的统计信息;区域3:Spark任务的运行状态区域。
下面分别介绍这3个区域。

区域1:导航栏,点击不同的链接右边的区域会刷新。

这里主要介绍“Applications”。
Applications:所有提交的Spark任务列表。例如通过“作业管理”、“工作流”、“交互式查询”提交的任务都会在这里显示。
Applications-RUNNING:正在运行的Spark任务。点击后会显示任务列表中“State”是“RUNNING”的任务列表。例如下图:
Snip20190622_34
Applications-FINISHED:运行结束的Spark任务。点击后会显示任务列表中“State”是“FINISHED”的任务列表。
Applications-FAILED:运行失败的Spark任务。点击后会显示任务列表中“State”是“FAILED”的任务列表。

区域2:集群的统计信息,主要显示集群的统计信息。

_
常用信息说明如下:

名称 说明
Memory Total 集群总可用内存。
Memory Used 集群已经使用的内存。
VCores Total 集群总可用的虚拟cpu core个数。提交spark任务指定的“--driver-cores”和“--executor-cores”使用的数据就是对应这里的VCores
VCores Used 集群总已经使用的虚拟cpu core个数。
Active Nodes 可用的节点。节点是具有内存Memory和Vcores资源的单位,一个Nodes中会有若干Memory和Vcores。点击下面的数字会显示每个节点的Memory和Vcores的使用情况。
Decommissioned Nodes、Lost Nodes、Unhealthy Nodes 可能出现问题的Nodes。

下面看下点击“Active Nodes”下面的数字后展示的信息。
_
如上图,点击数字后显示如下信息:
_
如上图红色区域展示了“Active Nodes”的信息,例如节点状态、多少可用的内存、多少可用的VCores等。
常用信息说明如下:

名称 说明
Memory Used 节点已经使用的内存。
Memory Avail 节点可用的内存。如果Spark 任务一直不能起来,可以先到这里看看是否可用内存不足。
VCores Used 节点已使用的虚拟cpu core个数。提交spark任务指定的“--driver-cores”和“--executor-cores”使用的数据就是对应这里的VCores
VCores Avail 节点可用的Vcores。如果Spark 任务一直不能起来,可以先到这里看看是否可用Vcores不足。

区域3:Spark任务的运行状态区域,显示每个Spark任务的运行信息,例如,开始时间、结束时间、状态等信息。

_
常用信息说明如下:

名称 说明
ID 每个Spark任务都会有一个唯一标识的ID。
Name 提交Spark任务的名称。对应控制台提交命令中的“--name” 信息。
State Spark任务运行的状态,例如RUNNING/FINISHED/FAILED/SUCCEEDED等。
Tracking UI Spark UI的链接,点击ApplicationMaster可以进入Spark UI。注意:只有State为RUNING的Spark任务才能进入Spark UI。

Spark UI 介绍

Spark UI入口

Spark UI入口有两个。

1、从Yarn UI进入。

如下图,进入Yarn UI后点击“RUNNING” 查看Spark任务列表。
注意:只有State为RUNING的Spark任务才能进入Spark UI。
Snip20190622_38

2、从“作业管理”中每个作业的运行结果状态显示栏入口。如下图:

Snip20190619_27

Spark UI功能介绍

下图是Spark UI的首页,分两个区域。导航栏和信息显示栏。
Snip20190622_39

导航栏

导航栏常用信息说明:

名称 说明
Jobs 显示所有的Spark 任务的Job运行状态。
Stages 显示所有的Spark 任务的Job的Stages运行状态。
Environment Spark集群的配置信息。
Executors Spark集群的Executors状态信息。
Streaming Spark集群的Streming任务的统计信息。
SQL Spark集群的SQL运行状态信息。

下面分别介绍每个导航栏的用途。

Jobs

Jobs页面如下:
Snip20190622_40
常用信息说明:

名称 说明
Active Jobs 正在运行的Job。
Completed Jobs 已经运行结束的Job。
Duration Job运行的时间,可以查看下Job运行的性能。
Submitted Job提交的时间。
Stages: Succeeded/Total 此job对应的所有Stages的总数和运行成功的个数。
Tasks (for all stages): Succeeded/Total 此job对应的所有的stages的task总数和运行的成功的个数。“1 running”表示有1个task正在运行,正在运行的task个数表示job运行并行度,一般情况下提高task的运行个数可提高Job的执行性能。

Stages

Stages页面如下:
Snip20190622_41
Stages 页面的是展示Job的所有Stages信息的页面,Stages的详细信息比Jobs多出几个常用的信息如下,这几个信息常可用来分析Spark 任务的性能。

名称 说明
Input Stage输入的数据量。
Output Stage输出的数据量。
Shuffle Read Stage Shuffle 输入的数据量。
Shuffle Write Stage Shuffle 输出的数据量。

另外点击Stage的“Description”可以进入Stage的tasks运行明细,下图是Stage的task运行明细:
Snip20190622_42
Tasks运行明细是在调试程序、分析任务性能的常用信息。这里可以看到每个task的运行时间、GC多少、运行状态等信息。
常用信息说明:

名称 说明
Duration Task的执行时间,用于评估task的性能。
GC Time Task的GC时间。如果GC时间过长,会影响task的运行性能,这时可以增加Executor的内存:在提交命令中增加--executor-memory的值,或者减少task的并行度:在提交命令中减少--executor-cores的值
Errors Task的错误信息。如果task执行失败,部分的错误信息会显示在这里。全部的错误信息要点击“Host”一栏中的“stderr”日志。

Environment

Environment主要展示Runtime Information、Spark Properties、System Properties、Classpath Entries。这里不做详细介绍。

Executors

Executors页面如下:
Snip20190622_44

常用信息说明:

名称 说明
Summary 显示Executor的总体运行状态。Active、Dead的个数
Logs Driver日志 和 Executor 日志的入口,点击可以查看对应的stdout和stderr日志。stdout:代码中使用print命令打出的信息会显示在这个日志中。stderr:系统产出的日志信息会显示在这个日志中。

Streaming

Streaming页面如下主要分两块:
Streaming Statistics:统计Streming的数据输入量、Streming的处理时间和时延。如下图:
Snip20190622_45
Streming每个批次的运行状况,便于分析每个批次的性能。如下图:
Snip20190622_46
常用信息说明:

名称 说明
Batch Time 批次产生的时间。
Records 批次获取到的数据量。
Scheduling Delay 批次开始处理的时延。
Processing Time 批次处理的时间。
Total Delay 批次处理完毕的总时延。
Records 批次获取到的数据量。

SQL

SQL 页面主要显示每个SQL任务信息,主要可以用于SQL的执行计划的查看。例如点击SQL页面的“Description”信息可以看到对应SQL的执行计划。如下图:
Snip20190622_47
其它的这里不做详细介绍。

小结

本文只对Yarn UI和Spark UI的进行简单的介绍,其它更详细信息可以参考: 社区资料
X-Pack Spark平台使用可参考:X-Pack Spark

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
存储 缓存 分布式计算
Spark任务OOM问题如何解决?
大家好,我是V哥。在实际业务中,Spark任务常因数据量过大、资源分配不合理或代码瓶颈导致OOM(Out of Memory)。本文详细分析了各种业务场景下的OOM原因,并提供了优化方案,包括调整Executor内存和CPU资源、优化内存管理策略、数据切分及减少宽依赖等。通过综合运用这些方法,可有效解决Spark任务中的OOM问题。关注威哥爱编程,让编码更顺畅!
217 3
|
21天前
|
存储 SQL 关系型数据库
【赵渝强老师】PostgreSQL的运行日志文件
PostgreSQL的物理存储结构包括数据文件、日志文件等。运行日志默认未开启,需配置`postgresql.conf`文件中的相关参数如`log_destination`、`log_directory`等,以记录数据库状态、错误信息等。示例配置中启用了CSV格式日志,便于管理和分析。通过创建表操作,可查看生成的日志文件,了解具体日志内容。
|
22天前
|
监控 应用服务中间件 定位技术
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
要统计Nginx的客户端IP,可以通过分析Nginx的访问日志文件来实现
|
24天前
|
存储 Prometheus 监控
Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行
本文深入探讨了在Docker容器内进行应用调试与故障排除的方法与技巧,包括使用日志、进入容器检查、利用监控工具及检查配置等,旨在帮助用户有效应对应用部署中的挑战,确保应用稳定运行。
31 5
|
1天前
|
监控 安全 Linux
启用Linux防火墙日志记录和分析功能
为iptables启用日志记录对于监控进出流量至关重要
|
1月前
|
存储 SQL 监控
|
1月前
|
运维 监控 安全
|
1月前
|
监控 关系型数据库 MySQL
分析慢查询日志
【10月更文挑战第29天】分析慢查询日志
44 3
|
1月前
|
监控 关系型数据库 数据库
怎样分析慢查询日志?
【10月更文挑战第29天】怎样分析慢查询日志?
48 2
|
2月前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1708 14