用于hadoop mapreduce作业的最佳单元测试工具/方法
我在这里是新手，但需要知道对使用Apache Hadoop编写的程序进行单元测试的最佳方法。 我知道我们可以编写单元测试用例的逻辑内部映射和减少方法的JUnit方式。 此外，我们也可以为其他涉及的逻辑做同样的事情，但这并不能保证它经过良好测试，并且能够在实际运行环境中工作。
我已经阅读了关于MRUnit的内容，但它似乎也像我之前提到的那样，但是以更成熟的方式。 但它也没有像真正的地图减少工作那样运行，而是一个嘲弄的工作。
任何帮助，将不胜感激。
谢谢。
你当然有其他选择。 轻点谷歌搜索，你会自己得到它。 在这里，我为你做到了！
以下是我正在粘贴的文字：http://blog.cloudera.com/blog/2009/07/advice-on-qa-testing-your-mapreduce-jobs/
除了使用传统的jUnit和MRUnit，您有以下选择：
本地作业运行器测试 - 在单个JVM中的单台计算机上运行MR作业
传统的单元测试和MRUnit应该尽早地做出足够的工作来检测错误，但都不会用Hadoop测试您的MR作业。 本地作业运行器允许您在本地机器上的一个JVM上运行Hadoop，从而在作业失败的情况下使MR作业更容易调试。
要启用本地作业运行器，请将“mapred.job.tracker”设置为“local”和“fs.default.name”为“file：/// some / local / path”（这些是默认值）。
请记住，使用本地作业运行器时不需要启动任何Hadoop守护进程。 运行bin / hadoop将启动一个JVM，并为你运行你的工作。 创建一个新的hadoop-local.xml文件（或者如果您使用0.20，则使用mapred-local.xml和hdfs-local.xml）可能是有道理的。 然后可以使用-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是工具实现。
要开始使用本地作业运行器在Hadoop中测试您的MR作业，请创建一个新的配置目录，该目录是启用本地作业运行器并像平常一样调用作业，记住包含-config参数，该参数指向包含您的目录本地配置文件。
-conf参数也适用于0.18.3版本，您可以指定hadoop-local.xml文件，而不是使用-config指定目录。 Hadoop将会愉快地开展工作。 这种测试形式的困难在于验证作业是否正确运行。 注意：在运行作业之前，您必须确保输入文件设置正确并且输出目录不存在。
假设您已设法配置本地作业运行器并使作业运行，则必须验证作业是否正确完成。 简单地将成功置于退出代码上并不够好。 至少，您需要验证您的工作输出是否正确。 您可能还想扫描bin / hadoop的输出以查找异常。 您应该创建一个脚本或单元测试，以设置先决条件，运行作业，区分实际输出和预期输出，并扫描异常情况。 然后，此脚本或单元测试可以以适当的状态退出，并输出特定的消息来解释作业失败的方式。
请注意，本地作业运行程序有两个限制：只支持一个Reducer，并且DistributedCache不起作用（修复正在进行中）。
伪分布式测试 - 使用守护进程在一台机器上运行MR作业
本地工作管理者可以让你在一个线程中运行你的工作。 在单个线程中运行MR作业对于调试非常有用，但它不能正确模拟运行多个Hadoop守护进程（例如，NameNode，DataNode，TaskTracker，JobTracker，SecondaryNameNode）的真实集群。 伪分布式集群由运行所有Hadoop守护进程的单台机器组成。 这个集群仍然比较容易管理（尽管比本地作业运行者更难），并且比本地作业运行者更好地测试与Hadoop的集成。
要开始使用伪分布式集群在Hadoop中测试您的MR作业，请遵循上述关于使用本地作业运行器的建议，但在前提条件中，您需要配置和启动所有Hadoop守护进程。 然后，开始你的工作，就像平常一样使用bin / hadoop。
全集成测试 - 在QA集群上运行MR作业
测试您的MR作业最彻底但最麻烦的机制可能是在由至少几台机器组成的QA群集上运行它们。 通过在QA集群上运行您的MR作业，您将测试您的工作以及与Hadoop集成的所有方面。
在QA群集上运行您的工作有许多与本地求职者相同的问题。 也就是说，你必须检查你的工作输出是否正确。 您可能还想扫描每个任务尝试产生的标准输入和标准输出，这需要将这些日志收集到中心位置并对其进行剔除。 Scribe是收集日志的有用工具，尽管根据您的QA群集它可能是多余的。
我们发现，我们的大多数客户都有某种QA或开发集群，他们可以部署和测试新作业，尝试更新版本的Hadoop，并练习将集群从一个Hadoop版本升级到另一个版本。 如果Hadoop是生产管道的重要组成部分，那么创建QA或开发群集就很有意义，并且重复运行作业将确保对作业的更改继续得到彻底测试。 EC2可能是您的QA群集的良好主机，因为您可以根据需要上下调整它。 如果您有兴趣在EC2中创建QA群集，请查看我们的测试版EC2 EBS Hadoop脚本。
您应根据组织质量检查的重要性以及您拥有的资源数量来选择质量检查实践。 只需使用传统的单元测试框架，MRUnit和本地作业运行者就可以以简单的方式彻底测试您的MR作业，而无需使用太多的资源。 但是，在QA或开发集群上运行您的工作自然是通过Hadoop集群的开销和操作任务完全测试您的MR作业的最佳方式。
链接地址: http://www.djcxy.com/p/11599.html上一篇: Best unit testing tool/method for a hadoop mapreduce job