2

我知道这里有类似的帖子，但我找不到真正有可靠答案的帖子。

我们有一个加载了二进制文件的 Hadoop 集群。这些文件的大小可以从几百 k 到几百 mb 不等。

我们目前正在使用自定义记录阅读器处理这些文件，该阅读器将文件的全部内容读入每个地图。从那里我们提取我们想要将其序列化为 JSON 的适当元数据。

我们预见的问题是我们最终可能会达到我们的名称节点无法处理的大小。只有这么多的内存可以使用，拥有一个具有几 TB 内存的名称节点似乎很荒谬。

有没有一种优雅的方式来处理像这样的大型二进制文件？尤其是那些因为我们不知道reducer会按照什么顺序将它们重新组合在一起而无法拆分的那些？

4

3 回答 3

1

所以不是这样的答案，但我有很多问题，评论列表会更难传达，所以这里是：

您说您将每个地图的全部内容读入内存，您能否详细说明这些文件的实际二进制输入格式：

  • 它们是否包含逻辑记录，即单个输入文件是否代表单个记录，还是包含许多记录？
  • 文件是否被压缩（事后或某些内部压缩机制）？
  • 您目前如何一次处理此文件，您将转换为 JSON 的整体 ETL 逻辑是什么？
  • 您是否真的需要在处理开始之前将整个文件读入内存，或者一旦填充了一定大小的缓冲区（例如 DOM 与 SAX XML 解析），您是否可以处理。

我的猜测是，您可以将一些映射器逻辑迁移到记录阅读器，甚至可能找到一种在多个映射器之间“拆分”文件的方法。这将允许您解决您的可扩展性问题。

要解决您问题中的一些问题：

  • NameNode 只需要内存来存储有关块的信息（名称、块[大小、长度、位置]）。假设您为其分配了一个不错的内存占用量（GB），那么您没有理由不能拥有一个在 HDFS 存储中保存 PB 级数据的集群（假设您有足够的物理存储）
于 2012-06-21T01:42:48.837 回答
0

Namenode与存储或处理没有任何关系。你应该专注于你的Datanodes和Tasktrackers。另外我不知道你是想解决存储问题还是在这里处理你的文件。如果你正在处理大量二进制文件，值得一看 Hadoop SequenceFile。SequenceFile 是由二进制键/值对组成的平面文件，因此在 MapReduce 中广泛用作输入/输出格式。有关详细说明，您可以访问此页面 -

http://wiki.apache.org/hadoop/SequenceFile
于 2012-06-20T19:48:41.130 回答
0

当您有大型二进制文件时，使用 SequenceFile 格式作为输入格式并相应地设置映射的输入拆分大小。您可以根据总输入大小和您设置的拆分大小来设置映射器的数量。Hadoop 将负责拆分输入数据。

如果您有以某种格式压缩的二进制文件，则 hadoop 无法进行这种拆分。所以二进制格式必须是SequenceFile。

于 2012-06-21T01:32:15.140 回答