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

Question

我是新来的，但需要知道对通过 Apache Hadoop 编写的程序进行单元测试的最佳方法。我知道我们可以用 jUnit 方式为 map 和 reduce 方法中的逻辑编写单元测试用例。我们也可以对涉及的其他逻辑做同样的事情，但这并不能保证它经过良好的测试并且可以在实际运行环境中工作。

我读过关于 MRUnit 的文章，但它似乎也与我上面提到的类似，但方式更成熟。但它也不会作为真正的 mapreduce 工作运行，而是一个被 mock 的工作。

任何帮助，将不胜感激。

谢谢。

Answer 1

你当然有其他选择。稍微用谷歌搜索一下，你自己就会得到它。在这里，我为您做到了!

这是我粘贴的文本:http://blog.cloudera.com/blog/2009/07/advice-on-qa-testing-your-mapreduce-jobs/

除了使用传统的 jUnit 和 MRUnit，您还有以下选择:

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

传统的单元测试和 MRUnit 应该可以在早期检测错误，但它们都不会使用 Hadoop 测试您的 MR 作业。本地作业运行器允许您在本地机器上运行 Hadoop，在一个 JVM 中，使 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=file:///(args) 运行这个类，其中 Bar 是 Tool执行。

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

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

假设您已成功配置本地作业运行程序并运行作业，您必须验证您的作业是否正确完成。仅仅基于退出代码取得成功还不够好。至少，您需要验证作业的输出是否正确。您可能还想扫描 bin/hadoop 的输出以查找异常。您应该创建一个脚本或单元测试来设置前提条件、运行作业、区分实际输出和预期输出，并扫描引发的异常。然后，此脚本或单元测试可以以适当的状态退出，并输出解释作业失败原因的特定消息。

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

伪分布式测试——使用守护进程在单台机器上运行 MR 作业

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

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

完整集成测试——在 QA 集群上运行 MR 作业

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

在 QA 集群上运行您的作业与本地作业运行器存在许多相同的问题。也就是说，您必须检查作业的输出是否正确。您可能还想扫描每个任务尝试产生的 stdin 和 stdout，这需要将这些日志收集到一个中心位置并对其进行 grep 处理。 Scribe是收集日志的有用工具，但根据您的 QA 集群，它可能是多余的。

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

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