关于人工智能:AI-应用的全流程存储加速方案技术解析和实践分享

AI 利用对存储系统的挑战是全面的，从离利用最近的数据计算如何减速，到离利用最远的数据存储如何治理，到数据存储和数据计算之间如何高效流通，再到不同利用之间的资源调度如何协调 …… 这其中每一个环节的低效，都有可能连累最终的 AI 工作的最终实现工夫，让 AI 利用在始终期待数据，多个 AI 利用之间无奈高效并发。

本次分享，将以存储系统为视角，对 AI 利用减速中的全副流程进行开展，剖析其中要害节点和解说相应技术，并分享百度智能云在 AI IaaS 建设上的最佳实际，减速 AI 利用。以上内容将为大家在做 AI 存储的方案设计、技术选型、工程实际等方面上提供最前沿的参考。

本文整顿自 InfoQ《公开课》，文末附带 Q&A 和视频回看链接。

01 收场

明天的分享内容次要分为三个局部：

• 第一局部简略梳理一下企业的 AI 训练基础设施的倒退历程，通过展示云原生 AI 训练的一个残缺流程，总结出和其中存储相干的问题。
• 第二个局部对这些问题做一些简略的剖析，分享一下百度智能云是思考和剖析这些问题的。
• 最初一个局部介绍百度智能云的桑田存储在高性能畛域的全流程减速的计划，在这个计划里会对上述存储问题有残缺的解答。

02 AI 训练中的存储问题

企业的 AI 训练基础设施是怎么一步一步倒退到明天的模样的呢？这个倒退过程其实经验了 4 个阶段：

• 阶段一：一开始企业训练的模型和数据量都不太大，最关怀的是训练的性能，对计算之外的其它局部关注比拟少，基础设施是怎么能疾速跑起来怎么来。这一阶段次要是单机的训练，存储应用本地资源，如内存和本地盘。
• 阶段二：等到模型、数据质变大之后，单机训练就不能满足企业的需要，企业开始多机训练。对于存储，一方面数据集可能大到单机无奈存储，另外一方面数据集须要不便地被多机共享。这个阶段，一个便捷和省心的抉择就是去购买商用的网络存储。
• 阶段三：等到企业用户的训练规模、业务规模持续一直的增长之后，购买了越来越多的机器。从企业的角度来讲，心愿可能充沛地把计算资源利用率进步上来。企业在这一阶段引入训练平台解决这个问题，让不同业务的训练可能最大限度的并行跑在训练平台上。这个阶段对存储的需要产生了分化。一方面，数据量大了之后，企业老本敏感，大量的数据须要大容量低成本的存储。另一方面，对于训练的时候须要的那局部数据，还是心愿存储的性能可能满足训练的要求，这一部分依然是一个高性能存储的需要。这个阶段企业的规模曾经绝对比拟大了，有足够的能源去自研或基于开源计划二次开发整个存储体系。
• 阶段四：进入云时代，企业尝试把曾经比拟成熟的体系往云上搬，所以看起来云时代的 AI 训练基础设施架构就是阶段三的翻版， 对于存储而言，依然是“大容量存储 + 高性能存储”的组合。然而这里其实曾经产生了比拟重要的一个变动，就是它的数据流向和阶段三时代是不一样的 ，这在前面的局部有具体的介绍。

当初来看明天的云原生 AI 训练基础设施，最底层是数据湖存储，定位是大容量、高吞吐、高吞吐、低成本、高牢靠的存储底座，是企业进行数据流转的外围。

在数据湖之上，针对 AI 训练的高性能需要，提供一个减速层作为数据湖存储的补充，补救数据湖存储在撑持高性能计算时性能有余的问题。凑近计算的地位有训练平台、各类 AI 框架，和硬件基础设施。

如果咱们仔细观察企业的 AI 训练基础设施的倒退过程，会发现其中的存储问题是一直的累加的，每一个阶段之前的问题依然存在，但又呈现的新的问题。

例如，在阶段一阶段二的时候，次要关怀的是训练效率，这时候对存储的要求是不能拖计算的后端，必须能撑持好计算，这个问题无论是什么时候都是最外围的问题。因而，云原生时代面临的存储问题，涵盖了之前所有阶段的问题，咱们只须要剖析这一个阶段即可失去所有的纳闷和答案。

须要留神的是，从最开始的本地盘，到起初的商用网络存储、冷热分层、数据湖，存储在这个倒退过程中出现进去的一个大趋势就是，存储离计算的间隔越来越远 。这就导致明天咱们去做一个云原生的 AI 训练，会经验一个很长的流程：

• 云原生时代的业务数据首先是集中积攒到数据湖存储中，这里就包含将来用于训练的数据。咱们面临的第一个问题就是数据湖存储如何选型，以保障可能牢靠的寄存企业的海量数据，这就是“①海量数据”问题。
• 筹备训练前，因为数据湖存储不能满足训练时的性能要求，所以训练数据须要转移到一个速度更快的减速层中，这个转移过程就是“②数据流转”问题。
• 邻近训练，训练平台负责协调训练要求的各类资源，这里当然也包含存储资源，那么存储和调度器如何能力配合好，产生了“③资源调度”问题。
• 经验了漫长的流程链之后，终于能够跑训练了，这个时候存储要达到一个什么样的性能，才不至于成为计算的瓶颈，这是“④计算减速”问题。

