网站建设开发岗位职责,厦门有做网站建设,抖音广告推广,营销智库网站2020 年末#xff0c;谷歌旗下 DeepMind 研发的 AI 程序 AlphaFold2 在国际蛋白质结构预测竞赛上取得惊人的准确度#xff0c;使得 “AI 预测蛋白质结构” 这一领域受到了空前的关注。今天我们邀请到同领域企业#xff0c;深势科技为大家分享其搭建基础平台时的实践与思考。…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 步在超算上算的会牵涉到数据的整合日志的整合监控的整合。
最后存算分离是必然如果机器资源和存储是绑定的是没法去做调度的。早期我们的存储和机器算力是绑定的机器上挂载了本地盘当把计算任务调过去之后存储是调不过去的所以说存算分离是必然。
