由中国计算机协会（CCF）主办，CCF大数据专家委员会协办，CSDN承办的国内大数据领域最纯粹的技术盛会——“Hadoop与大数据技术大会”（Hadoop&BigData Technology Conference 2012，HBTC 2012）将于2012年11月30日-12月1日在北京新云南皇冠假日酒店举行。在大会召开前夕，CSDN云计算频道特别举办4期的“Hadoop&BigData技术赢门票”的活动。第一期“改进MapReduce降低Hadoop计算延迟”获奖公布，第二期如期启动。
规则：
1.回答方向、内容、字数均不限；
2.参与方式四种，任君选择：微博@CSDN云计算，CSDN论坛直接回复；邮件kangwb@csdn.net，抄送guoxm@csdn.net；问题主页评论部分直接回复（注意标注联系方式）；
3.本期活动由出题者来确定一个技术问题的获奖人，一个开放问题的获奖人，定期公布在获奖主页；
4.第三期和第四期问题将同时于11月21日发布；
没有最好，只有更好！HBTC 2012期待你的参与！
11月14日，第二期
技术问题：我们都知道Hadoop的Namenode的单点问题一直是Hadoop没有解决的，即便是Hadoop 2.0的多Namenode分片管理的HA方案，目前也仅支持手工切换。那么，我们是否有办法来自动避免Namenode的单点故障导致的集群不可用？
开放性问题：我们都知道，Hadoop在当前是大数据处理领域的王者，但是使用范围都集中在大型公司中，那么在你看来，阻碍Hadoop的平民化最大的问题在哪里？你有什么好的解决办法吗？
精彩回答：期待！
获奖者及点评：期待！
更多精彩内容，请关注新浪微博：@CSDN云计算；HBTC 2012
相关链接：
第一期问答：“Hadoop&BigData 技术赢门票”活动正式启动
第一期获奖：“改进MapReduce降低Hadoop计算延迟”获奖公布
------解决方案--------------------------------------------------------
技术问题：
方案一:
使用传统的HA方案, 配置两个NameNode server, 一个Active, 一个Standby, Active与Standby之间共享存储, 用heartbeat在Active和Standby之间做一个HA. 如果Active挂了的话, heartbeat自动将Standby启动在Active,Standby共享的Virtual IP上.
方案二:
NameNode 将Meta数据存储在有HA功能的NoSQL或者传统的数据库中, 比如Berkeley DB, 而不是直接存放在本地磁盘中. 同样配置两个NameNode server, 用heartbeat在Active和Standby之间做HA.
方案三:
直接利用已有的方案,比如AvatarNode
开放性问题：
一般小公司的数据量不大,对Hadoop没有多少现实需要, 传统的关系数据库已经能很好地满足他们的需求了. 也有一些公司规模不大但是产生的数据量巨大,他们也会用Hadoop帮助他们进行数据分析.
同传统的数据库比较,Hadoop还是比较新的技术,掌握他们要一段时间, 一般小公司也找不到有Hadoop知识的人才.
Hadoop自身的配置比较复杂, MR模型在现阶段还没有被大多数人掌握, 这也阻碍了小公司对Hadoop的利用.
如果Hadoop要平民化:
1) 安装配置管理要比较简单,最好可以通过Web界面进行配置管理.
2) 更多的人对MR模型有比较深入的理解, 小公司就可以找到熟悉Hadoop的人才.
3) 在Hadoop基础之上进行二次开发, 二次开发的软件同大家熟悉的模型的GAP比较小. 小公司可以直接利用二次开发的软件间接利用Hadoop. 比如Hive就是比较好的数据分析工具,它在传统的数据库和Hadoop之间架起了一道美丽的桥梁. 希望看到越来越多的在Hadoop基础之上开发的, 比较易用的软件面市.
------解决方案--------------------------------------------------------
关于技术问题, 又想到了一个办法:
可以仿照Redis的思路, 一个Master Namenode, 多个Slave Namenode, 写入Master Namenode的Meta data直接复制到slave Namenode中. 写入文件必须写入Master Namenode, 读取文件可以访问Slave namenode以获取Meta data.
------解决方案--------------------------------------------------------
技术问题：
自动避免NameNode单点故障导致集群的不可用，这个议题我有2种理解：
第1种理解（我的理解：要真正解决NameNode的单点故障，就要实现分布式的NameNode集群）：
实现分布式的NameNode集群，对于用户而言，NameNode对其而言是透明的，当他在使用Hadoop服务的时候，并不知道使用的是哪个NameNode。对于实现分布式的NameNode集群，这里根据规模的大小不同，有2种方案。
方案一（数据量不是像淘宝、百度、腾讯那么的大的应用场景）：
这种场景下，数据量不是特别的大，那么NameNode维护的元数据信息也不会特别特别的大。这样的话，可以采用分布式NameNode集群的方法来解决现在的NameNode单点故障问题。具体方法是：
（1）每个NameNode都做RAID1，挂载NFS文件系统存储元数据（加上之前做了RAID1，相当于系统是冗余的，元数据有3份），进行双网卡绑定。
（2）每个NameNode存储整个集群的全部元数据信息。
（3）用户在使用Hadoop服务的时候，NameNode对其是透明的，用户不知道是哪个NameNode为其服务。访问量大的时候，通过负载均衡，将任务分发给不同的NameNode去执行，那么就可以解决NameNode的单点故障问题。
方案二（数据量像淘宝、百度、腾讯那么的大的应用场景）:
这种场景下，数据量是很大的，那么NameNode维护的元数据信息就会很大，那么NameNode出现单点故障的概率也就大了。可以通过采用分布式的NameNode集群方式来解决，把不同的应用交给不同的NameNode来管理，然后每个应用对应的NameNode都需要做RAID1，挂载NFS文件系统存储元数据，双网卡绑定，还要做HA热备，具体做热备的方法请见“第2种理解”中的描述。这样的话，对于用户而言，NameNode对其是透明的，用户不知道是哪个NameNode在为其工作，而且按应用划分NameNode有个好处，NameNode维护的元数据量会大量减少，负担轻了，NameNode出现单点故障的几率也就下降了一点。
第2种理解：
将“手工切换”的方式变换成“自动切换”方式，也就是实现Hadoop的NameNode热备份HA
实现思路：采用2台或者是2台以上机器做NameNode节点，其中一台处在Active状态，另外的机器处在Standby状态，每个NameNore节点都做RAID1且挂载共享的NFS文件系统（存储fsimage及最新的edits文件等），通过心跳检测信号来判断处在Active状态的NameNode是否正常；如果不正常，则处在Standby的NameNode转为Active状态。当然这样有个缺陷，那就是：无法做到完全的无缝切换，切换过程中会有一小段时间无法提供服务，不超过30秒，当然这个时间可以设置的更短（Active服务器和Standby服务器之间的网络延迟要低的情况下)。