5

我有一个问题可以通过 Hadoop Streaming 在“typedbytes”或“rawbytes”模式下解决，它允许使用 Java 以外的语言分析二进制数据。（如果没有这个，Streaming 会将一些字符（通常是 \t 和 \n）解释为分隔符并抱怨非 utf-8 字符。将我所有的二进制数据转换为 Base64 会减慢工作流程，从而达到目的。）

这些二进制模式是由HADOOP-1722添加的。在调用 Hadoop Streaming 作业的命令行中，“-io rawbytes”允许您将数据定义为 32 位整数大小，后跟该大小的原始数据，“-io typedbytes”允许您将数据定义为 1 - 位零（表示原始字节），后跟 32 位整数大小，然后是该大小的原始数据。我已经创建了具有这些格式的文件（带有一条或多条记录），并通过使用/对照typedbytes.py的输出检查它们来验证它们的格式是否正确。我还尝试了所有可能的变体（大端、小端、不同的字节偏移等）。我正在使用来自 CDH4 的 Hadoop 0.20，它具有实现 typedbytes 处理的类，并且在设置“-io”开关时进入这些类。

我使用“hadoop fs -copyFromLocal”将二进制文件复制到 HDFS。当我尝试将其用作 map-reduce 作业的输入时，它会在尝试创建我指定长度的字节数组（例如 3 个字节）的行上出现 OutOfMemoryError 失败。它必须错误地读取数字并尝试分配一个巨大的块。尽管如此，它确实设法将记录发送到映射器（以前的记录？不确定），它将它写入标准错误，以便我可以看到它。记录开头总是有太多字节：例如，如果文件是“\x00\x00\x00\x00\x03hey”，则映射器会看到“\x04\x00\x00\x00\x00\x00 \x00\x00\x00\x07\x00\x00\x00\x08\x00\x00\x00\x00\x03hey”（可重现的位，虽然我看不到任何模式）。

从本次演讲的第 5 页，我了解到流式传输有“loadtb”和“dumptb”子命令，它们可以在一个步骤中复制到 HDFS 或从 HDFS 复制和包装/解包序列文件中的类型化字节。当与“-inputformat org.apache.hadoop.mapred.SequenceFileAsBinaryInputFormat”一起使用时，Hadoop 会正确解压缩 SequenceFile，但随后会以完全相同的方式误解其中包含的 typedbytes。

此外，我找不到有关此功能的文档。2 月 7 日（我通过电子邮件发送给自己），它在 Apache 上的 streaming.html 页面中被简要提及，但这个 r0.21.0 网页已被删除，r1.1.1 的等效页面没有提及 rawbytes或打字字节。

所以我的问题是：在 Hadoop Streaming 中使用 rawbytes 或 typedbytes 的正确方法是什么？有没有人让它工作？如果是这样，有人可以发布食谱吗？对于任何想要在 Hadoop Streaming 中使用二进制数据的人来说，这似乎都是一个问题，这应该是一个相当广泛的群体。

PS 我注意到Dumbo、Hadoopy和rmr都使用了这个特性，但是应该有一种方法可以直接使用它，而不需要基于 Python 或 R 的框架。

4

3 回答 3

5

好的，我找到了一个有效的组合，但这很奇怪。

  1. 按照文档或模仿typedbytes.py在本地文件系统中准备一个有效的 typedbytes 文件。

  2. 采用

    hadoop jar path/to/streaming.jar loadtb path/on/HDFS.sequencefile < local/typedbytes.tb

    一步将 typedbytes 包装在 SequenceFile 中并将其放入 HDFS。

  3. 采用

    hadoop jar path/to/streaming.jar -inputformat org.apache.hadoop.mapred.SequenceFileAsBinaryInputFormat ...

    运行 map-reduce 作业，其中映射器从 SequenceFile 获取输入。请注意，-io typedbytes或不-D stream.map.input=typedbytes应该使用——明确要求 typedbytes 会导致我在问题中描述的误解。但不要害怕：Hadoop Streaming 在其二进制记录边界上拆分输入，而不是在其 '\n' 字符上。数据以“原始数据”形式到达映射器，由 '\t' 和 '\n' 分隔，如下所示：

    1. 32位有符号整数，表示长度（注意：无类型字符）
    2. 具有该长度的原始二进制块：这是关键
    3. '\t' （制表符...为什么？）
    4. 32位有符号整数，表示长度
    5. 具有该长度的原始二进制块：这是值
    6. '\n' （换行符...？）

  4. 如果您想另外将原始数据从 mapper 发送到 reducer，请添加

    -D stream.map.output=typedbytes -D stream.reduce.input=typedbytes

    到您的 Hadoop 命令行，并将映射器的输出和减速器的预期输入格式化为有效的类型字节。它们还交替用于键值对，但这次使用类型字符，没有 '\t' 和 '\n'。Hadoop Streaming 正确地在它们的二进制记录边界上拆分这些对，并按键分组。

我能找到的唯一文档是在stream.map.outputHADOOP - 1722交换中，从 09 年 2 月 6 日开始。（之前的讨论考虑了一种不同的参数化格式的方法。）stream.reduce.input

这个秘籍没有为输入提供强类型：类型字符在创建 SequenceFile 并用-inputformat. 但是，它确实提供了在二进制记录边界处的拆分，而不是真正重要的 '\n'，以及映射器和化简器之间的强类型。

于 2013-03-02T08:37:55.613 回答
1

在将数据流式传输到 Mapper 时，我们使用对拆分级别的数据进行 hexaencoding 解决了二进制数据问题。这将利用并提高操作的并行效率，而不是在节点上处理之前先转换数据。

于 2013-09-24T08:41:05.377 回答
0

显然有一个用于流式传输的 JustBytes IO 模式的补丁，它将整个输入文件提供给 mapper 命令：

https://issues.apache.org/jira/browse/MAPREDUCE-5018

于 2014-10-27T09:08:41.113 回答