hadoop配置之初体验

缘来似你

　　刚刚开始学习hadoop，在配置hdfs的时候经常出现一些莫名其妙的问题。总结一下：
　　一 关于hadoop namenode -format
　　每个节点（datanode、namenode）都需要进行hadoop namenode -format ，这是必须的，但是这也经常引发一些问题。例如datanode的namespaceID不匹配问题。导致datanode无法链接到namenode。在网上看到外文的参考方法:
Big thanks to Jared Stehler for the following suggestion. I have not tested it myself yet, but feel free to try it out and send me your feedback. This workaround is "minimally invasive" as you only have to edit one file on the problematic datanodes:
1.stop the datanode
2.edit the value of namespaceID in /current/VERSION to match the value of the current namenode
3.restart the datanode
If you followed the instructions in my tutorials, the full path of the relevant file is /usr/local/hadoop-datastore/hadoop-hadoop/dfs/data/current/VERSION (background: dfs.data.dir is by default set to ${hadoop.tmp.dir}/dfs/data, and we set hadoop.tmp.dir to /usr/local/hadoop-datastore/hadoop-hadoop).
If you wonder how the contents of VERSION look like, here's one of mine:
#contents of /current/VERSION
namespaceID=393514426
storageID=DS-1706792599-10.10.10.1-50010-1204306713481
cTime=1215607609074
storageType=DATA_NODE
layoutVersion=-13
个人感觉配置hadoop.tmp.dir路径很重要，因为dfs.data.dir和dfs.name.dir都是参考这个路径。默认是在/tmp中。当然这两个路径也可以在hdfs-site.xml中配置：
　　hdfs-site.xml添加如下配置

　　

　　 dfs.name.dir #非添加内容.hadoopfs需要新建,name不用新建

　　 /home/hadoop/hadoopfs/name

　　

　　

　　 dfs.data.dir #非添加内容.data不用新建

　　 /home/hadoop/hadoopfs/data

　　
但是我感觉这个方法不如前面的好。
当遇到datanode和namenode的ID不匹配时可以把datanode中的${hadoop.tmp.dir}/dfs/data/current/VERSION的namespaceID改成跟namenode的一致即可。或者把${hadoop.tmp.dir}/dfs/data全部删除，重新在namenode中format，然后再start运行即可。
二、关于/etc/hosts问题
　　有些版本的linux在每次启动后会在/etc/hosts中生成一个127.0.0.1 主机名 的配置项。这样会造成一些很恶心的问题，例如：
　　在core-site.xml中




fs.default.name

hdfs://主机名:54310

当你这里使用主机名时，会出现问题。由于对应的主机名的/etc/hosts中第一项为127.0.0.1，所以这里他监听的ip地址实际上不是你想监听的namenode的ip，而是127.0.0.1，是你当前主机的ip地址，由此会出现各种恶心人的问题:........不再一一列举了。还有就是：有一点很重要！！：多看logs日志，里面会记载所有的异常，这些问题都是我在一点一点研究logs日志里面的异常时发现的。另外在master和slave中不用写主机ip地址，写主机名就可以，因为他是找的当前主机的/ect/hosts中对应的主机名然后匹配ip地址，所以没问题。
同理，mapred-site.xml中的配置也是一样

　　
                mapred.job.tracker
                :9001
        
　　三、关于secondarynomenode
　　光从字面上来理解，很容易让一些初学者先入为主的认为：SecondaryNameNode（snn）就是NameNode（nn）的热备进程。其 实不是。snn是HDFS架构中的一个组成部分，但是经常由于名字而被人误解它真正的用途，其实它真正的用途，是用来保存namenode中对HDFS metadata的信息的备份，并减少namenode重启的时间。对于hadoop进程中 ，要配置好并正确的使用 snn，还是需要做一些工作的。hadoop的默认配置中让 snn进程默认运行在了 namenode 的那台机器上，但是这样的话，如果这台机器出错，宕机，对恢复HDFS文件系统是很大的灾难，更好的方式是：将snn的进程配置在另外一台机器 上运行。
　　在hadoop中，namenode负责对HDFS的metadata的持久化存储，并且处理来自客户端的对HDFS的各种操作的交互反馈。为了保 证交互速度，HDFS文件系统的metadata是被load到namenode机器的内存中的，并且会将内存中的这些数据保存到磁盘进行持久化存储。为 了保证这个持久化过程不会成为HDFS操作的瓶颈，hadoop采取的方式是：没有对任何一次的当前文件系统的snapshot进行持久化，对HDFS最 近一段时间的操作list会被保存到namenode中的一个叫Editlog的文件中去。当重启namenode时，除了 load fsImage意外，还会对这个EditLog文件中 记录的HDFS操作进行replay，以恢复HDFS重启之前的最终状态。
　　而SecondaryNameNode，会周期性的将EditLog中记录的对HDFS的操作合并到一个checkpoint中，然后清空 EditLog。所以namenode的重启就会Load最新的一个checkpoint，并replay EditLog中 记录的hdfs操作，由于EditLog中记录的是从 上一次checkpoint以后到现在的操作列表，所以就会比较小。如果没有snn的这个周期性的合并过程，那么当每次重启namenode的时候，就会 花费很长的时间。而这样周期性的合并就能减少重启的时间。同时也能保证HDFS系统的完整性。
　　这就是SecondaryNameNode所做的事情。所以snn并不能分担namenode上对HDFS交互性操作的压力。尽管如此，当 namenode机器宕机或者namenode进程出问题时，namenode的daemon进程可以通过人工的方式从snn上拷贝一份metadata 来恢复HDFS文件系统。
至于为什么要将SNN进程运行在一台非NameNode的 机器上，这主要出于两点考虑：

• 可扩展性： 创建一个新的HDFS的snapshot需要将namenode中load到内存的metadata信息全部拷贝一遍，这样的操作需要的内存就需要 和namenode占用的内存一样，由于分配给namenode进程的内存其实是对HDFS文件系统的限制，如果分布式文件系统非常的大，那么 namenode那台机器的内存就可能会被namenode进程全部占据。
  
• 容错性： 当snn创建一个checkpoint的时候，它会将checkpoint拷贝成metadata的几个拷贝。将这个操作运行到另外一台机器，还可以提供分布式文件系统的容错性。
  

　　以上关于secondarynamenode的讲解是参考网上的。
在secondarynamenode主机上的core-site.xml中配置检查点：

fs.checkpoint.dir
/data/work/hdfs/namesecondary

从secondarynamenode远程拷贝namesecondary文件到namenode的namenode上面${hadoop.tmp.dir}/dfs/namesecondary，然后进行hadoop namenode –importCheckpoint。他会将  secondarynamenode文件夹中的文件恢复到${hadoop.tmp.dir}/dfs/name文件夹中，来实现namenode宕机恢复数据。

以上都是自己亲身体验写的，如有误请指正。