共计 4840 个字符，预计需要花费 13 分钟才能阅读完成。
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✿)