▌金融行业大数据需求

云原生相比 Hadoop 的优势

传统 大数据 集群 通常 基于 Hadoop 系统构建， 传统大数据作业通常是以裸进程的形式运行在节点上，很容易受到节点上的其他进程或其他因素干扰，因此带来的 作业稳定性 问题 经 常困扰用户。

一个实际的例子 ， 如果 一个 Flink 作业发生了延迟，找不到业务上的原因 ，但是 观测到 节点的 CPU 使用率比较高。用户通常选择杀掉节点上的其他作业，使机器负载下降，这时作业很有可能恢复了正常。但是，最终也没有定位到延迟的具体原因，一段时间后很可能会再次出现相同的问题，而且每次杀掉其他作业的处理方式非常繁琐，并且代价 比较高 。

那么，在 大数据 场景下， 云原生 系统 相比 Hadoop 系统，具备以下能力：

• 强制的容器化能力 ： 可以屏蔽 大数据 作业的运行环境，提高运行时 隔离 能力；

• 可定制化的网络 / 存储 能力： 可以 支持 大数据 作业 使用复杂 的 容器化网络技术，以及 云原生 支持的任意存储 系统 ；

• 便捷的运维能力 ： 可以轻松地进行 节点 上下线， 集群 扩缩容，降低 基础设施 运维成本。

因此， 大数据 架构向云原生演进是全行业，特别是金融行业的重要趋势。

困扰用户的第二个问题是 资源效率问题。

在实践中，通常存在独立的 K8s 集群和 Hadoop 集群。 独立的 K8s 集群运行着在线服务，独立的 Hadoop 集群运行着 大数据 作业 ，这两个集群 不仅 不能 彼此共享资源 ， 而且 资源利用率都非常低 。

离线计算和在线业务的资源需求具有周期性变化，资源需求高峰时资源不足，低峰时资源冗余。 而 在线业务与离线计算的资源高低峰期往往是错开的，所以离线计算高峰时如何利用在线集群资源，在线业务高峰时如何利用离线集群资源， 成为 了降本增效的关键。

集群管理的总体 目标 是 在硬件资源不增加的情况下承载更多业务，整体提升集群资源利用率。

因为在线服务部署在云原生系统已经成为行业规范。在这个前提下，如果大数据系统也部署在云原生系统，和在线服务部署在一起，那么就具有如下优点：

• 在线资源和大数据资源可以高效、灵活地相互转换

• 整个集群的利用率可充分地提升，降本增效

• 资源共池，统一的配额管控、机器运维、软件部署等，降低维护成本。

因此， 资源的高效利用是金融行业特别关注的能力和需求。

大数据迁移云原生的难点

现在，云原生系统仍然存在很多不足，大数据集群难以直接基于云原生构建，这也是为什么大部分公司仍然还在使用 Hadoop 系统的原因。大数据场景下，迁移使用云原生系统存在以下不足：

• 一个运行在 Hadoop 系统上的传统 大数据 作业迁移到 云原生 系统， 具有一定的改造成本；而一个大数据集群通常存在数百个、数千个，甚至数万个、数十万个作业，全部迁移到云原生系统上，改造成本巨大，难以实现 ；

• 传统的 大数据 引擎 ，比如 Flink 、 Spark ，最初 不是针对 云原生 系统 设计， 其 AM-Task 作业形态难以 直接在 云原生 系统上 部署；

• 云原生 系统的原生调度器 不具备与 Hadoop YARN 队列 类似的多租户资源管控能力；

• 云原生 系统的 原生调度器不存在 “作业” 概念，不具备作业排队能力，不具备作业级调度策略；

• 云原生 系统的原生 调度器吞吐能力 差，不适用于任务量大且运行时间较短的 大数据 作业 ，比如一个 只需要运行 1 分钟的 Spark 作业， 在 调度 阶段就花费 三分钟，不仅 使作业完成时间大幅增加， 还 造成了集群 资源浪费 ；

因此，只有在 云原生 系统上补齐上述 不足 ，才可以更好地支撑金融行业 大数据 场景。

▌云原生大数据部署

