当前比较常见的大数据方案基本是采用Hadoop，其中使用CDH最为普遍。不过Hadoop大数据方案在大规模场景会遇到各种挑战，之前文章有做基本的分析《Hadoop大数据存算分离需要什么样的存储？》。除此之外，面对海量小文件存储时，Hadoop方案也存在明显瓶颈。

01

NameNode内存占用问题

NameNode是HDFS中的管理者，主要负责文件系统的命名空间、集群配置信息和数据块的复制等。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的联邦方案并没有被生产环境所采用。

2、归档文件

Hadoop归档文件或HAR文件是将HDFS文件打包到归档中的工具。这是在HDFS中存储大量小文件的比较常用的选择。HAR文件的原理是将很多小文件打包到一起，形成一个HDFS文件（有点类似Linux的TAR文件），这样可以有效的减少HDFS管理的block数量，从而降低NameNode使用。

当访问HAR文件的时候，需要使用“har://”前缀。读取HAR归档文件的中的某个子文件时，需要先读取HAR中的子文件映射关系（索引信息），也就是子文件的位置，再根据位置信息获取实际的文件内容。这样的实现方式会造成一定的读性能损失。

在使用HAR时，要清楚哪些文件需要做归档处理，这就增加了文件系统管理的复杂度。

3、通过HBase

用HBase来存储小文件，也是比较常用的方法之一。HBase在设计上主要为了应对快速插入、存储海量数据、单个记录的快速查找以及流式数据处理。

图片来源：Cloudera文档

使用HBase，可以较好的应对实时数据写入以及实时查询的场景，在HBase 里同一类的文件实际是存在同一个列族下面，如果文件数量太多，会导致regionserver 内存占用过大，JVM内存过大时gc会卡业务。根据实际测试无法有效支持10亿以上的小文件存储。

06

XSKY解决方案

流式数据导入过程中产生的小文件是一个比较让人头疼的问题。根据当前面临的挑战，XSKY对象存储产品XEOS和Hadoop大数据平台结合的实践方案，互补两个系统的优势。

1、Hadoop原有方案：

2、XEOS + Hadoop新方案：

XEOS是XSKY专为海量非结构化数据、高效跨地域按需访问和云原生的存储产品。通过全新的存储技术手段，基于通用服务器硬件构建了一个近乎无限扩容、持续在线、可跨地域访问的高性价比存储架构体系，在保证了数据高安全性的同时，打破存储规模和地域限制的壁垒，降低企业IT建设的投入，满足了新业务形态的多源化存储需求。

通过XEOS来存储管理所有海量文件数据，应用将小文件统一存储到XEOS存储系统，同时将采集到的结构化数据存储在XEOS中，小文件的URL通过Flink和Kafka服务进行流转，最终将小文件URL和结构化数据存储到Hive中，最终后台会将数据同步到HBase。

业务在对数据进行查询检索时，可以从HBase中获取原始文件数据在XEOS存储中的URL信息，通过URL直接从XEOS存储中读取对应的文件数据，该方案完美解决了原来Hadoop方案的海量小文件存储瓶颈问题。

07

存储特性介绍

1、海量小文件管理

海量小文件处理的瓶颈在于对元数据的处理，XEOS对象存储产品对元数据的存储和管理采用了RocksDB，RocksDB具有很好的写性能。

每个磁盘元数据分区部署1个RocksDB实例，规划一组磁盘组成一个RocksDB集群（索引池）。纯SSD盘或混合盘采用副本方式，用于存储所有元数据，满足百亿元数据管理的同时进一步提高了元数据访问效率。

元数据管理-索引池架构（以混合盘为例）：

对象索引池不但承载元数据管理功能，还承载了分布式缓存功能，小文件写入SSD缓存分区后即返回成功，进一步提升分布式存储对海量小文件的性能支持。

在资源管理方面，可同时支持副本及EC安全策略，HDD盘采用EC策略，用于存储最终文件数据。采用副本和EC配合的安全策略，在满足海量小文件存储及高性能的同时大幅提升存储空间利用率。

2、小文件归并

XEOS对象存储系统可自识别文件大小，实现小文件归并存储，大文件切片存储技术，降低海量小文件写入的随机性，提升大文件读写效率。

