HDFS中的存储格式

Question

HDFS如何存储数据？

我想以压缩方式存储大量文件。

例如：我有一个1.5 GB的文件，默认复制因子为3。

它需要（1.5）* 3 = 4.5 GB的空间。

我相信目前没有隐式压缩数据。

是否有一种压缩文件并将其存储在HDFS中以节省磁盘空间的技术？

Answer 1

HDFS将任何文件存储在多个“块”中。块大小可以基于每个文件进行配置，但具有默认值（如64/128/256 MB）

因此，给定一个1.5 GB的文件，块大小为128 MB，hadoop会将文件分解为~12个块（12 x 128 MB~ = 1.5GB）。每个块也可以复制多次。

如果您的数据压缩得很好（如文本文件），那么您可以压缩文件并将压缩文件存储在HDFS中 - 同样适用于上面，因此如果1.5GB文件压缩到500MB，那么这将被存储为4块。

但是，使用压缩时要考虑的一件事是压缩方法是否支持拆分文件 - 也就是你可以随机寻找文件中的位置并恢复压缩流（例如GZIp不支持拆分，BZip2可以）。

即使该方法不支持拆分，hadoop仍然会将文件存储在多个块中，但是您将失去“数据局部性”的一些好处，因为块很可能会在您的群集中传播。< / p>

在地图缩减代码中，Hadoop默认安装了许多压缩编解码器，并会自动识别某些文件扩展名（例如GZip文件的.gz），使您不必担心输入/输出是否需要被压缩。

希望这是有道理的

编辑回复评论的其他一些信息：

当写入HDFS作为Map Reduce作业的输出时，请参阅FileOutputFormat的API，特别是以下方法：

• setCompressOutput（Job，boolean）
• setOutputCompressorClass（Job，Class）

将文件上传到HDFS时，是的，它们应该预先压缩，并且具有该压缩类型的相关文件扩展名（开箱即用，hadoop支持扩展名为.gz的gzip，因此file.txt.gz表示一个gzip文件）

Answer 2

前段时间我试图在博文here中总结一下。 基本上这是一个数据可分割性的问题，因为文件被分成块，这些块是复制的基本块。 Name节点负责跟踪属于一个文件的所有块。选择压缩时块必须是自治的 - 并非所有编解码器都是可拆分的。如果格式+编解码器不可拆分，这意味着为了解压缩它，它需要在一个地方，这对mapreduce中的并行性有很大影响。基本上在单个插槽中运行。 希望有所帮助。

Answer 3

查看演示文稿@ Hadoop_Summit，特别是幻灯片6和幻灯片7。

1. 如果DFS块大小为128 MB，对于4.5 GB存储（包括复制因子3），则需要35.15（~36块）
2. 只有bzip2文件格式是可拆分的。在其他格式中，整个文件的所有块都存储在相同的Datanode
中
3. 查看算法类型和类名称及编解码器
4. @Chris白色答案提供有关如何在编写Map输出时启用压缩的信息

Answer 4

该问题的答案是首先了解当今Hadoop中可用的文件格式。 HDFS现在提供了可以管理文件格式和压缩技术的选项。使用LZO或BZIP进行显式编码和拆分的替代方法。如今，有许多格式支持具有功能的块压缩和列式行压缩。

存储格式是定义信息存储方式的一种方式。有时这通常由文件扩展名指示。例如，我们知道图像可以是几种存储格式，包括PNG，JPG和GIF等。所有这些格式可以存储相同的图像，但是每种都有特定的存储特征。

在Hadoop文件系统中，您可以使用所有传统存储格式（例如，可以根据需要在HDFS上存储PNG和JPG图像），但是您还可以使用某些以Hadoop为重点的文件格式，以用于结构化和非结构化数据。

了解这些格式为什么很重要

在任何性能折衷中，对于支持HDFS的应用程序（如MapReduce，Hive，HBase和Spark）而言，巨大的瓶颈在于在特定位置查找相关数据所需的时间以及将数据写回到另一个位置所需的时间。位置。管理大型数据集时，这些问题会更加突出。 Hadoop文件格式经过改进，可以在许多用例中缓解这些问题。

选择适当的文件格式可以带来一些明显的好处：

1. 最佳阅读时间
2. 最佳写入时间
3. 拆分或分区文件（因此您无需读取整个文件，只需读取一部分）
4. 模式适应（允许将字段更改为数据集）压缩支持（不牺牲这些功能）

某些文件格式是为一般用途而设计的，其他文件格式是为更特定的用例（例如为数据库提供动力）而设计的，而某些文件格式则考虑了特定的数据特征。因此，在Hadoop中存储数据时确实有很多选择，应该知道将数据最佳存储在HDFS中。目前，我的存储空间是ORC格式。

检查您的大数据组件（Spark，Hive，HBase等）是否支持这些格式，并做出相应的决定。例如，我目前正在将数据注入Hive并将其转换为ORC格式，这在压缩和性能方面对我很有效。

Hadoop的一些常见存储格式包括：

纯文本存储（例如CSV，TSV文件，定界文件等）

数据按行排列，每一行都是一条记录。在典型的UNIX世界中，行以换行符\ n终止。文本文件本质上是可拆分的。但是如果要压缩它们，则必须使用支持拆分的文件级压缩编解码器，例如BZIP2。这效率不高，在执行MapReduce任务时将需要一些工作。

序列文件

最初是为MapReduce设计的，因此非常易于与Hadoop MapReduce流程集成。它们为每个记录编码一个键和一个值，仅此而已。以比基于文本的格式小的二进制格式存储。即使在这里，它也不会对键和值进行编码。序列文件的一个好处是它们支持块级压缩，因此您可以压缩文件的内容，同时还可以将文件拆分为多个地图任务的片段。尽管按照Parquet和ORC这样的统计数据仍然不够高效。

Avro

格式直接在文件中编码其内容的架构，从而使您可以原生存储复杂的对象。其文件格式带有附加框架，序列化和反序列化框架。使用常规的旧序列文件，您可以存储复杂的对象，但是您必须管理该过程。它还支持块级压缩。

镶木地板

这些天我最喜欢的热门格式。它是一种列式文件存储结构，它对磁盘进行编码和写入。因此，数据集在水平和垂直方向都被划分。面向列的文件格式的一个巨大好处是，同一列中的数据趋于压缩在一起，这可能会产生一些大规模的存储优化（因为同一列中的数据趋于相似）。如果您的处理可以最佳地使用列存储，请尝试使用它。您可以参考柱状存储的优点。

如果您要定期分割和分割数据集，那么这些格式对于提高应用程序的速度非常有好处，但是坦率地说，如果您的应用程序通常需要整行数据，那么列格式实际上可能是有害的由于需要增加网络活动而导致性能下降。

ORC

ORC代表“优化行列”，这意味着它可以以比其他文件格式更优化的方式存储数据。 ORC会将原始数据的大小最多减小75％（例如：100GB文件将变为25GB）。结果，数据处理的速度也增加了。 ORC比文本，序列和RC文件格式显示更好的性能。  ORC文件包含称为“条纹”的组中的行数据以及文件页脚。 Hive处理数据时，ORC格式可以提高性能。

它与Parquet类似，但编码技术不同。它不适合该线程，但您可以在Google上查找差异。