为了满足业务的多种需求， 火山引擎 支持 大数据 作业在 云原生 系统上的 两种 部署方式：

• 基于 Serverless YARN 的 Hadoop 方式 部署

• 基于 Arcee Operator 的 云原生 方式 部署

基于云原生的 YARN 解决方案 —— Serverless YARN

Serverless YARN 是基于 云原生 的 YARN 解决方案，帮助 大数据 作业透明迁移到云原生系统。简单来说，在 K8s 系统 上模拟实现了 YARN 系统 ，传统作业可以像 往常 一样提交 和运行，不需要进行任何改造 ，完全感知不到 K8s 的存在。

Serverless YARN 保留了 YARN Client、 YARN API ，以及 YARN 原有的 AM 管理、Quota 管理、权限管理等功能。

作业提交 流程如下图：

1. 用户 在 计算引擎 的基础上进行开发 ，调用 YarnClient SDK ，提交作业到 Serverless YARN 的 Resource Manager 组件 ；

1. RM 组件为作业创建 AM Pod （每个作业有一个 Master 实例，负责管控整个作业， 全 称为 Application Master） ；

1. AM Pod 经过 K8s 的 API Server 和调度器调度到一个具体 的 节点 ，然后由节点上的 Kubelet 负责启动和管控；

1. A M 启动后定期向 RM 发送心跳， 心跳信息包括自身 运行状态 ，以及 资源 申请 请求 ；

1. AM 向 RM 申请更多资源，RM 将这些资源请求转换为 K8s 上的 Pod ，由 K8s 负责调度和启动；

1. 作业的其他 Pod 启动，开始实际计算，受 AM 管控。

上述过程和 YARN 完全相同，唯一的区别在于 所有作业实例 都收敛到 K8s 上，通过 Kubelet 启动 容器并运行。

但是 ， YARN 系统负责启动和管控作业实例的 Node Mananger 组件具 有很多 Kubelet 不具备的 大数据 特有 功能 。 所以， Serverless YARN 还 在每个节点上部署了大数据辅助 插件，以弥补 Kubelet 的功能不足 ， 比如 ：

• 提供 为作业 提前 下载 Jar 包的功能（在 大数据 体系中称为 Localization） ；

• 启动 计算引擎的 Shuffle 服务 ；

• 为 大数据 作业提供 日志 服务 ；

• 为 大数据 作业提供 监控 能力 ，等 等。

Serverless YARN 还提供作业迁移工具，新作业可以无缝提交到 Serverless YARN 集群上， 旧的 YARN 集群等到 没有 任何 作业 运行后， 可以 被操作 下线。

更重要的是， Serverless YARN 做了深度 的 性能优化，RM 切主时间 控制在 秒 级 以 内， Pod 调度吞吐提高到 每秒 2000 个 以上 。

基于云原生的大数据统一 Operator —— Arcee Operator

Arcee Operator 是基于 云原生 的 大数据 统一 Operator，统一管控多种计算引擎 。

Arcee 借鉴了 YARN 的 两级 管理模式 ， 管理 大数据 作业的 Application Master，再由 AM 管理 计算 Worker。

这种管理模式能够有效管理和表达 大数据 作业状态，定制作业管理策略，确保计算引擎对计算作业运行有充分的掌握能力，有能力按需调整资源使用。

除 两级管理外 ， Arcee Operator 还具备 以下 特性：

• Arcee 定义了统一作业实例 ： Arcee Operator 利用 K8s 的自定义资源定义了统一作业实例，无论是 Spark 还是 Flink ， 或者使 其他类 YARN 的 计算引擎 ，都 可以 使用统一的 CRD 描述作业 ，包括作业配置、作业 规格 等信息 ，而且可以收集 并展示作业的统一且 详细 的 运行状态，有利于业务的统一表达和处理；

• Arcee 实现了作业异常处理 ：Arcee Operator 可以 实时监控所有作业状态， 处理作业异常 ，持续保障作业正常运行； 比如因为节点磁盘故障而导致 AM 运行异常，Arcee 检测到后在其他节点重新启动 AM，并接管之前启动的 Work Pod ，使作业恢复正常运行；

