简介：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 元数据服务当中。文件大小按 1：1 相应地创立 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 亿级别的文件数，磁盘占用有近 100GB，JindoFS 元数据服务只会缓存局部热文件元数据，那么元数据文件的 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 组目录，
目录 a：Hive warehouse 目录蕴含 31.7 万目录，1250 万文件；
目录 b：某 database 目录蕴含 1 万 2 目录，32 万文件；
目录 c：某 table 目录蕴含 91 个目录，7.7 万文件；
目录 d：spark 后果寄存目录蕴含 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，目前从事开源大数据存储和优化方面的工作。
原文链接
本文为阿里云原创内容，未经容许不得转载