首先我介绍一下什么是Prophecis(ProphecyInWeDataSphere)？它的中文含义就是预言的意思。
最底层的基础平台就是KubeSphere管理的高性能容器化计算平台。
我们去构建这样一套面向我们当前金融场景或者互联网场景的机器学习平台的时候，我们有两个考虑的点：
第一个点是一站式，就是工具要全，从整个机器学习应用开发的整体的Pipeline去提供一个完整的生态链工具给到用户去使用；
接下来，简单介绍一下我们机器学习平台Prophecis的各个组件的功能。
机器学习开发环境MLLabis
第一个是我们目前已经放到开源社区的组件叫MLLabis，其实跟AWS的提供给机器学习开发人员去用的SageMakerStudio差不多。
我们在JupyterNotebook做了一些定制开发，总体的架构其实就是左上角的这张图，其实主要的核心有两个组件，一个是NotebookServer(RestfulServer)，提供Notebook生命周期管理的各种API接口；另外一个是NotebookController(JupyterNotebookCRD)，管理Notebook的状态。
用户创建Notebook的时候，他只需要选择有权限的命名空间(KubernetesNamespace)，然后去设置Notebook运行时需要的一些参数，比如说CPU、内存、GPU或者是它要挂载的存储，如果一切正常，这个Notebook容器组就会在对应的Namespace启动并提供服务。
我们在这里做了一个比较加强的功能，就是提供一个叫LinkisMagic的组件。我们WeDataSphere开源产品中有个组件叫Linkis，它提供大数据平台计算治理能力，打通各个底层的计算、存储组件，然后给到上层去构建数据应用。
LinkisMagic通过调用Linkis的接口，就可以将JupyterNotebook中写好的数据处理的代码提交到大数据平台上去执行；我们可以把处理好的特征数据通过Linkis的数据下载接口拉到Notebook的挂载存储中去，这样我们就可以在我们的容器平台里面用GPU去做一些加速的训练。存储方面，目前MLLabis提供两种数据存储，一种是Ceph；一种是我们的大数据平台HDFS，关于HDFS这里提一句，我们其实就是把HDFSClient和HDFS的配置文件通过Mount到容器中，并且控制好权限，就可以在容器内跟HDFS交互了。
以上是我们MLLabis的Notebook列表页面；
以上是我们从列表页面进到Notebook的界面。
机器学习分布式建模服务MLFLOW
接下来，介绍我们另外一个组件MLFlow。
我们构建了一个分布式的机器学习实验管理服务。它既可以管理单个建模任务，也可以通过跟我们WeDataSphere一站式数据开发门户DataSphereStudio打通，构建一个完整的机器学习实验。这里的实验任务通过JobController(tf-operator、pytorch-operator、xgboost-operator等)管理运行在容器平台上，也可以通过Linkis提及到数据平台运行。
这里再说明一下，MLFlow与DataSphereStudio之间通过AppJoint的方式交互，这样既可以复用DSS已经提供的工作流管理能力，又可以将MLFlow实验作为子工作流接入到DSS这个大的数据工作流中去，这样构建一个从数据预处理到机器学习应用开发的Pipeline。
这个是我们数据处理和机器学习实验组成的完成数据科学工作流。
这个是MLFlow的机器学习实验DAG界面，目前提供GPU和CPU两种任务类型，支持TensorFlow、PyTorch、xgboost等机器学习框架任务的单机和分布式执行。
机器学习模型工厂ModelFactory
接下来给大家介绍我们的机器学习模型工厂：ModelFactory。我们模型建好之后，我们怎么去管理这些模型，它的模型的版本怎么管理，它的部署怎么管理，模型的校验怎么做，我们用的就是ModelFactory。
这个服务我们主要是基于SeldonCore进行二次开发，提供模型解释、模型存储、模型部署三块的能力。要强调的一点是这一块的服务接口我们也可以接入到MLFlow中去，作为一个Node接入到机器学习实验中，这样训练好的模型，可以通过界面配置快速部署，然后进行模型验证。另外一个要说明的是，如果我们只是单模型的验证，我们主要是使用MF提供的基于Helm的部署能力。如果是构建一个复杂的生产可用的推理引擎，我们还是会用KubeSphere提供的CI/CD、微服务治理能力去构建和管理模型推理服务。
机器学习应用工厂ApplicationFactory
最后一个要介绍的组件，就是机器学习应用工厂ApplicationFactory。
正如刚才所说，我们如果对一些复杂的模型去构建一些复杂的InferenceSevice的时候，其实我们用一个简单的单容器服务其实是不够的，我们要去构成一整套的类似于DAG的一个推理的过程，这个时候其实我们就需要更复杂的容器应用的管理的能力。
ApplicationFactory这一块我们就是基于KubeSphere去做的，我们在前面做好这些模型的准备之后，我们会使用KubeSphere提供的CI/CD工作流去完成整体的模型应用发布流程，模型服务上线之后，使用KubeSphere提供的各种OPS工具去运维和管理各个业务方的服务。
接下来进入到KubeSphere在我们微众银行应用实践部分。
使用KubeSphere前我们面对的问题
我们在引入KubeSphere之前，其实我们面对的问题，主要还是一些运维的问题。当时，我们内部也有用我们自己写的一些脚本或者是AnsiblePlaybook去管理我们这一套或者几套K8s集群，包括我们在公有云上面的开发测试集群，以及行内私有云的几套生产K8s集群。
以KubeSphere为底座开发机器学习容器平台
因此，我们选择了构建一个以KubeSphere为基础运维管理基座的机器学习容器平台。
整体的服务架构基本是跟KubeSphere当前的API架构差不多，用户的请求进来之后，它通过APIGateway定位要访问服务，这些服务就是刚才介绍那些组件，Gateway将请求分发到对应的微服务当中去。各个服务依赖的那些容器平台的管理，就是KubeSphere全栈平台去给我们提供的能力：CI/CD、监控、日志管理，还有代码扫描工具等，然后我们在这一套解决方案之上做了一些改造点，但总体来说改造的东西也不是特别多，因为当前开源的KubeSphere提供的这些能力基本上能满足我们的需求。
我们内部使用的版本是KubeSphere的v2.1.1，我们改造主要如下：
这是我们测试环境的一个管理界面。
其实这里我们主要做了两个事情，第一我们把整个监控的对象跟我们行内的这一套CMDB系统进行结合。
以上这一块是我们做的GPU资源配额定制。
这一块是我们基于KubeSphere的日志查询界面。
未来展望
接下来说下未来的展望。由于我们当前因为我们人力非常有限，然后各个组件开发的压力也比较大，目前，我们还是基于之前的KubeSpherev2.1.1的版本去做的，我们接下来考虑把KubeSphere3.0这块的东西去跟我们现有开发的一些能力做结合和适配。
第二，目前KubeSphere还没有GPU监控和统计指标管理的一些能力，我们也会考虑去把我们之前做的一些跟GPU监控与配额管理等功能迁移到KubeSphereConsole里面去。
最后一个是我们整个WeDataSphere各个的组件基于KubeSphere的容器化适配和改造，我们最终是希望各个组件都完成容器化，进一步降低运维管理成本和提升资源利用率。
说到这里，我就简单再介绍一下我们微众银行大数据平台WeDataSphere。
WeDataSphere是我们大数据平台实现的一整套金融级的一站式机器学习大数据平台套件。它提供从数据应用开发、到中间件、在到底层的各个组件功能能力，还有包括我们的整个平台的运维管理门户、到我们的一些安全管控、还有运维支持的这块一整套的运营管控能力。
社区合作
再展望一下，我们WeDataSpehre跟KubeSphere的未来，目前我们两个社区已经官宣开源合作。
我们计划把我们WeDataSphere大数据平台这些组件全部能容器化，然后贡献到KubeSpehre应用商店中，帮助我们用户去快速和高效的完成我们这些组件与应用的生命周期管理、发布。