• Arcee 屏蔽了底层调度器 ：Arcee Operator 封装 了 底层调度功能，降低 了 作业使用高级调度策略的门槛 ，比如优先级调度、Gang 调度等 大数据 作业的强需求；并且可以从调度器上收集作业调度信息，然后对外展示，用户可以轻松知道 “作业为什么没有进行调度”。

Arcee Operator 与其他云原生部署方案相比具有诸多优势，以 Spark 为例：

• Spark 社区推荐 的 K8s Native 方式，Spark Pod 没有统一资源描述，很难进行管理和描述 ；

• Google 的 Spark Operator 在 K8s Native 方式的 基础上封装了 CRD ，提供 了 统一的资源描述 ， 但是 它 是以旁路的方式实现的， 基本不存在 管控策略， 而且 不支持 Spark Client 模式。

相比上述两种方案， Arcee Operator 在适配 大数据 计算引擎的原生运行模式的同时， 提供了 ：

• 统一的作业描述，以及详细、准确的状态信息；

• 丰富的作业异常处理策略；

• 快速接入高级调度功能的能力。

▌云原生大数据调度

火山引擎 的 云原生 大数据 系统存在三层 资源管理 ：

• 全局的 多机房统一资源湖 —— ResLake ，负责全局统一的 资源管理 、调度、分发和 容灾 ；

• 每个集群上，GRO Scheduler 负责集群内的 Quota 管控和 Pod 调度；

• 每个节点上，GRO Agent 负责单机调度和隔离增强。

基于云原生的高性能资源管理调度器 —— GRO

GRO Scheduler 是基于 云原生 的高性能 资源管理 调度器，管控集群资源，并结合 GRO Agent 实现单机调度、隔离、和 混部 能力。

GRO Scheduler

云原生 系统 原生调度器的主要功能是 Pod 放置， 也就是 为 Pod 选择一个最优的节点 ， 但是这完全不能满足 大数据 作业的需求。

GRO Scheduler 参考 YARN 等 大数据 调度器，在 Pod 放置的基础上，增加了 Quota 管控。

整个调度流程如图：

• Quota 管控：调度器首先将集群资源分配给各个队列，然后将队列资源分配给该队列的各个作业，最后将作业资源分配给该作业的各 Pod。不是所有 Pod 都可以获得资源，只有获得资源的 Pod 才可以进入后续的 Pod 放置流程；

• Pod 放置：和原生调度器一样，首先为 Pod 筛选符合条件的节点，然后对筛选出来的节点进行打分，最后将 Pod 绑定到分数最高的节点上。

大数据作业，特别是批式计算，只会占用资源一段时间，运行结束后归还资源。为了保证大数据作业可以充分利用集群资源，通常用户会提交多个作业，部分作业不能立刻获得资源，而是排队等待，直到有作业结束退出，才开始获得资源开始运行。这其中涉及两个重要的概念，“队列” 和 “作业”。

云原生系统原生调度器最初是针对在线服务设计，没有这两个概念。

没有 “ 队列 ” 的概念：一个集群包含多个节点，可以供多个租户同时使用集群资源。为了避免一个租户占用集群全部资源，而影响到其他租户，集群的运维人员或者资源的管理人员非常希望能够按照一定比例，或者按照指定数量将集群资源分配给不同租户。而云原生系统不支持这样的多租户资源管控能力。

没有 “作业” 的概念：在大数据集群里，一定存在作业排队的情况，对于这些不同的作业，哪些获得资源，哪些排队等待，是需要一个能够感知作业优先级、规格或其他信息的资源分配策略的。云原生系统只有 Pod 的概念，而不能感知作业，不具备作业级的调度策略。

因此， 为了更好地支持 大数据 场景资源分配， GRO 使用 K8s 自定义资源 能力 新增 这两个概念 ：

• Queue CRD ： 描述了一个 “ 队列 ”，即 Quota（资源配额）的抽象；

• PodGroup CRD ： 描述了一个 “作业”，标识多个 Pod 属于同一个集合，从而可以把多个 Pod 看作整体进行调度。

GRO 的每个 队列 有两个资源配额属性：

