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

Question

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

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

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

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

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

Answer 1

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

你说你将每个 map 的全部内容读入内存，你能详细说明这些文件的实际二进制输入格式吗:

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

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

要解决您问题中的一些要点:

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