一程序员在阿里HBase团队的所感所悟

2 评论 35397 浏览 1 收藏 17 分钟

“committer为开源社区的一个光荣和义务的职务。拥有对某项目拥有直接提交代码、代码审核与提交、投票否决代码、参加核心会议、决定项目未来走势、加入committer邮件列表等多个重要权利。”

“hadoop社区的committer主要来自于两个项目:hadoop以及hbase,几乎是清一色来自西8区(Bay Area)的同学,天梧同学的加入是第一个来自东8区的同学。”

赞赏总能让本人激动,熟人开心,生人好奇。进公司前,HR会和你说,“在阿里,你可以得到快速地成长”,我信了,也不乏有同学反应,“进了公司后,自己越长越着急了”。在日复一日的工作中,两年很短也很快,而回头想想,不论成败与否,未来如何,这段职业生命的开始之路,就是我人生中的第一桶金。

阿里很大,HBase团队很小,而我就停留在这个小小的团队里面,没有出奇的经历,没有精彩的故事,没有业务上的激情澎湃,也没有过人的牛逼之处,平淡的记录权当是对工作、对同事、对团队发展的回忆与总结。

11年4月从学校毕业后进入了淘宝,和不少应届同学相比,我很幸运地知道团队是做啥的,也和老板有过简单地交流,再加上杭州待了7年,从学校切换到公司很自然,自然得工作日会去学校吃个午饭。。。

入职后,幸运地搭上了HBase团队成立的班车,那时对于HBase的理解程度是“听过”。团队总共三个人,毕玄、竹庄、我。毕玄是我师兄,花名他起的,有一天若牛了都没机会让人猜猜花名来由!!我在很长一段时间后才知道他是淘宝的大牛,哈哈,又幸运了一把,让人羡慕的暗喜。。。牛人负责Carry,菜鸟负责辅助,所以尽管坐着第三把交椅,我也只能打打酱油,那个时候他们群里沟通的内容我是简单明了的不懂。毕玄和竹庄,两人性格相似,谦顺温和,感受不到啥牛气,团队也处于刚成立的调研测试期,没有太多的规矩要学(不像现在新同学进来的话,业务、环境、文档等需要熟悉的东西很多。。。),他们忙着测试、部署,我也不善于搭讪,所以就默默地干着领的活,谷歌+百度+编码,就是一天的工作内容。

我的第一份活是做监控系统,要求很低,毕玄说能看就行了,指标也已经放在百科上了。没有苛刻的用户,一个人做东西很美好,需求、设计、开发、测试、运维自己说了算,唯一的那么点遗憾就是和周围的人干着两个世界的活,还好有伟大的搜索引擎。最近也时常有人问我监控系统是怎么做的,简单地说就是在HBase代码中植入要监测的指标,将监控数据发送到Ganglia,后台另一进程从Gmond中拉取数据持久化存储,然后前端使用Highcharts进行数据绘图。为什么不直接用Ganglia,相信很多搞后端的同学都用过或用着。关于这个问题,第一,你想从监控系统中得到什么;第二,Ganglia能不能满足你的需求。

没多久,团队新来了两个实习生,之前就是研究HBase的,所以上手很快,做自动化测试和服务端计算方面的工作,话说其中的刘佳现在已经是新成立公司的CTO了。这个时候开始陆续上线了HBase最初的几个项目,像是数据魔方以及TT3,想想那时的工作真美好,专注在一块工作上,没有人找你,所以竹庄肯定很忙,而我虽然游离在团队核心工作之外,干着一个产品要干的活,但也不忘自己所在的庙,时常研究学习一下HBase的源码细节。

搞了一个月,监控系统第一版做好了,也给了个好评。这时,竹庄是主开发,毕玄要负责运营项目,也没有安排HBase方面的活给我,我就自我翻新,找到了一套好的绘图工具Highcharts+一套jqueryUI大大地改进了一下前端,后端进行了一些数据存储优化及运维优化,顺便又开发了一套HBase运维页面:实时统计展现系统的关键数据及常用管理操作,差不多可以转岗去前端工程师发展了。。。话说某次大团队开会的时候,老板剑英夸我能前端能后端,那是第一次工作上的喜悦,傻傻又天真的美好。。。

