这是我参与「第四届青训营 」笔记创作活动的第14天
本次笔记重点内容
- 介绍 HBase 的适用场景和数据模型
- 分析 HBase 的整体架构和模块设计
- 大数据场景支撑
- 分享 HBase 大规模实战的最佳实践
HBase数据模型
HBase是基于HDFS实现存储计算分离架构的分布式表格存储服务，是一个开源的KV分布式数据库，但数据实际存储在HDFS。
逻辑结构
HBase以列族组织数据，以行键索引数据。列族需要在使用前先创建。既然HBase是KV的数据库，那么当然是以获取KEY的形式来获取到Value。
列族对应的值就是info和area，列对应的就是name、age、country和city，Row key对应的就是Row 1和Row 2，Cell对应的就是具体的值。
物理结构
最小单元是KeyValue架构
同列族内的KeyValue按rowkey字典序升序、column qualifier升序、version降序排列，不同列族的数据存储在相互独立的物理文件中，仅单个物理文件内有序。
在HBase中查找不同的CF的数据
在HBase中是以CF为单元的存储结构。
HBase使用场景
- “近在线”的海量分布式KV/宽表存储，数据量级达到百TB级以上
- 写密集型应用，高吞吐，可接受一定的时延抖动
- 需要按行顺序扫描的能力
- 接入Hadoop大数据生态
- 结构化、半结构化数据，可以经常新增/更新列属性
- 平滑的水平扩展
HBase 架构设计
HMaster
元数据管理，定期巡检元数据，感知有无其他组件出问题来注意调度确保整体无误，有多个待命，但只有一个在活跃；通过Zookeeper选主
RegionServer
提供数据读写服务，每个集群有多个
Zookeeper
分布式一致性共识协作管理，负责转发Client的请求和提供心跳机制，会让HRegion Server和HRegion注册进来，同时保存着Rowkey和Region的映射关系
ThriftServer
提供一层以Thrift协议访问数据的代理层
HBase的大数据支撑
水平扩展能力
增加RegionServer实例，分配部分region到新实例，数据还在原来的文件里面，可用性影响时间很短，用户基本无感知
region热点切分
当某个region数据量过多，会切分成两个独立的子region分摊负载，RegionServer检查region是否应该切分，优先均匀切分最大的数据文件，找出最大的cf，cf中哪个HFile的数据大小最大，找到其中最中间位置的data block，用这个data block的第一条KeyValue的Rowkey作为切分点，不搬迁实际数据，通过类似于指针的方式指引回原始未拆分的文件。
region碎片整合
当某些region数据量过小、碎片化，合并相邻的region整合优化数据分布
region负载均衡
定期巡检各RegionServer上的region数量，保持region均匀分布在各个RegionServer上
实践
rowkey设计
key在保证功能的前提下建议越短越好，因为key是冗余到每个cell存储的，过长的key会占用更多存储、缓存空间；避免以时间戳作rowkey前缀，否则一段时间的请求会全部集中在同一regionserver上，造成热点瓶颈。要充分利用排序存储这个特性，将经常一起读取的行存储到一起。
Column family设计
过多的Column family会影响HBase性能，建议不超过5个；需要同时读取的数据最好放在相同列族，读取时只读取必需的列族。
ByteTable——字节跳动自研替代HBase场景
采用C++编写，存储底座设计充分支持在线场景性能、功能需求，架构设计上更细粒度、更灵活的数据分片组织方式，激活更多优化空间，故障隔离性强，避免多租户相互影响，缩短了故障恢复时间。
