ING 国际银行基于 Volcano 的大数据分析平台应用实践

在 KubeCon + CloudNativeCon North America，ING 集团发表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主题演讲，重点介绍了云原生批量计算项目 Volcano 如何在数据管理平台中为大数据分析作业提供高性能调度工作。

详情参见：KubeCon + CloudNativeCon North America

ING 背景介绍

ING 集团（荷兰语：Internationale Nederlanden Groep），亦名荷兰国际集团，是一个国际金融服务私营企业，成立于 1991 年，由荷兰最大的保险公司 Nationale-Nederlanden，与荷兰的第三大银行 NMB PostBank Group 合并而成。

ING 集团的服务遍及全球 40 多个国家，核心业务是银行、保险及资产管理等。ING 集团的全球职员大约 56,000 人，顾客 5320 万人，包括自然人、家庭，企业、政府及其他等，例如基金组织。

业务背景介绍

在银行行业有许多法规和限制，如：监管要求在全球范围内各不相同、数据孤岛-全局和本地限制、数据安全、合规创新等，想要快速引入新技术不是一件容易的事情，为此，ING 布局符合自身产业的 DAP 平台（Data Analytics Platform），为全球 50%的 ING 员工提供安全的、自助的端到端分析能力，帮助员工在数据平台之上构建并解决业务问题。

2013 年开始我们有了数据平台的概念，2018 年通过引入云原生技术打造新一代基础设施平台，从那时起，平台需求有了稳定的增长，采用率也在持续提升，目前数据索引平台上的项目已超过 400 个。我们所构建的平台目标是在高度安全的自助服务平台中完成所有分析需求，并且具备以下特点：

1. 开源工具模型

2. 强大的计算能力

3. 严格的安全和合规措施

4. 所有的分析集中在同一个平台

5. 满足全球和本地需求

挑战与方案

目前我们在由传统的 Hadoop 平台向 Kubernetes 过渡，但是对于作业管理和多框架支持方面还存在一些挑战，如下：

1.Job 的管理

a.Pod 级调度，无法感知上层应用

b.缺乏细粒度的生命周期管理

c.缺乏任务依赖关系，作业依赖关系

2.调度

a.缺少基于作业的调度，如：排序、优先级、抢占、公平调度、资源预定等

b.缺少足够的高级调度算法，如：CPU 拓扑、任务拓扑、IO-Awareness，回填等

c.缺少对作业、队列、命名空间之间资源共享机制的支持

3.多框架支持

a.对 Tensorflow、Pytorch 等框架的支持不足

b.对每个框架部署（资源规划、共享）等管理比较复杂

利用 Kubernetes 来管理应用服务（无状态应用、甚至是有状态应用）是非常方便的，但是对于批量计算任务的调度管理不如 yarn 友好，同样 yarn 也存在一些限制，比如对新框架的支持不够完善，比如 TensorFlow、Pytorch 等，为此，我们也在寻找新的解决方案。

▍Kubernetes + Hadoop

在我们之前的集群管理上，会把 Hadoop 和 Kubernetes 的调度分开，基本上所有的 spark 作业都会运行在 Hadoop 集群中，其他的一些任务和算法会运行在 Kubernetes 集群，我们的目标是希望所有的任务全部运行在 Kubernetes 集群，这样管理起来会更简单。

Kubernetes 和 YARN 共同工作时，由于 Kubernetes 和 Hadoop 资源是静态划分的，在正常办公时间，Hadoop 应用和 Kubernetes 各自使用自身分配资源，即便 spark 任务压力大也无法借用更多资源。夜晚时间，集群中仅有批处理任务，Kubernetes 资源全部空闲，却无法分配给 Hadoop 进行有效利用，对于调度平台来讲，这不是一种最佳的资源分配方式。

▍Kubernetes with Volcano

使用 Kubernetes 管理整个集群，通过 Volcano 进行 spark 任务调度，此时不需要再对资源做静态划分，集群资源可根据 Pod、Batch、Interactive 任务的优先级、资源压力等进行动态调整，集群整体资源利用率得到极大提升。比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch 和 Interactive 应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch 业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。

