共计 5292 个字符，预计需要花费 14 分钟才能阅读完成。
简介：深度学习平台在微博社交业务扮演着重要的角色。计算存储拆散架构下，微博深度学习平台在数据拜访与调度方面存在性能低效的问题。本文将介绍微博外部设计实现的一套全新的基于 Fluid（内含 JindoRuntime）的新架构计划，显著晋升了海量小文件场景模型训练的性能和稳定性，多机多卡分布式训练场景可将模型训练的速度晋升 18 倍。
作者 |
吴彤 微博深度学习平台工程师
郝丽 微博深度学习平台工程师
导读：深度学习平台在微博社交业务扮演着重要的角色。计算存储拆散架构下，微博深度学习平台在数据拜访与调度方面存在性能低效的问题。本文将介绍微博外部设计实现的一套全新的基于 Fluid（内含 JindoRuntime）的新架构计划，显著晋升了海量小文件场景模型训练的性能和稳定性，多机多卡分布式训练场景可将模型训练的速度晋升 18 倍。
背景
新浪微博是中国最大的社交媒体平台，每天上亿条内容产生并在万亿级关系的社交网络上进行流传。下图是微博的业务生态图，通过优质用户生产、流传优质内容，普通用户生产这些内容，进而关注本人喜爱的博主，建立联系，造成闭环生态。
微博机器学习平台的次要作用是让整个过程流转得更高效晦涩：通过了解优质内容，构建用户画像，把用户感兴趣的优质内容推给用户，让他们和内容生产者互动，进而刺激生产者生产更多更好的内容, 实现信息消费者和信息生产者的双赢。而随着多媒体内容变成支流，深度学习技术就变得更为重要。从多媒体的内容了解，到 CTR 工作的优化，都离不开深度学习技术的反对。
大规模深度学习模型训练挑战
随着深度学习在微博业务场景中的宽泛应用，微博深度学习平台表演了十分外围的角色。该平台采纳了存储与计算拆散的架构，使得计算资源得以与存储资源解耦，从而实现了灵便的资源配比以及便捷的存储扩大，并且升高了存储老本。
然而，这种架构也带来了一些挑战，其中比拟要害的问题体现在数据拜访性能和稳定性方面：
计算存储拆散架构导致数据拜访高延时，导致训练慢：业务团队应用的深度学习工作（图像或语音模型）会拜访海量小文件。试验表明，HDFS 读取海量小文件场景与本地读取比照性能相差近十倍甚至百倍。
Kubernetes 调度器数据缓存无感知，同一数据源屡次运行拜访仍旧慢：雷同模型、不同超参的；微调模型、雷同输出的；AutoML 等深度学习工作运行会一直反复拜访同一数据，产生能够复用的数据缓存。然而因为原生的 Kubernetes 调度器无奈感知缓存，导致利用调度的后果不佳，缓存无奈重用，性能得不到晋升。
少数深度学习框架并不反对 HDFS 接口，导致开发难：比方 PyTorch，MxNet 等框架只反对 POSIX 协定接口，HDFS 接口须要额定的对接开发。因而须要同时反对模型开发阶段的 POSIX 接口以及模型训练阶段的 HDFS 接口，引入模型代码适配不同存储的复杂性。
HDFS 成为数据并发拜访的瓶颈点，稳定性挑战大：微博机器学习平台上百台 GPU 机器同时训练都会并发拜访 HDFS 集群，同时深度学习训练的 IO 压力比拟大，HDFS 服务成为了性能单点，这对 HDFS 的性能和稳定性提出了微小的挑战。一旦某个工作拖慢了 HDFS 零碎，其余的训练任务也会受到影响。而且，一旦 HDFS 无奈工作，整个训练集群也会受到影响。
通过对微博深度学习平台的监控剖析，咱们发现：一方面因为 IO 性能问题导致 GPU 等低廉计算资源不能被充分利用；另一方面，咱们也发现集群中的内存和本地硬盘的水位很低，余量较多并且稳固，这是因为少数的深度学习工作并不应用本地磁盘，同时内存使用率也不高。因而咱们思考如果可能充分利用集群本身的内存和磁盘资源减速数据拜访会是一种更好的计划。
Fluid + JindoRuntime：为微博深度学习平台提供高效撑持
为了能更好满足大规模深度学习模型训练的计算需要，须要获得更好的数据本地性成果。因而，咱们心愿达到以下指标：
计算可能充分利用本地化拜访数据，这样数据就不需通过网络重复读取，减速深度学习模型训练的速度和晋升集群的 GPU 使用率。
升高 HDFS 负载压力，通过利用对于局部数据的本地读取，减小数据拜访延时和晋升 HDFS 的可用性。
充分发挥热点数据集的缓存节点劣势，在对用户无感知的前提下，智能的将任务调度到数据缓存节点上。让罕用的模型训练程序越来越快。
通过 POSIX 接口读取数据，这样无需在模型开发和训练阶段应用不同的数据拜访接口，升高开发深度学习模型程序的老本。
为了达到上述指标，咱们迫切希望找到 Kubernetes 上具备分布式缓存减速能力的软件。很侥幸，咱们发现 CNCF Sandbox 我的项目 Fluid 正好能够满足咱们的诉求。于是，咱们设计了基于 Fluid 的新架构计划，通过验证比拟，咱们抉择 JindoRuntime 作为减速运行时。
- 架构组件介绍
1）Fluid
Fluid[1] 是一个运行在 Kubernetes 上可扩大的分布式数据编排和减速零碎，它通过数据的编排和应用数据的利用调度，解决云原生编排框架运行此类利用面临数据拜访延时高、多数据源联结剖析难、利用应用数据过程简单等痛点。
2）JindoRuntime
JindoRuntimed[2] 是 Fluid 一种分布式缓存 Runtime 的实现，基于 JindoFS 分布式缓存减速引擎。JindoFS 是阿里云 EMR 团队自研大数据存储优化引擎，齐全兼容 Hadoop 文件系统接口，给客户带来更加灵便、高效的计算存储计划。JindoRuntime 应用 JindoFS 的 Cache 模式进行远端文件的拜访和缓存，反对 OSS、HDFS、规范 S3 协定等多种存储产品的拜访和缓存减速。在 Fluid 上应用和部署 JindoRuntime 流程简略、兼容原生 K8s 环境、能够开箱即用。深度联合对象存储个性，应用 Navite 框架优化性能，并反对免密、checksum 校验等云上数据安全性能。
- 应用基于 JindoRuntime 的 Fluid 的起因
Fluid 能够将数据集编排在 Kubernetes 集群中，实现数据和计算的同置，并且提供基于 Persistent Volume Claim 接口，实现 Kubernetes 上利用的无缝对接。同时 JindoRuntime 提供对 HDFS 上数据的拜访和缓存减速能力，并且能够利用 FUSE 的 POSIX 文件系统接口实现能够像本地磁盘一样轻松应用 HDFS 上的海量文件，pytorch 等深度学习训练工具可利用 POSIX 文件接口读取训练数据。
针对海量小文件的近程数据拜访性能问题，JindoRuntime 对小文件的数据组织治理和拜访性能进行了大量针对性的优化，可能提供高效的小文件拜访性能，远高于间接对 HDFS 的数据拜访性能。
提供元数据和数据分布式分层缓存，以及高效小文件检索。
提供数据预热机制，防止在训练时刻拉取数据造成的数据拜访竞争。
Slab allocation 形式组织文件数据，高效利用缓存空间。
通过 Fluid 的数据感知调度能力，用户无需晓得缓存节点信息就能够将工作搁置到有缓存数据的节点，实现数据拜访性能的劣势最大化。
对于大文件和小文件提供不同的缓存策略和存储形式，对于小文件 AI 训练场景具备很好的自适应性，无需用户配置。
- 落地实际
抉择适合的缓存节点：应用 JindoRuntime 能够取得更好的数据本地性能，在理论生产中咱们也发现不是所有的节点都来做缓存性能就比拟好。起因是有些节点的磁盘和网络 IO 性能不是很好，这个时候须要咱们可能把缓存节点尽量抉择一些大容量磁盘和网络较好的节点下来。Fluid 反对 dataset 的可调度性，换言之就是缓存节点的可调度性，咱们通过指定 dataset 的 nodeAffinity 来进行数据集缓存节点的调度，从而保障缓存节点可高效的提供缓存服务。
指定 Master 调度策略：JindoRuntime 由 master/worker/fuse 三局部组成，master 负责集群的大脑，负责元数据和集群缓存的治理，所以 master 节点得具备很强的可靠性和故障复原速度。在生产过程中咱们发现在不应用多 master 的条件下，单个 master 也具备很强的稳定性和故障复原速度，影响 master 节点稳定性的重要因素还是宿主机的稳定性，比方宿主机满磁盘、通信故障等，基于此咱们对 mater 节点应用 nodeselector 来抉择性能较好的宿主机作为 master 容器的环境，进一步保障 master 环境的稳定性。
定时数据预热：在进行训练前的一个重要的步骤是进行元数据和数据的预热，Fluid 提供了 CRD 的模式进行元数据和数据的缓存，在训练前将训练文件的元数据和数据缓存到本地，可大大减速训练速度。然而存储在 HDFS 上的训练文件是每天一次更新，于是须要进行周期性定时的进行数据预热流程，基于 dataload 的 CRD，咱们应用 cronJob 的模式进行周期性调度，使得在每次训练前都可能实现元数据和数据的筹备，从而进行高效训练。当然 JindoRuntime 自身也反对增量同步的性能，所以每次只须要更新变动的文件即可，也大大放慢了数据预热的速度。
- 性能测试计划
为了验证以上计划的整体成果，咱们从稳定性、性能不同角度进行了验证，这里着重介绍性能测试计划，训练的模型都是基于 mmaction 的视频了解模型，采纳的是 rawframes_train 形式，是领有 400w 图片的训练数据集试验，数据是从实在业务场景中提取的 40w 视频中抽帧失去，每个场景下抽 10 帧图片，因为视频清晰度各异，每张图片大小由几 KB 到十几 M 各异，总计大小 780G 左右，每个缓存节点提供 300G 的缓存空间；同时依据教训个别在 50epoch 左右会实现模型收敛。
而当咱们把测试的视频数据量调整到 100w，总共的数据大小 2T，因为数据量大和延时长，HDFS 接口的形式齐全不能工作；而通过 Fluid+JindoRuntime 则能够满足业务的须要。
测试的流程是会通过 Fluid JindoRuntime 进行数据预热，之后进行模型训练。
- 性能测试后果
联合 Fluid+JindoRuntime 计划，在数据预热的前提下，咱们获得了非常明显的训练速度晋升，从下图能够看到：在 3 机 12 卡的场景下，咱们发现基于 HDFS 接口读取数据的试验往往会因为网络通信等问题中断，导致试验不能跑完，减少异样解决后，workers 之间的等待时间加长，导致减少卡数并不能减少训练速度，反而会拖慢。能够察看到 1 机 8 卡和 3 机 12 卡的场景总体训练速度根本持平，计算资源的扩容。而通过新的计划，咱们发现相比于 HDFS 接口，1 机 4 卡能够失去 5 倍的减速，2 机 8 卡能够失去 9 倍的减速，3 机 12 卡能够失去 18 倍的减速。
因为训练的速度和稳定性失去了保障，端到端的模型训练工夫也失去了显著的晋升，训练总时长由原来的 389 小时（16 天）缩短到了 16 小时。
总结：从两周到 16 小时的训练速度跃升
集成了 Fluid+JindoRuntime 后，显著晋升了小文件场景模型训练的性能和稳定性，在多机多卡分布式训练的状况下，能够将模型训练的速度晋升 18 倍；将过来须要两周能力实现的训练缩减到了 16 个小时。更短的训练工夫和更小的 HDFS 压力，也晋升了训练任务的稳定性，将训练的成功率从 37.1% 晋升到了 98.3%。目前咱们在生产环境的数据量是 4TB，同时随着一直迭代数据量还在持续增长。
微博 AI 训练场景对于数据读取有很高的性能要求，而且海量的小文件对于拜访延时也十分敏感，通过 JindoRuntime 的缓存能力能够无效地对大数据存储系统上的数据进行缓存减速，提供稳固牢靠的高吞吐、低延时的数据拜访性能，同时也能够无效地缓解对后端存储系统的的压力，保障后端存储的稳定性。联合本身的具体场景，优化小文件读取和缓存，不仅能够缓解 HDFS 集群的 IO 压力，也大大提高训练效率。
瞻望
目前 Fluid+JindoRuntime 更像是杀手锏，用来减速小文件场景，而非常规性武器对于所有数据集进行减速优化，咱们冀望可能把弹性的数据减速作为微博深度学习平台的差异化能力，晋升整体训练任务速度和计算资源的利用率；另一方面也帮忙社区一直演进，帮忙到更多的开发者。具体来说：
反对定时工作反对动静扩缩容
数据预热性能的晋升和元数据备份机制的提供，实现疾速重建数据集的能力
提供性能监控控制台
反对 Runtime 元数据的高可用和镜像降级
反对规模化 K8s 集群中多数据集的全生命周期治理
致谢
感激阿里云 JindoFS 团队的辰山、扬礼和容器团队的车漾在整个方案设计和优化过程中的微小帮忙，在简直没有任何利用革新前提下，将数据减速能力赋予了现有利用；同时对于测试和生产环境中的需要和问题也及时业余的提供了反对。
相干链接
更多 Fluid 和 JindoFS 相干介绍请参考以下链接：
[1] Fluid：https://github.com/fluid-clou…
[2] JindoFS：https://github.com/aliyun/ali…
👇👇 戳下方链接，中转我的项目 GitHub 地址！
https://github.com/fluid-clou…