下面的流程梳理下来是“①海量数据 -> ②数据流转 -> ③资源调度 -> ④计算减速”这样一个程序，但前面的局部会依照“④计算减速 -> ③资源调度 -> ①海量数据 -> ②数据流转”这样的程序讲述，从大家最关注的计算减速问题讲起。

03 关键问题剖析和解决思路

## 3.1 计算减速

在剖析这个问题之前，让咱们通过一个简略的例子来理解一下一个典型的训练到底长什么样：

• 训练的计算会通过很多很多轮，每一轮称为一个 epoch，每一轮 epoch 反复以下过程：
• 首先，为了让算法达到比拟好的鲁棒性、放慢收敛速度，把整个训练应用的数据集随机打散，相似于咱们打牌前先把牌洗一遍，这个过程称之为 shuffle。至于样本集蕴含哪些样本，是从存储系统读取的。
• shuffle 确定了数据集样本的读取程序，接下来，数据会进一步分成很多个批次（batch），算法接下来就读取一个 batch 训练一次，直到整个样本集都解决完。这个过程波及到大量的读操作。
• 一次训练继续的工夫可能十分长，数个小时甚至数天数个月都有可能。所有的机器都没有方法保障在训练的过程百分之百没有故障产生，故障产生后，用户不会想从头开始计算，能复原到一个较近工夫点，从那个工夫点从新开始计算是最现实的。因而须要有故障复原的机制，通常的做法是周期性的把训练的状态保留下来，故障产生后，加载保留的状态持续计算。这个机制叫 checkpoint。checkpoint 对存储系统来说是写操作。

从下面的剖析，能够看到和存储无关的操作蕴含 3 种，shuffle、读 batch、checkpoint，前两者是读，后者是写。那么这些操作到底对训练产生什么影响呢？

为了解答这个问题，在下图中列出一个简略的公式。 掂量存储在这个过程两头是不是好，咱们须要看的是整个训练过程中，真正用于计算的那局部工夫在总工夫中所占的比例 。这个比例越高，阐明存储的影响就越小。在不思考其它因素、假如计算工夫不变的状况下，这就是要求让存储的影响工夫变短。

checkpoint 不肯定每个 epoch 都保留，且是对存储系统比拟敌对的程序大 I/O，整体耗时占比拟小，个别剖析时会疏忽它的影响。当然，这里的论断不相对，如果遇到 checkpoint 慢的状况，能够做粗疏的剖析。

读操作的局部，咱们首先看 shuffle。后面说到 shuffle 须要把整个数据集做一次打散，在这个打散实现前，其实是是没有数据能够计算的，也就意味着这是一个纯正期待的工夫。这个工夫从根本上无奈齐全打消，只能通过更高效的实现办法、更好的存储性能，把它在整体工夫中的占比降到一个可承受的比例。

接下来看读 batch 的局部。对于“读 batch 而后训练”这个一直反复的过程，古代的一些训练框架其实曾经做了很多的优化，目前在大部分框架里，“读 batch”的这个过程，由所谓的 Data Loader 模块来实现，它的思路是让读的过程和计算自身并行起来。这对 GPU 训练的成果更显著一些。

在 GPU 训练中，计算和读数据的工作别离是由 GPU 和 CPU 来实现的，在 GPU 忙于一个 batch 的计算的时候，CPU 其实是空进去的，能够提前开始读取前面一个或多个 batch 的数据。整个过程呈现出一种流水线的感觉 。第一个 batch 开始读的时候还没有数据能够计算，只能期待，然而从第二个 batch 开始，破费在存储上的工夫如果短于前一个 batch 计算的工夫，就能够被计算齐全覆盖掉。因而，这个阶段对于存储的要求是快到不连累计算、读等待时间靠近 0 即可。

具体到这两个阶段，咱们能够拿起放大镜再仔细观察一下这里到底蕴含哪些操作。

在 shuffle 阶段，须要把样本集蕴含哪些样本列出来，一种典型的奢侈实现是将所有的样本依照目录分类寄存，咱们就能够通过文件系统提供的 ls 性能来枚举目录获取残缺的文件列表，这时候就产生了大量的 open、getdents、close 操作，这些操作都能够归类为元数据操作。

多个 Data Loader 会启动多个过程，读取这个 batch 所有的样本文件，对于每一个文件都是“open -> stat -> read -> close”这样的流程，其中 open、stat、close 是元数据操作，read 是数据操作。

咱们很容易察看到一个景象，对于一个样本数量确定的数据集，元数据操作的数量是确定的，只有 read 操作可能会因为文件大小而变动，对于较小的（几百 KB 以下）文件，一次 read 操作就能够实现，对于较大的文件（数 MB 以上），须要调用屡次 read。 因而，样本大小影响了元数据操作耗时的占比，元数据操作的耗时占比进一步决定了元数据还是数据对训练的影响更大 。