比如在正常办公时间内，常规服务应用资源空闲的情况下，Batch 和 Interactive 应用资源需求增多时，可以暂时借用常规服务的资源；在假期和夜晚休息时，Batch 业务可以使用集群所有资源进行数据计算，集群资源利用率得到极大提升。

Volcano 是专为 Kubernetes 而生的批处理调度引擎，其提供了以下能力：

1. 加权优先级的作业队列

2. 如果集群具有备用容量，可提交超过队列资源限制的任务

3. 当更多的 pod 被调度时，具备抢占能力

4. 丰富可配置的工作负载调度策略

5. 兼容 YARN 的调度能力

Volcano 的引入，补齐了 Kubernetes 平台对批处理作业的调度管理能力，并且自 Apache Spark 3.3 版本以来，Volcano 被作为 Spark on Kubernetes 的默认 batch 调度器，安装使用更方便。

业务常用特性

▍冗余与局部亲和

Volcano 保留 Kubernetes 中 pod 级别的亲和性反亲和性策略配置，并增加了 task 级别的亲和性和反亲和性策略。

▍DRF（Dominant Resource Fairness）调度

DRF 调度算法的全称是 Dominant Resource Fairness，是基于容器组 Domaint Resource 的调度算法。volcano-scheduler 观察每个 Job 请求的主导资源，并将其作为对集群资源使用的一种度量，根据 Job 的主导资源，计算 Job 的 share 值，在调度的过程中，具有较低 share 值的 Job 将具有更高的调度优先级。

比如集群资源总量为 CPU：18C，Memory：72GB，两个用户分别是 User1 和 User2，每个 User 分配 1 个队列，在提交作业时会根据主导资源计算 job 的调度优先级。

• User1: CPU share 值为 6/18=0.33，Memory share 值为 24 / 72 = 0.33，最终 share 值为 0.33

• User2：CPU share 值为 12/18=0.67，Memory share 值为 24 / 72 = 0.33，最终 share 值为 0.67

DRF 策略在任务调度时，优先分配 share 值较低的 Job，即 User1 所申请的资源。

集群内队列资源可以通过配置权重值进行划分，但是当本队列提交任务超出队列分配的资源，并且其他队列存在资源空闲时，可以进行队列间资源共享。即 User2 在使用完本队列 CPU 资源后，可以使用 User1 队列内的空闲 CPU 资源。当 User1 队列提交新任务需要 CPU 资源时，将会触发抢占动作，回收 User1 被其他队列借用的资源。

▍避免资源匮乏

在使用过程中，需要避免批量计算任务与自有服务出现资源抢占与冲突的问题。比如：我们集群中有两个可用节点，集群中需要部署一个统一的服务层对外提供服务，比如 Presto，或者类似 Alluxio 的缓存服务。但是在批量计算调度时，集群的资源空间有可能全部被占用，我们将无法完成自有服务的部署或升级，为此我们增加了空间可用系数相关配置，为集群预留一些备用空间，用于自有服务的部署使用。

▍DRF 仪表盘

我们根据 Volcano 的监控数据做了一个 drf 调度的仪表盘，在不同层次显示更细粒度的调度信息。在业务集群中，我们有一个队列存放交互式用户的任务，另有队列存放平台运行的所有重大项目的计算任务，我们可以为重大项目队列提供一定的资源倾斜，但是此时对交互式用户的任务将不会太友好。

目前我们正在考虑增加集群高峰时段展示的功能，为用户提供更多的集群使用状态和压力等信息，在自助服务平台用户视角来看，用户按照集群的繁忙程度选择自己任务的开始时间，这样可以避免后台复杂的配置就可以获得高性能的运算体验。

总结

Volcano 对批处理任务调度做了很好的抽象，使我们在 Kubernetes 平台能够获得更高的调度性能，后面我们也会将开发的功能逐步回合社区，比如：DRF Dashboard、在每个节点添加空闲空间、自动队列管理、更多的 Prometheus 监控指标、Grafana 仪表盘更新、kube-state-metrics 更新和集群角色限制等。

Volcano 社区技术交流地址

Volcano 官网：https://volcano.sh

GitHub : https://github.com/volcano-sh/volcano

每周例会： https://zoom.us/j/91804791393

点击关注，第一时间了解华为云新鲜技术~