揭秘字节跳动云原生 Spark History 服务 UIService

2022 年 3 月 14 日
本文字数：4386 字
阅读完需：约 14 分钟

本文是字节跳动数据平台数据引擎 SparkSQL 团队针对 Spark History Server (SHS) 的优化实践分享。

文 | 字节跳动数据平台—数据引擎—SparkSQL 团队

在字节跳动内部，我们实现了一套全新的云原生 Spark History 服务—— UIService，相比开源的 SHS，UIService 存储占用和访问延迟均降低 90% 以上，目前 UIService 服务已经在字节跳动内部广泛使用，并且作为火山引擎湖仓一体分析服务 LAS（LakeHouse Analytics Service）的默认服务。LAS

业务背景

开源 Spark History Server 架构

为了能够更好理解本次重构的背景和意义，首先对原生 Spark History Server 原理做个简单的介绍。

开源 Spark History Server 流程图

Spark History 建立在 Spark 事件（Spark Event）体系之上。在 Spark 任务运行期间会产生大量包含运行信息的 SparkListenerEvent，例如 ApplicationStart / StageCompleted / MetricsUpdate 等等，都有对应的 SparkListenerEvent 实现。所有的 event 会发送到 ListenerBus 中，被注册在 ListenerBus 中的所有 listener 监听。其中 EventLoggingListener 是专门用于生成 event log 的监听器。它会将 event 序列化为 Json 格式的 event log 文件，写到文件系统中（如 HDFS）。通常一个机房的任务的文件都存储在一个路径下。

在 History Server 侧，核心逻辑在 FsHistoryProvider 中。FsHistoryProvider 会维持一个线程间歇扫描配置好的 event log 存储路径，遍历其中的 event log 文件，提取其中概要信息（主要是 appliaction_id, user, status, start_time, end_time, event_log_path），维护一个列表。当用户访问 UI，会从列表中查找请求所需的任务，如果存在，就完整读取对应的 event log 文件，进行解析。解析的过程就是一个回放过程（replay）。Event log 文件中的每一行是一个序列化的 event，将它们逐行反序列化，并使用 ReplayListener 将其中信息反馈到 KVStore 中，还原任务的状态。

无论运行时还是 History Server，任务状态都存储在有限几个类的实例中，而它们则存储在 KVStore 中，KVStore 是 Spark 中基于内存的 KV 存储，可以存储任意的类实例。前端会从 KVStore 查询所需的对象，实现页面的渲染。

痛点

存储空间开销大

Spark 的事件体系非常详细，导致 event log 记录的事件数量非常大，对于 UI 显示来说，大部分 event 是无用的。并且 event log 一般使用 json 明文存储，空间占用较大。对于比较复杂或时间长的任务，event log 可以达到几十 GB。字节内部 7 天的 event log 占用约 3.2 PB 的 HDFS 存储空间。

回放效率差，延迟高

History Server 采用回放解析 event log 的方式还原 Spark UI，有大量的计算开销，当任务较大就会有明显的响应延迟，响应延迟是指从用户发起前端访问到页面 UI 完全渲染出来的等待时长。作业结束之后，用户可能要等十几分钟甚至半小时才能通过 History Server 看到作业历史。而大型作业结束后，用户往往希望尽快看到作业历史从而根据作业历史进行问题诊断和作业优化，用户等待 UI 完成渲染时间过长，非常影响用户体验。

扩展性差

如上所述，History Server 的 FsHistoryProvider 在回放解析文件之前，需要先扫描配置的 event log 路径，遍历其中的 event log，将所有文件的元信息加载到内存中，这使得原生服务成为了有状态的服务。因此每次服务重启，都需要重新加载整个路径，才能对外服务。每个任务在完成后，也需要等待下一轮扫描才能被访问到。

当集群任务数量增多，每一轮扫描文件的耗时以及元信息内存占用都会增加，这也要求服务有越来越高的资源配置。如果通过拆分 event log 路径来缩小单实例的压力，需要对路由规则进行改造，运维难度增大。目前，字节跳动内部通过增加 UIService 实例就可以方便的进行水平扩展。

非云原生

Spark History Server 并非是云原生的服务，在公有云场景下改造和维护成本高。首先公有云场景需要进行租户资源隔离，其次公有云场景下不同用户的 workload 差异很大，不同用户任务量有数量级的差别，会出现大量长尾作业。为每个用户单独部署 History Server 计算和存储成本过大且不均衡，而部署统一的 History Server 无法做到资源隔离，一旦出现问题影响较多用户，两种方式运维成本都会很高。火山引擎湖仓一体分析引擎 LAS（Lakehouse Analytics Service），提供了云原生的 UIService，可以有效解决上述问题。

UIService

方案

为了解决前面的三个问题，我们尝试对 History Server 进行改造。如上所述，无论运行中的 Spark Driver 还是 History Server，都是通过监听 event，将其中包含的任务变化信息反映到几种 UI 相关的类的实例中，然后存入 KVStore 供 UI 渲染。也就是说，KVStore 中存储着 UI 显示所需的完备信息。对于 History Server 的用户来说，绝大多数情况下我们只关心任务的最终状态，而无需关心引起状态变化的具体 event。因此，我们可以只将 KVStore 持久化下来，而不需要存储大量冗余的 event 信息。此外，KVStore 原生支持了 Kryo 序列化，性能明显于 Json 序列化。我们基于此思想重写了一套新的 History Server 系统，命名为 UIService。

