华泰证券基于 Kubernetes 构建 AI 基础平台的落地实践

华泰证券一直将信息化建设作为公司发展的主推力，目前公司正在推动 AI+、AI 中台等战略。公司内部的 AI 基础平台已经落地，作为量化平台、数据科学平台等业务平台的基座，承载了华泰证券目前以及未来深度学习等领域的工程孵化。

目前 AI 基础平台底层基于 Kubernetes 和大数据平台，支持 Job 驱动、Pipeline、DAG、分布式计算框架等功能；同时支持异构计算，包括 Kubernetes 集群、Spark 集群等。本文暂只描述 AI 基础平台上层设计部分，后期会另外撰文聊聊如何打通大数据平台获取行情数据等资讯为量化平台、数据科学平台提供数据支持。

AI 基础平台项目出发点

随着大数据和人工智能技术的发展，人工智能相关技术已在华泰证券内部多个业务场景里取得创新应用，包括精准营销、量化交易、智能投顾、智能诊股、营销反欺诈、相似 K 线等场景；类似应用案例都需要依托于海量金融、产业、行业相关数据，并通过数据挖掘、机器学习、深度学习等相关技术来实现。这类计算密集型业务，一般都需要使用 GPU 服务器，在没有 AI 基础平台时，各个算法团队需要自购或申请自己团队独占的服务器资源。但是这种各自为战的模式会因为资源管理、服务器运维、资源争抢等问题致使各个团队效率降低。在这种背景下，需要建设统一的集群资源管理来解决这些问题。

华泰证券的 AI 基础平台基于海量数据，支持多用户、超高频率训练/预测/回测、主流深度学习框架，提供机器学习、深度学习所需的统一运行环境。各个算法团队可以将精力从资源、数据等方面抽出来，集中精力在自己团队的核心业务上。

华泰证券信息技术部数据科学中心平台团队研发的 AI 基础平台定位于承载公司内部所有一站式人工智能平台所需的底层平台，基于底层高性能计算资源、海量数据和资源调度能力，并持续集成主流深度学习/机器学习框架，能够对外提供通用机器学习/深度学习所需基础平台环境。平台主要功能包括：深度融合大数据平台和 AI 基础平台；为上层数据科学开发平台、量化平台的数据处理、模型训练、模型预测、模型发布提供底层支撑；为 AI 算法工程师以及业务团队提供便捷高效的深度学习框架技术。平台在提供多样化服务的同时还需具备稳定性、自动分布式化、算法兼容性、弹性扩缩容、易用性、资源利用率提升这几大特点。AI 基础平台是满足各种业务场景下机器学习、深度学习需求的通用基础服务平台。

选型考虑

从大部分用户的角度出发，最迫切的需求是保证离线跑批任务的资源隔离性，离线任务运行时不出现资源争抢，还需要为用户提供方便快捷的调试环境，比如常用的 Jupyter Notebook、Jupyter Lab 等等。由于历史原因，大部分的算法工程师习惯于单机单卡或单机多卡，因此为了让算法工程师们无感知迁移到机器学习平台，除了要为算法工程师们提供回测支持，还需要提供个人调试环境，个人调试环境中需要将数据持久化存储以供开发人员频繁读取写入。

根据以上重点进行架构选型的研究，底层使用容器技术来保障离线计算任务的资源隔离性，同时又可以保障个人调试环境的隔离性，还可以提高单服务器上的资源使用率。不仅如此，对于不同的开发人员，常用的机器学习框架不同，例如 Sklearn、TensorFlow、Pytorch 等，每种框架还有不同的版本分支，因此引进容器镜像来保障不同开发人员的需求是非常必要的，也是机器学习平台的基本功能。

选定容器技术后，如何支持、编排、多资源混合调度也是需要考量的。早期内部使用自研开发的容器调度编排工具，但是无法有效支持混合资源管理，所以转型过程中考虑引入业内活跃开源组件，通过与开源社区紧密联系保障架构的可持续演进。机器学习平台天生就和大数据强相关，因此 Yarn 作为大数据平台的调度核心是我们可选方向之一。但是 Yarn 对容器、GPU 的友好性比较差，同时业内 Kubernetes 已经成为容器编排、调度的事实标准，因此选择 Kubernetes 作为我们 AI 基础平台的底层支撑也就顺理成章了。

华泰证券的 AI 基础平台服务于量化平台、数据科学开发平台，因此天然需要支持异构框架，除了需要对接 Kubernetes 集群，还需要同时对接 Spark 集群实现离线学习。随着分布式计算的逐步成熟，以及深度学习模型的快速增长，业务对于在线深度学习的需求越来越强，因此华泰证券 AI 基础平台需要支持在线分布式机器学习，为用户带来更快的模型迭代速度，同时通过流数据及时修正模型参数，真正形成模型开发、发布、修正的闭环。因此我们在原生 Kubernetes 集群和 Spark 集群基础上实现了 JOB 类型任务、在线服务类型任务、SideCar 机制。同时由于原生的 Kubernetes 是通过内部 namespace 实现资源配额而无法实现跨集群资源配额限制，因此我们的 AI 基础平台额外实现了自身的配额管理，面对多集群实现统一的用户资源隔离。

架构分析

AI 基础平台主要包括几大模块：

• 任务解析模块，负责将上游提供的 Job 任务进行解析，包括 Kubernetes 类型任务、Spark 类型任务、DAG 类型任务、Batch Job 类型任务，等等；

• 任务调度模块，负责两级调度功能；

• 逻辑资源管理模块，负责统筹多集群、异构集群的资源管理；

• 状态管理模块，负责对 Job 任务进行状态探测和管理；

• 模板管理模块，负责抽象出可复用模板，实现模板复用；

