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

內容來源：2018 年 09 月 01 日，阿里雲技術專家郭澤暉在“中國HBase技術社群第3屆 MeetUp 杭州站 ——HBase應用實踐專場”進行《雲上HBase冷熱分離實踐》的演講分享。IT 大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。

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

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

摘要

一般冷資料的定義是訪問的比較少，且訪問頻次會隨著時間的流逝而減少的資料，比如監控的資料、線上臺賬資料，如果在業務上出現問題，我們檢視的肯定是最近一段時間的資料，而不會檢視諸如半年前的監控資料。

而我們這邊對冷資料的定義，根據時間成本來估算的話，大概是平均每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本身的KV功能以外，我們還架設了一些其他的開源元件。最底下的儲存層上，目前我們的應用資料場景主要有兩塊，一般的資料是放在雲盤，冷資料放在OSS。

下面介紹一下基於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的底層儲存的形式，其實現在的Hadoop 社群已經實現了一個叫NativeFileSystem的類，它繼承至FileSystem，我們可以把FileSystem的實現類在配置裡邊替換掉，這樣資料讀寫就可以直接轉發到OSS上。

不過由於NativeFileSystem是針對mapReduce這樣的離線作業產品實現的，所以在模擬檔案系統過程中會有幾個問題。前面說過OSS實際上是一個物件儲存，沒有檔案系統的結構的。

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

對於該問題雲HBase的解決方案是，自己實現了一個OSSFileSystem，它能避免剛才說的原子的問題。具體的實現上，我們是把雲資料的管理放在HDFS上，HBase呼叫FileSystem的API時候，呼叫的其實是我們實現ApsaraDistnbutedFileSystem，由它來控制檔案是放在HDFS裡還是OSS上。HLog依然是完全放在HDFS上，主要是考慮寫入效能。

雲資料操作通過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限制會適當動態放寬，順序讀寫流量不做限制。

以上為今天的分享內容，謝謝大家！