用Hadoop处理大型二进制文件

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

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

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

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

---

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

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

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

---

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

---

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

因此不是这样的答案，但我有太多的问题，以至于评论列表更难传达，因此：

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

• 它们是否包含逻辑记录，即单个输入文件是表示单个记录，还是包含多个记录
• 文件是否经过压缩（在事实发生后或某种内部压缩机制之后）
• 您目前是如何一次处理这个文件的，转换为JSON的总体ETL逻辑是什么
• 在开始处理之前，您真的需要将读取的整个文件读入内存吗？或者，在填充了一定大小的缓冲区之后，您可以进行处理吗（例如，DOM与SAXXML解析）

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

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

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

---

Chris，这些文件是包含许多逻辑记录的TIFF文件。我们从TIFF文件中提取特定的元数据，并将其转换为JSON。我认为我们必须读取整个文件。我假设逻辑记录是子文件，如上所述。实际上不，在这种情况下，我们不必担心子文件。因此，在这种情况下，每个TIFF文件包含一条记录？您提取的元数据是什么？它是基于存储在文件头中的内容还是实际元数据？