跟facebook工程师交流HDFS笔记整理

  首先声明，下面文章为转载文章，感谢兄弟的无私分享，我个人觉得写得很不错，而且借鉴的地方很多，就贴到自己的博客上来了，再次感谢！！

原文地址：http://luoli523.com/blog/2012/11/03/gen-facebookgong-cheng-shi-jiao-liu-hdfsbi-ji-zheng-li/

hadoop在纽约的大会今年是10月22日～10月25日召开的。被公司派去美国参加hadoop大会，本来非常高兴，谁知道一切具备的情况下居然莫名其妙的被美国使馆给拒签了…… 连B1签证都被拒了，点儿实在是太背。没办法，本来事先约好的跟facebook hadoop团队的交流中我的那部分，只有由同事代劳了。听说FB的人得知我因为签证被拒而没有去，都很诡异的笑了 -_-

不过还好，虽然人没到场，但我要交流的topic和相应的细节都整理好了托同事带到了，然后通过事后的邮件来往，并不影响实质的交流。随着沟通的深入，我们的情况他们也都了解，他们的一些细节，我也都已经清楚。

很客观的讲，在开发方面（运维方面我们的ops团队实在是够专业：） @淘大舞@dun_2010），至少在存储这一部分，FB比我们做的好，走的比我们快。邮件的深入交流中，我整理了一下他们特别提到的几点。应该说，由于集群规模和数据规模很接近，使用的hadoop版本也接近，所以大家遇到的问题和解决的方式都基本是很接近的思路，这其实非常的神奇，他们自己都说：在另外的一个地方，有一个跟我们最大的集群差不多规模的集群，做着相同的事情，遇到相同的问题，真的是一件神奇的事情。

把交流的内容整理了一下，主要有一下几个方面：

namenode heapsize

这个问题我们和FB都遇到了，而且很客观的讲，全球所有的hadoop集群，碰到namenode heapSize触发java6 JDK bug的，可能就只有FB的warehouse集群和我们的云梯集群。这个bug导致的后果就是namenode的heapsize加大到130GB以后，再往上加就会crash，即使物理内存够（我们服务器的是192GB）也无法使用了。想要遇到这个问题，其实不是一件容易的事情，集群的规模没到，前期各种瓶颈没有解决，是不可能来到这个地方。不过对FB来说，他们的Federation已经在线上运行，所以遇到这个问题可以绕过去，而且他们已经在调研java7，估计在不久后会迁移上去（BTW，java7中这个问题的解决也是淘宝同事的贡献：））。对我们来说非常的不幸，由于federation还在开发阶段，就不得不直接面对。幸好我们的JVM组的同事给力（@王王争@坤谷），拿到我们的反馈后，迅速做出响应，并将这个bug的解决patch提交给了java社区（详情请见bug详情 和 patch BTW：我永远不会承认java跟Oracle这家律师事务所有任何的关系，SUN才是Java的娘家），问题解决。
如果你走在雷区的最前沿，趟雷的是你，为别人插旗指路的也是你。

储存优化

由于namenode heapsize的问题，引发了很多的讨论，各自也都想过很多的办法。从开发上，FB开发了一套HDFS Raid系统，能够在不降低数据可靠性的情况下，利用Reed Solomon编码（RS编码），减少分布式文件对物理存储20%～30%的消耗。从Raid系统核心开发人员的沟通中了解到，Raid系统已经帮助FB节省了10.74 PB的物理存储空间。可能有人对这个没有太深的概念，但是，十几个PB的存储空间，几百万的资产。。。。
经过几个月对代码的熟悉和修改，我们的Raid系统也与今年7月份成功上线，目前节省存储空间100T左右。我们的Raid系统才刚刚起步，刚上线不久，公司很多业务线都还不了解，还没有把自己的数据给Raid化，不过相信我们不遗余力的推广，成效会慢慢显现出来的。（这里其实不得不说，有时候在一些机构推行一个对大家都有利的东西，或者一个机制，真的好难。就好比给绝大部分的人两个选择：1，伴随着阵痛的治疗；2，无痛的死去，面对这样的选择，大部分的人居然会选择后者……原因很多，但有一点不可否认：绩效，让很多人失去闯劲和改变的勇气。治疗？改变？可没有KPI里的业绩重要。。。。不得不感谢量子团队和数据平台团队勇敢的成为第一个吃螃蟹的人，积极的配合我们去优化存储，造福大家。）越说越远了。。。赶紧拉回来！

设计上的修改

FB的同学还透露给我目前还在思考的一个从开发上的改进方案：可变blocksize方案。 目前在HDFS中，对一个文件进行切分的时候，都是按照固定blocksize进行切分，除了最后一个block，其他的block的size都是一样大。而如果实现了可变blocksize方案，这个格局将被打破，文件的不同block，size可以不一样（这一点其实不难做到，因为在namenode里，每个block对象的size其实都是一个独立的变量）。这样的后果就是：当要合并两个文件的时候，不再需要像现在一样将两个文件进行读出，然后顺序的写到另外一个merge的文件中去。也就是说，要合并文件，只需要一个调用，修改一点点meta信息，不产生任何的IO读写就能够做到。这将是一个不错的选择，不错的方案，能够以最小的代价合并HDFS上的小文件，减少meta信息对namenode内存的消耗。concatenate files，这将是我们团队接下来的一个很重要的工作。我会把细节和原理在将来的笔记里记录到这里来。

RPC方面

FB的做法跟我们一样，因为他们也发现了在namenode的个总rpc响应中，每一个rpc的处理时间里有很大的一部分是用来处理文件路径（breaking into components, getting bytes out of them），所以对namenode优化很大的一部分就是将这种类型的操作尽量的挪出读写锁。另外，FB的同学提到了一个新的想法：将namenode的rpc中，处理datanode的rpc和来自Client的rpc分开，用100个handler来处理datanode的请求，用更多的handler来处理Client的请求，根据他们的介绍，这能够对提高namendoe吞吐有很大的帮助。这是我们还没有尝试过的做法，肯定从程序的实现上做了比较大的修改，还有很多细节需要去了解才行。

edits log

目前FB也是使用了本地和NFS各一份的方式，不过也在做Bookkeeper和QJM的调研，呵呵，真的很神奇，大家的想法再一次不谋而合。

Federation

FB已经上线了他们的federation，实现跟社区稍有不一样，但原理基本一致。而且他们也是一个namenode一个pool的做法，这样简单。设计上完美的东西，永远都只能停留在paper和PPT里面，真正解决问题的，通常都是那些简单可靠的办法。（非常遗憾，在美国人看来，这样的做法简单高效，是最优方案，在很多中国人看来。。。。。 还不够吹毛求疵的。唉，又扯远了）

Failover

还有一点也非常神奇，FB的failover方案，目前来说也是人工介入的切换，并没有要做成自动切换。说白了，failover要解决的问题，99%都是升级不停服务的问题，为了TNND那1%的可能性去做那80%的工作，真的没有必要.

整理了一下，重要的就以上这些。真的是对我们接下来的工作有很多方向上的帮助。不得不说，跟FB的开发团队的交流有一种如沐春风的感觉。很单纯的一群人，听说他们的Raid系统在我们的集群也成功上线，他们都高兴的欢呼，击掌相庆。什么叫价值观？这才是价值观:)

自从删除CSDN上的博客以后，好久没有整理笔记了，以后我会把我们开发中的积累和经验都记下来，整理到这里来。呵呵，好记性，还是不如烂笔头的～