依据一些统计的后果，能够发现很多训练的样本集面临的状况是，样本数量十分大，但样本的均匀大小又很小。以 ImageNet 数据集为例，整个数据集蕴含几百万（ImageNet 1K）、上千万（ImageNet 22k）的图片，均匀一个图片大小仅为一百多 KB。这个大小对存储系统来说是十分小的。

因而，很多 AI 训练都面临海量小文件的问题。如果大家对存储系统的架构有肯定理解，就会晓得， 在一个存储系统里，元数据的扩展性和性能是远比数据局部差的。这个论断无论对单机的存储系统还是分布式的存储系统都成立 。
**

那应该如何来解决这里面临的计算减速问题呢？

假如要解决的这个问题是咱们的敌人，咱们要战胜它，有几个方向能够尝试的方向：

方向一：我发现敌人太强大了，能不能减弱它的实力，让它变得更弱呢

后面说到海量小文件场景的要害是元数据操作的占比拟高，同时也说到，元数据操作的性能在存储系统里是更差的。那么咱们是不是能把较难的元数据操作转化成更容易的数据操作呢，如果能做到这一点，就能够把问题简化。

这里采纳的优化措施次要是软件层面的。对于 shuffle，能够为样本集保护一个独自的列表文件，或者采纳更适合的元数据系统。对于读数据，能够通过 TFRecord、HDF5 等打包格局，对小文件进行打包，变成大文件。这些操作的外围都是将元数据操作转化成更容易优化的数据操作。这类优化措施的次要毛病是须要用户扭转应用习惯。

方向二：不论敌人有多弱小，让我本人变得更强必定没错

硬件层面，就是开启“买买买”模式，花更多的钱，应用更高规格更快的硬件来撑持训练。例如，存储介质方面应用更多的内存、更快更多的 SSD 硬盘等，网络方面降级到 100G/200G 的高速 TCP/RDMA 网络。

软件方面，对软件架构做一些降级来进步整个软件系统的扩大能力，缩短软件栈的 I/O 门路长度。这里大家可能有肯定理解的计划就是并行文件系统，这一类文件系统通过 hash、stripe 等形式将元数据和数据尽可能地扩散到更多的节点上，以此来进步元数据和数据的并发解决性能。这类零碎同时还会实现公有的内核客户端，申请间接发送给存储节点，以此来缩短 I/O 门路。

方向三：在咱们和敌人绝对实力不变的状况下，想方法让敌人离我更近，让等同力道的拳头对敌人造成更大的挫伤

这样的办法同样蕴含硬件和软件上的一些办法。

硬件方面，咱们能够在组网的时候让计算节点和存储节点在物理上靠得更近。这件事件和硬件降级自身是独立的，因为如果仅仅是降级硬件，一次操作还是须要逾越很多跳交换机，效率同样会受到影响。对于单机而言，GPU Direct Storage 这样的技术，能够让 GPU 间接去读取存储系统上的数据，打消掉一部分 CPU 解决的开销，实质上是抄了一个近道，少绕了一些路。

软件方面，能够做的一点是让须要拜访的数据可能尽可能的搬到计算节点本地，或者和计算节点比拟近的中央。这就是缓存的思路，通过利用计算节点本地的冗余的内存、磁盘资源，让一些申请在缓存里解决掉，会比间接拜访存储系统的性能更好。

到目前为止，咱们的这些优化思路里，曾经提出来两个比拟重要的软件计划，一个是并行文件系统，一个是缓存。接下来再略微开展介绍一下这两类零碎。

并行文件系统和其它品种的文件系统有什么样的差异呢？明天咱们去查看私有云厂商的官网，能够发现文件存储产品通常分为两类：

第一类零碎是 NAS。这是一种对标 NetApp 这类传统厂商提供的网络文件存储产品，提供规范的 NFS、SMB 协定拜访能力，产品状态上是 serverless 的。这样一类产品的一个特点就是规范，NFS 和 SMB 协定是失去业界认可的标准协议，用户应用时没有兼容性累赘和学习老本，支流操作系统也会内置反对，基本上是开箱即用的状态。 但这类存在的一个最大毛病就是，为了去兼容规范的协定，须要在解决门路上引入专门的协定解决节点，这些节点负责将申请转化为存储节点能够了解的外部格局。这种架构有两个影响性能的问题 。第一个问题是让申请的解决链条变得更长，让延时变大。第二个问题是协定解决节点自身可能成为解决瓶颈，影响并发度。

第二类零碎是并行文件系统。并行文件系统走了和 NAS 相同的路线，专门针对特定的高性能场景去做一些极致的优化。 这类零碎通常会放弃或弱化对标准协议的兼容性，取而代之，实现公有的客户端协定，通常运行在内核态 。业务的申请进入客户端后，迅速、间接发往后端的存储节点。这种设计让软件上的 I/O 门路达到最短，充分利用后端节点、设施的并行处理能力。这类零碎的代表有 Lustre、BeeGFS、GPFS，和百度智能云 PFS。