• 异构代理模块，负责跨多集群、跨异构集群的对接。

跨集群资源管理

针对跨集群管理用户组资源配额的需求，我们采用了逻辑资源管理，将异构集群内的所有资源进行逻辑分割，面对不同的用户组分配不同的资源配额，主要是为了整合不同集群的资源，不需要面对单个集群资源过大导致迁移困难问题，同时单集群迁移时可以实现在线不中断服务。

DAG 支持

面对机器学习中最基础的任务调度问题，我们采用了任务调度模块，支持单次任务调度和定时任务调度，同时在面对机器学习的可视化建模，数据的抽取、转换、加载（ETL）等业务复杂情况下，需要基于 DAG 的调度管理。一个完整的 DAG 主要包括数据读取/数据预处理、特征工程、模型训练、模型预测、模型评估、模型固化。任务调度模块通过对任务中的 Node 信息解析，转化为上下文强依赖的任务，以此保证 DAG 的有向无环图特性。

Kubernetes 上的 Master-Worker 与 SideCar 模式

类似于 Spark on K8s 模式，一个 Job 任务发送到 AI 基础平台，将会在经过前置分解后，交由 Master Pod 进行整个 Job 任务的处理。同时 Worker Pod 使用 SideCar 模式与 Master Pod 保持心跳和状态同步，可以实现在无侵入客户应用容器情况下完成定制化改造。Sidecar 在 Kubernetes 中是一个辅助容器的概念，和主容器跑在同一个 pod 中。同时 Sidecar 由我们平台团队自己提供，对应用户只需要提交自己的应用镜像，定义输入输出和特殊参数等。同时基于该 Master-Worker 与 SideCar 模式，可以方便地支持分布式框架。AI 基础平台可以定制化提供 SideCar 实现不同用户的需求，例如支持 CDH 环境 Kerberos 认证获取行情数据、特殊流量管控等等，而不需要用户修改自己的应用镜像。

整个流程如下：

1. 用户向 AI 基础平台提交 Job 任务

2. AI 基础平台将 Job 任务分解，解析

3. 根据任务类型与逻辑资源管理判断提交任务的集群

4. 通过异构代理模块在 Kubernetes 集群中初始化 Master Pod

5. Master Pod 根据任务需求在集群中孵化 Worker Pod

6. Worker Pod 通过 SideCar 容器初始化工作上下文，与 Master Pod 交互

7. Worker Pod 内应用完成后，由 Master Pod 控制 SideCar 实现有状态容器管理，优雅退出

Module 形式管理

支持模板定义，简化了用户提交任务的参数复杂度。不同用户组所需的模板不同，例如量化平台某些团队所需的模板里面需要访问某些特定数据集，需要初始化一些高频、低频因子数据，而另一些团队对于数据源的需求不同，但是对于整个团队而言基本上这些定制化的需求都相同。因此通过模板实现大部分配置通用化，可以让用户更专注于自身业务。

二级调度：让 Kubernetes 集群支持 Batch 类型

Kubernetes 默认的 Kube-scheduler 通过 list watch Kube-apiserver 获取需要 bind node 的 Pod，利用全集群串行，保障资源不会发生冲突。但是该串行是以 Pod 为粒度的，当出现前置 Batch Job 资源不够，而后置 Batch Job 某些 pod 资源满足，很可能会导致整个集群的资源死锁，比如两个 Batch Job 单独提交可以完成调度，但是同时提交则会每个 Batch Job 占用一些资源而无法同时启动。在许多机器学习的分布式框架中，比如 Ps-Worker，需要所有 worker 都启动后，训练才能正常进行。

为了解决无法支持 Batch Job 任务调度的问题，AI 基础平台采用了二级调度的方法。其核心思想是将一个 Batch Job 的所有 Pod 当做整体来调度，当该 Batch Job 所有 Pod 都能启动，才进行下一个 Batch Job 的调度。同时会动态调整 Batch Job 在调度时候的优先级，考虑在集群资源不足时优先保障资源需求较少的 Job 完成任务，提高用户的体验。从而避免了任务间的资源死锁，提高了资源的利用率。后期打算参考 Kube-batch 队列的机制，不同队列直接可以设置优先级，优先级高的队列的任务会优先得到调度，队列还可以设置权重，权重高的队列分配到的资源会更多。

目前华泰证券内部的 Spark 集群主要使用 Yarn 来支持资源调度，由于 Yarn-client 模式下 Application 发生故障时，直接在 Client 端查看日志、定位错误较为方便。因此目前华泰内部 Spark 集群主要采用该模式。而 AI 基础平台二次调度模式对于 Yarn-client 模式同样可以无缝支持，即当该 Batch Job 所有 Executor 都能启动，才进行下一个 Batch Job 的调度。

未来展望

对于机器学习和深度学习来讲，算力集中化和工程平台化是未来持续演进的方向。脱离以前的烟囱式发展，赋能平台用于管理不断爆发式增长的算力，持续提高资源利用率，降低算力使用成本，对算法用户便捷可用，是 AI 基础平台的持续演进方向。

未来华泰证券的 AI 基础平台将会支持更多的通用分布式训练框架，比如 Ray，以帮助用户进行代码分布式改造。由于证券行业的特殊性，AI 基础平台对数据的访问控制，对流量策略会有很强的安全性考量，因此考虑利用 Service Mesh 实现全平台的访问策略管理。AI 基础平台最重要的是稳定性、性能和安全，因此下一阶段希望能将基于 Job 粒度的监控和任务状态异常探测加入其中。

作者介绍：

刘赐民，曾就职于中兴通讯、苏宁易购，一直从事云平台、大数据平台相关工作，目前是华泰证券数据科学中心平台团队的资深工程师，也是 Kubernetes、CNI、Kata-container 等项目的 contributor。