成為HBase Committer後

在和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的想法依然是沒變的。雖然還沒有很清晰的路線,但也算時刻準備著。

微信公眾號地址: 成為HBase Committer後

微博地址:Sina Visitor System

推薦閱讀:

分散式系統理論 - 從放棄到入門
CAP 理論常被解釋為一種「三選二」定律,這是否是一種誤解?
zhh-2015在分散式系統和資料庫領域研究水平和工程能力怎樣?
大數據計算框架除了 MapReduce 還有哪些呢,不應該是 MapReduce 去解決所有問題吧?
到現在為止,NoSQL運動給資料庫系統留下什麼寶貴的思想?

TAG:HBase | 分布式数据库 | 分布式系统 |