从本地到云端豆瓣如何使用 JuiceFS 实现统一的数据存储

从本地到云端豆瓣如何使用 JuiceFS 实现统一的数据存储

作者|曹丰宇

策划|Tina

豆瓣成立于2005年，是中国最早的社交网站之一。在2009到2019的十年间，豆瓣数据平台经历了几轮变迁，形成了DParkMesosMooseFS的架构。

由机房全面上云的过程中，原有这套架构并不能很好的利用云的特性，豆瓣需要做一次全面的重新选型，既要考虑未来十年的发展趋势，也需要找到与现有组件兼容且平滑过渡的解决方案。一番改造后，豆瓣数据平台目前形成了SparkKubernetesJuiceFS的云上数据湖架构，本文将分享此次选型升级的整体历程。

01豆瓣早期数据平台

在2019年，豆瓣所使用的数据平台主要由以下组件构成：

GentooLinux，内部使用的Linux发行版；MooseFS，分布式文件系统；ApacheMesos负责整个集群的**管理，以及Dpark作为分布式计算框架提供给开发者使用。

（豆瓣早期数据平台架构）

从上图可以看到在这个数据平台中，计算和存储是一体的，每个计算任务是由Mesos进行调度的。计算任务的I/O操作都是通过MooseFS的Master获取元数据，并在本地获取需要计算的数据。此外，GPU计算集群也是通过Mesos进行管理，不同的是，GPU会基于显存进行共享。

平台组件介绍

GentooLinux

GentooLinux是一个较为小众的Linux发行版，具有几乎无限制的适应性特性，是一个原发行版。GentooLinux***用滚动更新的方式，所有软件包都直接从社区中获取二进制包，我们则通过源代码构建我们所需的软件包。GentooLinux有一个***大的包管理器，使用它也会带来很多便利，也同时存在一些问题。比如，滚动更新的速度非常快，但对于服务器来说，可能存在一定的不稳定性。

使用源代码构建软件包的好处是当社区没有预编译好我们所需的软件包时，我们可以非常简单地构建出自己所需的软件包，并且当已有的软件包无法满足我们的需求时，也可以很容易地进行定制调整。但这也会带来较高的维护成本。

另外，如果所有软件包都能按照规范进行编写的话，依赖冲突问题几乎是不存在的，因为在打包过程中就已经可以发现。但实际情况是并不是所有软件包都能遵守一个好的依赖描述的约定，因此依赖冲突问题可能仍然存在。

GentooLinux是较为小众的选择，尽管社区质量很高，但是用户也比较少，一些新项目可能没有用户进行足够的测试，我们在实际使用过程中会遇到各种各样的问题。这些问题大部分需要我们自己解决，如果等待其他人回复的话，响应会比较慢。

MooseFS

MooseFS是一个开源的、符合POSIX标准的分布式文件系统，它只使用FUSE作为I/O接口，并拥有分布式文件系统的标准特性，如容错、高可用、高性能和可扩展性。

对于几乎所有需要使用标准文件系统的场景，我们都使用MooseFS作为替代品，并在其基础上开发了一些自己的小工具。例如，我们可以直接使用分布式文件系统来处理CDN的回源。在早期版本中，MooseFS没有主节点的备份功能，因此我们开发了一个ShadowMaster作为元数据的热备节点，并编写了一些分析MooseFS元数据的工具，以解决一些运维问题。作为一个存储设施，MooseFS整体比较稳定，并且没有出现重大的问题。

ApacheMesos

Mesos是一个开源的集群管理器，与YARN有所不同，它提供公平分配**的框架，并支持**隔离，例如CPU或内存。Mesos早在2010年就被Twitter***用，IBM在2013年开始使用。

Dpark

由于公司全员使用Python，因此使用了Python版的Spark，即Dpark，它扩展了RDDAPI，并提供了DStream。

