ITPub博客

首页 > 大数据 > Hadoop > 【原】Hadoop in China 2011 有感

【原】Hadoop in China 2011 有感

Hadoop 作者:zengzuqing 时间:2011-12-06 15:28:31 0 删除 编辑
作者:icymary       作者Blog: http://icymarywei.blog.163.com/

通过一天的参会体验,一天的网上学习,有很多收获,很多感触,特记录如下:

1. 据作报告的各位专家描述,Zookeeper基本上是Hadoop开源社区中,最稳定的一款。并且它也提供了很多开源软件都需要用到的Master选举,Namenode主备维护等功能。维护节点的退出与加入。很多开源系统都依附于Zookeeper,如HDFD,HBase等。现有的很多企业公司定制的大规模系统中也有Zookeeper的一席之地。由于Zookeeper功能比较全,相应的也就比较庞大,所以,淘宝的OceanBase没有采用Zookeeper,而是使用Linux系统自带的Pacemaker进行主备同步。

2.这次报告,听到Bookkeeper的报告,如果Bookkeeper不从Zookeeper中分离出来,可能大家一直都不会对Bookkeeper重视起来。Bookkeeper是Zookeeper的一个核心组件,用于维护Write Ahead Log的。淘宝的技术人员很不错,估计是前一天刚听了该报告,第二天关于Bookkeeper的测试报告就出来了。

3.CAP一直都是数据处理领域一个不可回避的准则,最开始单机数据库为了满足强一致性和高可用性,而损失了P(网络分割容忍性);紧接着的并行数据库也满足不了P(因为一台机器坏掉之后,整个系统就Down掉了);随后NoSql数据库以满足P为前提,从而在A和C中进行选择,如Cassandra通过选择了弱一致性,而HBase牺牲了高可用性。二者都有一定的市场。随着大数据业务的复杂化,对事务的要求越来越高,而不仅仅是需要满足单行事务,需要多行多表事务。于是出现了很多此类系统,如Google的Percolator,Yahoo的OMID,淘宝的OceanBase。但是这些事务的保证也是有一些代价的,如淘宝的OceanBase是通过引入UpdateServer来保证多行多表事务,但是,此类更新只能在UpdateServer上进行,所以,UpdateServer的扩展性就成为一个新的问题。如Google的Percolator,通过引入Lock列来满足多行事务,这些多加入的列会带来存储开销,且Percolator的性能也不高。Yahoo的OMID与Percolator的操作比较相近,是将并行操作串行化以保证多行事务,但是如何判断几个操作是操作相同的几列又是一个问题。看来NoSql要想达到与传统数据库相同的可用性,还有一段距离的。

4.Google的技术一直都很超前,当大家还在想办法解决多行事务时,Google的Tenzing已经可以支持SQL92和SQL99的部分扩展功能。Tenzing通过改进的MapReduce来支持多表Join,因为采用的是MapReduce,所以,大约响应级别是60m级。

5.为什么Google一直可以引领技术,我想,可能是因为Google的数据膨胀比较大,数据膨胀了,又需要提供良好的服务,就必须在架构上做文章。Hans说得好,性能提升几倍,可以做一些优化,而想提升十倍以上,就需要修改架构了。而其他的企业,因为没有这么大的数据需求,所以就出现了以下两种情况:a)利用现有的开源软件,如Hadoop改造改造,裁剪裁剪,推出自己的系统;b)根据自己的实际需求,参考大牛(如Google)的架构重新开发。

6.学术界与工业界的合作是非常需要的,工业界提出需求,学术界给出解决方案。一个企业成熟的标志也许是有没有一个强大的研究院作为后盾。纵观国内外,成功的企业都有研究院,其实做一些前瞻性的工作是一个公司赖以生存的条件。呵呵,这也许是要评断一个高校的好坏就看其有无研究生院的原因吧。这次Hadoop in China受邀嘉宾,学术界和企业的代表旗鼓相当,还是挺好的。互相借鉴,互相学习。

7.这次报告,发现现在大家的关注点已经从Offline转向Online了,如实时搜索,实时处理等等。时代在变化,科技在进步,关注点也在一步步变化,这是发展的必然。

以上只是一些个人见解,如有不对,烦请指出,谢谢
<!-- 正文结束 -->

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24043738/viewspace-1120278/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 没有了~
下一篇: 没有了~
请登录后发表评论 登录
全部评论

注册时间:2010-06-06