1、在讲测试用例之前,我们首先为系统当前用户在HDFS中创建一下工作目录,并服务相应的权限。
1.1、由于我安装的时候是用的root用户,因此也就需要在hdfs中为root用户创建工作目录,并授予权限。
(1)首先在HDFS中,在用户目录/user/下创建一个root用户文件夹,作为root用户的工作目录。执行如下代码:
sudo -u hdfs hadoop fs -mkdir /user/root
(2)授予/user/root目录相应的权限
1)先将该目录的所有权赋给root用户: sudo -u hdfs hadoop fs -chown root /user/root
2)再将该目录的组的权限赋给root用户自己管理:sudo -u hdfs hadoop fs -chgrp root /user/root
3)最后设置该目录的权限:sudo -u hdfs hadoop fs -chmod 777 /user/root (该权限是拥有者:可读可写可执行;组用户:可读可写可执行;其他用户:可读可写可执行)
1.2、给普通用户创建HDFS工作目录,并授予权限。普通用户与root方法类似,只不过这个过程是需要在root用户下执行的。
2、测试WordCount例子。
2.1、执行测试用例
通过CDH自身的jar来测试,该jar是在/opt/cloudera/parcels/CDH/jars/hadoop-examples.jar包。然后通过在界面执行如下命令:
hadoop jar /opt/cloudera/parcels/CDH/jars/hadoop-examples.jar /user/root/input /user/root/output
以上代码需要注意的是/user/root/output必须是未存在的。mapreduce运行完之后,会自动创建。
本以为可以搞定,并等待结果,当执行完毕后,通过hdfs网页管理进入/user/root/output发现有48个part-r-000xx文件,这说明该作业提交后,执行了48个reducer任务。这就奇了怪了。我并没有让他执行48个reducer任务啊,而且我以前部署了这么多次的hadoop集群都没有出现过这个问题,这次运行WordCount竟然出现了这样的问题。
2.2、2.1的问题的原因分析
通过查看上面产生的48个文件的内容,发现对应的是只是执行了map任务,对应的每一个单词就是1,reducer并没有进行累加。出现上面的这个问题,开始分析发现是由于yarn-site.xml配置文件中没有设置shuffle过程。就是没有设置洗牌的过程。也就是在yarn-site.xml文件中设置:
<property>
<name>yarn.nodemanager.aux-services</name>
<value>mapreduce_shuffle</value>
</property>
通过查看Cloudera CDH的配置文件,发现貌似还真的没有设置。查看的方式是分别查看两个路径下的配置文件内容:
客户端:/etc/hadoop
服务端:/var/run/cloudera-scm-agent/process/ (在该目录下找yarn-RESOURCEMANAGER或yarn-NODEMANAGER的目录)
在这两个目录下可以查看相应的配置文件。发现配置文件并没有上面需要添加的信息,于是手动添加。最后发现也还是没用。
最后考虑reducer的代码的问题。最后发现是我的reducer类的代码下的有问题。
2.3、此时本以为问题已经解决了,但是运行之后,发现还是会有48个文件产生,这个时候我有郁闷了,我在查看了这48个文件的内容,发现这次reducer函数起到了作用,单词的个数进行了累加。那为什么还是会产生48个文件呢?
原因:不明
修改的方法是:通过在代码中设置reduce的个数来设置reducer的数目。如:job.setNumReduceTasks(1);
此时发现有效,最后只有一个reducer。
进一步测试,通过分别设置job.setNumReduceTasks(10);和job.setNumReduceTasks(100);,并运行产生结果,发现最后的结果都产生了我设置数目的reducer的个数的文件。这个时候,我推断默认情况下是reducer是48个。
下一步要去分析pritition函数的应用。