CubeFS在大数据和机器学习的探索和实践丨ArchSummit峰会实录

CubeFS 主要分为资源管理模块、元数据子系统、数据子系统以及多协议客户端四个大的模块。其中资源管理模块（Master）负责管理数据节点和元数据节点的存活状态、创建和维护卷 (volume) 信息、元数据分片（metaPartition，简称mp）和数据分片(dataPartiton，简称dp）相关的创建和更新。Master 由多个节点构成，通过 Raft 保证服务的高可用。

这里涉及到一个概念——volume，这个是虚拟的逻辑概念，对于文件系统来说，volume 是一个挂载的文件系统；对于对象存储来说，volume 则是对应的一个 bucket。每个 volume 存储用户的数据以及对应数据的元数据，其中数据存储在数据子系统中，可以是多副本引擎的数据分片或者是纠删码引擎的条带中。

元数据保存在元数据节点的 metaPartition 中，元数据的分片是 CubeFS 的一个设计亮点。实际情况中 MetaNode 和 DataNode 可以同机部署，因为一个消耗内存资源，一个消耗是磁盘资源。

除了数据和元数据子系统之外，还有多协议的客户，客户端可以兼容 S3、HDFS 和 POSIX 协议。

总结一下，CubeFS 是开源的分布式存储产品、

• 提供多协议兼容 S3/POSIX/HDFS 等多种协议，

• 支持纠删码和多副本引擎，用户可以根据实际情况选择合适的存储引擎。

• 其优秀的水平扩展能力，可以帮忙用户快速构建 PB 甚至 EB 级别存储。

• 元数据全内存缓存和多级缓存技术提供高性能存储、

• CubeFS 还支持多租户管理，可以提供细粒度的租户隔离策略，保证不同用户之间的数据安全和隔离。

• 除此之外，CubeFS 还提供了基于 CSI 插件的快速部署方案，可以方便地在 Kubernetes 上使用 CubeFS。

PART

02

机器学习的应用

OPPO 的机器学习存储主要分为四个阶段，

• 第一阶段使用 CephFS 作为存储；

• 第二阶段使用 CubeFS 和 CephFS 混存；

• 第三个阶段单独使用 CubeFS 存储；

• 最后一个阶段使用 CubeFS 存储+多级缓存技术。

接下来具体看看每个阶段遇到的问题和挑战，以及如何应对这些挑战。

第一阶段使用 CephFS 存储集群学习的数据，这个阶段存储节点数目在150台，磁盘1500块左右。由于 MDS 采用的是主备模式，无法水平扩容，单个 MDS 承受10亿级别的元数据访问，节点负载过高导致 MDS 时延上升，训练的 IO 吞吐下降，大量 GPU 训练的利用率低。MDS 在稳定性方面也存在问题，用户频繁的超大目录遍历导致 oom，服务的恢复周期较长。

最直接的解决方案是分而治之，将大的 CephFS 集群拆分成6个小集群，保证每个集群规模控制500块盘以内，小集群模式在稳定性确实有提升，但是小集群模式并不是真的小而美。首先小集群模式的存储资源利用率不高，通常需要将存储水位控制在70%左右来应对突发的业务增长，其次面对百亿参数的大规模机器学习训练，小集群无法满足高 IO 的吞吐要求。这个阶段 CubeFS 技术团队也开始了灰度和验证 CubeFS。

总的来看，这一阶段机器学习存储的主要特点是海量小文件、超大目录热点目录以及访问时延敏感。在经过一段时间验证了 CubeFS 的稳定性、扩展性以及性能方面都能满足机器学习的存储需求之后，最终使用 CubeFS 作为统一存储。依靠 CubeFS 可扩展的元数据服务，元数据节点不会成为单点瓶颈，用户的元数据会均匀分配到不同 MetaNode 节点，由所有 MetaNode 节点共同承担，有效地解决热点目录的问题。最终将机器学习超过70亿的文件数量，总存储量超过30PB的数据全量存储在 CubeFS 中，SLA 也从3个9提升到4个9，元数据的访问时延从10ms降低到1ms，全年稳定运营无故障，为后续机器学习的高性能存储打下基础。

方案一：将数据存储在公有云的文件系统中，公有云的训练访问公有云的文件系统，以此来减少机房之间的时延。这种方案抛开昂贵的数据迁移代价不谈，还存在以下问题，数据是全量迁移还是部分迁移，如果全量迁移数据，公有云已经有全量的数据，无法做到弹性计算；如果是部分迁移，私有云的 CubeFS 和公有云的文件系统存在数据一致性需要解决；另外考虑终端用户的数据隐私安全问题，将数据保存公有云可能会产生数据安全合格风险。

通过深入了解集群学习的训练过程的特点，发现大规模 AI 训练的 IO 有以下特点，每一轮迭代 epoch 会反复读取同一批数据，通常单次训练会跑上万轮。总的来说，AI 训练的 IO 特征就是在某个训练集的反复并且多次读取的一个过程。基于这个特征，利用 CubeFS 作为统一存储结合多级缓存的方案非常适合。

第一轮训练将数据从私有云 CubeFS 加载到公有云的缓存节点，客户端会缓存元数据 inode 和 dentry 信息，可以大量减少训练过程使用 fuse 客户端的 loopup 和 open 操作的元数据查询延时开销，并且元数据缓存可以指定缓存文件数量，最大可以支持千万级别的文件。GPU 的云盘（通常是1TB）可以作为数据缓存盘，通过指定缓存目录和配置 LRU 策略，无须申请额外资源就可以缓存数据。通过缓存加速策略，RESNET18 模型下 dataload worker分别是1和16的时候，整体性能提升了360%和114%，即使相比私有云的训练也有12-17的性能提升。

PART

03

大数据的应用

大数据的存储过程也可以分为四个阶段，

• 第一阶段是 HDFS 存储，这一阶段主要面临的是存储成本和运维复杂高等问题；

• 第二阶段是使用对象存储做降冷，来解决 HDFS 集群高成本的问题，但是由于对象存储不支持文件语义，在 list 等操作时候代价较高；

• 第三阶段使用 CubeFS 来承接冷数据；

• 第四阶段阶段是使用 CubeFS 作为统一存储。

第三阶段是基于 CubeFS 的来存储大数据冷数据，CubeFS 不仅能够提供低成本的存储，本身也支持文件语义。目前已经使用 CubeFS 存储超过100PB的大数据冷数据，整体存储成本比使用 HDFS 节约40%以上，即使比使用对象存储的成本也有所下降，并且整个降冷过程更快、更节约资源。

最后一个阶段是使用 CubeFS 作为统一存储，冷数据采用 CubeFS 低成本、高可靠的纠删码引擎，热数据采用 CubeFS 三副本引擎。CubeFS 统一存储可以支持更大 IO 并发需求，例如 Flink 的 check point 集群，需要定期将任务持久化到存储，会产生很多频繁大 IO 请求，小规模的 HDFS 集群需要靠扩容解决，导致集群整体存储利用率不高，存储成本增加，而使用 CubeFS 统一存储，可以提升整体存储利用率并且能够满足大 IO 的要求。

大数据业务经历了这个四个阶段的存储演进，简单来说，大数据存储目前的需求就是以下几点。最核心的需求就是降本增效，这个也是目前很多公司的关键目标，在降本增效的同时需要保证系统的可用性、数据的可靠性以及运维的便捷性。

关于 CubeFS 如何助力大数据降本，第一个策略是从数据冗余度出发， CubeFS 本身提供了弹性可变的副本机制，用户可以根据业务特性选择特定数量的副本数目。举个例子，大数据的 Shuffle 业务产生的是临时数据，这个业务场景很适合采用单副本存储来节约存储成本。

除了弹性副本之外还可以采用低成本的纠删码，不同冗余度的编码支持可配，用户可以根据对数据耐久度的需求来选择合适的编码，例如可以选择支持AZ级别容灾的编码，在降低数据冗余度的同时兼顾数据可靠性。

除了软件层面的降本之外，CubeFS 技术团队还在硬件层面做了降本优化，这里主要是选择一些高密的存储服务器，高密存储服务器单位存储量的成本和功耗都更低，整体的存储成本也更低。

除了节约存储成本之外，CubeFS 技术团队也特别关注大数据存储的性能，通过多级缓存技术可以在 Client 节点上同机部署 BlockCache 组件，在内存缓存元数据，利用本地磁盘来缓存数据，元数据和数据就近访问可以提升数据的读性能，当然由于本地磁盘容量有限，需要配置一定的缓存淘汰策略。

本地缓存之外还有全局缓存，如果业务对缓存容量需求更大，可以使用多副本 DataNode 作为缓存，例如利用 DataNode 作为全局缓存，相比本地缓存，全局缓存容量很大，并且副本数目可以调整。

除了利用多级缓存做优化之外，CubeFS 对小文件也有特定的优化，在前面机器学习的场景有提到过，机器学习主要通过缓存元数据的 inode 和 dentry 来优化读性能。其实多副本引擎的小文件会聚合到一个大文件中，小文件聚合会减少 DataNode 管理的文件数量。纠删码引擎写入小文件会采用填充的方式，这样小文件读取时候只访问第一块数据，可以避免跨 AZ 的读流量。顺便提一点，纠删码的读写采用 quorum 机制，RS(n,m) 的编码任意写 n+1份（这里+1还是加几可以配置）就成功，读任意 n 份就返回成功，这样可以有效避免长尾的时延问题。

下面是一个大数据热数据在 CubeFS 的应用实例分享，传统大数据的 shuffle 任务中 map 和 shuffle-work 是同机部署，这样 shuffle-work 读写数据会抢占 CPU 资源，另外由于单机存储的空间有限，可能因为任务分配资源不均衡等问题导致任务失败。remote shuffle 是 OPPO 大数据团队开源的一个项目，将 shuffle-worker 与 map 解绑，在云上部署 shuffle-worker，使用分布式存储 CubeFS 存储 shuffle 过程中产生的临时文件。Shuffle 过程产生的是临时数据，即使数据丢失可以重新生成任务，对数据可靠性要求不高，更加关注成本；临时数据需要快速清理；另外 shuffle 对数据读写的吞吐量和性能要求较高，在多任务并行场景对读写带宽需求较大，测试过程中会发现经常能把网卡、磁盘打满导致机器负载整体能够达到 80%以上。

针对这些存储特点，CubeFS 提供以下的解决方案：

• 提供单副本存储，虽然会存在坏盘会导致数据丢失，但是就像上面所说， Shuffle 场景下产生的是临时数据，数据丢失后任务可以重做，代价就是任务时延增加，相比于正常情况下性能提升和成本降低，这是一个合理的权衡。

• 利用 CubeFS 的就近读写的能力，可以将 Shuffle-worker 与 CubeFS 的数据节点同机部署，这样 Shuffle-worker在读写数据的时候，就不需要经过网络，也不受网卡带宽的限制，直接从本机的 DataNode上读取数据，从而提高 Shuffle-worker 的数据读写性能。

• 提供异步删除的功能，将待清理的目录先 rename 到一个临时待删除的目录下，然后  CubeFS 后台定时扫描，异常清理待删除目录。一次 rename 操作在 CubeFS 只需要跟后端交互两次，相比于之前串行的删除目录下所有文件，延时由 N 个ms降低到了稳定的 2ms 左右。使用 CubeFS 存储将 Shuffle 的时延减低20%，成本降低20%。

总结来说，CubeFS 帮助大数据服务实现了快、稳、省的目标。有效提升数据的访问性能、提高存储服务的稳定性并大量地节约存储成本，降低总 TCO。

PART

04

未来演进

未来，CubeFS 将会在下面几个方面提供新的特性：

智能分层，未来会根据数据的特性和访问频度将数据分层存储，例如将热数据保存三副本的 SSD 中，而将不常用的冷数据存储在 HDD 或者直接存储到纠删码引擎，以实现更好的性能和资源利用率的提升。

多版本快照能力，机器学习存储过程可能存在多人同时修改文件的需求，对文件安全要求性很高，通过多版本快照能力记录文件变化的过程，可以帮忙用户快速恢复到特定版本混合云多云的支持，帮助用户充分利用不同云服务的优势和特性，实现多云的管理。除此之外还会在 GDS、数据加解密以及数据回收站等方面持续演进。

唐之享总结道，CubeFS 是开源的云原生分布式存储产品，高效、稳定、弹性；助力大数据与 AI 无限潜能，让大家存得放心、用得省心！同时呼吁大家参与到社区共建中，一起推动 CubeFS 的发展，为更多企业提供高性能、高可靠的分布式存储解决方案。

END

About AndesBrain

安第斯智能云

OPPO 安第斯智能云（AndesBrain）是服务个人、家庭与开发者的泛终端智能云，致力于“让终端更智能”。作为 OPPO 三大核心技术之一，安第斯智能云提供端云协同的数据存储与智能计算服务，是万物互融的“数智大脑”。