hadoop应用程序测试.pptxVIP

Hadoop应用程序测试 李相娜 单机测试 分布式测试 上线模拟测试 计算申请单 主要内容 单机测试 Map和Reduce应用程序需要在单机模拟集群运算： cat input | mapper | sort | reducer output 关注点： 内存最大使用量 程序正确运行返回值为0 结果正确性 异常情况下程序能及时退出 （破坏管道比如kill cat进程时，程序是否退出） 提交单机测试报告给sos接口人审核 分布式测试 分布式计算测试 向sos接口人获取测试集群地址（和客户端） 启动MapReduce计算 关注点： 执行是否成功 程序总运行时间、map和reduce总输入输出数据量及单个任务平均运行时间 结果正确性 计算失败有重试，防止平台升级、网络瞬断等短暂故障引起任务失败而报警。 可以通知sos接口人配合关注平台资源消耗情况 分布式测试 其它测试 数据上传/下载脚本 计算启动脚本 测试完毕后需提交测试报告给sos接口人审核 测试经验 上线模拟测试 测试集群 根据上线单操作流程在测试集群实施上线 运行并监控状态，一般超过24小时 线上集群 根据前期测试的统计数据，提交计算申请单，申请在线上集群测试 通过审核后，手动在线上集群启动测试 测试启动后，通知sos接口人配合关注平台资源消耗情况 计算申请单范例 1 输入数据总量 251G 2 分几轮map-reduce，每轮计算是否分批 3轮 3 map中间结果数据量 76G 76G 76G 4 reduce结果数据量，是否长期保存 76G,否 76G,否 4G,否 5 map程序内存最大使用量 27M 3M 13M 6 reduce程序内存最大使用量 150M 85M 355M 7 map程序和reduce程序处理小规模数据的时间，如单机处理256MB数据map和reduce程序各消耗多少时间。 20s 62s 7s  40s 14s 36s 8 map和reduce是否使用配置文件或字典；如果使用，大小是多少，是否有目录结构 使用ccode字典，1.3M,一级目录 无 无 9 任务名称 clickreport-di-1-1 clickreport-di-1-2 clickreport-di-1-3 10 日志输出位置 ./log 11 附上启动脚本 见附件 测试经验 已审核过的计算单重新提交申请计算时，建议在邮件中标明，可以加快审核流程。 确认文件的分发机制 -file 适合分发更新频繁的小文件或单个文件 -cacheArchive 适合分发大文件甚至整个目录结构 关于reducer任务数的确定 一般来说，每个reducer的运行时间在1~3分钟最为理想，但reducer任务包括数据拷贝的过程，时间不太可控，因此一般平均每500M~1G的中间数据需要一个reducer任务。 测试经验 关于内存使用统计 单机统计时，并不需要使用线上量数据整个运行一次，那样会耗费太多时间。结合程序的特点，我们可以采用简化的统计方式： 对于资源占用稳定的程序 一些程序资源占用稳定，申请到一定量的资源后就不再上长。这样的程序，用一定的输入数据，观察到这个固定的占用量即可。 对于资源占用可能上升的程序 部分程序或脚本的资源占用随输入数据的增长而增长。这样的情况下， 我们需要估算线上数据运行后分配给每个任务的数据量，然后在这个数据量的基础上以合理比例加大输入数据量，统计峰值。 总之，我们统计的，应该是每个任务在hadoop上可能产生的资源占用峰值，并根据这个峰值确定该模块的资源占用是否符合SOS的要求。如果资源占用严重超标，需返回RD对程序进行修改，减少资源占用。如果是在临界范围，不好确认，可以要求SOS协助对计算进行监控，由SOS判断是否能够接受。压力测试最好也能由SOS进行监控。 - 摘自PS QA的项目总结 QA