• Min Quota，又称为保障资源量。调度器为该队列预留 Min Quota 的资源量，不允许其他队列占用，以保障该队列在需要使用时可以立刻获得资源；

• M ax Quota，又称为资源使用上限。调度器限制该队列使用资源不超过 Max Quota 的资源量。

GRO 将根据所有队列的 Min-Max 属性，将集群资源公平地分配给各个队列，再根据不同的调度策略，将队列资源公平地分配给队列内的各个作业，再进一步分配各作业内的各个 Pod。

目前支持的几种常用调度策略：

• 优先级调度：所有作业按照定义的优先级排序，调度器优先分配高优先级的作业；

• Gang 调度：调度器一次性为作业的所有 Pod 分配资源，或者一个 Pod 也不分配，保证不出现一个作业的部分 Pod 启动，部分 Pod 排队等待的情况；一个作业只有部分 Pod 启动，有可能不能正常运行，这样不仅浪费了集群资源，还可能存在多个类似作业相互死锁，导致所有作业都不能正常运行；

• DRF 调度：调度器公平分配资源给各个作业的同时，兼顾多维度资源的比例，尽可能提升资源利用率；比如队列剩余大量 CPU 和少量内存时，优先分配 CPU 需求多、内存需求少的作业，避免队列的内存完全耗尽，大量 CPU 剩余，无法被利用的问题。

GRO 还支持其他 Quota 管控策略 ：

• 队列 间抢占：队列没有使用的 Quota 允许临时被其他队列占用，当队列有资源需求时，可以从其他队列将资源抢占回来；

• 队列 内抢占：队列没有剩余 Quota，高优作业提交后可以将正在运行的低优作业占用的资源抢占回来；

• 大作业资源预留：资源需求较大的作业很有可能因为节点资源碎片一直无法调度，调度器支持预留节点资源，保证大作业调度成功。

GRO Scheduler 具有强大的 Pod 放置能力，支持将一个 Pod 调度到具体节点的各种不同策略，支持大部分原生调度器功能，比如节点名称、节点 Label、节点污点、亲缘性、集中调度、均衡调度等策略；也支持大数场景的高级策略，比如真实负载平均、GPU 共享、微拓扑调度等策略。

GRO Scheduler 具有极高的调度吞吐，采用批式调度，在支持复杂调度策略的前提下，调度吞吐性能仍然可以达到每秒上千个 Pod。

GRO Scheduler 具有丰富的信息统计，支持队列的资源统计，作业的状态、资源、计量统计，作业的运行事件等信息的收集和展示等。

大数据作业部署在云原生系统上，在线服务也部署在云原生系统上，在离线业务可以同时部署到同一个集群上。 GRO Scheduler 统一管控云原生集群资源，同时调度在线服务和大数据作业。

• 在线服务高峰时，离线计算尽量停止运行，在线服务使用集群大部分资源；

• 在线服务低谷时，在线服务让出大部分资源，离线计算开始运行。

以证券交易场景为例，每天交易时间是固定的，这期间在线服务承接大量流量，需要大量资源，离线计算作业全部停止，优先保证在线服务运行；当交易时间结束后，在线服务没有流量，资源闲置，离线计算作业开始运行。

以上， 在离线资源可以高效且灵活地相互转换，整个 集群利用率得到极大地提升，实现降本增效 。

同时，面对在离线业务，基础组件 运维人员 只需要维护 云原生 集群， 降低维护开销 。

GRO Agent

在线服务和大数据作业可以运行在一个集群，不可避免地也会运行在一个节点上。但是大数据作业的运行特性是大幅利用机器资源，是有可能会影响到在线服务的。

云原生系统的资源隔离机制可以限制每个 Pod 的 CPU 时间片和内存使用量，但是这样的隔离程度是不够的。比如大数据作业导致节点 Load 升高，会影响到同一个节点上的在线服务。

因此，GRO Agent 部署到每个节点上，用于增强单机隔离性。

单机隔离手段包括 CPU（调度权重、核心隔离）、内存（独立内存水位）、磁盘（IOPS / 带宽限制）、网络（网络打标流量限制）等多个层面。

