这是我参与「第四届青训营 」笔记创作活动的的第7天
HBASE架构设计
- HMaster：元数据管理，集群调度，保活
- 管理RegionServer的生命周期，保证服务可用性
- 协调RegionServer数据故障恢复
- 集中夫案例集群元数据，执行负载均衡等工作
- RegionServerL提供数据读写服务，每个实例负责若干个互不重叠的rowkey区间内的数据
- ThriftServer：提供Thrift API读写的代理层
- 提供rpc读写服务
- 依赖组件
- ZooKepper：HMaster登记信息，RegionServer登记信息，等级Meta表位置信息，工SDK查询读写位置信息，供HMaster和RegionServer协作
Region Split 热点切分
- ConstantSizeRegionSplitPolicy：0.94版本前默认切分策略。一个region中最大store的大小大于设置阈值之后触发切分。
- IncreasingToUpperBoundRegionSplitPolicy: 0.94版本~2.0版本默认切分策略。总体来看和ConstantSizeRegionSplitPolicy思路相同，一个region中最大store大小大于设置阈值就会触发切分。
- SteppingSplitPolicy: 2.0版本默认切分策略。如果region个数等于1，切分阈值为flush size * 2，否则为MaxRegionFileSize。
故障恢复机制
- Hmaster 自身恢复流程
- 故障恢复流程即从master实例从ZK监听到主master节点掉了，抢主成功后执行启动流程。
- RegionServer 故障恢复
- regionserver每次启动的startcode不同，都视为一个新的rs实例，因此走一遍启动流程。
最佳实践
rowkey设计
- 最大长度是64KB，实际应用中长度一般为 10 ~ 100bytes。key在保证功能的前提下建议越短越好，因为key是冗余到每个cell存储的，过长的key会占用更多存储、缓存空间。
- 设计Key时，要充分利用排序存储这个特性，将经常一起读取的行存储到一起。HBase以HFile文件块为单位从HDFS读取数据，一次性读出相邻相关数据可以达到随机读变成顺序读的效果。
但同时要防止出现热key聚焦打爆region server实例。（例如时间戳为key）
Column family数量
过多的cf会影响HBase性能，建议不超过3个。
value大小
建议不要超过1MB。过大的value会影响HBase读写性能。可以将实际value存储在其他对象存储系统，在HBase的value存储其位置信息。
Region数量
一个region的大小最好在10-50GB之间。
mapreduce的应用在低峰期运行
批处理任务建议在业务低峰期运行，并且需要对HBase的访问流量进行一定限制。
尽量复用client实例
新建client实例需要访问Zookeeper和元信息表所在regionserver，频繁操作有打垮服务的风险。
client参数调优
- nodelay设置true
- 读较多的应用中gc的新生代不能设置太小
- 数据版本尽可能少来增加有效缓存容量，提升命中率
- 避免一次scan过多的row，尽量拆分为多次小规模scan作分页查询
