您的位置: 首页 > 技术杂谈 > 正文

火山引擎云原生大数据在金融行业的实践

2022-12-01 18:00 https://my.oschina.net/u/5941630/blog/5602102 字节跳动云原生计算次阅读条评论

大数据架构向云原生演进是行业的重要趋势，火山引擎协助关键金融客户在大数据云原生方向进行了深度实践，形成了整体解决方案，本文将分享火山引擎云原生大数据在金融行业的实践。

作者｜张云尧-火山引擎云原生计算研发工程师

▌金融行业大数据需求

云原生相比 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 管理、权限管理等功能。

作业提交流程如下图：

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

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

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

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

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

作业的其他 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 启动，有可能不能正常运行，这样不仅浪费了集群资源，还可能存在多个类似作业相互死锁，导致所有作业都不能正常运行；