大数据 架构向云原生演进是行业的 重要 趋势， 火山引擎 协助关键金融客户在大数据 云原生方向进行了深度实践，形成了整体解决方案，本文将分享火山引擎云原生大数据在金融行业的实践。
作者｜张云尧-火山引擎云原生计算研发工程师
▌金融行业大数据需求
云原生相比 Hadoop 的优势
传统 大数据 集群 通常 基于 Hadoop 系统构建， 传统大数据作业通常是以裸进程的形式运行在节点上，很容易受到节点上的其他进程或其他因素干扰，因此带来的 作业稳定性 问题 经 常困扰用户。
一个实际的例子 ， 如果 一个 Flink 作业发生了延迟，找不到业务上的原因 ，但是 观测到 节点的 CPU 使用率比较高。用户通常选择杀掉节点上的其他作业，使机器负载下降，这时作业很有可能恢复了正常。但是，最终也没有定位到延迟的具体原因，一段时间后很可能会再次出现相同的问题，而且每次杀掉其他作业的处理方式非常繁琐，并且代价 比较高 。
那么，在 大数据 场景下， 云原生 系统 相比 Hadoop 系统，具备以下能力：
因此， 大数据 架构向云原生演进是全行业，特别是金融行业的重要趋势。
困扰用户的第二个问题是 资源效率问题。
在实践中，通常存在独立的 K8s 集群和 Hadoop 集群。 独立的 K8s 集群运行着在线服务，独立的 Hadoop 集群运行着 大数据 作业 ，这两个集群 不仅 不能 彼此共享资源 ， 而且 资源利用率都非常低 。
离线计算和在线业务的资源需求具有周期性变化，资源需求高峰时资源不足，低峰时资源冗余。 而 在线业务与离线计算的资源高低峰期往往是错开的，所以离线计算高峰时如何利用在线集群资源，在线业务高峰时如何利用离线集群资源， 成为 了降本增效的关键。
集群管理的总体 目标 是 在硬件资源不增加的情况下承载更多业务，整体提升集群资源利用率。
因为在线服务部署在云原生系统已经成为行业规范。在这个前提下，如果大数据系统也部署在云原生系统，和在线服务部署在一起，那么就具有如下优点：
因此， 资源的高效利用是金融行业特别关注的能力和需求。
大数据迁移云原生的难点
现在，云原生系统仍然存在很多不足，大数据集群难以直接基于云原生构建，这也是为什么大部分公司仍然还在使用 Hadoop 系统的原因。大数据场景下，迁移使用云原生系统存在以下不足：
因此，只有在 云原生 系统上补齐上述 不足 ，才可以更好地支撑金融行业 大数据 场景。
▌云原生大数据部署
为了满足业务的多种需求， 火山引擎 支持 大数据 作业在 云原生 系统上的 两种 部署方式：
基于云原生的 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 的功能不足 ， 比如 ：
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 Operator 与其他云原生部署方案相比具有诸多优势，以 Spark 为例：
相比上述两种方案， Arcee Operator 在适配 大数据 计算引擎的原生运行模式的同时， 提供了 ：
▌云原生大数据调度
火山引擎 的 云原生 大数据 系统存在三层 资源管理 ：
基于云原生的高性能资源管理调度器 —— GRO
GRO Scheduler 是基于 云原生 的高性能 资源管理 调度器，管控集群资源，并结合 GRO Agent 实现单机调度、隔离、和 混部 能力。
GRO Scheduler
云原生 系统 原生调度器的主要功能是 Pod 放置， 也就是 为 Pod 选择一个最优的节点 ， 但是这完全不能满足 大数据 作业的需求。
GRO Scheduler 参考 YARN 等 大数据 调度器，在 Pod 放置的基础上，增加了 Quota 管控。
整个调度流程如图：
大数据作业，特别是批式计算，只会占用资源一段时间，运行结束后归还资源。为了保证大数据作业可以充分利用集群资源，通常用户会提交多个作业，部分作业不能立刻获得资源，而是排队等待，直到有作业结束退出，才开始获得资源开始运行。这其中涉及两个重要的概念，“队列”和“作业”。
云原生系统原生调度器最初是针对在线服务设计，没有这两个概念。
没有“ 队列 ”的概念：一个集群包含多个节点，可以供多个租户同时使用集群资源。为了避免一个租户占用集群全部资源，而影响到其他租户，集群的运维人员或者资源的管理人员非常希望能够按照一定比例，或者按照指定数量将集群资源分配给不同租户。而云原生系统不支持这样的多租户资源管控能力。
没有“作业”的概念：在大数据集群里，一定存在作业排队的情况，对于这些不同的作业，哪些获得资源，哪些排队等待，是需要一个能够感知作业优先级、规格或其他信息的资源分配策略的。云原生系统只有 Pod 的概念，而不能感知作业，不具备作业级的调度策略。
因此， 为了更好地支持 大数据 场景资源分配， GRO 使用 K8s 自定义资源 能力 新增 这两个概念 ：
GRO 的每个 队列 有两个资源配额属性：
GRO 将根据所有队列的 Min-Max 属性，将集群资源公平地分配给各个队列，再根据不同的调度策略，将队列资源公平地分配给队列内的各个作业，再进一步分配各作业内的各个 Pod。
目前支持的几种常用调度策略：
GRO 还支持其他 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 核资源。
运行流程简述：
-
GRO Agent 监控所有 Pod 的资源使用情况，结合实时/历史资源变化曲线，实时计算出节点上可以被重复利用的闲置资源量（BestEffort 资源） ；
-
GRO Agent 上报 BE 资源量到 GRO Scheduler；
-
GRO Scheduler 调度有预期的低优作业到节点上使用 BE 资源 ；
-
GRO Agent 通过单机隔离机制保障正常 Pod 的稳定性和性能 ；
-
GRO Agent 根据 BE 资源变化情况压缩 混部 Pod 资源或者驱逐混部 Pod 。
基于云原生的多机房统一资源湖 —— ResLake
ResLake 是基于 云原生 的多机房统一资源湖，统一管理全局计算、存储、网络资源，并提供全局 容灾 能力。
数据中心通常存在多个机房，每个机房也存在多个集群，而每个集群上都存在不同队列。用户面对不同机房、不同集群的多个队列，存在一定使用成本。
ResLake 提供了全局 虚拟队列 。每个虚拟队列对应不同机房或集群的多个队列。用户提交作业到虚拟队列，ResLake 考虑资源情况、存储亲和性等因素，自动分发到合适的机房、集群和队列。
另外， ResLake 还提供了全局 Quota 管控。ResLake 在调度作业时，会考虑 Quota 约束、数据局部性、机房拓扑、自定义约束等条件。
ResLake 优先调度作业到和存储资源更“近”的计算队列。这里的“近”，包括同一个集群、同一个集群，或者网络通信开销较小的不同机房。
ResLake 还支持管理和调度存储资源：
全局的计算和存储资源调度，可以避免大规模跨机房网络通信， 达成“最优化资源利用率。最小化作业完成时间”的最终调度目的。
ResLake 支持分发作业到具体的集群和 队列 ：
结合上述分发策略， ResLake 提供三种 容灾 能力：
▌云原生大数据助力金融
火山引擎 云原生 大数据 平台致力于金融行业云原生大 数据解决方案 ：
上述四个解决方案提供了精细强大的作业管理能力，高效极致的 资源管理 能力和跨机房作业 容灾 能力，帮助 大数据 作业平滑迁移到 云原生 系统。 满足用户在硬件资源不增加的情况下承载更多业务，整体提升集群资源利用率。