6月后,参加了新人培训百技、百淘,第一次听到了马总的名言,“今天是残酷的,明天是残酷的,后天是美好的,但是很多人都死在明天晚上”,“态度比能力重要,选择同样也比能力重要”。培训很美好:不用干活;培训很有意义:树立价值观,增强存在感;培训很愧疚:很多要做的工作落下了。

不久,团队加入了测试神秀和新的开发务挺、飞云,神秀的加入对整个Team以及个人都意义重大,话说“术业有专攻”,他帮我们构建了自动化测试系统,有了日常Hudson构建、详细的性能基准、严格的异常测试,值得赞叹的是他不仅仅是测试,和我们一起探讨问题、解决问题、code review。在这个Team,我们向着共同的目标,做着不同的分工。除了日常开发,飞云兼顾了Zookeeper的研究,而务挺之前从事Mysql、C方向的工作,落地了HBase跨机房容灾相关的工作。外部的竞争力可以给内部很大的凝聚力,我们依靠着开源这颗大树,容易想到马总的话,“今天,HBase在公司发展好、服务好,跟我们可能无关,但反之,那肯定是我们的责任”。

到了9月中,HBase也已经从半年前的零发展到了好几十个项目,团队的需求也越来越多,而我也开始改行了,重心投入到HBase的开发中,而这第一次与HBase的亲密接触是二级索引,这是一次不成功的接触。HBase本身不支持二级索引,一般都是由业务端自己维护索引表。HBase实现二级索引的难点是数据一致性,因为这需要分布式事务保证。当然我也没有去解决分布式事务而实现二级索引,经过讨论,采用了异步读取log,重放客户端行为的方式构建索引,这样可以不牺牲HBase良好的写入性能。最后开发完成了,自测性能也还行,但是没有上线,现在回头看看原因:1.异步索引对业务使用会有一定地变扭;2.修改了HBase的内核逻辑,不利于与社区同步更新;3.客户自己构建索引更灵活。当然,个人在这过程中收获还是不小的,而HBase的二级索引目前社区还是没有计划及进展,在今年的中国HADOOP大会上华为介绍的二级索引实现方案可能是迄今为止我见过最好的,没有实现分布式事务,却保证了原数据与索引数据的强一致性。如果这方案那时就出来了,或许HBase的一大需求现在解决已久,而现在这一需求实现在我们正在开发的新项目wasp中,随之还有SQL、事务特性。

到了10月中,随着异常测试的投入,HBase在稳定性、正确性方面似乎表现得十分脆弱,大量地issue宠幸给了我,这些case的定位及解决之于我都是对HBase的又一层理解。那段时间,我和神秀基本就扑在这些问题上,他主要通过log梳理流程,我主要通过代码找出疑迹,有些bug,几天几周才能触发一次,我们通过想象、推测、debug日志等手段加大bug重现的几率,也开发了一些有用的分析工具,这过程中很大的体会是:1.问题很可能发生在你忽略的代码处;2.概率性问题就是问题;3.原理->现象这是一个理解的过程,现象->原理,这是一个经验累积的过程。

随着对代码理解的加深,我开始尝试选择一个比较重要的patch,提交给开源社区。很幸运地是,社区committer TedYu很快review了issue及patch,提出了意见,反复修改review后,最终第7个版本合并到了社区Trunk中。成功的第一次总是让人兴奋,随着后来在社区提交patch的增多,也感受到了团队内提交patch与社区提交patch的明显不同点:1.团队中的patch更强调逻辑正确性,社区的patch更强调代码规范性、可读性,包括命名、注释、格式等;2.社区patch带单元测试是基本要求;4.社区patch,review很严格,你能从多人多方面获益。

进入2012年后,毕玄开始专职做T4去了,竹庄开始负责整个团队的运营与管理,而我则成为了HBase的主力开发,团队中也新加入了叔宝、天照、慕飒、济万、伏波、一苇,团队规模与业务规模相比1年前已经扩大了很多,内部分工也明确起来,济万、慕飒、伏波着手着NamenodeHA及实时化HDFS,叔宝着手HBase的权限认证、coprocessor研究及产品服务,天照从专职HIVE过来兼顾了Hadoop、HBase、Hive的开发,一苇成为了我们第二位测试。我们渐渐有了完善的版本发布体制,有了值班制度,有了完善的review及pre-commit机制。随之向我咨询的同学变多了,运维及DBA也爱找我了,而我想说的是服务是成长的另一途径,让我对HBase的理解更加全面与深刻,对不足与需求更加清晰。

