Hadoop 中的流式处理或自定义 Jar答案

【问题标题】：Streaming or custom Jar in HadoopHadoop 中的流式处理或自定义 Jar
【发布时间】：2011-07-31 21:34:50
【问题描述】：

我正在使用 Python 编写的映射器和缩减器在 Hadoop（在 Amazon 的 EMR 上）中运行流式作业。我想知道如果我在 Java 中实现相同的映射器和减速器（或使用 Pig），我将体验到的速度提升。

特别是，我正在寻找人们从流式传输迁移到自定义 jar 部署和/或 Pig 的经验，以及包含这些选项的基准比较的文档。我找到了这个question，但答案对我来说不够具体。我不是在寻找 Java 和 Python 之间的比较，而是在 Hadoop 中的自定义 jar 部署和基于 Python 的流之间的比较。

我的工作是从 Google Books NGgram 数据集中读取 NGram 计数并计算聚合度量。计算节点上的 CPU 利用率似乎接近 100%。（我想听听您对 CPU 密集型作业或 IO 密集型作业的区别的看法）。

谢谢！

澳大利亚

【问题讨论】：

标签： java python streaming hadoop mapreduce

【解决方案1】：

为什么要考虑部署自定义 jar？

能够使用更强大的自定义输入格式。对于流式作业，即使您使用here 中提到的可插入输入/输出，您也仅限于映射器/缩减器的键和值是文本/字符串。您需要花费一些 CPU 周期才能转换为所需的类型。
我还听说 Hadoop 可以很聪明地跨多个作业重用 JVM，这在流式传输时是不可能的（无法确认）

什么时候用猪？

Pig Latin 非常酷，是一种比 java/python 或 perl 更高级别的数据流语言。您的 Pig 脚本往往比任何其他语言编写的同等任务要小得多

什么时候不使用 pig ？

尽管 pig 非常擅长自己计算出多少个 map/reduce 以及何时生成一个 map 或 reduce 以及无数这样的事情，但如果你确定你需要多少 maps/reduce 并且你有一些您需要在 Map/reduce 函数中进行非常具体的计算，并且您对性能非常具体，那么您应该考虑部署自己的 jar。这个link 表明 pig 在性能上可能落后于原生 hadoop M/R。您还可以看看编写自己的 Pig UDFs，它隔离了一些计算密集型函数（甚至可能使用 JNI 在 UDF 中调用一些本机 C/C++ 代码）

关于 IO 和 CPU 绑定作业的注意事项：

从技术上讲，hadoop 和 map reduce 的全部意义在于并行化计算密集型函数，所以我认为您的 map 和 reduce 作业是计算密集型的。当数据通过网络发送时，Hadoop 子系统唯一一次忙于执行 IO 是在 map 和 reduce 阶段之间。此外，如果您有大量数据并且您手动配置了太少的映射和减少导致溢出到磁盘（尽管太多的任务会导致花费太多时间启动/停止 JVM 和太多的小文件）。流式作业还会产生额外的启动 Python/Perl VM 的开销，并在 JVM 和脚本 VM 之间来回复制数据。

【讨论】：

谢谢！由于我已经有纯文本输入/输出要求，因此自定义输入格式与我的情况无关。猪猪的评价告诉我，我宁愿远离它。我已经有了 Python 实现。我的脚本是 CPU 密集型的。他们只是从标准输入中读取数据，进行一些数字运算，然后输出结果。但我不确定这是否意味着我的 Hadoop 工作作为一个整体可以被视为 CPU 密集型。无论如何，我真正想问的是作业是 CPU 密集型还是 IO 密集型以及它是作为自定义 jar 还是流式作业实现之间的交互。
考虑到您的 Maps 和 Reduce 任务将在其自己的 JVM 上运行，并且通常 map 和 reduce 函数受 CPU 限制，这些单独的 Hadoop 任务将受 CPU 限制。 Hadoop 作业的协调 JVM 很可能是 IO 密集型的，因为它忙于等待来自将数据发送到 map 和 reduce 层的各个任务的响应。
实际上，我刚刚意识到，运行 map 和 reduce 任务的 JVM 也处理一些 IO（从 HDFS 输入流并将输出写入 HDFS）。由于 hadoop 确保 map 函数在靠近数据的位置完成，这通常非常快（对于 reduce 函数来说不是这样）。