【蚂蚁】蚂蚁集团AI大规模存储加速实践.pdf

1、蚂蚁集团AI大规模存储加速实践蚂蚁集团 刘键目录 大规模存储加速场景面临的问题 蚂蚁整体方案介绍 正在做的事&未来计划大规模存储加速场景面临的问题PART 1文件类型多，缓存加速需求不尽相同 如何同时满足各场景的需求文件类型文件大小数量读写操作性能需求图片1100K10亿100亿级顺序读延迟、QPS视频100M1G千万级随机读吞吐Checkpoint1G100GB百万顺序读、写延迟、吞吐NLP 文本10k100M千万级顺序读，随机读吞吐列存数据10M1G百万级顺序读，随机读吞吐元数据规模急速增长 如何应对大模型时代元数据规模的急速增长2022单次训练:千万文件+GB/TB级 数据集群规模:亿级

2、文件+50TB 数据2023单次训练:10亿文件+100TB 数据集群规模:50亿文件+500TB 数据2024单次训练：百亿文件+PB级 数据？集群规模：千亿文件+10PB 数据？和训练混部时的性能问题 部署上的变化 为了更好的利用率存储资源 同地域近端机房-同集群混部-同节点混部 大规模训练任务混部时的长尾和毛刺问题 随着训练任务规模的增大，单文件读取平均延迟增大，同时长尾问题越越来严重。020040060080010001200140010卡50卡200卡500卡平均延迟(ms)P75(ms)P90(ms)Failover时间长，线上运维成本高 节点重启时间长，导致线上运维难以操作、Fa

3、ilover 时间过长等 5 亿文件规模的集群，master初始化需要 12 小时。5 千万 block 的 worker 重启注册需要3小时，集群全量节点重启恢复需要 10+小时。多副本的成本高 多模态的训练数据已达百 TB 级，通过多副本提高服务 SLA 的额外存储成本过高。一般只为部分类型数据提供多副本能力，e.g.checkpoint。蚂蚁整体方案介绍PART 2蚂蚁缓存加速解决方案 多类型+多语言 API 自动预取优化 小文件折叠 基于联邦集群的元数据横向扩展 Follower read 支持单集群元数据扩展 Worker 异步注册，加快重启的恢复时间 云原生储存 分布式预热系统 弹

4、性决策系统用户接入Runtime基础设施层蚂蚁缓存加速当前规模2.6PB130亿多模态、NLP、传统机器学习、大数据离线处理等场景文件数存储量如何支持百亿元数据-1：提高元数据处理能力-横向扩展 联邦集群：提供集群级别的元数据横向扩展能力。Follower read：提供单集群内的元数据横向扩展能力。如何支持百亿元数据-2：减少元数据规模-文件折叠适配多类型缓存读写需求：客户端预取优化 基于用户读取方式 随机读时自动关闭预取，减少不必要的网络开销 顺序读时自动打开预取，提高网络传输效率 基于文件类型/用途 读取大文件时，e.g.training checkpoint，自动多并发读取远端的数据到

5、 local cache。Failover自动化&加速：云原生存储 基于云原生的方式部署服务 Pod 管理计算资源 PVC 管理存储资源 故障时的自动恢复 通过 Pod name、PVC name 的管理，在非物理机故障时的 Pod 重启做到服务数据不丢。物理机故障时，主动触发数据的迁移或预热。训练混部下的长尾问题解决 完善数据链路 metric 读取链路 worker、proxy 各节点的吞吐、延迟的分布统计，e.g.mean，p75，p90，p99。系统监控信息，e.g.网络情况、系统负载 load。带宽问题 混部场景下，要根据带宽情况留意单机上调度的 Alluxio worker、pro

6、xy 和训练 worker 数量。可以通过 K8s Anti-Affinity 做节点打散。必要的时候可以改造 Client SDK 通过 RPC 直连 Alluxio worker，减少 proxy 带宽开销。当前在做的事&未来计划PART 3正在做的事：基于 K8s 容器编排能力完善故障机自动恢复 故障机未完全下线 创建新 Pod。自动迁移故障机数据到新 Pod。迁移完成后，删除原始 Pod，并启用新节点。故障机下线，无法提供服务 创建新 Pod。自动创建预热任务，对丢失