AI 企业多云存储架构实践 | 深势科技分享

2020 年末，谷歌旗下 DeepMind 研发的 AI 程序 AlphaFold2 在国际蛋白质结构预测竞赛上取得惊人的准确度，使得“ AI 预测蛋白质结构”这一领域受到了空前的关注。今天我们邀请到同领域企业，深势科技为大家分享其搭建基础平台时的实践与思考。AI 场景中的使用的数据有哪些新特点？混合云架构如何与超算平台结合？为何会选择 JuiceFS？

背景

深势科技成立于 2018 年，是 “AI for Science” 科学研究范式的先行者，致力于运用人工智能和分子模拟算法，结合先进计算手段求解重要科学问题，为人类文明最基础的生物医药、能源、材料和信息科学与工程研究打造新一代微尺度工业设计和仿真平台。

新一代分子模拟技术，是深势科技研究问题的本质方法；高性能计算、机器学习、科学计算方法，这些是研究分子模拟技术的一些工具和手段。

Hermite 和 Bohrium 是针对不同行业领域的解决方案，Hermite 是针对药物研发领域的一个计算设计平台， Bohrium 是针对材料和科学领域的微尺度计算设计平台，Lebesgue 是任务调度和算力编排平台。

什么是 AI for Science

一直以来对科学研究有两大范式，第一个是以数据驱动的开普勒范式。第二个是以第一性原理驱动的牛顿范式。

开普勒范式是通过观察、总结的方式，研究事物的规律，开普勒范式三大定律就是通过不断的天文观测，前人积累的天文经验总结出来的。开普勒范式属于数据驱动，通过观察事物的现象，总结规律，然后拿它解决实际的问题。这种方式解决问题有一个缺点，可能会出现知其然不知所以然的情况，很难泛化。

牛顿范式是从事物的本质出发，通过第一性原理，发现事物的规律。牛顿范式属于模型驱动，模型驱动比较准确，但因为计算的量大，很难用以解决实际的问题。

