HDFS存储大量小文件有什么问题？如何存储大量小文件？

Shockang
1,411 阅读6分钟

这是我参与8月更文挑战的第5天，活动详情查看：8月更文挑战

正文

HDFS存储大量小文件有什么问题？如何存储大量小文件？.png

HDFS 存储大量小文件有什么问题？

小文件是指文件大小小于 HDFS 上 Block 大小的文件。 这样的文件会给 Hadoop 的扩展性和性能带来严重问题。

首先，在HDFS中，任何 Block、文件或者目录在内存中均以对象的形式存储，每个对象约占 150Byte。

如果有100000个小文件，每个小文件占用一个 Block，则 NameNode 大约需要2GB空间。

如果存储1亿个小文件，则 NameNode 需要约20GB空间。这样一来， NameNode 的内存容量严重制约了集群的扩展。

其次，访问大量小文件的速度远远小于访向几个大文件。

HDFS 最初是为流式访问大文件而开发的，如果访问大量小文件，则需要不断地从一个 DataNode跳到另个 DataNode，严重影响了性能，导致最后处理大量小文件的速度远远小于处理同等大小的大文件的速度。

每个小文件要占用一个 Slot，而 Task 启动将耗费大量时间，从而导致大部分时间都耗费在启动和释放 Task 上。

要想解决小文件的问题，就要想办法减少文件数量，降低 NameNode的压力。

通常有两种解决方法：一种是用户程序合并，另一种是从机制上支持小文件的合并。

用户程序合并

Hadoop自身提供了三种解决方案: HadoopArchive、 SequenceFile 和 CombineFileInputFormat

HadoopArchive

Hadoop Archives 为特殊的档案格式。一个 Hadoop Archive 对应一个文件系统目录。

Hadoop Archives 包含元数据(形式为 _index 和 _masterindex )和数据(part-*)文件。

index 文件包含了档案中的文件的文件名和位置信息。

Hadoop Archives 为*.har文件，该文件的内部结构如图所示。 在这里插入图片描述

创建存档文件的问题

  1. 存档文件的源文件目录及源文件都不会自动删除，需要手动删除。
  2. 存档的过程实际是一个 MapReduce 过程，所以需要 Hadoop 的 MapReduce 的支持
  3. 存档文件本身不支持压缩。
  4. 存档文件一旦创建便不可修改，要想从中删除或者増加文件，必须重新建立存档文件
  5. 创建存档文件会创建原始文件的副本，所以至少需要有与存档文件容量相同的磁盘空间

SequenceFile

SequenceFile 是 Hadoop提供的一种对二进制文件的支持。 二进制文件直接将<Key， Value>对序列化到文件中。

HDFS文件系统是适合存储大文件的，很小的文件如果很多的话对于 Namenode 的压力会非常大，因为每个文件都会有一条元数据信息存储在 Namenode上， 当小文件非常多也就意味着在 Namenode上存储的元数据信息就非常多。

Hadoop是适合存储大数据的，所以我们可以通过 SequenceFile 将小文件合并起来，可以获得更高效率的存储和计算。

SequenceFile 中的 key 和 value 可以是任意类型的 Writable 或者自定义 Writable 类型。

对于一定大小的数据，比如说100G0B，如果采用 SequenceFile 进行存储的话占用的空间是大于100G0B的，因为 SequenceFile 的存储中为了查找方便添加了一些额外的信息。

特点

  1. 支持压缩:可定制为基于 Record(记录) 和 Block(块) 压缩。 无压缩类型:如果没有启动压缩(默认设置)，那么每个记录就由它的记录长度(字节数)、键的长度，键和值组成，长度字段为4字节。 SequenceFile 内部结构如图所示。 Record 针对行压缩，只压缩 Value 部分不压缩Key； Block 对 Key 和Value 都压缩。 在这里插入图片描述
  2. 本地化任务支持:因为文件可以被切分，因此在运行 MapReduce 任务时数据的本地化情况应该是非常好的；尽可能多地发起 MapTask 来进行并行处理进而提高作业的执行效率。
  3. 难度低:因为是 Hadoop 框架提供的API，业务逻辑侧的修改比较简单。

CombineFileInputFormat

CombineFileInputFormat是一种新的 InputFormat，用于将多个文件合并成一个单独的 Split。另外，它会考虑数据的存储位置。

通用合并方法

业界针对数据的不同特征，有一些合并优化的方法，可以降低文件数量、提高存储性能。

WebGIS 解决方案

在地理信息系统中，为了方便传输，通常将数据切分为KB大小的文件存储在分布式文件系统中。

论文结合 WebGIS 数据的相关特征，将相邻地理位置的小文件合并成个大的文件，并为这些文件构建索引。

论文中将小于 16MB 的文件当作小文件进行合并处理，将其合并成 64MB 的 Block 并构建索引。

BlueSky 解决方案

BlueSky 是中国电子教学共享系统，主要存放的是教学所用的 PPT 文件和视频文件，存放的载体为 HDFS 分布式存储系统。

在用户上传 PPT 文件的同时，系统还会存储些文件的快照。用户请求 PPT 时可以先看到这些快照，以决定是否继续浏览。

用户对文件的请求具有很强的关联性。当用户浏览 PPT 时，其他相关的 PPT 和文件也会在短时间内被访问，因而文件的访问具有相关性和本地性。

TFS解决方案

TFS(Taobao File System)是一个高可扩展、高可用、高性能、面向互联网服务的分布式文件系统，主要针对海量的非结构化数据，它构筑在普通的 Linux机器集群上，可为外部提供高可靠和高并发的存储访问。

TFS为淘宝提供海量小文件存储，通常文件大小不超过1MB， 满足了淘宝对小文件存储的需求， 被广泛应用在淘宝的各项应用中。

它采用了HA架构和平滑扩容， 保证了整个文件系统的可用性和扩展性。

同时扁平化的数据组织结构可将文件名映射到文件的物理地址，简化了文件的访问流程，一定程度上为TFS提供了良好的读/写性能。

小文件社区改进HDFS-8998

社区在HDFS上进行了改进，HDFS-8998提供了在线合并的方案。

HDFS自动启动一个服务，将小文件合并成大文件。

其主要架构如图所示。

在这里插入图片描述

相比原生HDFS，新增一个 FGCServer 的后台服务，服务本身支持HA。元数据存储在 levelDB 中，文件和日志都存储在 HDFS 本身。

后台服务自动搜索小文件，合并符合规则的小文件到大文件。

小文件合并成大文件需要记录小文件在大文件里面的大小、偏移位置、对应关系等信息，这些元数据存储在 levelDB 中因为合并后原始文件的存储位置发生了变更，所以原HDFS的读写等接口的流程也发生了变更。

比如，要读取一个文件，需要先到 FGCServer 中获取小文件元数据、然后再到 HDFS 中获取对应的文件。

通过合并，减轻了 NameNode 的压力，增大了 HDFS 单个 NameNode 支持的文件个数。

avatar
文章
阅读
粉丝