简略总结一下，想要兼容性更好，抉择 NAS 类的产品，想要性能更高，抉择并行文件系统产品。

从咱们之前的剖析能够看出，AI 场景下对数据集的应用是只读的。因而，对于 AI 训练场景，缓存是一个十分好的优化伎俩 。具体做法是将数据缓存到计算节点本地或邻近节点的内存、磁盘上，达到就近拜访的成果。缓存零碎在 cache miss 的状况下须要从远端存储系统读取数据，性能是比拟低的，训练中应该尽量避免这样的状况。

目前，本畛域业界支流的缓存解决方案分为两大类。一类是 Alluxio 这类绝对比拟纯正的缓存零碎，不扭转数据的格局，忠诚地做一个数据的搬运工。另外一类是近些年比拟热门的云原生文件系统，如 JuiceFS，这类零碎在对象存储之上从新定义了一层数据结构，数据只能通过零碎自身拜访。无论是哪一类零碎，晋升计算侧性能的实质依然是缓存。阿里云 JindoFS、百度智能云 RapidFS 都是兼有这两类缓存零碎能力的对立解决方案，用户能够依据本人的理论需要抉择不同的工作模式。

目前为止，曾经提到了并行文件系统和缓存两大类软件解决方案，那么困扰抉择恐惧症患者的问题来了，它们到底有什么区别，该怎么选。

并行文件系统次要是面向高性能场景（传统 HPC、AI 场景）优化，提供了对 POSIX 规范文件系统接口的残缺反对，所以大部分通用文件系统的需要，同样能够用这类文件系统来满足。从久远的发展趋势看，并行文件系统的仍然是去兼容 POSIX，将文件系统的规范能力做大做强做好用。

缓存零碎的实现则绝对灵便很多，齐全是为无限的特定场景定制的一类零碎，目前在云上的次要服务场景是 AI 和大数据存算拆散。这类零碎的一个重要发展趋势是持续摸索一些非标准的能力，和下层的框架、生态增强交融。

所以，整体上来看，并行文件系统能够实用于须要规范文件系统的场景，缓存零碎是配合对象存储应用的定制零碎，这两个计划只是在 AI 场景下产生重叠。如果业务尚未没有实现云原生的革新，或者强依赖文件系统的一些语义（如多过程并发写同一文件），并行文件系统是更省心的抉择。如果业务曾经是数据湖为外围的云原生架构，在 AI 的场景下，能够尝试缓存零碎。

从长远看，这两类零碎更多的是互补的关系：

• 性能方面：尽管说缓存零碎通常是用来减速一些绝对较慢的存储系统，但并不能排除能够用来进一步减速并行文件系统。例如，元数据申请即便通过并行文件系统解决比拟快，但依然产生很多轮的网络拜访开销，如果能在其上叠加一层元数据缓存，对进步性能也是很有帮忙的。
• 性能方面：缓存零碎能够更好的实现一些非标准的能力，配合一个规范的高速文件系统，能够有一些好玩的用法，这些用法其实也是业界摸索的方向。例如，后面提到一种优化 shuffle 的办法是应用文件列表代替 ls，缓存零碎齐全能够实现一种性能，将列表映射成文件系统目录的构造，并缓存下来，而数据拜访持续由并行文件系统解决。这样的形式能够让之前的训练代码持续应用，不感知其中的变动。

## 3.2 资源调度

所有的训练平台都存在一个终极的幻想，就是让计算资源利用率维持在一个较高的水位。 这个水位如果能到 60%+、70%+ 是一个很了不起的事件。这儿有些同学可能不能了解，平时的训练很容易达到 90%+ 的利用率呀，为什么上了训练平台就降落了呢？

次要的起因是在一个残缺的训练流程里，除了计算的局部，还有很多其它的操作和步骤，训练之间也可能存在串行、并行等关系。这些操作如果调度上解决不好，让计算资源处于期待的状态，就会拉低整体的利用率。此外，还有低峰期这样的因素进一步拉低利用率。

本文讲的是存储相干的问题，不会波及计算侧的相干优化。如果想要理解计算优化的局部，能够看一下我的两位共事之前做的很精彩的分享，链接如下：

• 百度智能云技术站：双引擎 GPU 容器虚拟化，用户态和内核态的技术解析和实际分享
• InfoQ 直播回放：https://www.infoq.cn/video/RB…

回到咱们明天的主题，存储这部分在平台化训练和云原生训练阶段面临的问题是统一的。在这两个阶段，咱们会发现很多时候数据的起源是速度较慢的大容量存储或者数据湖。这就导致在真正开始训练前，须要一个数据筹备的阶段，将数据搬到速度更快的存储里。

咱们来看一个简化的例子，Task 1 和 Task 2 申请同一批 GPU 资源，数据筹备工夫和 GPU 计算工夫一样长。

