元数据是存储系统的核心大脑 , 元数据性能对整个大数据平台的性能和扩展能力至关重要 。尤其在处理海量文件的时候 。在平台任务创建、运行和结束提交阶段 , 会存在大量的元数据 create,open , rename 和 delete 操作 。因此,在进行文件系统选型时,元数据性能可谓是首当其冲需要考量的一个因素 。
目前主流的大数据存储方案中,HDFS 是使用最为广泛的方案 , 已经过十几年的沉淀和积累;以 Amazon S3 为代表的对象存储是近年来云上大数据存储的热门方案;JuiceFS 是大数据圈的新秀 , 专为云上大数据打造,基于对象存储来进行大数据存储 。因此,我们选取了这 3 个典型的存储方案 HDFS、Amazon S3 与 JuiceFS 社区版 进行元数据的性能测试 。
测试方法NNBench 是Hadoop 中有一个专门压测文件系统元数据性能的组件,本次测试就是使用它来进行的 。
原版的 NNBench 有一些局限性,我们做了调整:
- 原版 NNBench 的单个测试任务是单线程的,资源利用率低,我们将它改成多线程,便于增加并发压力 。
- 原版 NNBench 使用 hostname 作为路径名的一部分 , 没有考虑同一个主机里多个并发任务的冲突问题,会导致多个测试任务重复创建和删除文件,不太符合大数据工作负载的实际情况,我们改成使用 Map 的顺序号来生成路径名 , 避免的一个主机上多个测试任务的产生冲突 。
测试软件:
- emr-6.4.0,hadoop3.2.1,HA部署
- master(3台):m5.xlarge, 4 vCore, 16 GiB
- core(3台): m5.xlarge, 4 vCore, 16 GiB
JuiceFS 元数据引擎:ElastiCache,6.2.6,cache.r5.large
性能表现先来看看大家都熟悉的 HDFS 的性能表现:
文章插图
此图描述的是 HDFS 每秒处理的请求数(TPS)随着并发数增长的曲线,随着并发的增加 , TPS基本呈现线性增长 。
【元数据性能大比拼:HDFS vs S3 vs JuiceFS】
文章插图
- S3 速度比 HDFS 慢了一个数量级,但它的各种操作的速度基本保持稳定,总的 TPS 随着并发数的增长而增长 。
- 但 S3 性能不太稳定 , 可以看到 Delete 请求在 100 并发下反而出现了下降的情况,猜测可能和 S3 本身的负载有关 。
文章插图
- 整体趋势和 HDFS 类似,Open 会比其他操作快很多 。
- JuiceFS 的 TPS 也是在 20 个并发以内基本保持线性增长,之后增长放缓 , 在 80 个并发左右达到上限
文章插图
文章插图
文章插图
文章插图
- JuiceFS 在所有元数据操作上均大幅领先于 S3 。
- JuiceFS 在 Create 和 Open 操作上领先于 HDFS 。
- 此次测试中使用的元数据引擎是ElastiCache,各操作在 80 并发左右会达到性能瓶颈 , 表现比 HDFS 差 。
文章插图
上图是 20 个并发下的各操作的时延(未跑满负载),可以发现:
- S3 非常慢,尤其是 Rename 操作,因为它是通过 Copy + Delete 实现的 。本文测试的还只是单个空文件的 Rename,而大数据场景常用的是对整个目录的 Rename , 差距会更大 。
- JuiceFS 的速度比 HDFS 更快 。
文章插图
上图是 100 个并发时的吞吐量对比,可以发现:
- S3 的吞吐量非常低,和其它两个产品有一到两个数量级的差距,意味着它需要使用更多的计算资源,产生更高的并发,才能获得同等的处理能力 。
- JuiceFS 比 HDFS 的处理能力基本和 HDFS 持平,部分操作性能高于 HDFS 。
推荐阅读
- 全国状元-今年高考全国状元是谁啊
- JS数据结构与算法-队列结构
- 骁龙888和骁龙870性能对比-骁龙888和骁龙870哪个好
- Day04:Java数据类型
- 关于入门深度学习mnist数据集前向计算的记录
- 天玑920和天玑900有什么区别_性能差多少
- .NET性能优化-是时候换个序列化协议了
- EasyPoi大数据导入导出百万级实例
- JAVA开发搞了一年多的大数据,究竟干了点啥
- 重新整理 .net core 实践篇 ———— linux上性能排查 [外篇]