共计 1195 个字符，预计需要花费 3 分钟才能阅读完成。
首先要答复一个问题，为何要应用 HBase？
随着业务一直倒退、数据量一直增大，MySQL 数据库存在这些问题：
- MySQL 反对的数据量为 TB 级，不能始终保留历史数据。而 HBase 反对的数据量为 PB 级，适宜存储长远的历史冷数据
- 新增列的代价较高，数据量越大消耗工夫越长。而 HBase 能够随便减少列，空列不占据空间，业务模型能够灵便变动
要应用 HBase，最重要的一点是 rowkey 行键设计，如果设计不妥，后续要改的代价十分大。
HBase 行键设计准则
上面列几个 HBase rowkey 设计的准则：
- 组合键 ：组合键是指拼接多个业务字段，如需查问，则业务字段必须作为 rowKey 的一部分
- 字段程序 ：一对多，则一应该放在后面，以便可能 scan 失去后果，如用户 id: 订单 id，如果反过来则无奈失去用户下的所有订单
- 业务字段对齐长度 ：因为 rowKey 是按字典序排列的，所以须要对齐长度，比方 id 取 12 位，9 位 id 前补齐 3 个 0，否则就会呈现 123456789 比 654321 比排在后面的问题。对齐长度后，000000654321 排在 000123456789 之前，合乎预期
- 打散以防止热点 ：id 与工夫无关，随工夫递增，如果不做解决可能导致局部节点有读写热点，加上前缀能够打散，如取 业务 id 的后几位 % region 个数 作为 rowKey 的前缀
HBase 利用举例
冷热数据拆散
- HBase 适宜作为冷数据存储，存储和查问海量历史数据
- MySQL 适宜作为热存储存储，反对数据读写、事务操作
- 归档近期未更新的历史数据，新增数据至 HBase，再删除 MySQL 记录
流水记录
- 流水记录可随时新增字段
- 适宜存储海量流水记录
简要回顾 HBase 架构
- region：所有行按 rowkey 字典序排列，region 是其中一部分，相当于分片，每个 region 只能在一个 region server 上
- region server：能够蕴含一到多个 region，调用 HDFS 的客户端接口对 region 所有数据进行读写操作
- WAL：预写日志，WAL 是 Write-Ahead Log 的缩写。事后写入，WAL 是一个保险机制，数据在写到 Memstore 之前，先被写到 WAL 了。这样当故障复原的时候能够从 WAL 中复原数据
- store：一个列族对应一个 store，因而为了进步性能，不倡议应用超过 2 个列族。一个 store 蕴含一个 memstore 和多个 HFile
- memstore：数据写入 WAL 之后就会被放入 memstore，次要用于在内存中对行做排序，排序实现后再写入 HFile
- HFile：数据的存储实体，memstore 写满后就会写入 HFile
- region 主动分片（split）、合并（merge）：region 大小达到阈值后，会主动分区，反之会做合并 region 的操作
- HFile 合并（compaction）：删除数据后会导致 HFile 变小，须要合并以缩小 HFile 的数量，即缩小碎片文件数量，进步寻址效率
正文完
