在和HBase社区打了快一年交道后，我成为了HBase项目的第55个committer，国内第10个。
在当年的一个知乎回答《zhh-2015在分布式系统和数据库领域研究水平和工程能力怎样？》中，我曾经讲过，分布式数据库这个圈子其实不大，外面的人作为用户经常接触，但实际上在圈子里搞这个的人不多。在这种情况下，想判断一个搞分布式数据库的人是否牛逼，主要是看“同行怎么认”，也就类似于学术界的同行评审。对开源的数据库来说，如果能贡献代码说明略懂乃至比较懂，能持续贡献代码并被社区认可成为committer说明非常懂。而现在，PMC已经决定啦，你来当committer。所以，我现在属于HBase官方钦定的懂HBase的人了。当然了，开源的不开源的分布式数据库还有很多，尤其是在大公司。所以，虽然比我更懂HBase的不多，但整个分布式数据库领域，至少在现在国内比我牛的人还是很多的，我也有很多需要接着学习的。
之前在一些文章中也提到，其实我刚毕业的时候并不懂分布式数据库，作为一个做业务的服务端码农只是一个数据库的用户，用的是有道根据Google的论文自己造的轮子。后来infra组散伙了，那个轮子没人维护了，我自告奋勇+组织钦点去接触开源的替代品，加上也调研了redis cluster，在那个时候才开始真正接触分布式数据库甚至分布式系统，到现在大概不到三年吧。当时我选的是Cassandra，积累了一些Cassandra的经验。在这个Tag里可以看到我博客里写过的C*相关的文章，可惜我想写的“Cassandra系列文章”只写了几篇就烂尾了……总之这次转型不仅非常符合最初的设想，目前来看也非常成功。当然第一年全职做业务+第二年还留了一半时间做业务我也并不觉得是浪费时间，积累了很多和PM撕逼、成功说服PM改需求甚至砍需求的经验，而且站在业务的角度其实对知识储备广度的扩展也挺重要，能了解单纯infrastructure码农了解不到的东西。比如和客户端、前端打交道的话可以了解各种对应工种的常识。如果爱这行的话，还是愿意多接触一些东西的。当年有段时间有道词典ios的码农比较忙，我发现了一个bug后看他们没时间搞，就自己弄了个xcode看了看代码，然后自己把bug给改了，虽然我不懂ios开发，但有道词典的客户端里也有我的两行代码，还是挺开心的……何况即使是单纯为了工作，有做业务的经验也可以更好的搞infra为业务服务。后来在豌豆荚干了将近一年，开始全职做infra，但也没接触HBase。在末端快离职的时候才在业余时间接触HBase，看看代码，有不懂就就问当时的Committe、现在的PMC，虽然没在社区提过patch但偶尔有些issue也提供了一些想法和思路。所以在开头才说是“打了快一年交道”，真正开始给社区提patch已经是今年2月入职小米之后了。
就像我前几天在知乎回答《如何评价小米团队拥有4个hbase committer?》的一样，做分布式数据库，很大程度上最终都会去大公司。因为大公司对它要求更高，有更多工作可以做，同时也需要足够强的人来做（愿意出的钱自然更多）。小公司可能需要牛逼的PM/做业务的码农，但不一定需要那么强的基础架构的储备，即使储备了可能也是超前的，导致码农有时候是找事做而不是被事情赶着做。何况现在还有云服务，小公司对infra的需求更少，反过来infra工程师能去的公司也更少。所以这次换工作也算没太犹豫就选择了小米。来了之后发现，小米对HBase的使用确实很深入，在过去若干committer和其他同事的工作下已经比较成熟，但依然还有很多事情需要做。同时随着对HBase了解的深入，也发现HBase可以做的事情挺多，我自己是想了好多可以做的idea但根本做不过来。毕竟HBase在去年才刚刚发布1.0而已。当然，这些事情其实都是各种优化，设计上甚至实现上的优化。很多人其实不喜欢搞工程优化，更想去一个全新的项目从头造轮子。我自己倒是更倾向于实用，有现成的就不要造轮子。所以我在小米这大半年干的还是挺开心的。
前段时间我去PingCAP做交流的时候，提出过一个我的个人观点——分布式数据库本质上需要解决的只有俩问题：不丢数据；在不丢数据的前提下做到尽可能的可用。不丢数据自然是大前提，其他的问题其实都是可用的问题。这里的可用是站在用户也就是业务方的角度讲，而非我们平时说的可用性。比如功能上不支持XX对用户来说就是不可用；性能上用户关注“当前这些机器能不能抗住这些流量”，用户不一定在乎要多少机器，而在乎能不能抗住，抗不住就是不可用；延迟上是“用户期待的时间内能不能按时返回”，超时等于不可用，不超时但一直很慢也可能属于不可用。提升性能降低延迟都是为了提高用户眼里的可用，顺带着也为了能让单机抗住更多请求进而更省钱。所以我现在想做的事情其实都是围绕小米各种业务目前遇到的一些关于可用的问题，去着手改进。
Apache基金会的顶级项目很多，当前还活跃/有广泛使用者的明星项目其实不多。总体来说ASF提供了一种社区运营的流程。这个流程的核心是PMC（Project Management Committee）和committer的两种角色，其中前者是后者的子集，拥有更高的权力。Committer有git的权限可以直接提交代码，通常也有权review别人的代码决定是否可以commit，而PMC在拥有committer全部权力之外还可以投票决定是否可以发版本、并可以投票选新的PMC和committer。所以大家基本都是先当committer，而后如果依然能对社区持续做出很大贡献就有可能最终变成PMC成员。Apache之外很多开源项目一般并没有很系统的社区运营流程，更没有PMC和committer的角色。对应的很多无法进入社区核心的人无论改个typo还是贡献很多都只能叫“contributor”，我个人觉得在调动贡献者积极性这块是不如Apache的项目的，同时无法进入PMC之类的核心层也意味着无法获得任何话语权，这在某个公司主导的项目上很常见。无法获取话语权也就意味着其他大公司可能不敢用，除非能有随时fork的能力才敢上，或者这个项目太牛逼了以至于不用也不行。之前关于TensorFlow和MXNet的选择、关于中立性的探讨，其实就是这个原因。开源本身并不意味着中立，开放而中立的社区机制才能真正的让一个开源项目中立。至于中立对项目本身是好是坏，就是另一个话题了。一般来说，越是牛逼的项目或者牛逼的公司推进的项目越不需要中立。“中立”和“开源”一样，都是一种推广的策略，没啥高下之分。
因为官方钦定我“懂HBase”，从我个人利益的角度讲，用HBase的公司越多我自然身价越高。甚至某种程度上HBase火不火可能比小米卖多少手机更影响我的身价。所以无论从自身利益还是从对技术的喜爱，我都愿意在国内乃至全球推广HBase，欢迎业界多多交流。被选为committer后也算有种责任在里面，除了自己写代码外要多参与社区的讨论、多review别人的代码，“投好庄严一票”……之前我在微博中也说过，无论出于什么目的，想贡献代码给开源社区的人总是非常多的，如果利用的好是一股非常强大的力量。很多公司的开源项目都期望着外面的人来贡献，但效果通常一般，而HBase因为用的公司多、参与开发的公司也多、流程更规范，所以改善HBase要容易一些。如果各个公司的HBase工程师有这个想法，或起码对HBase在“可用”这个问题上有需求，又不知道从何着手的话，可以联系我然后看是如何把问题提交到社区甚至最终把“答案”提交给社区。
HBase在目前主要维护的1.1、1.2版本，之后会相继迎来1.3、1.4，而现在的master分支会发下一个大版本2.0。2.0在“可用”和性能上是非常值得期待的，尤其是终于支持各种offheap了，从而尽可能降低Java的GC带来的影响。目前读取路径上的offheap工作已经基本完成，阿里把这个特性移植到了自己的分支，效果很好，并且有可能移植到社区的1.4中。等2.0的写入路径offheap也搞定，加上AsyncWAL+FanOutOutputStream，整个性能会提升很大。虽然BigTable的设计有一定的缺陷（新的强一致性数据库几乎无一例外用raft/paxos+rocksdb等本地引擎的架构），但作为目前来说开源的强一致性分布式数据库中最成熟的一个，HBase在长期都会是很好的选择，尤其是和Hadoop的生态系统结合也非常紧密。即使我在没当committer的时候，甚至在我还不是HBase contributor而只是Cassandra contributor的时候我也说过，在国内，如果纠结用HBase还是Cassandra，那就还是用HBase。一个是强一致性，一个是国内用的人多、中文资料多、招人容易。
同样是committer，国内第一个committer和第十个committer的含金量是不一样的。而committer越来越多之后，老committer毕竟远远没有退休，所以这个title带给我们每个人的价值是在持续贬值的。类似于每年都有新大学生毕业，即使不考虑扩招，“大学生”或者“XX大学学生”这个title也自然越来越不值钱，以至于确实有的人高考是人生巅峰。而我也需要进一步努力学更多的东西、做更多的事情，在业界获得更多的名望、title、地位，避免当committer这一刻成为我的人生巅峰。一些committer的做法是转型做别的，比如升官做管理或转去做其他项目，至少短期内我倒是没这些想法，还是想把HBase接着做好。毕竟眼看着可以改进的地方太多，亲自改进或参与改进都是非常好的提升，尤其是参与改进更容易了解思考的过程，而单纯看已经完成的代码会忽略过程。
最后，想当CEO而非CTO的想法依然是没变的。虽然还没有很清晰的路线，但也算时刻准备着。
发表回复