1. 程式人生 > >一程式設計師在阿里HBase團隊的所感所悟

一程式設計師在阿里HBase團隊的所感所悟

“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專案委員會投票決定的,而推薦及候選我就不得而知了。

路還很長,祝願我和我的夥伴們在新的一年繼續乘風破浪,願每一個同學都能在自己的目標上前進。。

歲月靜好,學著變老,健康生活,綠色工作。