使用Hadoop处理大型二进制文件

Question

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

我们有一个装有二进制文件的Hadoop集群。这些文件的大小范围可以从几百k到几百mb。

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

我们预见到的问题是我们最终可能达到我们的名字节无法处理的大小。只有那么多的内存可供使用，拥有一个带有几兆兆字节内存的名字节点似乎很荒谬。

是否有一种优雅的方式来处理像这样的大型二进制文件？特别是那些不能拆分的，因为我们不知道减速器将它们重新组合在一起的顺序是什么？

Answer 1

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

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

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

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

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

• NameNode仅需要内存来存储有关块的信息（名称，块[大小，长度，位置]）。假设你为它分配了一个不错的内存占用（GB），没有理由你不能拥有一个在HDFS存储中保存数PB数据的集群（假设你有足够的物理存储空间）

Answer 2

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

http://wiki.apache.org/hadoop/SequenceFile

Answer 3

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

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