如何解决Hadoop管理百亿小文件瓶颈?
当前比较常见的大数据方案基本是采用Hadoop,其中使用CDH最为普遍。不过Hadoop大数据方案在大规模场景会遇到各种挑战,之前文章有做基本的分析《Hadoop大数据存算分离需要什么样的存储?》。除此之外,面对海量小文件存储时,Hadoop方案也存在明显瓶颈。
01
NameNode内存占用问题
在运行时,HDFS中每个文件、目录和数据块的元数据信息(大约150字节)必须存储在NameNode的内存中。根据Cloudera的建议,默认情况下,会为每一百万个数据块分配一个最大的堆空间1GB(但绝不小于1GB)。所以我们可以计算得出如果HDFS要存储3亿个文件(每个文件对应一个数据块),则需要至少300GB的内存空间。
02
Hadoop中的小块问题
这里的小块一般是指块大小明显小于Hadoop的block size。一般有两种情况会产生这个问题:1、海量小文件,如5亿的200kb小文件;2、海量小块,如block size是128MB,但加载到HDFS的文件都是130MB,则会出现大量2MB的block。处理这种“小块”问题可以选择调大block size来解决,但解决小文件问题却要复杂的多。03小文件的来源
小文件的来源有很多,比较典型的有以下几种:
源数据为海量小文件,直接拷贝到HDFS集群,如一些图片、短视频、短音频等文件;
在Hadoop处理实时或者准实时计算场景中,大部分时候抽取数据的时间间隔决定了文件的大小,如果间隔较小,比如每小时抽取一次,则生成的文件可能只有几MB或十几MB;
由计算组件生成,当MapReduce中reduce数量设置过多,就可能导致任务运行结果变成N多小文件。对于Hive,如果设置了分区表,当表的数据量不大时,分区越多,则每个分区的数据量越小,对应的分区表文件也就会越小。
04内存过大的影响
假设一个HDFS管理3亿的小文件,通过估算NameNode占用的内存大概是300GB。那么当它重启时,则需要从本地磁盘读取每个文件的元数据。这意味着NameNode需要加载300GB大小的数据到内存中,从而不可避免的导致服务启动时间较长。
又因为NameNode是基于JVM运行,如果占用300GB的内存,则表示JVM需要配置300GB的heap,当JVM执行full gc时,将会导致业务阻塞。
在HDFS中,DataNode会通过定时的心跳来上报其数据块的位置信息,NameNode会不断跟踪并检查每个数据块的存储位置。所以数据节点需要上报的数据块越多,则会消耗越多的网络带宽,进而对网络造成压力。
内存过大导致实际限制了HDFS中可以存储的对象数量,也就意味着对于一个拥有大量文件的超大集群来说,内存将成为限制系统横向扩展的瓶颈。
同时,作为一个可扩展的文件系统,单个集群中支持数千个节点。在单个命名空间中DataNode可以扩展的很好,但是NameNode并不能在单个命名空间进行横向扩展。通常情况下,HDFS集群的性能瓶颈在单个NameNode上。
05常规解决方案及存在的问题要解决Hadoop中小文件的问题,首先要尽量在源头解决问题,也就是对于因为某些组件配置不合理导致产生大量小文件的情况,需要优化配置来减少小文件的生成。但有些场景会不可避免地生成一些小文件,就需要引入其他方案来解决问题。Hadoop提供了几种常用的方法来解决这个问题,这些方法在某些方面解决了一定的问题,但也都存在着各自的不足。1、联邦HDFS在Hadoop 2.x发行版中引入了联邦HDFS功能,期望可以解决NameNode的内存问题。联邦HDFS允许系统通过添加多个NameNode来实现扩展,其中每个NameNode管理文件系统命名空间中的一部分。但是,系统管理员需要维护多个NameNode和负载均衡服务,这又增加了管理成本。所以HDFS的联邦方案并没有被生产环境所采用。
使用HBase,可以较好的应对实时数据写入以及实时查询的场景,在HBase 里同一类的文件实际是存在同一个列族下面,如果文件数量太多,会导致regionserver 内存占用过大,JVM内存过大时gc会卡业务。根据实际测试无法有效支持10亿以上的小文件存储。
06
XSKY解决方案
流式数据导入过程中产生的小文件是一个比较让人头疼的问题。根据当前面临的挑战,XSKY对象存储产品XEOS和Hadoop大数据平台结合的实践方案,互补两个系统的优势。1、Hadoop原有方案:业务在对数据进行查询检索时,可以从HBase中获取原始文件数据在XEOS存储中的URL信息,通过URL直接从XEOS存储中读取对应的文件数据,该方案完美解决了原来Hadoop方案的海量小文件存储瓶颈问题。
07
存储特性介绍
1、海量小文件管理海量小文件处理的瓶颈在于对元数据的处理,XEOS对象存储产品对元数据的存储和管理采用了RocksDB,RocksDB具有很好的写性能。每个磁盘元数据分区部署1个RocksDB实例,规划一组磁盘组成一个RocksDB集群(索引池)。纯SSD盘或混合盘采用副本方式,用于存储所有元数据,满足百亿元数据管理的同时进一步提高了元数据访问效率。元数据管理-索引池架构(以混合盘为例):08
总结
XSKY对象存储产品XEOS和Hadoop大数据平台结合的实践方案,补充了Hadoop在管理实时小文件上的不足,很好的解决了Hadoop管理海量小文件的问题,XEOS支持的海量小文件管理及文件归并特性很好的面对海量数据增长需求。多活动池及整池扩容功能可支持灵活扩容,不但不影响业务正常使用,还可以新、旧资源池同时使用,聚合性能和容量同时提升。灵活的生命周期管理大大降低了数据存储成本,提高了空间利用率。结合Hadoop大数据平台成熟的分析及元数据管理技术,为业务访问提供了更好性能。随着客户业务不断增长和对数据有不同访问和管理需求,XSKY对象存储产品还可以支持根据不同访问需求的数据进行数据分层,将对访问频率不高的数据存储到性能低存储介质中进行管理,同时支持分层到云端管理。—END—推荐阅读
Recommended reading
点击下列标题 阅读更多资讯
| 「行业观察」从vSphere7看SDS在私有云场景的发展趋势
| 基于英特尔®傲腾™的XSKY XSCALER fCache技术助力医疗影像系统
| 如何利用Kubernetes部署并管理XSKY SDS?