公司内部还开发了一些小工具，例如drun和mrun，可以通过Dpark将任意Bash脚本或数据任务提交到Mesos集群，并支持MPI相关的任务提交。Dgrep是用于快速查询日志的小工具，JuiceFS也提供了类似的工具。虽然Dpark本身可以容器化，但公司主要的数据任务是在物理服务器上运行的。支持容器化可以让场内任务更好地利用线上业务的模型代码。

02平台演进的思考

在2019年，公司决定将基础设施转移到云端并实现计算和存储分离，以提高平台的灵活性。由于以前的计算任务在物理机上运行，随着时间的推移，出现了越来越多的依赖冲突问题，维护难度不断增加。

同时，公司希望内部平台能够与当前的大数据生态系统进行交互，而不仅仅是处理文本日志或无结构化、半结构化的数据。此外，公司还希望提高数据查询效率，现有平台上存储的数据都是行存储，查询效率很低。最终，公司决定重新设计一个平台来解决这些问题。

平台演进时，我们没有非常***的兼容性需求。只要成本收益合理，我们就可以考虑将整个平台替换掉。这就像是环法自行车比赛中，如果车有问题就会考虑换车，而不是只换轮子。在更换平台时，我们如果发现现有平台的任务无法直接替换，可以先保留它们。在切换过程中，我们有以下主要需求：

Python是最优先考虑的开发语言。

必须保留FUSE接口，不能直接切换到HDFS或者S3。

尽可能统一基础设施，已经选用了部分Kubernetes，就放弃了Mesos或其他备选项。

新平台的学习成本应尽可能低，让数据组和算法组的同事能够以最低的成本切换到新的计算平台上。

03云上构建数据平台

目前的云上数据平台几乎是全部替换了，GentooLinux的开发环境变成了Debianbasedcontainer的环境，MooseFS是换用了现在的JuiceFS，**管理使用了Kubernetrs，计算任务的开发框架使用了Spark，整体进行了彻底替换的，其他的设施是在逐渐缩容的过程，还会共存一段时间。

（豆瓣数据平台架构）

JuiceFS作为统一存储数据平台

为了更好地满足不同的I/O需求和安全性考虑，我们会为不同的使用场景创建不同的JuiceFS卷，并进行不同的配置。JuiceFS相对于之前的MooseFS，创建文件系统更加简单，实现了按需创建。除了SQL数据平台外，我们的使用场景基本上都是由JuiceFS提供的服务。

在JuiceFS中，数据有几种类型：在线读写、在线读取离线写入、在线写入离线读取、离线读写。

所有的读写类型都在JuiceFS上进行，比如日志汇聚到卷中，Spark可能会读取并进行ETL，然后将数据写入数据湖。此外，从Kafka数据源读取的数据也会通过Spark进行处理并写入数据湖。

Spark的CheckPoint直接存储在另一个JuiceFS卷中，而数据湖的数据则直接提供给算法组的同学进行模型训练，并将训练结果通过JuiceFS写回。我们的运维团队则通过各种脚本或工具来管理JuiceFS上的文件生命周期，包括是否对其进行归档处理等。因此，整个数据在JuiceFS中的流转过程大致如上图所示。

新数据平台组件介绍

Debianbasedcontainer

首先，运维团队选择了Debianbasedcontainer作为基础镜像，我们就直接使用了。我们的计算平台的镜像很大，为了解决任务启动速度的问题，团队在每个节点上预拉取了镜像。

JuiceFS

切换到JuiceFS存储系统时，用户感受不到变化，JuiceFS非常稳定。JuiceFS比MooseFS更好的一点是，它拥有HDFS的SDK，方便了团队将来切换到Spark等工具。团队在Kubernetes上使用了JuiceFSCSI，可以直接使用JuiceFS作为PersistVolume，用起来十分方便。JuiceFS团队沟通高效，解决问题迅速。例如，当stream的checkpoint频率太高时，JuiceFS团队早早通知并迅速解决。

Kubernentes

我们早在1.10版本的时候就开始试用Kubernetes。后来豆瓣对外的服务集群在1.12版本开始逐步迁移到Kubernetes，基本上是在现有机器上完成了原地的替换。计算集群则是在上云后开始搭建的，基于1.14版本。我们在版本升级方面可能比其他公司更为激进，目前我们的Kubernetes版本已经升级到了1.26版。