UIService 框架图

实现

UIMetaStoreKVStore 中和 UI 相关的所有类实例，我们将这些类统称为 UIMeta 类。具体包括 AppStatusStore 和 SQLAppStatusStore 中的信息（如下所列）。我们定义一个类 UIMetaStore 来抽象，一个 UIMetaStore 即一个任务所有 UI 信息的集合。UIMetaStore 所包含信息：

#AppStatusStore org.apache.spark.status.JobDataWrapper org.apache.spark.status.ExecutorStageSummaryWrapper org.apache.spark.status.ApplicationInfoWrapper org.apache.spark.status.PoolData org.apache.spark.status.ExecutorSummaryWrapper org.apache.spark.status.StageDataWrapper org.apache.spark.status.AppSummary org.apache.spark.status.RDDOperationGraphWrapper org.apache.spark.status.TaskDataWrapper org.apache.spark.status.ApplicationEnvironmentInfoWrapper #SQLAppStatusStore org.apache.spark.sql.execution.ui.SQLExecutionUIData org.apache.spark.sql.execution.ui.SparkPlanGraphWrapper

UIMetaStore 还定义了持久化文件的数据结构，结构如下：

Magic Number 用于文件类型标识校验。
Body 是 UIMetaStore 的主体数据，使用连续存储。每一个 UI 相关的类实例，会序列化成四个片段：类名长度（4 byte long 类型）+ 类名（string 类型）+ 数据长度（4 byte long 类型）+ 序列化的数据（二进制类型）。在读取时顺序读取，每个元素先读取长度信息，再根据长度读取后续相应数据进行反序列化。
使用 Spark 原生的 KVStoreSerializer 序列化，可以保证前后兼容性。

UIMetaLoggingListener

类似于 EventLoggingListener，为 UIMeta 开发了专用的 Listener —— UIMetaLoggingListener，用于监听事件，写 UIMeta 文件。和 EventLoggingListener 进行对比：EventLoggingListener 每接受一个 event 都会触发写，写的是序列化的 event；而 UIMetaLoggingListener 只会被特定的 event 触发，目前是只会被 stageEnd，JobEnd 事件触发，但每次写操作是批量的写，将上一阶段的 UIMetaStore 的信息完整地持久化。做一个类比，EventLoggingListener 好比流式，不断地追加写，而 UIMetaLoggingListener 类似于批式，定期将任务状态快照下来。

UIMetaProvider

替换原先的 FsHistoryProvider，主要区别在于：

将读取 event log 文件和回放生成 KVStore 的流程改为读取 UIMetaFile，反序列化出 UIMetaStore。

去掉了 FsHistoryProvider 的路径扫描逻辑；每次 UI 访问，根据 appid 和路径规则，直接去读取 UIMetaFile 解析。这使得 UIService 无需预加载所有文件元信息，不需要随着任务数量增加提高服务器配置，方便了水平扩展。

优化

避免重复写

由于每个 stage 完成都会触发写 UIMeta 文件，这样对于 UIMeta 的很多元素，可能会出现重复持久化的情况，增加写入耗时和文件的大小。因此我们在 UIMetaLoggingListener 内部维护了一个 map，记录已经被序列化的实例。在写 UIMeta 文件时进行过滤，只写没有写过或者数据发生改变的元素。这样可以杜绝大部分的写冗余。

此外，开发期间发现，占用空间最大的是 task 级别信息 TaskDataWrapper。在一个 stage 完成触发写时。可能会将仍处于 RUNNING 状态的 stage 的 task 序列化下来，这样当 RUNNING 的 stage 完成时，task 信息会再被写一次，也会造成数据冗余，因此我们对序列化 TaskDataWrapper 信息进行过滤，在 stage 结束时只持久化状态是 Completed 的 task 信息。

支持回退到 event log

鉴于 UIService 在初期有存在问题的风险，我们还支持了回退机制，即访问一个任务的 UI，优先尝试走 UIService 的路径：解析 UIMeta 文件，如果 UIMeta 文件不存在或者解析报错，会回退到读 event log 文件的路径，避免 UI 访问失败。同时还支持将 event log 文件转换成 UIMeta 文件，这样下一次调用时就可以使用 UIService。这个功能保证我们迁移过程的平滑。

收益

存储收益

线上测试显示存储平均减少 85%，总量减少 92.4%。下图显示了某机房 event log 和 UIMeta 存储占用监控，可以看到 UIMeta 较 event log 在存储量上有数量级的减少。目前字节内部 7 天的 event log 占用存储空间 3.2 PB，改用 UIMeta 后，空间占用只有 350TB。凭借 UIService 的存储优势，我们可以保留更长时间的日志信息，有助于历史分析，问题复盘。目前我们已从保留 7 天日志提高到了保留 30 天，并可以根据需求增大保留时间。