HBase技术与应用实践 | HBase2.0重新定义小对象实时存取

• 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可以采用不同于主体表的压缩，编码，块大小等配置