共计 5103 个字符，预计需要花费 13 分钟才能阅读完成。
主动驾驶是最近几年的热门畛域，专一于主动驾驶技术的守业公司、新造车企业、传统车厂都在这个畛域投入了大量的资源，推动着 L4、L5 级别主动驾驶体验能尽早进入咱们的日常生活。
主动驾驶技术实现的外围环节是主动驾驶模型的训练，训练数据是由汽车理论采集回来的实在路线驾驶视频，数据规模无数 PB 到数十 PB 之多。在模型训练之前，先要对这些原始视频进行解决，截取其中的关键帧保留为照片。而后再由业余数据标注团队在图片上标记要害信息，比方红绿灯、路线标记等。最终通过标记的数十亿图片和标记数据成为真正要「喂给」训练框架的内容。
相熟分布式系统和分布式存储的敌人肯定晓得，LOSF（Lots of Small Files，海量小文件）是存储畛域的大难题。而在人工智能 CV（Computer Vision）畛域中基于 LOSF 的训练又是刚需，包含主动驾驶、人脸识别、物体检测等细分畛域。
本篇文章来自 JuiceFS 某主动驾驶行业客户的架构实际，在百亿规模小文件训练场景下进行了一系列胜利的摸索，心愿能为相干行业的利用带来一些参考和启发。
百亿小文件治理的极致挑战
主动驾驶零碎的训练数据集大多有数十亿到数百亿小文件（小于 1MiB 的文件），一次训练通常须要数千万到数亿文件。而且训练 worker 每一次生成 mini-batch 都须要频繁拜访存储系统，其中大部分是对元数据的申请，因而，元数据性能间接影响模型训练的效率。
这就要求存储系统不仅要具备治理百亿文件的能力，还必须在高并发申请下，放弃低时延、高吞吐的元数据性能。
在存储系统选型中，对象存储是可能承载百亿规模文件的，然而短少原生目录反对、短少残缺 POSIX 语义反对、元数据性能弱这三方面的问题让对象存储并不适宜海量小文件训练场景。
在一些常见的分布式文件系统架构设计中，HDFS 并不适宜存储小文件，尽管能够采纳 Scale-Up NameNode 和联邦（federation）的形式包容肯定规模的数据，但要存储百亿级小文件仍然是一件十分艰难的事件；CephFS 的 MDS 尽管有 Scale-Out 能力，但单过程的并发解决能力不高，随着 MDS 集群规模的增长过程间协调开销增大，使得整体性能达不到线性增长。
尽管在 TensorFlow 中反对将多个小文件合并成大文件的 TFRecord 格局来升高训练过程中对存储系统的元数据负载压力，然而在主动驾驶畛域，这种计划升高了数据集随机取样的精度，而且其它训练框架（如 PyTorch）也不兼容，造成很多不便。
JuiceFS 如何解决？
JuiceFS 是面向云原生环境设计的开源分布式文件系统，JuiceFS 的翻新在于：
- 能够用任意对象存储作为数据长久层，保留数据内容。无论任何私有云、公有云环境，只有有对象存储服务，都能用 JuiceFS；
- 100% 兼容 POSIX、HDFS、S3 三大支流拜访协定，能对接所有利用；
- 元数据引擎是可插拔架构，反对包含 Redis、TiKV、MySQL 等多种数据库作为存储引擎，同时，也提供兼具高性能和海量存储的商用元数据引擎。
JuiceFS 的商用元数据引擎采纳 Raft 算法组成分布式集群，保证数据的可靠性、一致性和高可用性。元数据全副存储在节点的内存中，保障低时延响应。元数据引擎采纳动静目录树计划进行横向扩大，每个分片（shard）是一个独立的 Raft 组，文件系统目录树能够任意划分，调配到须要的分片中，主动平衡与手动平衡相结合。分片机制对于客户端拜访通明。
灵便配置缓存大幅晋升训练效率
既然训练任务须要频繁拜访存储系统，每次通过网络的开销叠加起来也是不小的冗余，目前工业界都在摸索存储与计算拆散后的缓存减速计划。JuiceFS 曾经内置了缓存能力，客户端拜访过的数据，能够主动缓存在该节点指定的存储介质上，下次访问就能间接命中缓存，不必再通过网络读取。同样，元数据也会主动缓存到客户端内存中。
缓存机制在应用上是通明的，无需扭转现有利用，只有在 JuiceFS 客户端挂载时增加几个参数，阐明缓存的门路、容量等信息即可。缓存对于训练减速的成果非常明显，能够参考咱们另外一篇文章「如何借助 JuiceFS 为 AI 模型训练提速 7 倍」。缓存不仅能减速训练，还能显著缩小对象存储 API 的调用，从而升高费用开销。
对于分布式训练平台来说，雷同的训练数据可能会被不同的工作共享，这些工作不肯定会被调度到同一个节点上，如果是散布在不同节点那缓存数据还能共享吗？利用 JuiceFS 的「缓存数据共享」个性，多个训练节点独特组成一个缓存集群，在这个集群中的训练任务都能够共享缓存数据。也就是说当训练任务所处的节点没有命中缓存时，可能通过同一集群中的其它节点来获取数据，而不必去申请远端的对象存储。
训练节点可能不是一个动态的资源，特地是在容器平台里，生命周期的变换是很快的，是否会影响缓存数据共享的成果呢？这就要引出下一个问题。
缓存机制在弹性集群中的挑战
每一家主动驾驶畛域的公司都有很多算法研究员、工程师，他们的算法要共享公司的计算资源实现训练和验证。从平台角度讲，资源弹性伸缩是一个进步整体利用率的好办法，按需给每个训练任务分配资源，避免浪费。
但在这种弹性伸缩的集群中，后面提到的本地缓存数据会受到肯定影响。尽管缓存集群通过一致性哈希确保了当集群成员发生变化时，须要迁徙的数据尽量少，然而对于大规模的训练集群来说这样的数据迁徙还是会对整体的训练效率造成影响。
有没有一种办法既能满足训练集群资源弹性伸缩的需要，又不显著影响模型训练效率呢？
这就须要 JuiceFS 独有的「独立缓存集群」个性了。
所谓独立缓存集群，就是将负责存储缓存数据的节点独立部署，提供常驻的缓存数据服务。这样不会受训练集群动态变化的影响，让训练任务有更高、更稳固的缓存命中率。
整体零碎的架构如下图所示：
比方有一个动静的训练集群 A 和专门用来做缓存的集群 B，他们都须要应用雷同的挂载参数 --cache-group=CACHEGROUP 来构建一个缓存组，其中集群 A 的节点挂载时须要加上 --no-sharing 参数。当集群 A 的利用读数据时，如果以后节点的内存和缓存盘上没有该缓存数据，它就会依据一致性哈希从集群 B 中抉择一个节点来读取数据。
此时整个零碎由 3 级缓存形成：训练节点的零碎缓存、训练节点的磁盘缓存、缓存集群 B 中的缓存，用户能够依据具体利用的拜访特点配置各个层级的缓存介质和容量。
为了确保当磁盘损坏时不会对训练任务产生影响，JuiceFS 还提供了缓存数据容灾能力。如果缓存节点的磁盘意外损坏，更换新的磁盘后 JuiceFS 能够主动重建须要的缓存数据。
如何实现混合云中的降本增效？
主动驾驶的训练任务须要大量的 GPU 资源，在充分利用的状况下，本人在机房中洽购 GPU，能够比应用私有云便宜不少，这也是目前很多主动驾驶公司的抉择。然而，在机房中自建存储系统则没这么简略，会遇到两个挑战：
- 数据增长快，洽购很难跟上扩容速度，一次买太多，又会造成节约；
- 保护大规模的存储集群，必须面对磁盘损坏等问题，运维老本高，效率低；
相比自建存储系统，私有云上的对象存储服务能够弹性伸缩，有限扩容，单位成本便宜，数据的可靠性和服务的可用性相比机房自建存储都更高，是存储海量数据的不错抉择。
JuiceFS 非常适合这种 IDC 机房 + 私有云的混合云架构。用户将本人的 IDC 机房与私有云专线连贯，数据通过 JuiceFS 长久化到私有云对象存储中，在 IDC 机房里设置一个缓存集群，起到缓存数据减速训练的成果，相比每次从对象存储拜访数据，既能节俭专线带宽，还能节俭对象存储 API 调用费用。
当混合云架构联合 JuiceFS 之后，既享受了云存储带来的便当，又通过自建 IDC 升高了 GPU 老本。对于训练平台的使用者、维护者来说都非常简单不便，满足企业多样化的基础设施架构设计需要。
多机房的数据同步与治理
在这个实际案例中，客户有两个 IDC，相距上千公里，训练任务也会被调配到两个 IDC 中，因而数据集也须要在两个 IDC 中被拜访。之前，客户是手工保护将数据集复制到两个 IDC 中。应用 JuiceFS 后，「数据镜像」个性能够省去此前的手工劳动，数据实时同步，满足多地协同工作的需要。
具体来说，数据镜像性能须要在两个 IDC 中都部署 JuiceFS 的元数据集群，当数据镜像启用后，原始文件系统会主动将元数据复制到镜像区域。镜像文件零碎被挂载后，客户端会从原始文件系统的对象存储拉取数据，写入到镜像文件零碎的对象存储。镜像文件零碎挂载后，数据会优先从本地的对象存储读取，如果因同步未实现而呈现读取失败，则会尝试从原始文件系统的对象存储读取。
启用数据镜像后，所有数据能够主动复制到两个对象存储中，起到异地灾备的作用。如果不须要异地灾备，在镜像区域能够不配置对象存储，只进行元数据的复制，数据能够提前预热到镜像区域的独立缓存集群来减速训练。这样能够省去一份对象存储的老本，本案例中的客户就采纳了此计划。
全方位数据安全爱护
不论是为了实现辅助驾驶还是真正的主动驾驶，日常都须要通过路采车收集大量的路采数据，这些数据会再通过一些解决流程二次加工当前最终存储到企业的存储系统中。主动驾驶企业对于这些数据的安全性和可靠性有着极高的要求，因而数据保护是一个十分要害的问题。
咱们首先来看看企业上云当前的平安问题。很多时候企业对于上云会存在肯定的数据安全担心，特地是当波及到一些敏感数据时。JuiceFS 提供的「数据加密」个性同时反对传输中加密（encryption in transit）和动态加密（encryption at rest），保障上云过程中各个环节的数据安全性。
其次可能面临的是数据管理问题。为了避免数据透露或误操作，企业可能须要针对不同团队、不同用户进行权限治理和管制。JuiceFS 托管服务通过「拜访令牌」能够限定某个 IP 范畴的读写权限以及可拜访的子目录。挂载之后，JuiceFS 反对基于「用户 / 用户组」的权限治理模型，能够灵便针对团队或者集体进行权限设置。
如果某个用户曾经具备拜访某些数据的权限，也还是须要进一步对数据进行爱护，比方用户可能误删除或者误更新数据。对于误删除，JuiceFS 托管服务提供的「回收站」性能能够确保数据被删除当前的一段时间内可能再次复原。
然而如果数据被误更新了或者因为某种原因损坏了，即便有回收站也杯水车薪，此时 JuiceFS 的「实时数据保护」个性就十分有用了。这个性能的实现原理是保留肯定工夫的 Raft 日志，这样当数据误更新产生时能够通过回放历史日志的形式将过后的元数据恢复。同时因为 JuiceFS 写入对象存储的文件是分块（block）存储，更新文件不会批改历史的 block 而是生成新的 block，因而只有对象存储上的历史 block 还没有被删除就能够残缺复原数据，就像一个能够随时时光倒流的「时间机器」一样！
总结
残缺架构设计
下图是本案例的整体架构图，在机房 A、B 中都部署了 JuiceFS 的元数据集群以及对应的独立缓存集群，模型训练时将会优先通过缓存集群读取数据集，如果缓存没有命中再从对象存储读取数据。在理论测试中，因为缓存命中率十分高，机房 B 简直不须要跨机房拜访对象存储。
下图形容了数据写入流程。客户通过 JuiceFS 提供的 S3 网关写入数据。当新数据写入当前，就会依照后面介绍的数据镜像流程来将元数据复制到另一个机房。同时在两个机房中都有对应的工作负责预热独立缓存集群，确保新数据可能及时建设缓存。
客户收益
这套计划曾经上线到客户生产环境中，上面列一些重要指标：
- 曾经存储了数十亿的文件，仍在持续增长；
- JuiceFS 元数据在数十万 QPS 压力下仍然能提供 1ms 时延响应；
- 模型训练吞吐数十 GiB/s；
- 独立缓存集群命中率 95%+；
- 两个 IDC 之间数据同步的均匀时延在数十毫秒级别。
通过降级到基于 JuiceFS 的存储系统，客户不仅可能轻松治理好海量数据集，同时借助 JuiceFS 的独立缓存集群个性保障了模型训练的效率。运维老本显著升高的同时，机房 + 私有云的混合云架构相比繁多私有云的架构 TCO 也更低，既能利用机房高性价比的计算资源，也能联合私有云上弹性的存储资源。
得益于 JuiceFS 齐全兼容 POSIX 的个性，客户在迁徙过程中，训练任务的代码不须要做任何批改。
通过 JuiceFS 的数据镜像个性，主动地将数据从一个机房同步到另一个机房，解决多地合作问题，也满足了企业异地灾备的需要。
举荐浏览：
Elasticsearch 存储老本省 60%，稿定科技干货分享
我的项目地址 ：Github（https://github.com/juicedata/juicefs）如有帮忙的话 欢送关注咱们哟！ (0ᴗ0✿)
