第二期“Hadoop&BigData技术赢门票”：技术+开放自由选
由中国计算机协会（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服务器之间的网络延迟要低的情况下)。
特色：（1）NameNode做RAID1，即使一块硬盘坏了，NameNode仍可以正常工作；（2）NameNode共享NFS文件系统，相当于Active状态的NameNode里面存储3份元数据，保证了元数据的安全性；（3）可以做双网卡绑定同一个IP地址，这样的话，就解决了NameNode的网络的单点故障了。
实现方法：使用heartbeat、PaceMaker、drbd实现hadoop的namenode热备份HA（大家感兴趣的话，可以直接联系我）
[解决办法]
开放性问题：
阻碍Hadoop平民化的最大问题：
（1）学习成本较高，出了Hive之外，其他的组件几乎都是一门全新的知识，Pig和HBase相对来说入门还比较容易，MapReduce程序简单的还好，复杂一点的程序编写程序是相当耗时间和非常考验编程能力的，Hive虽然支持SQL99的标准，但是很多数据库功能是没有的，用起来会非常的受限制，当然可以通过编写UDF函数来解决，但是据我自己编写UDF函数的经历告诉我，很耗时，而且不是那么容易上手的。
（2）现有业务平台的迁移问题，比如：之前我在数据仓库、数据集市跑的一些报表啊之类的存储过程，到了Hadoop这里似乎就不是那么好迁移了，就算能迁移，付出的代价也是非常高的，作为企业的管理者，引入Hadoop是为了节省投入，目前阶段，肯定不会把大量逻辑复杂的存储过程放到Hadoop上面来跑，因为至少目前而言，是不会有这个想法的。而且，还涉及到一个前台WEB展现的问题，要把已有系统的数据层迁移到Hadoop平台，前台WEB开发量是非常大的，而且除了HBase之外，其他的组件的查询性能是不适合现有实时的业务系统的。而且HBase在某些方面也跟不上传统数据库。
（3）现阶段，Hadoop的实时性是不怎么好的，编程模型单一，比较适合离线的大数据的分析和存储。
解决方案：
针对问题一：希望2013年第一季度Cloudera公司发布的Impala可以支持更多的数据库操纵函数，希望Hive能支持更多的数据库操纵函数，或者自己编写常用的UDF函数，然后打成JAR包，到Hive里面去创建函数，让后端的数据库开发人员可以比较轻松的使用Hadoop；
针对问题二：基于Hadoop开发WEB应用，我觉得是一个循序渐进的过程，同样是调用API，我觉得对于比较熟练的JAVA开发员来讲，问题不是很大。我希望Hadoop提供的API的功能可以更加的强大，调用起来更加的方便。
针对问题三：将JobTracker的MapReduce编程模型从运行环境中剥离，MapReduce变成了Hadoop的编程库。从而，在运行环境之上灵活开发MapReduce、DAG、Iterative MR等编程模型，实现对于多种应用场景的支持。
[解决办法]
技术问题：
以往的namenode不管是两个还是多个（每个分管一部分目录），在任何时刻只有一个处于活动状态，而另外的处于备份（热备份）状态，当单点故障后还是停留在手动切换。
解决思路：
先要稍微改动一下namenode和datanode的交流过程，每次datanode执行操作前改为接受2次namenode的确认。
在正常工作时，有两个活动的namenode1和namenode2，它们可以各分管一部分，但是分管的所有datanode的执行要经过namenode1和namenode2的各一次确认，并且两个活动的namenode之间一直存在交流，资源也共享。
当一个namenode故障时，如namenode1故障，那么namenode2在自己发送一个对于datanode的确认时，namenode2也向namenode1发送一次信息并要求响应（当然正常时，两个namenode之间都会相互回应），一个极短暂的超时倒计后，判断namenode1故障失效。立刻再向datanode发一次确认，使其能正常执行，同时接管原先namenode1分管的部分，并尝试恢复namenode1或启动namenode1的热备份（可以是两个节点的共同备份）。在此期间，namenode2要一直对原先两个节点管理的datanode每次发出两次确认，使集群仍可用，直到namenode2恢复。
当然多个namenode分管各个目录时，也可采用多次确认，显然不宜太多次的确认，换汤不换药，寻找最佳个数要经过实测。
[解决办法]
第二期问题回答：完全借助zookeeper思想，采用多namenode。在启动Hadoop集群时，选出leader namenode,其他作为follower.所有的datanode连接，操作信息等等follower与leader共享。当leader挂掉，从其余follower中再次选举新的leader.从而实现了namenode的自动切换。
开放性问题：阻碍Hadoop平民化的首要问题是其研究成本。不同的公司对hadoop有着不同方向的研究与优化，针对自己公司的业务又有着不同的改进方法。而对于绝大多数小公司来说，这样的研究与改进，无论从人力、物力还是时间等方面上，都是一笔巨大的成本。
建议改进方案：首先要让更多的人知道hadoop，不仅仅了解他的名字，要让更多的人知道其架构、体系、原理，甚至具体实现等等。这些工作做不应该由开源的爱好者来做，而真的由官方给出细致、清晰、易理解、易学习的讲解。甚至为了降低这样的成本，可以由hadoop官方成立相应的合作工作室，成立基于hadoop，针对具体业务和需求而进行优化改进的服务，将该服务作为产品来进行销售。从而降低hadoop研发成本，也可为该服务团队带来收益。
[解决办法]
可以参考hbase的master单点问题额。
[解决办法]
Namenode的单点故障导致的集群不可用个人觉得要分几个方面，不光是技术上的，首先namenode 的操作受编程API 的影响，对namenode 的操作就是不可控的，用户代码可以创建目录，创建文件，一些数据挖掘比如使用mapreduce实现的算法需要用到大量的临时空间来存储迭代的结果，这时候如果用户代码出错比如创建文件或者创建目录陷入死循环，这时候namenode 一定挂掉，淘宝就发生过这种情况，这种用户代码的任意性导致namenode挂掉实际上是无法完全避免的，相反，对于数据库里面很多HA 的思路，数据库里面执行每一个动作对元数据的影响都是已知的, 比如DML,DDL,pl/sql 等等，出现任意代码导致的不可用即使有也会马上被修正.所以从这个角度说，如果不控制namenode接口和操作数据API的限制和保护，namenode 一定可以恶意的被崩溃.
从2.0 实现的HA方案实际上已经做的非常的极限了，hadoop 未来会越来越成为一个通用的处理系统，包含各种应用， ETL,实时计算，data mining,real time query,HBASE 等等，未来的集群一定会是多个，包括不同版本，针对不同应用优化的集群配置不同的参数，不同的应用对于namenode 的需求和压力都是不同，现在提到的很多HA 都是从传统的分布式数据库的概念来的，如果hadoop 只是做一个分布式数据库，参考Amazon Dynamo 的实现，这个做到namenode 的HA 不会有任何难度，每次客户端提交请求都通过环里面多台机器处理和储存，每次namenode 挂掉自动重启都询问环里面所有机器谁是最新的然后同步，namenode HA真正难的地方在于应用的多样性，如果针对一种场景优化，我相信hadoop 早就可以做到HA 了.
另外namenode 的HA 现在谈的都是从server 端去保护他，其他分布式数据库所谓的HA 不仅包括多个server 端接受同一份数据，同时在其他处理节点（等同于分布式namenode+datanode）发现主namenode 挂掉都可以自动选其他的节点自动变成namenode 并修复数据，除非同一时间真的挂掉太多台（比如路由器故障）,不然集群是可以自动慢慢恢复的,因为里面储存的元数据信息不像现在namenode 存的这么多，所以不用NFS, 不用hadoop 2.0 的Quorum Journal Manager一样可以达到HA .
另外将namenode 包含block数量减少，将整个设计变得轻量级，namenode 变成分布式的实现，这个其实mapr 已经做了，但是同时需要改动很多很多接口，包括mapreduce 的部分都要重写，跟其他hadoop 框架的兼容也是一个大问题, 这种路线短期内hadoop 的主要开发者一定不会走这条路, 成本太高.
所以笼统的回答这期的技术问题: 不能自动避免Namenode的单点故障导致的集群不可用，或者说成本太高不在主线路之内.
[解决办法]
开放性问题:
hadoop 的安装和配置不算是太复杂，相反是使用一段时间之后的监控和trouble shooting 需要专业人士帮忙.安装的话只要你知道有cloudera 或者hortonworks 他们的标准安装文档，照着那200多页一步一步做就好了，对比现在很多的MPP 卖的一体机，由厂商的一个小团队来帮你装帮你配, 2个星期都只能算是勉强能跑，还有专业的使用人员和管理人员的培训，没3-5年相关行业经验，厂家给你培训3个星期听都听不懂. 现在hadoop 还刚开始，整个业界人员的培训，创新，传播还是需要靠专业的一线人员一点一点来积累. 另外国外是有专业公司卖服务和培训的，价钱和买MPP数据库的成本一比就知道了，国内即使有，培训老师和厂家技术能力也是需要3-5时间和口碑来确立的.
另外hadoop的apache 版本应该是很少人用的，其中重要原因就是和其他组件的兼容性和升级的困恼.这个只有碰到过这方面问题的同学才会理解那种困恼. 现在大部分生产环境应该都是cloudera 或者像是IBM,EMC 这些大厂家的集成hadoop 版本，未来长期也会作为生产环境的主流版本.
hadoop的监控，配置管理和trouble shooting 如果集群小,应用和故障也少，性能问题加机器就好了，这还不是很大的问题，如果集群慢慢扩容了，还是需要专业人员来维护的，这个永远跑不掉，对应就是数据库里面的高级DBA 和大集群的运维人员.即使是有图形化的工具辅助，有很多东西不是简简单单读十几篇文档就能搞懂的，这部分如有预算要么请非常一线的人员要么还是买专业公司的咨询服务吧.
另外还有配置更简单，调优更简单，执行计划更简单，功能更丰富，这都是一个过程，业界慢慢创新，慢慢分享，都会一步一步进步的，总是期望一次有一个东西做到完美这不现实，而且现在的hadoop 项目本来就不是一个短期1-2年的小项目，每个公司都会作为长期计划投入，即使以前的BI 或者DW 项目每家公司都是投入N 年的.
未来hadoop 在细分领域的创新或者集成会解决很大一部分特定领域的需求，从而使hadoop 变成一个大数据的操作系统, 比如实时计算或者流计算(storm)，交互式查询分析(apache drill 或cloudera impala )，数据挖掘(mahout 和 R), 在线应用(HBase)，搜索，这都需要看每个公司的投入和人员的技能水平，以及数据人员怎样将技术上的东西变成业务人员能参与和认同的东西了.