如果不在调度上做优化，间接依照算力需要，将工作作为整体调度，即下图中的调度策略 1，那么 Task 1 和 Task 2 只能串行执行，两头有很长的工夫被数据期待节约掉了，整个时间段的 GPU 利用率均匀下来只有 46%。这样的状况显然是不现实的。

让咱们换一个角度看这个问题。回忆一下 Data Loader 是如何解决让读数据和计算并行的，显然这里的问题也是相似的。咱们齐全能够让数据筹备的工夫和训练的工夫并行起来。如图中的调度策略 2 展现的那样，在 Task 1 训练的期间，就能够开始 Task 2 的数据筹备工作。在这个例子里，刚好 Task 2 的数据筹备工夫都能够被暗藏掉。这个调度策略能够让整体的 GPU 利用率晋升到 62%。

这里的思路具备肯定的普适性，对于优化其它的资源利用率问题也有参考意义，实质上就是让不产生竞争的环节最大可能的并行运行，达到工厂流水线的成果。

思路有了，具体应该怎么做呢。有聪明人在开源社区曾经后行了一步，实现了一个基于该思路的我的项目 Fluid。Fluid 自称是一个数据集编排跟减速的这样一个框架，其核心思想就是下面形容的流水线调度。

Fluid 把数据集的筹备工作从整个流程里独自抽取了进去，利用底层的 K8s 调配须要的资源，例如缓存零碎须要的内存和磁盘资源。资源分配进去后，能够选择性的发动元数据和数据的预热工作。等预热工作实现之后，再由 K8s 调度计算资源运行训练任务。训练任务能够抉择是否亲和，所谓亲和是让缓存的节点和计算的节点是同一批节点，这个能带来什么样的益处待会儿会讲到。训练实现后，用户能够视状况而定决定何时回收 Fluid 占用的资源，这个过程和计算也是独立的。

目前，社区对 Fluid 的定位依然是围绕缓存零碎开展的，但咱们认为数据筹备在 AI 训练里是一个广泛的问题，同样的原理也实用于并行文件系统和其它存储系统。从这个角度看，Fluid 的适用范围能够超出社区对它的定位。

在这个问题的最初，对 Fluid 的亲和调度略微开展再介绍下。亲和性调度次要对缓存零碎有帮忙，体现在两个方面。

第一个益处是性能方面的。计算节点和缓存节点是同一批节点，保障了计算节点拜访缓存数据的物理门路是比拟优的。同时，局部数据通过本地就能够满足，不再须要网络拜访。

第二个益处是容错方面的。缓存零碎和并行文件系统最大的一个差异是自身的容错能力较弱，缓存节点故障，就意味着其上的缓存数据生效。如果没有亲和调度，即便可能从远端从新拉取数据，也须要忍耐一段时间的性能降落，这段时间会拉低计算资源的利用率。有了亲和调度之后，缓存节点和计算节点同时生效，在复原计算工作前有机会先复原缓存数据，就躲避了性能进化的问题。

3.3 海量数据

后面咱们的关注点次要在 AI 训练局部，这部分对存储的性能有极致的要求。但如果咱们放眼去察看一下所有 AI 相干的流程，包含数据集治理、项目管理、预处理这些，会发现除了训练和预测，其它的流程对高性能并没有一个很强的诉求，它们的需要演绎下来是一个高吞吐、可共享、大容量、高牢靠的存储系统。

在思考到企业中存在其它各种业务，这些业务可能是 AI 的数据集起源，也可能是 AI 的应用方，这个存储系统须要可能不便地和这些业务进行数据交换。综合来看，对立的数据湖存储是最佳抉择。

有必要指出的一点就是，抉择数据湖的背地，是业务间的数据流转形式曾经产生了天翻地覆的变动。 在云原生之前，不同类型的业务处于信息孤岛的状态，大数据的业务应用 HDFS，高性能计算应用并行文件系统，数仓零碎本人保留数据。零碎 B 须要应用零碎 A 的数据，须要把数据从零碎 A 里导出来一份。这种点对点的数据交换显然是比拟低效和繁琐的。

数据湖、存算拆散这些概念的衰亡，让业界达成一个共识，那就是建设对立的数据湖存储底座，围绕数据存储进行数据流转，能够无效的解决零碎间数据流转的问题。对这部分内容感兴趣的同学能够浏览“百度智能云技术站”公众号的的数据湖系列专题文章。

大家认可的数据湖存储候选零碎有两个，一个是大数据畛域应用较多的 HDFS，一个是起源自 AWS S3 的对象存储。

HDFS 次要有两个模块，别离是用来提供元数据服务的 NameNode，和用来存储数据的 DataNode。HDFS 的元数据是依照树形构造来组织的，即所谓的层级命名空间。这种元数据组织形式的特点就是除了根目录外，每一个文件或者目录，都从属于一个父目录，从根目录往下看，就像是一颗倒挂的树。HDFS 的数据个别是 3 正本保留的。

