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

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

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