阿里雲在HBase冷熱分離的實踐

內容來源：2018 年 09 月 01 日，阿里雲技術專家郭澤暉在「中國HBase技術社區第3屆 MeetUp 杭州站 ——HBase應用實踐專場」進行《雲上HBase冷熱分離實踐》的演講分享。IT 大咖說做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：3825 | 10分鐘閱讀

觀看嘉賓完整演講視頻及PPT，請點擊：t.cn/ELx5wUX

摘要

本次演講主要分享的是在雲端怎麼樣作一個HBase的產品，首先會介紹一下冷數據的典型場景，以及HBase在雲端的一個實現方案。

典型數據場景

通常冷數據的定義是訪問的比較少，且訪問頻次會隨着時間的流逝而減小的數據，好比監控的數據、線上臺帳數據，若是在業務上出現問題，咱們查看的確定是最近一段時間的數據，而不會查看諸如半年前的監控數據。

而咱們這邊對冷數據的定義，根據時間成原本估算的話，大概是平均每GB數據月度訪問不超過10萬次這個層次的數據。同時對成本敏感的數據也能夠作冷熱分離。

傳統方案

若是是傳統的開源的HBase要作冷熱分離，方案只能是搞兩個集羣，一個集羣是SSD的配置，負責在線查詢，另外一個集羣是機械盤HDD的配置。 這兩張表之間須要手動進行同步，而且客戶端須要感知兩個集羣的配置。

這樣作的優勢就是不須要改HBase代碼，缺點也很明顯，要同時維護兩個集羣，開銷確定是比較大的，並且對於冷集羣來講，若是查的比較少，集羣上cpu資源浪費也會比較多。

在2.0的HBase的版本中新加入了一個特性，能夠指定表的HDFS存在哪一種介質上。這利用了HDFS的分級存儲功能，HDFS的分級存儲功能，能夠將DataNode配置到不一樣介質的盤。好比上圖中有三塊是機械盤一塊SSD，在表上能夠設置這樣的策略，指定表的HDFS是寫在冷介質仍是熱介質上，最後調到HDFS接口的時候，會根據設置的文件的屬性放置數據。

這樣2.0的HBASE就能夠作到在一個集羣內既有冷表也有熱表，相對來講比1.x版本更好管理。固然它也有一個缺點，由於要根據業務配比集羣的硬件配置，若是集羣上混合了比較多的業務，或未來業務的場景有了一些變化，集羣的硬件配置是很難調整的。

雲HBase雲端方案

因此咱們雲端的方案，將會是一個比較彈性的方案。在介紹雲端的冷存儲方案以前，我先大概介紹一下咱們雲HBase，它是一個存儲計算分離徹底的架構。

因爲HBase部署的節點訪問磁盤都是遠程讀的，所以咱們能作到動態調整磁盤大小，作到徹底彈性。這裏面還有一個多模式，在雲HBase上除開HBase自己的KV功能之外，咱們還架設了一些其餘的開源組件。最底下的存儲層上，目前咱們的應用數據場景主要有兩塊，通常的數據是放在雲盤，冷數據放在OSS。

基於OSS的HBase冷存儲

下面介紹一下基於OSS怎麼作HBase冷存儲。前面提到過，咱們作的是一個徹底彈性的模式，因此咱們的冷存儲方案，其實並無配置磁盤，冷表的數據是直接放在OSS上，而且在同一個集羣內也能實現冷表和熱表。

可能有朋友不太瞭解OSS，這裏簡單介紹下。OSS是阿里雲的一款對象存儲產品，能夠理解爲也是一個KV存儲，它特色在於能生成很是大的對象，可達到TB級別。 同時還能保證9個9的數據可靠性，而且成本很是低。

成本優點

OSS的成本若是跟雲盤對比的話，雲盤大概是每GB每月0.7元，OSS則只要兩毛錢成本，相差了3.5倍的。

再舉一個具體的例子，和一個汽車企業相關，該企業大概有10萬輛車，每30秒會上傳一個7K的包，而且數據是基本上半年以後就不會訪問，這樣計算下來三年的數據量大約是2P左右，和OSS相比每月成本的開銷會差2.5倍，若是徹底採用雲盤架構大概是140萬左右，混合OSS加雲盤大概是60萬的成本。

基於OSS架設HBase的問題

對於在阿里雲上使用OSS做爲HBase的底層存儲的形式，其實如今的Hadoop 社區已經實現了一個叫NativeFileSystem的類，它繼承至FileSystem，咱們能夠把FileSystem的實現類在配置裏邊替換掉，這樣數據讀寫就能夠直接轉發到OSS上。

不過因爲NativeFileSystem是針對mapReduce這樣的離線做業產品實現的，因此在模擬文件系統過程當中會有幾個問題。前面說過OSS其實是一個對象存儲，沒有文件系統的結構的。