对象存储的架构次要分为三个局部。首先因为对象存储提供的接口模式是规范的 HTTP，须要一些 Web Service 服务器来解决接口调用。Web Service 服务器解决的过程中会依据申请的类型拆分成元数据申请和数据申请，别离交由相干的子系统来负责：

• 元数据子系统：在实现上个别基于分布式 KV 或 NewSQL，提供平坦命名空间。平坦命名空间的特点是其中的每一个对象（等价于 HDFS 中的文件或目录）没有从属关系，相互独立。数据子系统。
• 数据子系统：应用纠删码（Erasure Coding，EC）技术存储数据，它的原理是将原始数据切成 N 个等大小的块，并计算出 P 个冗余的校验块。这些数据块和校验块存储到不同的节点上，只有有不少于 N 个块存活，就能复原进去残缺的数据。

咱们来简略地从几个方面比照一下这两个零碎：

• 老本：对象存储的老本要比 HDFS 低很多，因为以下几个起因：
• 首先是正本数。HDFS 本人有 3 正本，间接搬到云上应用云磁盘搭建，还存在正本放大问题。因为云磁盘自身也有 3 正本，叠加起来其实是 9 正本的开销。与之比拟，对象存储的纠删码能够做到 1.5 正本甚至更低。这部分的老本就差进去很多。
• 其次，云厂商的对象存储对不同冷热水平的数据应用不同的纠删码配置和存储介质，最冷的数据能够存储到磁带中，磁带比 HDFS 应用的机械硬盘老本更低。
• 最初，HDFS 的数据湖是存算一体架构。所谓存算一体是说，同样一批机器既用来跑计算，也用来跑存储。这个架构的劣势是能够实现亲和调度，调度的时候让计算工作间接跑到数据所在的节点上，和咱们后面说的缓存亲和调度殊途同归。但这也带来了一个问题，就是计算必须和存储同步扩容，事实中很难做到刚好匹配，必然会存在一类资源的节约。这个问题在对象存贮存算拆散数据湖架构上不存在，对象存储服务只提供纯正的存储能力，计算资源是客户按需购买的，计算需要不存在的时候甚至能够不买计算资源，非常灵活。采纳存算拆散架构，用户能够防止很多计算资源的节约。
• 扩展性：层级命名空间和平坦命名空间相比，扩展性要差很多：
• 这里次要就是因为层级命名空间须要保护父子关系。HDFS 为了简化这个关系的保护，应用了单点 NameNode 的设计，数据还间接放在内存里，这导致这个单点很难扩大，性能下限也比拟低，通常一个零碎只能保留数亿文件，几十 PB 的数据。尽管社区起初推出了 Federation 的性能，但没有实质上解决问题。
• 对象存储则不同，平坦命名空间里的每个对象人造没有任何关联，能够作为独立的个体看待，关联性的突破让扩展性更容易做。云厂商的对象存储服务因而能够做到一个集群 EB 级的容量，万亿条元数据，比 HDFS 大很多。
• 可用性 & 可靠性：HDFS 是一个单机房的服务，同一个数据只能容忍 2 个正本呈现问题。对象存储能够部署到多个机房，EC 编码也能够容忍更多的块失落，如 18 + 6 的编码能够容忍 6 个块故障，这些保障了对象存储可能提供更好的可用性和可靠性保障，完胜 HDFS。
• 吞吐：大家对数据湖比拟关注的性能指标就是吞吐，这个指标和集群规模是强相干的，集群的节点数越多，磁盘数量越多，可能提供的吞吐就越高。云厂商的对象存储在这方面有人造的劣势，一方面集群规模要大很多，另外一方面其中很多数据的拜访频率非常低，不会对须要高吞吐的数据产生挤兑，性能容易失去保障。
• 生态：两个零碎都是接受度比拟高的。对象存储不足对 rename、边写边读等个性的反对，使得它目前还不能满足局部大数据的场景需要。不过云厂商也在踊跃的解决这些问题，例如百度智能云推出了 RapidFS 和 BOS 层级 Namespace 作为补充。

通过这样的比照，能够失去一个简略直观的论断就是在对象存储是数据湖存储的首选。

3.4 数据流转

数据湖存储成为整个数据流转的 C 位之后，带来的最大的一个变动就是数据流向齐全逆转了 。在传统的架构里，大容量的冷数据存储和高性能存储是别离保护的，对于 AI 训练的局部，数据的存储、生产、生产都产生在高性能存储中，自成体系，只有转冷的数据才会思考转移到大容量存储中去。比例较小的反向数据流转（从大容量存储到高性能存储）通过工具来解决。

但到了数据湖里，数据湖存储才是最全量、最权威的数据起源，大部分状况下，数据的第一个落脚点是数据湖，而后才会到高性能的减速层。在存算拆散架构中，减速层自身都只是长期的存在，其中的数据生命周期和计算资源同步，略早于计算资源的创立而生成，计算资源销毁时同步删除。这就导致数据湖到减速层的数据同步成为一个高频、外围的需要，须要花大力量解决。

