Spark任务信息记录器的变更

Spark任务信息记录器的变更

@DeveloperApi注解标注的类代表
1.面向开发人员的低级、不稳定的应用程序接口。
2.可能会在 Spark 的次要版本中更改或删除。
3.注意：如果在此注解之前存在 Scaladoc 注释，则注解的第一行必须是":： DeveloperApi ::" ，后面不能有空行。这是因为 Scaladoc 仅显示注释或注释（以先显示者为准）这一已知问题。

切入类

org.apache.spark.ui.jobs.JobProgressListener

，此类继承了

SparkListener

类。属于监听器的一类

主要用来为UI跟踪task级别的相关信息。UI线程和

DAGScheduler

事件读取和更新

JobProgressListener

内部的数据结构。

有哪些数据？？？

Job级别，Stage级别，Task级别的运行信息与相关的指标信息。数据结构主要相关类列表：

• org.apache.spark.ui.jobs.UIData：其中定义了UI中使用的相关数据结构- ExecutorSummary：执行器的概要信息字段组合类- JobUIData：Job下的相关信息- StageUIData：Stage下的相关信息- TaskUIData：Task的相关信息，以及与TaskMetrics信息转换的一些方法。- TaskMetricsUIData：任务指标的相关信息- InputMetricsUIData：输入的相关指标- OutputMetricsUIData：输出的相关指标- ShuffleReadMetricsUIData：ShuffleRead的相关指标- ShuffleWriteMetricsUIData：ShuffleWrite的相关指标
• org.apache.spark.executor.TaskMetrics：Task执行过程中跟踪的指标信息。
• org.apache.spark.scheduler.StageInfo：存储scheduler程序向 SparkListeners 传递的Stage信息。
• org.apache.spark.scheduler.AccumulableInfo：task或stage中修改的org.apache.spark.Accumulable的相关信息。一旦进行 JSON 序列化，"update "和 "value "的类型将丢失并被转换为字符串。这是因为用户可以定义任何类型的累加器，而在事件日志的消费者中很难保留其类型。这不适用于表示任务级指标的内部累加器。在2.0.0标记废弃。补充AccumulatorV2进行替换。> 累加器

存在的Spark版本：0.8.0~2.2.3

升级和问题汇总ISSUE：SPARK-18085

升级原因

1. JobProgressListener中会存在大量的数据，极有可能造成OOM。虽然提供了spark.ui.retainedStages和spark.ui.retainedJobs配置项，用来控制保留的Stage和Job的数量，但是设置起来或遇到异常任务，会打爆内存。
2. 当spark日志（保存的任务很多，任务的异常日志很多）很大的时候，Spark history Server服务去加载就很慢。会占用大量服务器的资源，甚至OOM。同时在Spark History UI首次打开时，页面加载的时间太长，极易造成浏览器的卡死。
3. stage出现在未设置submission 时间的场景下进行了提交Spark监听器。task也有出现在未设置submission 时间的场景下进行了提交Spark监听器。这是一个bug。这是一个bug。

之前的优化方案

1. 增量解析事件日志在 SHS 中实现事件日志的增量解析将是一件好事。在新的工作中，用户界面数据存储在磁盘上，因此应该可以保存足够多的事件日志元数据和监听器状态，以便在上一次迭代停止的位置继续解析实时应用程序的日志。这将大大加快更新时的解析速度，而且可以投机性地进行，这样新应用程序的用户界面几乎可以立即在 SHS 中使用。
2. 使用 ApplicationAttemptInfo 检查点加快 HistoryServer 的重启速度在 HistoryServer 当前的代码中，jetty 服务器会在从 yarn 抓取的所有日志重放完毕后启动。然而，当日志数量越来越多时，jetty 的启动时间会过长。 在这里，我们实现了一种使用 ApplicationAttemptInfo 检查点来加快历史服务器启动速度的解决方案。当历史服务器启动时，如果存在检查点文件，它会首先从检查点文件中加载 ApplicationAttemptInfo，这比逐个重放要快。

实现重构

1. 新增一个Spark事件监听器，将应用数据存储在一个单独的KV存储中。Spark UI、REST API或其他请求应用数据的入口，直接请求KV存储，将监听器进行解耦。