所以常規路徑中的反斜槓分割符並不表明目錄，只能表示對象名字中的字符。 而要模擬出目錄的效果的話，建立目標對象的同時，必須還要建立額外的對象才能模擬出目錄結構（如圖所示）。這樣的模擬存在一個問題，咱們對文件目錄操做實際上不是原子的，相似rename這種操做，若是中途crash，會出現不一致，沒法保證原子性。對於依賴目錄操做原子性的一些系統使用社區實踐，就會存在問題，最後會使得目錄或文件不一致。

對於該問題雲HBase的解決方案是，本身實現了一個OSSFileSystem，它能避免剛纔說的原子的問題。具體的實現上，咱們是把雲數據的管理放在HDFS上，HBase調用FileSystem的API時候，調用的實際上是咱們實現ApsaraDistnbutedFileSystem，由它來控制文件是放在HDFS裏仍是OSS上。HLog依然是徹底放在HDFS上，主要是考慮寫入性能。

雲HBase冷存架構

雲數據操做經過ApsaraFileSystem直接請求能用的進行操做，熱表的數據調用Hadoop的FileSystem，冷數據會在HDFS裏建立一個文件，這個文件有一個屬性的標記表示該數據是冷的，讀冷文件時候會把讀通道轉發到OSS上，而後構建一個OSS的input stream和OSS output stream。

社區版對比

除了架構上區別於社區版，保證HBase能正常使用外。咱們對性能也作了優化。架設在對象存儲上的實現會存在一些限制，第一請求是要收費的，第二Hadoop FileSystem是提供OutPutStream讓用戶輸入數據，而OSS SDK提供的是InputStream讓用戶輸入。這樣的話，要實現Hadoop FileSystem接口嫁接OSS，就必須作一個OutPutStream到InputStream的轉換。

對此社區版實現是這樣的，數據寫入到NativeOSSOutPutStream上的時候，實際會寫到磁盤上，在磁盤上會有buffer文件，當文件寫滿128兆的時候，會被包裝成FileInputStream提交給OSS的SDK，由一個異步線程池負責。

這樣的實現有幾個問題，首先寫入過程須要過磁盤，性能上有一些損耗。 其次會比較依賴於磁盤的性能，以及機型內存的大小，配置參數等因素影響。

理論環境下這個線程池能夠併發提交，若是寫入速度足夠快，一會兒就能在磁盤上產生，好比十個128兆的buffer文件，這樣線程池就至關於有十個線程將這10個buffer一塊兒提交，速度是能夠說是很快的。

可是這只是理論環境，正常HBase下來的數據最多隻有100多兆，並且也不可能有那個速度瞬間產生十個128兆個文件。因此實際社區設計的這套寫入流程，寫入行數不夠快的話，這個異步發送線程池會退化成一個單線程，就至關於一個文件只有一個線程在提交。

另一個問題在於crash的時候，會在磁盤上殘留一些文件，對運維來講仍是比較麻煩的。

雲Hbase的設計的OSSFileSystem，整個寫入過程是不會在磁盤上落地的，這中間有一個RingBuffer，大概有幾兆，用戶的寫入會到這裏。RingBuffer裏面是由固定數量的page組成，一個page差很少是兩兆，總共是有五個page。

寫入page以後，藍色區域至關於用戶寫好的page。綠色這塊有一個異步線程，每一個文件寫入會有一個獨立的異步線程，這個線程會把藍色寫好的page數據讀出來，而後包裝成InputStream。

每當InputStream被OSS的SDK讀完128兆的時候會return 一個EOF等於-1，至關於欺騙OSS，告訴它這個數據結束了，而後把這128兆數據提交一下，以後再有數據寫入，會再包裝一個新的InputStream。因此從成本上來講，雖然跟社區的方案同樣，都是128兆提交一次，可是咱們的寫入過程是徹底不須要落地磁盤的，而且佔的內存開銷也很是少。同時咱們考慮到了冷熱表混合的場景，buffer內存都是本身管理的，避免了YGC，並解決了元數據操做原子性的問題，而HBase剛好依賴於這樣的原子性來完成一些操做。

在雲HBase上使用這樣的特性，也很是簡單，在建表的時候，如上圖配置就能夠了。設置成冷以後，表的全部數據寫入都會存到OSS裏面。

冷存儲建議使用場景

對於冷存儲使用的場景，咱們的建議的是寫多讀少以及順序讀。若是持續get，咱們會限制冷存儲讀的IOPS，對於偶爾訪問，IOPS限制會適當動態放寬，順序讀寫流量不作限制。

以上爲今天的分享內容，謝謝你們！

編者：IT大咖說，轉載請標明版權和出處