问hadoop mapreduce作业的最佳单元测试工具/方法

EN

你当然还有其他选择。在这里我为你做了这件事！

本地作业运行程序测试-在单个JVM中的一台机器上运行MR作业

传统的单元测试和MRUnit应该能在早期检测到足够的bug，但这两者都不能测试你的MR任务。本地作业运行器允许您在一台JVM中的本地计算机上运行Hadoop，这使得在作业失败的情况下更容易调试MR作业。

要启用本地作业运行器，请将“mapred.job.tracker”设置为“local”，并将“fs.default.name”设置为“file:///some/local/path”(这是默认值)。

请记住，在使用本地作业运行程序时，不需要启动任何Hadoop守护进程。运行bin/hadoop将启动JVM并为您运行作业。创建一个新的hadoop-local.xml文件(或者mapred-local.xml和hdfs-local.xml，如果您使用的是0.20)可能是有意义的。然后，您可以使用-config参数告诉bin/hadoop使用哪个配置目录。如果您希望避免摆弄配置文件，可以创建一个实现Tool并使用ToolRunner的类，然后使用bin/hadoop jar foo.jar com.example.Bar -D mapred.job.tracker=local -D fs.default.name=args (args)运行这个类，其中Bar是工具实现。

要开始使用本地作业运行器在Hadoop中测试MR作业，请创建一个启用了本地作业运行器的新配置目录，并像往常一样调用您的作业，记住要包含-config参数，该参数指向包含本地配置文件的目录。

在0.18.3中也可以使用-conf参数，它允许您指定hadoop-local.xml文件，而不是使用-config指定目录。Hadoop将愉快地运行该作业。这种形式的测试的困难在于验证作业是否正确运行。注意:在运行作业之前，您必须确保正确设置了输入文件，并且输出目录不存在。

假设您已经成功地配置了本地作业运行器并运行了一个作业，则必须验证作业是否正确完成。您应该创建一个脚本或单元测试，用于设置前提条件、运行作业、比较实际输出和预期输出，以及扫描引发的异常。然后，该脚本或单元测试可以以适当的状态退出，并输出解释作业如何失败的特定消息。

请注意，本地作业运行器有两个限制:只支持一个reducer，并且DistributedCache不工作(a fix is in progress)。

本地作业运行器允许您在单个线程中运行作业。在单线程中运行MR作业对调试很有用，但它不能正确模拟运行多个Hadoop守护进程(例如，NameNode、DataNode、TaskTracker、JobTracker、SecondaryNameNode)的真实集群。伪分布式集群由一台运行所有Hadoop守护进程的机器组成。这个集群仍然相对容易管理(尽管比本地作业运行器难)，并且比本地作业运行器更好地测试与Hadoop的集成。

要开始使用伪分布式集群在Hadoop中测试MR作业，请遵循前面提到的使用本地作业运行器的建议，但前提设置包括所有Hadoop守护进程的配置和启动。然后，要开始您的工作，只需像往常一样使用bin/hadoop。

测试MR作业的最彻底但最麻烦的机制可能是在至少由几台机器组成的QA集群上运行它们。通过在QA集群上运行MR作业，您将测试作业及其与Hadoop集成的所有方面。

您可能还希望扫描每个任务尝试生成的stdin和stdout，这将需要将这些日志收集到一个中心位置并对它们进行them。Scribe是一个收集日志的有用工具，尽管它可能是多余的，具体取决于您的QA集群。

我们发现，我们的大多数客户都有某种类型的QA或开发集群，他们可以在其中部署和测试新作业，尝试较新版本的Hadoop，并练习将集群从一个版本的Hadoop升级到另一个版本。如果Hadoop是您的生产管道的主要部分，那么创建QA或开发集群非常有意义，并且在其上重复运行作业将确保对作业的更改继续得到彻底的测试。对于您的QA集群，EC2可能是一个很好的主机，因为您可以按需启动和关闭它。

您应该根据QA对组织的重要性以及您拥有的资源数量来选择QA实践。只需使用传统的单元测试框架，MRUnit和本地作业运行器就可以以一种简单的方式彻底测试您的MR作业，而无需使用太多资源。但是，在QA或开发集群上运行作业自然是全面测试MR作业与Hadoop集群的开销和操作任务的最佳方式。