本次分享來自中國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+物件儲存

• • 優勢

    • 檢索能力強

    • 支援儲存結構化資料

  • 劣勢

    • 實時性差，一次請求要查詢N次伺服器

    • 讀寫存在不一致問題

    • 不支援動態列

    • 運維複雜

• HBase MOB

• • 優勢

    • 實時查詢，延遲低

    • 讀寫強一致

    • 檢索能力強

    • 支援儲存結構化資料

    • 支援動態列

    • 支援水平擴充套件

    • 易於維護

• 各方案對比

4.總結與展望

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

後續發展包括：

• 整合OSS

  • 將冷資料歸檔到OSS，優化成本

• 提升MOB合併能力

  • 目前由Master執行，考慮改為分散式

• 獨立配置

  • MOB可以採用不同於主體表的壓縮，編碼，塊大小等配置

相關推薦