AI for Science (下文简称 AI4S） 就是希望把这两大范式结合起来，用 AI 去学习科学原理，然后得到模型，进而去解决实际的问题。

AI for Science 范式如何解决科学原理工程化问题

药物研发领域，大家比较熟悉的是明星公司 Deep Mind 开发的一款人工智能程序 AlphaFold，简单来说是做蛋白质的结构预测；材料研发主要是做材料的性质研究，新材料发现等。这两大领域本质研究的是微观粒子的相互作用，微观粒子的运动轨迹。在高中化学的时候，老师讲过结构决定性质，性质决定用途。微观粒子的研究会用到薛定谔方程、密度泛函方程、牛顿力学方程等基本方程，这些都是在不同的尺度下的微观粒子的运动轨迹、运动状态的方程。

如果直接用第一性原理去解决问题的话，实际上是比较困难的，会陷入维数灾难问题。 AI4S 新范式就是用 AI 去学习和表示一系列的物理方程，进而去攻克维数灾难，在精度和效率之间取一个平衡。

混合云架构的选择与挑战

为什么选择混合云架构

深势科技作为一家初创公司，为什么在开始的时候就选择了混合云的架构，总结下来，主要是有三点：

第一点业务算力的需求， AI4S 领域的主战场是在超算，一些院校和研究所都有自己的超算机器。比较著名的就是天河系列，天河系列在 2014 年的时候拿到过 Top500 的第一名，它对计算的性能和算力的要求是非常高的。

上图计算任务算力需求： 128 张 A100s 的卡运行 5 天的时间。

下图是一个训练任务，分为三步，每一步对资源的需求差别是比较大的。第一步和第三步，对 GPU 的资源要求比较高，第二步它对 CPU 的需求是比较大的，需要 10000+ 核的 CPU 资源。这也是 AI4S 的一个特点，同一任务对资源的需求，在不同阶段差异是比较大的。

第二点是客户的诉求，一些客户在使用深势科技的资源或者产品之前，可能已经是 AWS 、阿里云或者其他超算的用户，客户希望他们的资源能够最大的程度的复用，从而提升资源的利用效率。

第三点是资源的可用性，算力平台负责给 AI4S 领域的工业客户或者科学研究院校提供算力资源，他们对资源的需求是很大的，在资源使用过程中也会用到一些抢占式资源和潮汐资源，对资源的可用性或者资源的丰富度要求高。所以选择混合云架构，也是比较大的一个优势。

混合云架构的挑战

首先是基础设施的差异性，公有云是比较开放的，买了一台机器之后，就有了这台机器的 root 账号，资源在底层做了虚拟化隔离，你可以在这个机器上做任何你想做的事情，不会影响到其他人。但是超算相对是比较封闭的，超算的环境是共用的，用户之间是逻辑隔离的，超算更多的是把资源拿出来让你去使用，但是你很难拥有资源的主导权，你在超算机器上安装一个软件，这个软件可能跟别人的软件是有冲突的，所以不能随意安装。

第二个是运行时环境的差异性，公有云上跑服务的话会打一个镜像，把程序依赖的一些操作系统以及依赖的一些软件都会装到镜像里面，直接做分发，这样就能屏蔽运行时环境的差异性。但在超算里面主要是借助 module 工具管理环境变量，解释下，module是Linux下的一个管理环境变量的工具。如果想用一个软件的话，需要通过 module 的方式把这个软件增加进来，然后再去使用。

第三点是用户体验的一致性，基于上面两点，公有云和超算还是有比较大的差异性。这会导致用户在使用的体验上会有比较大的差异。如何把差异补齐，让用户在日志、监控的查看上都有一致性的体验，对架构上也是一个挑战。

云与超算融合的探索

第一点就是容器化，超算上主要是用的是 Podman 和 Singularity容器镜像，使用Docker 是比较难的，因为 Docker 需要在主机上启动一个 daemon 的进程，其次还需要 root 账号。这两点在超算上实际上都是不太方便的，所以超算上一般用的比较多的就是 Singularity 镜像，Podman 和 Docker 镜像有比较好的兼容性，也慢慢流行起来。

第二点是 Slurm on K8s ，Slurm 在超算平台上是常用的一个资源调度的框架，早期安装 Slurm 是需要在物理机上直接安装，但是随着对资源弹性的需求，我们希望 Slurm 能直接装到 K8s 里面去。当用户需要 Slurm 资源的时候，可以基于 K8s 去分配资源，然后在分配的 pod 上安装 Slurm。

第三点就是 Virtual Kubelet，这是一个虚拟的 kubelet 技术。在阿里云和 AWS 的弹性资源上也都有一些应用，相当于把一些算力资源通过桥接的方式让 K8s 能使用起来。在超算上我们也在探索这种方案，让 K8s 集群通过 Virtual Kubelet 的方式使用超算的资源。

存储架构的思考与实践

举一个业务场景的存储例子，在药物研发场景中，分子对接具有十分重要的应用价值，分子对接就是两个或多个分子之间相互识别的过程，目的是找到药物分子与致命靶点的最佳结合模式。一次分子对接的过程中数据的需求如下：会产生约 6 亿的小文件，文件压缩前有 2.3T， 压缩后有 1.5T，单文件的大小大约 4k。

文件比较小的话，数据处理的难度会比较大。比如：在 Linux 上去处理很多的小文件时，它首先会有 inode 个数的限制，其次小文件比较多的话，读取的速度也上不去。

存储诉求

基于上述的业务场景，我们总结下对存储的诉求。
第一是文件的多样性，除了小文件，在实际业务场景中还有中文件、大文件，所以多种大小的文件，都需要有一个比较好的支持。

第二点是存储层的抽象与统一，在 AI 领域，很多都是使用 Python 的服务，Python 的服务对POSIX 接口是比较友好的，如果用户在使用存储的时候，需要频繁地通过 S3或OSS 去下载数据的话，会对用户会有体验上有影响。

第三点是方案的通用性，在公有云上会有很多的存储方案，在一家云上使用，完全没问题，非常的好用。但如果想把这种方案放到超算上去，或者放到一些线下的集群，实际上就不是那么通用了。

第四点是数据的分层，我们的数据是有典型的冷热特性，在一个任务在计算过程中，它用到的数据是热数据，任务计算之后或者过了几天之后，这个数据就变成了冷数据，我们对冷数据的读和操作是比较少的。

最后一点就是安全性的考虑，希望存储上能有一些业务的隔离，配额、授权以及删除之后的回收站等，来保障数据的安全性。

方案选型 & JuiceFS 测试

• 第一点是功能满足度，这个方案肯定要满足上述我们对存储上的功能需求。
• 第二点是技术栈，所采用的技术栈最好是能和公司使用的技术栈是匹配的。
• 第三点是可运维性，希望这个方案的运维相对来说比较容易，如果方案本身的复杂度比较高，那么出了问题之后，解决问题就比较麻烦和复杂。
• 第四点是社区活跃度，调研的时候我们发现JuiceFS 社区是非常活跃的，在使用过程中，有问题的话，会直接发到 JuiceFS 社区群里面，不论是晚上还是周末，社区的响应都是非常及时的，包括创始人苏锐也经常在群里面回答问题，所以社区的活跃度也是我们在方案选型的时候一个非常重要的考量点。

在做方案选型的时候做了一些测试，供大家参考，主要是以下几点：

第一点是 POSIX 的兼容性，我们对 POSIX 兼容性会考虑得比较多，如果 POSIX 兼容性不好，这个方案基本上是没法用的。

第二点是性能的基准测试，性能测试的数据见下图。

第三点是 K8s的CSI 挂载，我们有一些业务是通过 K8s 调度的，自然是希望存储对 K8s 比较友好。

第四点是业务PoC验证，测试的场景还是比较多的，从小文件中文件大文件，还有包括顺序读，顺序读里面又分为预热和不预热。

JuiceFS 有个功能特别好用，就是预热的功能，当我们需要运算的时候，可以把一些数据提前的去做预热。这功能对我们来说就非常实用，计算过程中任务依赖昂贵的GPU资源，成本是比较高的，一般我们会提前把数据预热到本地，然后再开启任务的运行。

上图是我们整体的存储架构，底层是基于对象存储的统一的存储，然后再往各个地方的计算中心分发数据，不论是超算，还是云机房也好，都是有一个缓存的集群。当任务开始的时候，会把数据从统一的存储中拉到计算集群就近的一个缓存集群里面去，在计算任务运行的过程中，只需要和本地的存储集群做通信。

JuiceFS 可以把数据缓存到本地，当数据比较旧的时候，它就会被淘汰掉。如果没有用 JuiceFS ，我们需要自己去做缓存的淘汰机制，想做好，还是有一定的成本的。但是有了 JuiceFS 之后，我们就不用考虑这个事情了，只需要把 JuiceFS 挂载上去，它就帮我们把这些事情都做了。

深势科技目前使用的是一个开源版本的 JuiceFS，以 redis 作为元数据管理，使用 SSD 做数据缓存。

深势科技生产环境使用情况

总结与展望

云与超算融合是趋势，现在一些公有云上都有超算服务，或者叫高性能计算服务，高性能计算集群等。超算也是不断的在往云上去靠，超算里面提到了一些超算云或者云超算的概念，就是通过虚拟化的技术，通过云原生的技术，把超算的资源更好、更方便的提供出去，让大家使用。

第二点容器化是关键，我们在做云与超算的融合的过程中，怎么样把运行时的环境保持一致，是一个很关键的点。如果在云上用的是容器，但在超算上用的是另一套方案，会出现服务在云上跑得好好的，但放到超算上之后就跑不起来，所以容器化是一个比较关键的点。

第三点统一存储是基础，调度相对来说是比较容易的，把算力从公有云上调度到超算平台上，其实是比较简单的，但是将存储调度过去难度就增加了。

这里面会有几个难点，第一点怎么样把数据从一个地方传输到一个地方。数据量小倒还好，但是数据量比较大就非常困难了。第二点是传输的网络，也会影响到数据传输的速度。第三点是数据的引用，把数据搬迁过去之后，怎么样和原来路径或结构保持一致，在不改程序的情况，也能继续运行。最后是数据的整合，比如整个计算过程中分为 5 步，前 2 步是在云上算的，最后 3 步在超算上算的，会牵涉到数据的整合，日志的整合，监控的整合。

最后，存算分离是必然，如果机器资源和存储是绑定的，是没法去做调度的。早期，我们的存储和机器算力是绑定的，机器上挂载了本地盘，当把计算任务调过去之后，存储是调不过去的，所以说存算分离是必然。

如有帮助的话欢迎关注我们项目 Juicedata/JuiceFS 哟！ (0ᴗ0*)