很容易想到的是一种比拟奢侈的计划，常常被大家用来做数据同步和迁徙。简略的讲，这个计划就是筹备一个中转折，在同一台机器上把数据湖存储和减速层高性能存储都挂载上，而后应用 cp 或 rsync 之类的工具来搬迁数据。

大家如果应用过这样一类办法，会很容易发现存在一些问题：

• 第一个问题是同步速度慢。这里受到很多环节的限度，中转折的硬件配置、存储系统单客户端的并发度等等因素。文件系统层也有很多冗余开销，这些冗余开销次要来自元数据，对于读的那方，每个文件都须要 open、stat、close，对于写的那方，每个文件须要 open、setattr、close。后面剖析训练效率的时候提过这类操作对海量小文件十分不敌对，但通过 cp、rsync 无奈优化掉这些开销。
• 第二个问题是同步策略不可定制，在有一些场景下，咱们可能会心愿只做元数据的同步，或一些特定条件数据的同步。例如，一些训练里文件都很大，训练任务对延时不敏感，数据湖存储就足以满足吞吐的要求，这时候只须要元数据的缓存。cp 和 rsync 这样的工具无奈满足要求。这种办法在解决增量同步的时候也比拟低效，须要比照全量的文件列表，而对象存储是反对告诉机制的，如果能利用这一点可能极大地改善增量同步的效率。
• 第三个问题是和调度器的集成艰难。奢侈的计划在实现上采纳脚本和命令行工具实现，简单的环境下稳定性比拟差，状态的获取和解析也不是很灵便。如果操作系统环境变动了，没测试过，真正应用的时候可能会发现跑不起来。这些问题导致和调度器集成时会遇到各种各样的问题，须要人工染指排查，保护老本极高。
• 最初一个问题是这种形式同步胜利还好，同步失败后须要善后，解决残留的垃圾，这些也须要染指或者半人工的形式来解决。

上述诸多因素的叠加，让奢侈计划在云原生时代显得十分的轻便和低效。咱们认为，减速层的存储系统内置数据同步的能力才是解决这一关键问题的正确思路。

在零碎外部实现，能够解决奢侈计划存在的各类问题。

对于同步速度慢的问题，充分利用零碎的多个节点去并发的同步数据，缩短中间环节，不给中间商赚差价的机会。

至于哪些数据同步，哪些不同步，在零碎外部很灵便，容易实现各种各样的策略。

调度器方面能够联合后面说的 Fluid 框架，将同步的发动、状态的展现、容错做到齐全自动化。

垃圾回收的问题也同样能够在 Fluid 的框架内解决掉，由 Fluid 的机制保障资源主动开释。

04 百度桑田·存储全流程存储减速计划

百度桑田·存储依据下面的剖析，推出一整套高性能存储的解决方案。

计划的数据湖局部由对象存储 BOS 来承当，除了前文剖析的大容量、高吞吐、低成本的特点，还内置了分级存储和智能生命周期性能。分级存储是进一步细分对象存储数据冷热降低成本的伎俩，配合智能生命周期能够让业务在更高的性能和更低的总持有老本之间获得均衡。

撑持训练的局部由专门的减速层来实现。这一层首先从网络环境保障存储和计算是离得比拟近的，让存储可能达到最好的性能。在这根底上，蕴含两个软件产品，一个是并行文件系统 PFS，一个是数据湖存储减速 RapidFS。每个 PFS 实例部署在托管的裸金属 BBC 上，或者虚拟机 BCC 上，无论是哪种模式，应用的硬件性能均有定量保障。每个 RapidFS 实例的资源则来自计算节点本地的内存和磁盘。PFS 和 RapidFS 均反对 Bucket Link 实现数据湖数据的主动同步，同时也反对 Fluid 调度器。

在咱们的计划里，对之前探讨的问题都有解答，具体如下：

• 海量数据：由 BOS 及周边生态解决。
• 数据流转：PFS 和 RapidFS 内置的 Bucket Link 能力反对主动从数据湖同步数据。
• 资源调度：PFS 和 RapidFS 均反对 Fluid 调度器，应用形式靠近，用户可灵便切换。
• 数据减速：PFS 和 RapidFS 作为数据湖减速层，采纳高速硬件，近计算部署的形式保障性能。

最初简略看一下 PFS 和 RapidFS 在理论反对用户训练时候的成果。在这个例子里，有三组数据，别离是基于 RapidFS、PFS、对象存储间接来做 GPU 训练。能够看出，当 RapidFS 和 PFS 应用 Bucket Link 做完数据预热之后，能够保障训练期间的 GPU 利用率打满。基于对象存储间接来做这个训练的话，两头很大一部分工夫是耗费在数据的读取上，整个 GPU 利用率在一个非常低的水位上。通过这样一个试验，咱们大抵可能看到 RapidFS 跟 PFS 在计算减速这一块的成果。

05 Q&A

问题 1：为什么对象存储能让存算拆散？HDFS 不能够？这个不是取决于计算和存储的架构吗？

所有的技术选型都离不开当年的大背景。

