【51CTO專稿】隨着市場規模的擴大，產品與技術的發展，業務數據量越來越大，對海量數據的高效寫入和讀取變得越來越重要。 HBase 是一個分佈式的可擴展、非關係型開源數據庫。它很好地用 JAVA 實現了 Google 的 Bigtable 系統大部分特性，因此在數據量猛增的阿里巴巴非常受歡迎。本文中，阿里巴巴數據庫技術專家朱金清（穆公）給大家分享了阿里巴巴 HBase 性能優化及容災方面的經驗。
（阿里巴巴數據庫技術專家 朱金清）
以下是採訪實錄：
第一部分：阿里巴巴 HBase 集羣介紹
51CTO：朱老師您好！首先請您簡單地做一下自我介紹。
穆公：我是朱金清，在阿里的花名叫穆公，這個花名是我師兄取的，後來由於我們阿里武俠的花名都被取光了，只能取以前的皇帝的名字，我這個是以前的秦穆公，發音跟水工、電工、木工中的“木工”一樣。我主要是做數據庫相關的工作，來阿里巴巴之前，我在百度做MySQL 。2011年年初來阿里巴巴了，主要做 MySQL/ HBase 相關的。
51CTO：阿里巴巴 HBase 集羣的規模大概是什麼樣兒？
穆公：現在我們總共在線加離線是有上千臺的機器，相對來說我估計應該算是國內比較大的。據我所知，百度好像不怎麼用這個 HBase （早期的時候有用過），騰訊好像還沒怎麼聽過。我知道有用 HBase 可能有幾家：小米、360和新浪，大概是這樣。我們這邊單獨的最大的集羣在搜索，一個集羣有二三百臺左右。
51CTO：阿里巴巴這邊 HBase 主要是用在搜索這個領域？
穆公：搜索的集羣比較大，因爲全網的日誌我們要抓下來。不過很多場景都用到了，包括 kv 型行數據、append型的數據、日誌業務、還要所有的歷史數據，我們現在也都是放在 HBase 上。如果你是全部作爲備份分析的，那就放雲梯那兒，如果你要實時查詢數據，或者是要查詢歷史數據，比如說我們的以往的訂單，都可以用 HBase 。
51CTO： HBase 典型的應用場景有哪些？
穆公：主要有幾種：
1、對高吞吐的寫入有要求的；
2、日誌型的應用；
3、有全網的數據抓取的；
4、有消息類的；
5、分析類的（如離線分析用 HBase 也是很好的選擇，不過要跟在線分開）；
6、結構易變類的。
51CTO：阿里巴巴對 HBase 的改進和擴展主要在哪些方面？
穆公：比如我報告裏面說的容災方案 iback ，實現了跨機房容災和異常切換等。還有我們後端團隊也開發了 Replication 方案，然後在二級索引上我們的後端研發團隊也一起來做了一個二級索引的這個策略，這個二級索引現在在社區都還沒有怎麼用，以前好像就是聽華爲有一套二級索引，然後我們現在就是在這方面做，就相當於對它功能的一些完善。然後就是說 HBase 要走得更遠的話，那可能跨機房容災可能一定要做好，這一點我們也投入精力，現在看 Facebook 基本上也朝着這方面，基本上他們也是這麼做，所以我覺得我們方向應該是比較對的。
51CTO：你們這邊有借鑑 Facebook 的經驗嗎？
穆公：有， Facebook 在 HBase 上打的 Patch 也比較多，我們可以直接把Patch拿過來，可能有一些能用，有一些不能用，我們就根據自己公司的實際情況，進行改進。我們跟 Facebook 溝通還是比較多的，上上週我去美國跟他們一起交流了這個，收穫還是很多的。
當然就 Facebook 來說，它是一個SNS的應用，應用可能相對單一一點。淘寶阿里這邊，又有交易，又有買家、賣家，是一個多維度的，相對來說，需求比較複雜多樣化。 Facebook 比較好，它的應用和產品沒那麼複雜，把產品優化做到極致。在這方面，我們可能需要更多的學習一下。
51CTO：阿里巴巴的 HBase 跟 Facebook 的 HBase 主要的相同點和不同點分別是什麼？
穆公：相同點：我們對 HBase 做事上的風格比較類似，組織結構也都蠻像的，有開發的團隊，有運維團隊；
不同點：我們比 Facebook 多了一個角色，我們有設計評審，相當於有點DBA的角色在裏面，而 Facebook 可能是沒有太多這樣的。
阿里和 Facebook 都非常注重高可用和性能， Facebook 也在高可用上投入了很多的精力，阿里也如此。但是在性能上，阿里投入精力還可能不見得有那麼多，這一點上我們需要根據自己的情況來彌補。
第二部分：阿里巴巴 HBase 性能優化和容災經驗
51CTO：阿里是如何做好 HBase 性能優化的呢？
穆公：我覺得主要有幾部分，第一個就是說我們在一個業務上，因爲性能優化不是說你上線了之後去優化，這是一種優化。還有一種優化就是說上線之前，我就幫它決定好，這個東西可能用什麼樣的存儲更好，有可能比如說這個用了之後， HBase ，我們也注意了，以前可能不清楚 HBase 用了之後，可能性能還沒有多好，換了一個其他還更好，其實這主要是在於選型階段要做好。要確定好哪個是最合適的方案，這個我覺得是一個評審的優化，還有一個就是到底每一臺機器的性能的優化，每一臺機器性能優化，我們相當於算是上線之後的優化了，我們分爲兩個方面，一個就是有硬件的解決方案，我們現在也有上 SSD 這個硬件，然後來提高隨機讀的性能，因爲 HBase 隨機讀性能相對來說是比較一般的，而 MySQL 我覺得達不到那麼好。還有一個就是相當於我們在進程，在 HBase 這個代碼上面進行優化，比如說我們現在也有後端的研發團隊也有做了二級索引的方案，就是提高這個讀查詢的性能，然後在代碼上面做了一些。剛纔說了一個軟件一個硬件，現在我們也有軟硬件結合的方式，就是說這個代碼改了，然後用了 SSD 或者 FusionIO 這種硬件，然後讓它的讀取，就相當於查詢很好。
51CTO：有效地提高讀取的速度？
穆公：對，因爲 HBase 現在寫性能很好，它需要更多做的是讀的性能要做得更好，所以慢慢可能是相對來說一個性能優化的一個更主要的一個地方，可能在讀取上。
51CTO：在做 HBase 性能優化的時候，主要注意事項有哪些？
穆公：一個就是說可能你對代碼能不清楚的話，我們可能儘量建議簡單的需求不要直接通過進入代碼來搞定，如果說在外圍或者配置參數能搞定的話，直接外圍或者配置修改來搞定。因爲這樣的話，我可能升級代價也小，就是相當於如果能從外圍和配置搞定的，不從 HBase 底層就能搞定，我們建議在外面直接搞定。所以現在有一個優先級，如果必須得通過代碼改名，那就得這個代碼進來以Patch的形式，在不同的版本上都可以用，大概是這樣。性能優化還有一個就是說我們也希望說這個不是說什麼場景我都去優化，就是對通用的，比如說這個東西做了一點就能很多集羣都能提升，那這個產品我們更傾向通用問題的解決。
如果只是說對特殊產品的優化，我們可能會更傾向於推動應用一起來做優化，因爲不然的話，可能會造成成本壓力，我需要買那麼多機器來搞定一個業務，那就代價太大了，所以我們需要更通用的，這個東西解決的是一個共性的東西，這樣就比較好。
51CTO： HBase 在容災方面的一些經驗，您能否分享一下？
穆公： HBase 的容災，因爲從需要其實我們還沒有容災上線，因爲 HBase 如果你做一個離線分析，它其實不用管容災不容災，因爲離線一存一分鐘兩分鐘沒有問題。如果你要做一個在線存儲，它就對這個可用性，服務持續性要求就很高了，所以我就覺得如果你要把這個東西做好，你容災一定要做好，容災現在有幾種，內部可能國內我們現在有容災，因爲社區原來自帶的容災方案不好使，好像有一個限制是說儲備機器要一樣，這個不可能的，如果我這邊擴了兩臺，那邊也必須擴兩臺，代價太大了。所以後來我們用的時候，我們傾向於從外圍來做，就是要做容災的話，就像MySQL一樣，如果MySQL有一個自帶的Replication並不是容災，因爲容災還有數據一致性，然後服務切換之後，就是說數據同步這是一部分，就是說如果你一層切換之後，數據一致性顯得更重要，所以這個東西是從 HBase 內部做不好。所以我們現在有自己做了一個，還有 Facebook 他們也自己做，我們思路是一樣的，我們並不知道他們具體產品叫什麼，但是思路大概類似。
51CTO：在部署 HBase 時，哪個環節比較容易出故障？
穆公：因爲它是一個分佈式集羣，所以單點故障率會比較高，就是一臺機器一層，比如說一個分佈是有十臺機器，一臺機器掛了，這個是正常的，因爲它是一個分佈式，它能自己恢復，但是這中間需要時間。還有一個就是因爲 HBase 現在還是快速發展中，它代碼等等有一些 Bug ，這個肯定我們以前也都遇到過，來了一個 Bug 又出現問題，所以這樣就導致你需要去把這些方面都考慮到，所以就相對來說，這些都是需要我們去注意的一個地方。
51CTO：一般故障出現最多的情況是？
穆公：我們最多的情況還是單機的故障，因爲現在還算是比較穩定了，基本上如果我們用最新版，有可能會有問題，但是我們用相對穩定的版本，基本上還好，但是相對穩定的就有另外的問題，它可能性能並不是那麼佳，但是因爲集羣那麼多，又不可能說對每個集羣都做一個升級，升級代價也會比較大，我們傾向於說每年會推一個大版本，第二年之後就新的業務上來了，我們就用新的版本，原來有一些需求需要升級的話，我們就把它升級掉。
還有就是 HBase 現在因爲它的這個升級時間也稍微代價有點大，並不是說每個馬上就能升級，數據量也很大，然後一般現在在這個比如說我在升級過程中，有一些相應就會有波動，所以這些都需要導致我們不可能說所有的集羣一下都升級了，我一直對這些重點的，有一些可能我覺得再加一兩臺機器能搞定，我們就傾向於這種方式來，就是這樣，所以我覺得這個代價是在可控的，而且還相對來說，有一些時候往往用硬件能解決問題，它其實我覺得代價還算是比較小的，因爲這個集羣的升級，它其實牽動的能力，比如開發也要幫忙配合一起來做，其實耗費的整體也是非常大的。
第三部分：如何加入阿里巴巴 HBase 團隊？
51CTO： HBase 能否成爲NoSQL領域的領導者？您是怎麼看待這個問題的？
穆公：我覺得就目前來說，爲什麼我們選擇 HBase ？一方面我覺得它比較通用，它基於Hadoop之上，本身它就有一個先天的優勢，然後還有一個，它確實的寫入的性能還是很好的，讀取性能，你說現在說沒有那麼好，但是我覺得也還可以了，只不過說我們現在讀業務，要求做到更極致的時候，不可能說機器成倍的長，我們所以需要做一些優化。然後現在的使用接口提供，或者功能各個方面，都是很完善的，所以在NoSQL上，特別是你要說持久化的NoSQL，就是 HBase 它是NoSQL，同時也支持持久化，就是不是NoSQL那種緩存系統，支持可以持久化的NoSQL，我覺得現在主流的，比如說像 cassandra ，還有MongoDB也算NoSQL，MongoDB確實量上億了之後，基本上性能就不怎麼樣了， cassandra 之前有說，我覺得 cassandra 跟 HBase ，可能目前還是會是NoSQL裏面，可能更大的兩個。但是 cassandra 之前也說了，它有不同的特性，它可能對一致性做得不好，但是它對可靠性要做得好，所以這個需要權衡。有可能像我們阿里三淘的業務等等，可能一致性就很高了，可能有一些比如說我說是其他一些離線分析或者等等這些，它可能延遲那麼一點點也沒有問題，我覺得這種用 cassandra 也是很好的，我這次去國外一看，他們也有一些東西，還用的 cassandra ，對在線服務的一致性要求不高， cassandra 還是用得很好的。
現在就是說 Facebook 自己不用 cassandra ，這也說明釋放出了一個信號，可能說這個東西可以用，但是可能它相比較來說， HBase 更好一些，因爲社區也更活躍，就是 HBase 現在還一直在發展，但是 cassandra 現在版本迭得很慢了，之前我看的是0.8還是多少，現在可能版本就沒有迭得那麼快，因爲開發 cassandra 的 Facebook ，他現在不怎麼用這個東西， HBase 現在社區還是非常活躍的，然後去國外看的時候，Twitter也在用， Facebook 更不用說了， Facebook 應該是國外我估計用這個最大的，我們應該可能算是國內最大的，目前我還是不知道有哪個公司用得比我們更大，單說機器應該沒有，然後容量等等之類的，然後 ebay 也有用 HBase ，ebay 好像搜索也是用 HBase ，然後 Twitter 具體我還真不知道，它那些消息還是什麼，我不知道它具體存在哪裏，但是 Twitter 他們說最近很緊急的需要招人， HBase 這方面也要招人，重點說了這兩塊，所以基本上就是 HBase ，我覺得前景還是非常好的，基本上我覺得還是可以在近幾年還是會是最核心的一個 NoSQL ，我覺得近幾年應該是這樣，可能多年之後，會不會有一個新的 NoSQL 浪潮衝擊一下，那也是有可能的。
就目前而言， HBase 應該是在 NoSQL 裏面發展前景比較好的，我也比較看好它。
51CTO：如果想加入阿里 HBase 這個團隊，需要具備哪些方面的素質，或者技術要領？
穆公：其實我們很缺 HBase 這方面的人才，如果大家有什麼問題，可以私下聊，也可以聯繫我，我們現在這個要求說高也蠻高的。
如果應屆生其實也還好，但是社招的話，我們一般要求就是說要有至少三年以上JAVA的一些開發能力，我們覺得這邊做下來，可能更多的是開發的工作，運維也需要開發東西來做，所以我關注的是以開發來解決 HBase 這個整體運維或者大規模雲計算，都是以開發來解決這個問題，所以我覺得我更看重 JAVA 一些開發能力，如果有 Hadoop 的一些基礎，就是最好了。然後對網絡 TCP 協議之類的，要有一定的理解，網絡資源 RPC 的調用，還有其他就是最好也能寫一些腳本這樣子，要處理一些運維的事情。但是我覺得更關鍵的是好學，學習能力強，這個相對而言可能還更重要，如果 Hadoop 基礎你沒有，你夠聰明也沒有問題。
其次人比較踏實，有技術追求，我覺得就可以了，應屆生應該主要以這種爲主，因爲應屆生他可能不見得會有Hadoop跟 HBase 的經驗，但是我覺得它只要有JAVA的開發能力，然後自己有這方面的追求，我們阿里可以培養，歡迎這樣的優秀的應屆畢業生加入我們。
好的，專訪到此告一段落，非常感謝穆公的分享。