5

HDFS 如何存储数据？

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

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

它需要 (1.5)*3 = 4.5 GB 的空间。

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

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

4

4 回答 4

7

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 仍会将文件存储在多个块中，但您将失去“数据局部性”的一些好处，因为这些块很可能会分布在您的集群中。

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

希望这是有道理的

编辑回应评论的一些附加信息：

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

  • setCompressOutput（作业，布尔值）
  • setOutputCompressorClass（作业，类）

将文件上传到 HDFS 时，是的，它们应该被预压缩，并使用该压缩类型的关联文件扩展名（开箱即用，hadoop 支持带有 .gz 扩展名的 gzip，因此 file.txt.gz 表示压缩文件)

于 2012-06-01T22:40:23.667 回答
0

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

于 2016-02-14T09:29:45.827 回答
0

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

在此处输入图像描述

在此处输入图像描述

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

这个问题的答案是首先了解当今 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 等统计数据仍然没有效率。

阿夫罗

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

镶木地板

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

如果您定期切分和切割数据集，那么这些格式可能对您的应用程序的速度非常有益，但坦率地说，如果您的应用程序通常需要整行数据，那么列格式实际上可能会损害性能，因为以增加所需的网络活动。

兽人

ORC 代表 Optimized Row Columnar，这意味着它可以以比其他文件格式优化的方式存储数据。ORC 将原始数据的大小减少到 75%（例如：100GB 文件将变为 25GB）。结果，数据处理的速度也提高了。ORC 表现出比文本、序列和 RC 文件格式更好的性能。ORC 文件包含称为条纹的组中的行数据以及文件页脚。当 Hive 处理数据时，ORC 格式提高了性能。

它类似于 Parquet，但具有不同的编码技术。它不适用于此线程，但您可以在 Google 上查找差异。

于 2018-10-16T15:01:20.060 回答