共计 1723 个字符,预计需要花费 5 分钟才能阅读完成。
背景
存储是大数据的基石,存储系统的元数据又是它的外围大脑,元数据的性能对整个大数据平台的性能和扩大能力十分要害。本文选取了大数据平台中 3 个典型的存储计划来压测元数据的性能,来个大比拼。
其中 HDFS 是被广为应用的大数据存储计划,曾经通过十几年的积淀和积攒,是最合适的参考标杆。
以 Amazon S3 和 Aliyun OSS 为代表的对象存储也是云上大数据平台的候选计划,但它只有 HDFS 的局部性能和语义,性能也差不少,理论应用并不宽泛。在这个测试中对象存储以 Aliyun OSS 为代表,其余对象存储相似。
JuiceFS 是大数据圈的新秀,专为云上大数据打造,是合乎云原生特色的大数据存储计划。JuiceFS 应用云上对象存储保留客户数据内容,通过 JuiceFS 元数据服务和 Java SDK 来实现 HDFS 的残缺兼容,不须要对数据分析组件做任何批改就能够失去跟 HDFS 一样的体验。
测试方法
Hadoop 中有一个专门压测文件系统元数据性能的组件叫 NNBench,本文就是应用它来做压测的。
原版的 NNBench 有一些局限性,咱们做了调整:
- 原版 NNBench 的单个测试工作是单线程的,资源利用率低,咱们将它改成多线程,便于减少并发压力。
- 原版 NNBench 应用 hostname 作为路径名的一部分,没有思考同一个主机里多个并发工作的抵触问题,会导致多个测试工作反复创立和删除文件,不太合乎大数据工作负载的理论状况,咱们改成应用 Map 的顺序号来生成路径名,防止的一个主机上多个测试工作的产生抵触。
咱们应用了 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)随着并发数增长的曲线,有两个发现:
- 其中 Open/Read 和 Delete 操作的性能要远高于 Create 和 Rename。
- 在 20 个并发前,TPS 随着并发数线性增长,之后就增长迟缓了,到 60 个并发曾经能压到 TPS 的极限(满负载)。
再来看看 OSS 的性能状况:
OSS 速度比 HDFS 慢了一个数量级,但它的各种操作的速度根本保持稳定,总的 TPS 随着并发数的增长而增长,在 80 个并发下还没遇到瓶颈。受测试资源所限,未能进一步加大压测晓得它的下限。
最初看下 JuiceFS 的体现:
从图中能够看出,整体趋势和 HDFS 相似,Open/Read 和 Delete 操作显著比 Create/Rename 快很多。JuiceFS 的 TPS 也是在 20 个并发以内根本放弃线程增长,之后增长放缓,在 60 个并发左右达到上线。 但 JuiceFS 增幅更快,下限更高 。
具体性能比照
为了更直观的看出这三者的性能差别,咱们间接把 HDFS、Aliyun OSS 和 JuiceFS 放在一起比拟:
可见无论是哪种元数据操作,JuiceFS 的 TPS 增长更快,下限也更高 ,显著优于 HDFS 和 OSS。
总结
个别咱们在看一个零碎的性能时,次要关注它的操作时延(单个操作所耗费的工夫)和吞吐量(满负载下的解决能力),咱们把这两个指标再汇总一下:
上图是 20 个并发下的各操作的时延(未跑满负载),能够发现:
- OSS 十分慢,尤其是 Rename 操作,因为它是通过 Copy + Delete 实现的。本文测试的还只是单个文件的 Rename,而大数据场景罕用的是对整个目录的 Rename,差距会更大。
- JuiceFS 的速度比 HDFS 更快,快一倍多。
上图是 80 个并发时的吞吐量比照,能够发现:
- OSS 的吞吐量非常低,和其它两个产品有一到两个数量级的差距,意味着它须要应用更多的计算资源,产生更高的并发,能力取得等同的解决能力。
- JuiceFS 比 HDFS 的解决能力高 50-200%,同样的资源可能撑持更大规模的计算。
从以上两个外围性能指标来看,对象存储不适宜要求性能的大数据分析场景。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟!(0ᴗ0✿)