存算一体架构自身在过来是十分棒的设计。过后的网络没有那么快，存算一体能够让计算和存储取得更好的亲和性，极大的升高了网络上的数据传输量开销。但随着数据量的爆炸式增长和网络速度的改善，存算一体架构的问题逐步裸露进去了。

首先，存储和计算对资源的需要不匹配，扩容时很容易导致其中一种资源的节约。

其次，网络速度的改善让数据传输变得很快，亲和性的重要性升高。

第三，HDFS 自身的扩展性缺点也裸露进去了，不能撑持上百亿文件。对象存储作为云厂商提供的一种存储服务，解决了扩展性的问题，老本也比自建 HDFS 更低廉。

更重要的是，对象存储让用户的计算资源和存储资源能够解耦，齐全能够按需应用，计算资源的老本也升高了。

这些劣势综合下来，让对象存储成为存算拆散架构的首选。

应用 HDFS 来做存算拆散架构，它的扩展性和老本会比对象存储差很多。HDFS 当然也在解决这个问题，但其设计的下一代 OZone 实际上就是对象存储。

问题 2：在进行存储系统选型的时候，你们会优先思考什么？

不同的存储系统有各自实用的场景，最重要的是调研分明这个存储系统服务哪些业务，这些业务的拜访模式是什么样的。例如，大数据业务程序读写比拟多，且多为大文件，所以它对存储的要求次要在吞吐方面。要满足吞吐的要求，就不肯定须要很快的硬件，通过堆机械硬盘，同样能够达到很高的吞吐。再例如，如果你的业务拜访元数据拜访十分频繁，或者产生很多的随机小 I/O，这时候就须要思考高速的硬件，软件架构也须要有针对性的优化。咱们须要先从业务的拜访模式理解它关注哪些方面的性能和性能，而后再去做存储硬件和软件系统的选型。

问题 3：如何将本地存储与私有云存储买通？

私有云厂商的数据买通根本都是通过对象存储来满足的。只有网络是通的，用户能够通过 SDK、FUSE、命令行工具等多种形式应用对象存储。如果须要进行数据同步和迁徙，纯软件的计划有相似 rsync 的工具。数据量比拟大的状况，百度智能云还能够提供一种叫月光宝盒的硬件，相似一个很大的移动硬盘，用户能够把数据拷贝进去，邮寄到百度智能云的机房，在百度内网实现数据的上传。更多的办法大家能够去 BOS 的官网理解。

问题 4：Ceph、HDFS 的区别是什么？

在答复它们的区别之前，先看看它们的共同点，它们的共同点是都能够归类为所谓的软件定义存储。在它们呈现之前，存储软件都是跑在磁盘阵列这种业余的硬件之上的，依附硬件来解决数据可靠性的问题，但 Ceph、HDFS 能够跑在通用服务器上，数据可靠性由软件自身保障，这是一个微小的扭转。

它们的区别在于定位不一样。HDFS 是专门面向大数据设计的，针对大数据的业务特点，实现了 POSIX 规范的一个子集。Ceph 蕴含 3 个子系统，别离是文件存储 CephFS、块存储 RBD、对象存储 RGW，其中 CephFS 和 HDFS 有些相似，但对 POSIX 规范的兼容水平要比 HDFS 高很多。例如随机写、hardlink 这样的能力没有被 HDFS 反对，但 CephFS 就反对。

问题 5：请问一下 AI 训练预读时，存储系统能够晓得预读的文件有哪些吗？

存储系统须要框架被动去读取才晓得预取的是哪些文件。目前业界在做的一个摸索就是让存储和框架配合，通过一些非标准的接口让存储系统提前晓得某个计算节点须要那些数据，这样就能够在框架真正读之前就将这些数据搬运到计算节点本地了。这个思路能够进一步把 shuffle 也卸载给存储来做。

问题 6：请问一下百度桑田 RapidFS 是 POSIX 局部兼容的吗？

是的，兼容的是 HDFS 接口。RapidFS 有两个模式，一种定位是缓存，和 Alluxio 比拟靠近，只实现缓存减速能力，对 HDFS 的兼容性和底层对象存储齐全对齐，不提供 rename 原子性、边写边读这样一些个性的反对。另外一种模式是云原生文件系统，和 JuiceFS 相似，在对象存储之上从新组织数据，提供残缺的 HDFS 兼容性。

问题 7: RDMA 技术相比间接用高性能 SSD 有劣势吗？

这两个不应该拿来比拟谁代替谁，是鱼和熊掌能够兼得的关系。高性能场景下，RDMA 搭配机械硬盘，成果不会好。反之，SSD 盘搭配万兆的 TCP 网络成果也不好。高性能场景关注端到端的延时体现，须要叠加了网络的奉献和存储介质的奉献。

问题 8: 写更多的场景应该应用 PFS 吗？

是的，特地是存在大量随机写的状况。PFS 的定位是一个残缺兼容 POSIX 的文件系统，而 RapidFS 是一个缓存服务，和 HDFS 比拟靠近，对随机写的反对很弱。

本次线上分享回看链接：https://www.infoq.cn/video/TI…