我们选择Kubernetes作为计算平台的原因之一是它有比较统一的组件。此外，通过schedulingframework或者Volcano，我们可以影响它的调度，这是我们比较希望拥有的一个特性。

我们还可以利用社区的Helm非常快速地部署一些需要的东西，比如Airflow、Datahub和Milvus等服务，这些服务都是通过Helm部署到我们的离线Kubernetes集群中提供的。

Spark

在最开始测试Spark时，我们像使用Dpark一样将任务运行在Mesos集群上。之后我们选定了Kubernetes，使用GoogleCloudPlatform上的spark-on-k8s-operator将Spark任务部署到Kubernetes集群中，并部署了两个Streaming任务，但并未进行大规模的部署。

随后，我们确定了使用Kubernetes和Airflow，**自己实现一个AirflowOperator，在Kubernetes中直接提交Spark任务，并使用Spark的ClusterMode将任务提交到Kubernetes集群中。

对于开发环境，我们使用JupyterLab进行开发。厂内有一个Python库对SparkSession进行了一些小的预定义配置，以确保Spark任务能够直接提交到Kubernetes集群上。

目前，我们使用KubernetesDeployment直接部署Streaming任务，这是一个很简单的状态，未来可能会有一些改进的地方。另外，我们正在准备试用Kyuubi&SparkConnect项目，希望能够为线上任务提供更好的读写离线数据的体验。

我们的版本升级非常激进，但确实从社区中获益匪浅。我们解决了日常计算任务中许多常见的优化场景。我们激进升级的原因是希望能够尽可能多地利用社区的**，提供新特性给开发者。但我们也遇到了问题，例如Spark3.2的parquetzstd压缩存在内存泄漏。为了规避这个问题，我们提前引入了未发布的补丁。

现在，我们使用两种方式来读写JuiceFS数据：FUSE和HDFS。FUSE主要用于ETL任务，例如读写日志和CSV文件。我们也会将Hive表转存为CSV文件下载供未切换到Spark的任务进行计算。其他的数据，则直接通过预先配置好的HDFS（如HiveTable和IcebergTable）进行读写，这大大简化了我们的工作。

在数据湖的选择上，我们一开始考虑了DeltaLake，但由于它不支持MergeonRead，在目前的使用场景存在写放大，我们放弃了它。取而代之，我们选择了Iceberg，并将其用于MySQLCDC处理。我们将数据直接存储在JuiceFS上进行读写，并且目前没有遇到任何性能上的问题。未来，如果我们需要扩大规模使用，可能需要与JuiceFS的团队沟通一下，看看有哪些优化措施。

04收获与展望

我们切换到新的计算平台之后，获得了很多原来没有的功能。例如，我们现在可以使用基于SQL的大量任务，这些任务的性能比以前好得多，各种报表的实时性也更好了。

与Mesos的情况不同，Spark声明了多少**就使用多少**，这与以前的Dpark相比有很大的差异，因为以前大家都是公平分享，相互之间会有影响。现在，每个任务的执行时间都比较可预测，任务评估也比较容易预测，整个新平台对于业务数据的读取也有更好的时效性。

以前的历史包袱是相当沉重的，现在我们已经赶上了社区的步伐。去年年末的各种统计和排名都已经迁移到了新的计算平台上，并且运行非常稳定。

我们正在优先考虑***取一些成本下降措施，以实现整个计算集群的动态扩缩容。我们正积极努力实现此目标，并希望提供更加稳定的SQL接口。为此，我们*****用支持Multi-tenant的SQL服务器，并尝试引入Spark3.4的最新特性。

长远来看，我们希望通过SparkRemoteShuffleService进一步实现存算分离，以便更有效地利用**。也许未来我们会开发一个“SparkasaService”，提供给开发者使用。总之，我们正在追赶社区的步伐，并不断努力提升我们的技术水平。

