中英版网站怎么做,进行网站开发前 需要干什么,网络运营好学吗,新浪博客怎么做网站简介#xff1a; Apache Hadoop FileSystem (HDFS) 是被广为使用的大数据存储方案#xff0c;其核心元数据服务 NameNode 将全部元数据存放在内存中#xff0c;因此所能承载的元数据规模受限于内存#xff0c;单个实例所能支撑的文件个数大约 4亿。JindoFS块模式是阿里云基… 简介 Apache Hadoop FileSystem (HDFS) 是被广为使用的大数据存储方案其核心元数据服务 NameNode 将全部元数据存放在内存中因此所能承载的元数据规模受限于内存单个实例所能支撑的文件个数大约 4亿。JindoFS块模式是阿里云基于 OSS 海量存储自研的一个存储优化系统提供了高效的数据读写加速能力和元数据优化能力。JindoFS 实际表现如何我们在 10亿文件数规模下做了压测验证 JindoFS 在达到这个规模的时候是否还可以保持稳定的性能。 主要介绍 Apache Hadoop FileSystem (HDFS) 是被广为使用的大数据存储方案其核心元数据服务 NameNode 将全部元数据存放在内存中因此所能承载的元数据规模受限于内存单个实例所能支撑的文件个数大约 4亿。JindoFS块模式是阿里云基于 OSS 海量存储自研的一个存储优化系统提供了高效的数据读写加速能力和元数据优化能力。在设计上避免了 NameNode 上的内存限制与HDFS不同的一点是JindoFS元数据服务采用RocksDB作为底层元数据存储RocksDB可以存储在大容量本地高速磁盘解决了内存容量瓶颈问题。借助于内存缓存将10%~40%的热文件元数据存放于内存缓存从而保持稳定的优秀的读写性能。借助于Raft机制JindoFS元数据服务可以组成3个主备实例实现服务高可用。JindoFS 实际表现如何我们在 10亿文件数规模下做了压测验证 JindoFS 在达到这个规模的时候是否还可以保持稳定的性能。同时在一些关键的元数据操作上我们也跟 HDFS 做了个测试对比。 JindoFS 10亿文件数测试 HDFS NameNode 单个实例所能支撑的文件个数大约 4亿主要原因是受限于内存大小。除此之外由于文件数增加需要处理的DataNode上报块也增加造成了性能上的巨大抖动。大量文件信息保存在一个很大的FsImage文件用于下次启动时加载而很大的FsImage文件使得 NameNode 启动需要花费10分钟以上的时间。
JindoFS 解决了以上系列问题它使用 RocksDB 存储元数据相比于 NameNode 可以存储更大规模的文件数不受限于内存。另外不需要Worker节点上报块信息没有性能抖动的问题。JindoFS 元数据服务可以在1s内完成启动毫秒内完成主备节点切换。所以本次测试我们分别测试了 JindoFS 从1亿文件数增长到10亿文件数从而测试其是否可以保持稳定的性能。 数据集共4组
为了测试在不同的元数据规模下JIndoFS元数据服务的性能。我们准备4组数据。分别是初始状态0文件数、1亿文件数、5亿文件数、10亿文件数。我们使用一份真实的经过用户脱敏的HDFS FsImage文件将其还原到JindoFS元数据服务当中。文件大小按11相应地创建block信息一起存入JindoFS元数据。最终生成的数据集如下。 元数据磁盘空间占用 另外目录层级主要分布在5到7级目录居多。数据集的文件大小分布、目录层级分布一定程度上比较接近生产环境的情况。 NNBench测试
NNBench全称NameNode Benchmark是HDFS官方自带的用于测试NameNode性能的工具。由于它使用的是标准的FileSystem接口因此我们可以使用它来测试JindoFS服务端的性能。NNBench的执行参数如下
测试写性能
-operation create_write -maps 200 -numberOfFiles 5000 -bytesToWrite 512
测试读性能
-operation open_read -maps 200 -numberOfFiles 5000 -bytesToWrite 512 启动200个Map Task每个Task写读5000个文件共计100万个文件。受测试集群规模限制实际同时执行Map个数为128个 测试结果 NNBench的结果很好地反馈了随着元数据规模增长元数据服务的性能变化曲线。通过结果我们可以分析得出
当达到10亿文件数时写入TPS受到略微影响TPS 下降为原先的88%。当达到5亿文件数时读TPS受到略微影响TPS 下降为原先的94%。而10亿文件数时读TPS保持稳定跟5亿文件数时基本持平。TPC-DS测试
使用的是官方TPC-DS数据集5TB数据量使用的是ORC格式Spark作为执行引擎进行测试。
测试成绩如下时间单位秒 99个查询总耗时对比 通过观察发现去掉误差影响随着元数据规模从0增加到10亿文件数TPC-DS成绩基本不受影响。 ls -R/count测试
上述NNBench工具主要测试高并发下元数据服务单点写入、单点查询的性能。然而文件列表导出ls -R)操作、文件大小统计du/count)操作也是用户使用频率较高的操作这些命令的执行时间反应了元数据服务遍历操作的执行效率。
我们使用两个样本数据进行测试
对一个表半年数据154个分区270万个文件执行ls -R操作统计执行时间使用以下命令
time hadoop fs -ls -R jfs://test/warehouse/xxx.db/tbl_xxx_daily_xxx /dev/null
对一个数据库50万个目录1800万个文件执行count操作统计执行时间使用以下命令
time hadoop fs -count jfs://test/warehouse/xxx.db 测试结果发现对于遍历ls -R/count)相同数量的文件目录元数据服务的性能保持稳定不会随着元数据总量的增长有所变化。 对于10亿级别的文件数磁盘占用有近100GBJindoFS元数据服务只会缓存部分热文件元数据那么元数据文件的page cache是否会对性能有所影响我们为此做了测试。
热启动直接重启元数据服务服务此时系统存在page cahe。
冷启动我们使用命令echo 3 /proc/sys/vm/drop_caches清空缓存并重启元数据服务。 测试结果如下使用10亿文件数据集 通过观察发现冷启动情况下这些操作耗时增加了约0.2秒只受到细微的影响。 与HDFS横向对比测试 通过上面的测试我们得知 JindoFS 在10亿文件数下依然保持了稳定的性能。另外我们补充测试了 JindoFS 跟 HDFS 的对比。由于 HDFS 存储10亿规模文件数需要极高规格的机器因此本轮测试我们主要测试1亿文件数场景我们通过横向对比list、du、count等常用操作对比两者的性能差异。 样本说明
抽取 a, b, c, d 共 4 组目录
目录 aHive warehouse目录包含 31.7万目录1250万文件
目录 b某 database 目录包含 1万2目录32万文件
目录 c某 table 目录包含 91个目录7.7万文件
目录 dspark 结果存放目录包含4.2万目录7.1万文件 测试结果用时更短性能更好
单层 list 操作
对单层目录进行展开并输出采样方法 time hadoop dfs -ls [DIR] /dev/null 递归 list 操作
对目录进行逐层展开并输出采样方法 time hadoop dfs -ls -R [DIR] /dev/null du 操作
对目录占用的存储空间进行计算采样方法 time hadoop dfs -du [DIR] /dev/null count 操作
对目录的文件(夹)数量、容量进行计算采样方法 time hadoop dfs -count [DIR] /dev/null 结果分析
通过上述测试结果可以明显发现 JindoFS 在list、du、count等常用操作上速度明显快于 HDFS。分析原因HDFS NameNode 内存中使用了全局的读写锁所以对于查询操作尤其是对目录的递归查询操作都需要拿读锁。拿锁之后使用了单线程串行的方式做目录递归操作速度较慢。拿锁时间长继而又影响了其它rpc请求的执行。JindoFS 从设计上解决了这些问题。它对目录的递归操作使用了多线程并发加速因此在对目录树的递归操作上速度更快。同时使用了不同的目录树存储结构配合细粒度锁从而减少了多个请求之间的影响。
总结 JindoFS 块模式可以轻松地存储10亿文件数并且提供高性能的读写请求处理能力。跟 HDFS NameNode 相比占用内存更小、性能更好、运维更加简单。我们可以利用 JindoFS 作为存储引擎将底层数据存放在对象存储比如OSS上并且利用 JindoFS 的本地缓存加速能力组成一个云上稳定、可靠、高性能的大数据存储方案给上层计算分析引擎提供强大有力的支撑。
作者苏昆辉花名抚月阿里巴巴计算平台事业部 EMR 技术专家, Apache HDFS committer目前从事开源大数据存储和优化方面的工作。
本文为阿里云原创内容未经允许不得转载
作者苏昆辉花名抚月阿里巴巴计算平台事业部 EMR 技术专家, Apache HDFS committer目前从事开源大数据存储和优化方面的工作。
原文链接
本文为阿里云原创内容未经允许不得转载
