HBase技術與應用實踐 | HBase2.0重新定義小對象實時存取

本次分享來自中國HBase技術社群第七屆MeetUp成都站，分享嘉賓天引 阿裡巴巴 技術專家專注在大資料領域，擁有多年分布式、高并發、大規模系統的研發與實踐經驗，先後參與HBase、Phoenix、Lindorm等産品的核心引擎研發，目前負責阿裡上萬節點的HBase As a Service的發展與落地。

分享主題：HBase2.0重新定義小對象實時存取

内容概要：小對象，特别指1K~10MB範圍的資料，比如圖檔，短視訊，文檔等廣泛的存在于人工智能，醫療，教育，生活分享，電子商務等領域。HBase2.0在MOB技術的加持下重新定義小對象實時存取，具有低延遲，讀寫強一緻，檢索能力強，水準易擴充等關鍵能力。本文介紹了MOB特性的原理與實作，以及與經典對象存儲相比，MOB帶來的差異性與優勢。

下載下傳連結：http://hbase.group/slides/167

參考連結：

HBase2.0重新定義小對象實時存取

1.背景介紹

HBase2.0加持MOB技術，支援小對象實時存取，具有讀寫強一緻，低延遲，高并發等特點，并相容所有企業級特性如Snapshot，Replication。

MOB問題背景諸如以下問題：

• IO放大：
  • 多副本
  • WAL
  • Flush
  • Compaction
• 資源限制
  • ECS 16核64G 5Gbps
  • 高效雲盤140MBps
  • ECS15個挂載點
• 寫入瓶頸
  • Compaction落後導緻檔案數上升，進而導緻flush延遲，進而導緻記憶體瓶頸，最終阻塞寫入；同時檔案數過多導緻查詢慢
  • 假設網絡IO放大系數=5，則實際可用帶寬為5Gbps / 8 / 5 = 128MB/s，對于1MB對象單機能提供的TPS=128

2.MOB原理與背景

解決思路：降低Compaction的頻率，一天或者一周做一次合并。

• 系統架構

• MOB合并政策
  • 分組合并
    • 按照檔案所屬分區以及日期兩個次元進行分區，分區内的檔案進行合并稱為：PartitionedMobCompactor
  • 預設每日合并
    • 按天分區，小于門檻值的檔案參與合并，門檻值預設為1028MB
  • 周月合并
    • 周合并，按周分區，目前周檔案小于門檻值的參與，其它周的檔案小于7*門檻值的參與
    • 月合并，按月分區，目前周不參與，本月周小于7*門檻值參與，其它月小于28*門檻值的參與
• MOB緩存
  • 檔案句柄緩存
    • hbase.mob.file.cache.size = 1000
    • LRU cache
  • MOB對象緩存
    • 複用BlockCache
• 使用方式
  • Shell通路
    • hbase> create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 102400} 
    • hbase> alter ‘t1’, {NAME => ‘f1’, IS_MOB => true, MOB_THRESHOLD => 102400} 
  • Java API

    • HColumnDescriptor hcd = new HColumnDescriptor(“f”);

      hcd.setMobEnabled(true);

      hcd.setMobThreshold(102400L);

3.MOB VS. 傳統對象存儲

• 回顧對象存儲
  • 模型
    • KV 結構
    • 一組KV組成的集合成為Bucket
    • 缺少靈活性
  • API
    • 支援字首掃描，擷取符合條件的Keys
    • 通過Key擷取對象
    • 檢索能力弱
  • 通路協定
    • REST
    • 簡潔，語言無關
    • 消耗更多的連結和網絡帶寬
  • 計費模式
    • 按請求次數計費
    • 請求頻率越高成本越高
    • Bug可能引發計費災難
• 雲HBase與對象存儲對比

• 從一條SQL開始

  • 使用者表T：包含三個屬性S1、S2、S3

    屬性的大小為50bytes左右，包含一個對象資料Object從100KB~10MB

    S1

    S2

    S3

    Object

    查詢 select Object from T where S1 = xxx and S2 > yyy and S3 < zzz
• 對象存儲方案
  • 設計邏輯表為：S1+S2+S3 => Object，将S1、S2、S3組合成一個key

• • 優勢
    • 讀寫強一緻
    • 支援水準擴充
  • 劣勢
    • 實時性差，一次請求要查詢N次伺服器
    • 檢索能力不足，僅支援key的字首檢索
    • 當屬性列增多，特别是動态增加的情況下，對象存儲很難支援(key會變得非常複雜)
• MySQL+對象存儲

• • • 檢索能力強
    • 支援存儲結構化資料
  • • 讀寫存在不一緻問題
    • 不支援動态列
    • 運維複雜
• HBase MOB

• • • 實時查詢，延遲低
    • 支援動态列
    • 易于維護
• 各方案對比

4.總結與展望

HBase2.0重新定義了小對象實時存取的業務通路方式，不再是索引+對象的多次查詢，提供簡潔的一體化解決方案。具有通路延遲低，讀寫強一緻，檢索能力強，水準易擴充等關鍵能力；并且具備動态列，多版本等靈活的功能；最後一體化的解決方案簡化了使用者端的代碼，也減少了服務端的運維成本。

後續發展包括：

• 整合OSS
  • 将冷資料歸檔到OSS，優化成本
• 提升MOB合并能力
  • 目前由Master執行，考慮改為分布式
• 獨立配置
  • MOB可以采用不同于主體表的壓縮，編碼，塊大小等配置

大家工作學習遇到HBase技術問題，把問題釋出到HBase技術社群論壇http://hbase.group，歡迎大家論壇上面提問留言讨論。想了解更多HBase技術關注HBase技術社群公衆号(微信号:hbasegroup)，非常歡迎大家積極投稿。

HBase技術交流社群 - 阿裡官方“HBase生态+Spark社群大群”點選加入：

https://dwz.cn/Fvqv066s