Maybe News Issue #1
「Maybe News」是一个定期(或许不定期)分享一些可能是新闻的知识的系列文章,名字来源于我非常喜欢的一个国内的音乐厂牌「兵马司」(Maybe Mars)。你也可以通过邮件订阅它。
CFS: A Distributed File System for Large Scale Container Platforms
跟上次介绍的 FoundationDB Record Layer 一样,这篇来自京东团队的论文也是发表在 SIGMOD 2019,介绍了一个为大规模容器平台设计的分布式文件系统。
系统整体由 3 部分组成:元数据子系统(metadata subsystem)、数据子系统(data subsystem)、资源管理器(resource manager)。元数据子系统负责维护 inode 和 dentry(directory entry),数据子系统负责存储数据块,资源管理器负责处理客户端的各种文件操作请求以及维护前面两个子系统的状态。元数据子系统和数据子系统都是多 partition 的分布式系统,多个元数据和数据的 partition 逻辑上共同组成一个卷(volume),这个卷即是对客户端(容器)可见的存储单元并且可以被挂载,通过传统的 POSIX 接口访问。
因为上述 3 部分组件内部其实都是一个分布式系统,因此都用到了 Raft 作为一致性协议,资源管理器还用到了 RocksDB 作为本地持久化存储。稍微特殊的是数据子系统根据不同类型的写操作选择了不同的复制方案,论文里把这个叫做 Scenario-Aware Replication,具体讲就是顺序写操作(比如 append)用的是 primary-backup,而覆盖(overwrite)操作用的是 Raft。
系统的另一个亮点是基于资源利用率的 partition 分配策略,论文中叫做 Utilization-Based Placement。传统的 partition 分配策略通常是哈希,这种策略的优点是简单但是当扩缩容时必须进行 rebalance。CFS 的做法是元数据和数据子系统定期上报内存、磁盘使用率到资源管理器,当需要创建新的 partition 时根据资源利用率 选择最低的那个节点,这样设计的好处是不再需要 rebalance。但是对于这种设计方案是否会造成数据不均衡表示存疑,论文中也没有做过多论述。
为了尽量减少客户端的网络交互,不让某个系统组件成为瓶颈,客户端会缓存元数据子系统、数据子系统和资源管理器的信息到本地,当执行文件操作时会优先读取本地缓存。当然某些组件(比如资源管理器)还是有可能在某一天成为瓶颈,但是基于京东的经验这件事情基本上不会发生。
在与 Ceph 的评测中,CFS 平均有 3 倍的 IOPS 提升,特别是多客户端和随机读写的场景。这很大程度上得益于元数据和数据节点分离的设计,且 CFS 的元数据是全内存存储,而 Ceph 并不是。
分布式文件系统一直都是比较重要的基础组件,在分布式数据库、大数据、机器学习领域有广泛应用。常见的分布式文件系统如 HDFS、Ceph,在如今这个全面推行容器化的时代越来越显得捉襟见肘。容器化一个很大的特点是快速扩缩容,传统的存储系统在这一点上是非常不友好的,因此才会有越来越多针对容器化场景的基础组件诞生(具体可以访问 CNCF 查看),这里介绍的 CFS 是一个例子,另一个类似的是 JuiceFS。
CFS 目前属于 CNCF 下的 sandbox 项目,且已经开源,使用 Go 语言编写。
tensorflow/community #237: RFC: Sparse Domain Isolation for Supporting large-scale Sparse Weights Training
推荐系统大规模稀疏特征分布式训练一直是工业界一件有挑战的事情,大公司内部自研的训练框架大多已经解决了这个问题,但是在开源社区问题仍然存在。TensorFlow 作为也许目前最流行的深度学习训练框架,社区里也早有相关的讨论(比如 #19324、#24539、#24915),但基本都以烂尾告终。最新的 RFC #237 来自腾讯,区别于现有的一些开源实现(比如阿里巴巴的 XDL、字节跳动的 BytePS、蚂蚁金服的 ElasticDL)完全自己重新造了一个 parameter server,腾讯的方案最大限度复用了 TensorFlow 现有的组件,对用户的代码侵入也最小。目前这个 RFC 还在讨论中,有兴趣可以订阅 PR。