关于作者

曹丰宇，负责豆瓣数据平台的功能开发和维护

直播回顾：

https://www.bilibili.com/video/BV1oM41137Rp/

豆瓣的基础架构-https://www.infoq.cn/article/douban-infrastructure-2014-

豆瓣的研发管理-https://www.infoq.cn/article/douban-dev-management-

洪***宁：编程三十年，因Python结识豆瓣，想用技术改变世界-https://www.infoq.cn/article/sa\*aTPRbs3whkd1xrpUY-

元数据性能大比拼：HDFS vs OSS vs JuiceFS

存储是大数据的基石，存储系统的元数据又是它的核心大脑，元数据的性能对整个大数据平台的性能和扩展能力非常关键。本文选取了大数据平台中 3 个典型的存储方案来压测元数据的性能，来个大比拼。

其中 HDFS 是被广为使用的大数据存储方案，已经经过十几年的沉淀和积累，是最合适的参考标杆。

以 Amazon S3 和 Aliyun OSS 为代表的对象存储也是云上大数据平台的候选方案，但它只有 HDFS 的部分功能和语义，性能也差不少，实际使用并不广泛。在这个测试中对象存储以 Aliyun OSS 为代表，其他对象存储类似。

JuiceFS 是大数据圈的新秀，专为云上大数据打造，是符合云原生特征的大数据存储方案。JuiceFS 使用云上对象存储保存客户数据内容，通过 JuiceFS 元数据服务和 J*a SDK 来实现 HDFS 的完整兼容，不需要对数据分析组件做任何修改就可以得到跟 HDFS 一样的体验。

Hadoop 中有一个专门压测文件系统元数据性能的组件叫 NNBench，本文就是使用它来做压测的。

原版的 NNBench 有一些局限性，我们做了调整：

我们使用了 3 台阿里云 4核 16G 的虚拟机来做压力测试。CDH 5 是目前被广泛使用的发行版，我们选用 CDH 5 作为测试环境，其中的 HDFS 是 2.6 版本。 HDFS 是使用 3 个 JournalNode 的高可用配置，JuiceFS 是 3 个节点的 Raft 组。HDFS 使用内网 IP，JuiceFS 使用的是弹性 IP，HDFS 的网络性能会好一些。OSS 是使用内网接口访问。

先来看看大家都熟悉的 HDFS 的性能表现：

此图描述的是 HDFS 每秒处理的请求数（TPS）随着并发数增长的曲线，有两个发现：

再来看看 OSS 的性能情况：

[图片上传失败...(image-5b3536-1644394129139)]

OSS 速度比 HDFS 慢了一个数量级，但它的各种操作的速度基本保持稳定，总的 TPS 随着并发数的增长而增长，在 80 个并发下还没遇到瓶颈。受测试**所限，未能进一步加大压测知道它的上限。

最后看下 JuiceFS 的表现：

从图中可以看出，整体趋势和 HDFS 类似，Open/Read 和 Delete 操作明显比 Create/Rename 快很多。JuiceFS 的 TPS 也是在 20 个并发以内基本保持线程增长，之后增长放缓，在 60 个并发左右达到上线。 但 JuiceFS 增幅更快，上限更高 。

为了更直观的看出这三者的性能差异，我们直接把 HDFS、Aliyun OSS 和 JuiceFS 放在一起比较：

[图片上传失败...(image-10c829-1644394129139)]

可见无论是哪种元数据操作， JuiceFS 的 TPS 增长更快，上限也更高 ，明显优于 HDFS 和 OSS。

一般我们在看一个系统的性能时，主要关注它的操作时延（单个操作所消耗的时间）和吞吐量（满负载下的处理能力），我们把这两个指标再汇总一下：

[图片上传失败...(image-a6e611-1644394129139)]

上图是 20 个并发下的各操作的时延（未跑满负载），可以发现：

上图是 80 个并发时的吞吐量对比，可以发现：

从以上两个核心性能指标来看，对象存储不适合要求性能的大数据分析场景。