GRO Agent 支持在线 SLA 保障机制，监控节点上在线服务的运行情况，结合业务指标、资源指标、基础指标等，在必要情况下，可以驱逐大数据 Pod，或者通知调度器重新迁移在线服务，以保障在线服务的稳定性。

闲置资源利用

GRO 支持闲置资源利用，实现资源超发，更进一步提高资源利用率，降低成本。

举例来说，一个 4 核的 Flink Pod，在高峰期资源使用率是 3.9 核，但是低谷期资源使用率只有 0.2 核。因此不能简单的减少 Flink Pod 的资源申请量，但是低谷期时会存在资源的大量浪费。因此 GRO 可以在低谷期时，调度一个低优的 Pod，利用空闲的 3.8 核资源。

运行流程简述：

1. GRO Agent 监控所有 Pod 的资源使用情况，结合实时 / 历史资源变化曲线，实时计算出节点上可以被重复利用的闲置资源量（BestEffort 资源） ；

1. GRO Agent 上报 BE 资源量到 GRO Scheduler；

1. GRO Scheduler 调度有预期的低优作业到节点上使用 BE 资源 ；

1. GRO Agent 通过单机隔离机制保障正常 Pod 的稳定性和性能 ；

1. GRO Agent 根据 BE 资源变化情况压缩 混部 Pod 资源或者驱逐混部 Pod 。

基于云原生的多机房统一资源湖 —— ResLake

ResLake 是基于 云原生 的多机房统一资源湖，统一管理全局计算、存储、网络资源，并提供全局 容灾 能力。

数据中心通常存在多个机房，每个机房也存在多个集群，而每个集群上都存在不同队列。用户面对不同机房、不同集群的多个队列，存在一定使用成本。

ResLake 提供了全局 虚拟队列 。每个虚拟队列对应不同机房或集群的多个队列。用户提交作业到虚拟队列，ResLake 考虑资源情况、存储亲和性等因素，自动分发到合适的机房、集群和队列。

另外， ResLake 还提供了全局 Quota 管控。ResLake 在调度作业时，会考虑 Quota 约束、数据局部性、机房拓扑、自定义约束等条件。

ResLake 优先调度作业到和存储资源更 “近” 的计算队列。这里的 “近”，包括同一个集群、同一个集群，或者网络通信开销较小的不同机房。

ResLake 还支持管理和调度存储资源：

• 针对周期性作业，ResLake 提交将存储资源搬迁到计算队列所在的机房；

• 针对临时查询，如果存在跨机房读取存储数据，ResLake 将存储资源缓存在目的机房一段时间。

全局的计算和存储资源调度，可以避免大规模跨机房网络通信， 达成 “最优化资源利用率。最小化作业完成时间” 的最终调度目的。

ResLake 支持分发作业到具体的集群和 队列 ：

• 支持一个作业全部分发到同一个队列；

• 支持一个作业的不同实例按照指定比例或者指定数量分发到不同队列，包括同集群、同机房的不同集群、不同机房的队列等。

结合上述分发策略， ResLake 提供三种 容灾 能力：

• 迁移 容灾 ：

  • 灾难发生后，自动重新提交作业到备用 队列 ；

  • 备用集群资源不足时，自动杀死低优作业以腾出资源 ；

• 多活 容灾 ： 基于 多副本的 输入 / 输出，在备用 队列 启动副本作业 ；

• 高可用 容灾 ： 基于作业自身 HA 能力，作业子实例被分发到两个 队列 同时运行 。

▌云原生大数据助力金融

火山引擎 云原生 大数据 平台致力于金融行业云原生大 数据解决方案 ：

• Serverless YARN：基于云原生的 YARN 解决方案

• Arcee Operator：基于云原生的大数据统一 Operator

• GRO：基于云原生的高性能资源管理调度器

• ResLake：基于云原生的多机房统一资源湖

上述四个解决方案提供了精细强大的作业管理能力，高效极致的 资源管理 能力和跨机房作业 容灾 能力，帮助 大数据 作业平滑迁移到 云原生 系统。 满足用户在硬件资源不增加的情况下承载更多业务，整体提升集群资源利用率。