用于hadoop mapreduce工作的最佳单元测试工具/方法

7 unit-testing hadoop mapreduce

我是新来的,但需要知道对通过Apache Hadoop编写的程序进行单元测试的最佳方法.我知道我们可以用jUnit方式编写单元测试用例,用于map中的逻辑和reduce方法.此外,我们也可以对其他逻辑进行相同的操作,但这并不能保证它经过良好测试并可以在实际运行环境中运行.

我已经读过关于MRUnit的内容,但它似乎也像我上面提到的那样,但是以更成熟的方式.但它也不是真正的mapreduce工作,而是一个嘲笑的工作.

任何帮助,将不胜感激.

谢谢.

Ama*_*mar 3

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

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

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

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

传统的单元测试和 MRUnit 应该能够在早期检测 bug,但两者都无法使用 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,则创建一个新的 hadoop-local.xml 文件(或者 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的输出以查找异常。您应该创建一个脚本或单元测试来设置前提条件、运行作业、区分实际输出和预期输出以及扫描引发的异常。然后,该脚本或单元测试可以以适当的状态退出,并输出解释作业如何失败的特定消息。

请注意,本地作业运行器有一些限制:仅支持一个减速器,并且 DistributedCache不起作用修复正在进行中)。

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

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

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

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

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

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

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

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

  • 没关系。但将来在此处发布问题之前请进行必要的搜索/研究。干杯:) (2认同)