对象索引池存放文件元数据和小于1MB的小文件数据，加速海量文件遍历效率。当小文件数量达到一定数量时，系统自动识别小于4MB的小文件数据都会归并为32MB的连续大文件，存储到EC数据池，不仅大大提高了写性能，也增加了存储空间的利用率。

3、多活动池-整池扩容 

为了满足海量数据的迅速增长，XEOS支持多活动池及整池扩容功能，在存储策略中添加多个存储池，存储数据时会根据数据池的剩余可用空间权重轮询选择从不同的数据池分配存储空间使用，这些可供写入新数据的资源池称为活动池。

根据需要可以将活动池设置成为非活动池，新写入数据时不再从非活动池分配空间。但无论是活动池还是非活动池，对已经存储在资源池中的数据，都可以读取或删除。

如果现有存储池空间已不满足存储增量需求，可以将新资源池加入存储策略活动池组中，即可投入使用。这种扩容方式，不会产生任何数据重平衡，可有效避免数据重平衡对前端业务的冲击。根据各个活动池的可用空间权重轮询分配存储空间写入数据，新、旧资源池同时使用，聚合性能和容量同时提升。

4、生命周期管理，过期删除

XEOS为用户提供了丰富的数据存储和管理机制。支持以存储桶粒度的数据生命周期管理，可以对存储桶内的数据通过匹配过期条件和规则进行删除，同时支持延时删除。

根据业务对数据的存储需求，配置所有相关桶的生命周期规则，设置过期删除时间，存储桶中的数据会根据数据的写入时间开始计算，达到删除条件数据的即执行删除操作，释放空间，提高存储空间的利用率。

08

总结

XSKY对象存储产品XEOS和Hadoop大数据平台结合的实践方案，补充了Hadoop在管理实时小文件上的不足，很好的解决了Hadoop管理海量小文件的问题，XEOS支持的海量小文件管理及文件归并特性很好的面对海量数据增长需求。

多活动池及整池扩容功能可支持灵活扩容，不但不影响业务正常使用，还可以新、旧资源池同时使用，聚合性能和容量同时提升。灵活的生命周期管理大大降低了数据存储成本，提高了空间利用率。结合Hadoop大数据平台成熟的分析及元数据管理技术，为业务访问提供了更好性能。

随着客户业务不断增长和对数据有不同访问和管理需求，XSKY对象存储产品还可以支持根据不同访问需求的数据进行数据分层，将对访问频率不高的数据存储到性能低存储介质中进行管理，同时支持分层到云端管理。

IT 解决方案：

XSKY服务器虚拟化解决方案

XSKY私有云解决方案

XSKY容器解决方案

XSKY企业级应用解决方案

XSKY桌面虚拟化（VDI）解决方案

XSKY容灾解决方案

XSKY开发测试平台解决方案

XSKY分支机构解决方案

XSKY新建数据中心解决方案

应用场景：

双活

容器

大数据

云平台

云桌面

产品规格：

SDS 软件

XCBS 云后端存储

XEBS 块存储

XEUS 统一存储

XEOS 对象存储

XEDP 统一数据平台

SDS 一体化产品

XSCALER EXPRESS 2000：XE2020、XE2030、XE2050

XSCALER 3000

服务区域：

成都  xsky、绵阳  xsky、自贡  xsky、攀枝花  xsky、泸州  xsky、

德阳  xsky、广元  xsky、遂宁  xsky、内江  xsky、乐山  xsky、

资阳  xsky、宜宾 xsky、南充  xsky、达州  xsky、雅安  xsky、

阿坝藏族羌族自治州 xsky、凉山彝族自治州 xsky、广安  xsky、巴中  xsky、眉山  xsky

服务内容：

软件安装部署服务

业务对接服务

故障处理与生产变更服务

SDS 架构咨询服务

数据迁移服务

现场保障服务

集群环境变更服务

健康巡检服务

集群环境优化服务

集群升级服务

接口开发服务

集群高级实施服务

文档开发服务

开源 SDS 升级服务

技术服务经理（TAM）

生产级分布式块存储，分布式存储 SDS 横向扩展存储，软件定义块存储系统

XSKY ：SDS，软件定义存储，分步式存储，分布式软件定义存储

成都科汇科技有限公司( SDS 解决方案专家）

地址：成都市人民南路四段1号时代数码大厦18F

电话：400-028-1235

QQ:     2231749852

手机：138 8074 7621（微信同号）