hadoop的python框架指南_Hadoop的Python框架指南

mrjob只需要安装在客户机上，其中在作业的时候提交。下面是要运行的命令：

export HADOOP_HOME="/usr/lib/hadoop-0.20-mapreduce"

./ngrams.py -r hadoop --hadoop-bin /usr/bin/hadoop --jobconf mapred.reduce.tasks=10 -o hdfs:///output-mrjob hdfs:///ngrams

编写MapReduce的工作是非常直观和简单的。然而，有一个重大的内部序列化计划所产生的成本。最有可能的二进制计划将需要实现的用户(例如，为了支持typedbytes)。也有一些内置的实用程序日志文件的解析。最后，mrjob允许用户写多步骤的MapReduce的工作流程，在那里从一个MapReduce作业的中间输出被自动用作输入到另一个MapReduce工作。

(注：其余的实现都非常相似，除了包具体的实现，他们都能被找到 here.。)

dumbo

dumbo 是另外一个使用Hadoop流包装的框架。dumbo出现的较早，本应该被许多人使用，但由于缺少文档，造成开发困难。这也是不如mcjob的一点。

dumbo通过typedbytes执行序列化，能允许更简洁的数据传输，也可以更自然的通过指定JavaInputFormat读取SequenceFiles或者其他格式的文件，比如，dumbo也可以执行Python的egg和Java的JAR文件

在我的印象中， 我必须要手动安装dumbo中的每一个节点， 它只有在typedbytes和dumbo以eggs形式创建的时候才能运行。 就像他会因为onMemoryErrors终止一样，他也会因为使用组合器停止。

运行dumbo任务的代码是：

dumbo start ngrams.py \

-hadoop /usr \

-hadooplib /usr/lib/hadoop-0.20-mapreduce/contrib/streaming \

-numreducetasks 10 \

-input hdfs:///ngrams \

-output hdfs:///output-dumbo \

-outputformat text \

-inputformat text

hadoopy

hadoopy 是另外一个兼容dumbo的Streaming封装。同样，它也使用typedbytes序列化数据，并直接把 typedbytes 数据写到HDFS。

它有一个很棒的调试机制， 在这种机制下它可以直接把消息写到标准输出而不会干扰Streaming过程。它和dumbo很相似，但文档要好得多。文档中还提供了与 Apache HBase整合的内容。

用hadoopy的时候有两种发发来启动jobs：

launch 需要每个节点都已经安装了Python/hadoopy ，但是在这之后的负载就小了。

launch_frozen 不要求节点上已经安装了Python，它会在运行的时候安装，但这会带来15秒左右的额外时间消耗(据说通过某些优化和缓存技巧能够缩短这个时间)。

必须在Python程序中启动hadoopy job，它没有内置的命令行工具。

我写了一个脚本通过launch_frozen的方式启动hadoopy

python launch_hadoopy.py

用launch_frozen运行之后，我在每个节点上都安装了hadoopy然后用launch方法又运行了一遍，性能明显好得多。

pydoop

与其他框架相比，pydoop 封装了Hadoop的管道(Pipes)，这是Hadoop的C++ API。 正因为此，该项目声称他们能够提供更加丰富的Hadoop和HDFS接口，以及一样好的性能。我没有验证这个。但是，有一个好处是可以用Python实现一个Partitioner，RecordReader以及RecordWriter。所有的输入输出都必须是字符串。

最重要的是，我不能成功的从PIP或者源代码构建pydoop。

其他

happy 是一个用Jython来写Hadoop job的框架，但是似乎已经挂了

Disco 成熟的，非Hadoop 的 MapReduce.实现，它的核心使用Erlang写的，提供了Python的API，它由诺基亚开发，不如Hadoop应用广泛。

octopy 是一个纯Python的MapReduce实现，它只有一个源文件，并不适于“真正的”计算。

Mortar是另一个Python选择，它不久前才发布，用户可以通过一个网页应用提交Apache Pig 或者 Python jobs 处理放置在 Amazon S3上的数据。

有一些更高层次的Hadoop生态体系中的接口，像 Apache Hive和Pig。Pig 可以让用户用Python来写自定义的功能，是通过Jython来运行。 Hive 也有一个Python封装叫做hipy。

(Added Jan. 7 2013) Luigi 是一个用于管理多步作业流程的Python框架。它与Apache Oozie 有一点相似，但是它内置封装了Hadoop Streaming(轻量级的封装)。Luigi有一个非常好的功能是能够在job出错的时候抛出Python代码的错误堆栈，而且它的命令行界面也非常棒。它的README文件内容很多，但是却缺少详尽的参考文档。Luigi 由Spotify 开发并在其内部广泛使用。

本地java

最后，我使用新的Hadoop Java API接口实施了MR任务，编译完成后，这样来运行它：

关于计数器的特别说明

在我的MR jobs的最初实现里，我用计数器来跟踪监控不良记录。在Streaming里，需要把信息写到stderr。事实证明这会带来不容忽视的额外开销：Streaming job花的时间是原生java job的3.4倍。这个框架同样有此问题。

性能比较

将用Java实现的MapReduce job作为性能基准。 Python框架的值是其相对于Java的性能指标的比率。

Java明显最快,，Streaming要多花一半时间，Python框架花的时间更多。从mrjob mapper的profile数据来看，它在序列化/反序列化上花费了大量时间。dumbo和hadoopy在这方面要好一点。如果用了combiner 的话dumbo 还可以更快。

特点比较

大多来自各自软件包中的文档以及代码库。

结论

Streaming是最快的Python方案，这面面没有任何魔力。但是在用它来实现reduce逻辑的时候，以及有很多复杂对象的时候要特别小心。

所有的Python框架看起来都像是伪码，这非常棒。

mrjob更新快，成熟的易用，用它来组织多步MapReduce的工作流很容易，还可以方便地使用复杂对象。它还可以无缝使用EMR。但是它也是执行速度最慢的。

还有一些不是很流行的 Python 框架，他们的主要优势是内置了对于二进制格式的支持，但如果有必要话，这个完全可以由用户代码来自己实现。

就目前来看：

Hadoop Streaming是一般情况下的最佳选择，只要在使用reducer的时候多加小心，它还是很简单易用的。

从计算开销方面考虑的话，选择mrjob，因为它与Amazon EMR结合最好。

如果应用比较复杂，包含了复合键，要组合多步流程，dumbo 最合适。它比Streaming慢，但是比mrjob快。

如果你在实践中有自己的认识，或是发现本文有错误，请在回复里提出。