HBase在公司的快速发展,当然这归功于毕玄、竹庄,促成了我在社区上的积极活跃,提交与合并的patch渐渐变多,也与很多committer,像是Stack、TedYu、ram、larsh等混了眼熟,经过在社区一段时间的交流后,慢慢地学会了如何英语解释、沟通代码上的琐碎细节,慢慢地明白了这个圈子中的短语、术语,慢慢地习惯了被质疑,不再害怕说错观点,而我也开始去质疑别人,在别人的issue上留下自己的声音,当然也给他们纠正过一些错误。记得有一段时间,华为公司的印度人committer Ram,经常会@我,问我有没有碰到过这个issue,或者在我的issue中让我帮看相似的issue。这是一段有意思的经历,和一群相同的人,在社区上讨论着共同的问题,分享着各自的理解,和大学期间水论坛的感觉很像。。。值得一提的是有一个issue,涉及到的事务很多,前前后后总共提交了10多个版本后才合并,原因是总有人能‘挑出刺’,最后结果是那个issue的comments中水了一大坨。

或许会有同学疑问,以后的绩效考核就定发文章、参加会议分享吧。这里我需要解释一下,也给各位工作在开源系统上的一个权衡的建议:1.问题及需求来源于、解决于实际工作本身;2.反馈于社区可以增强patch的健壮性,会有很多人帮你免费review,这是最主要的;3.与同业者的近距离交流能让人成长;4.扩大影响,增强团队的被认可度,维稳在公司的发展;5.适当的放弃,不要浪费口舌在无意义地争议上,所以我有很多patch提交了,但没有被合并。

进入2012下半年,HBase的稳定性与正确性已经可以得到有效保证,除了继续增强外,也开始进行了对HBase的优化工作,像是加快宕机恢复、多线程flush、动态compaction、group sync、lazy seek、coprocessor优化等,比较值得一提的是,从社区移植过来的group sync功能让写的极限TPS提升了100%,这个效果连作者自己都没在issue中提及,而我则是在一次社区代码浏览中意识到这个改动的作用,“Group sync”也是我们起的名字,在很久以后的一次私人邮件中,我向TedYu提及这个特性,他尚不知道。。。动态compaction则让运维人员对系统的控制更加游刃有余,多线程Flush进一步提升了写的性能等等。我们的HBase版本与社区版本保持同步的原则是:1.patch尽量提交给社区,减少同步社区版本时候的工作;2.社区发布大版本的时候,我们维护相应的分支,对于小版本则只选取有用的patch打到我们的版本上。

作为一个初级码农,在这一年的码农工作中,我对自己的一个总结是:1.写代码;2.看代码;3.写让人易懂的代码,而现在及很长一段时间内都会处在第三阶段。

在监控系统上,团队新来了专职的前端人员,重构了前端,添加了更加丰富的数据展现,而我也改进了后端,使得更加高效、可靠,依赖于监控之上的报警系统也有了,成为团队内外的常用系统,用于监控、报表、账单、趋势对比等。

到了10月份,我们启动了新项目Wasp(阿里megastore)的开发,而自己又在HBase上做两个比较大的改动,一个是在线Merge,另一个是HBase对于大内存的管理BucketCache,再加上日常事务,有这么一个月多在社区上一直做着潜水者。直到12月中,我将这两patch提交给社区后,Ram迅速地回应“So you are back with a bang”,真是令人怀念的开心哈。。。

在2012年的尾声,很荣幸地收到了Stack的committer邀请,这对个人及团队都是一次很大的认可与鼓舞,或许会有人关心如何成为committer的,这个是由社区的HBase项目委员会投票决定的,而推荐及候选我就不得而知了。

路还很长,祝愿我和我的伙伴们在新的一年继续乘风破浪,愿每一个同学都能在自己的目标上前进。。

岁月静好,学着变老,健康生活,绿色工作。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 😎

    来自河南 回复