? ? ? ? 之前一直在数仓中使用Hbase，但是具体都是不甚了了，现在专门记下来，用来还之前的债
目录
Hbase读写流程
? ? ? ? 读流程
?1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。
5） 将从文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache。
6）将合并后的最终结果返回给客户端
????????写流程
1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。
并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）将数据顺序写入（追加）到 WAL；
5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；
6）向客户端发送 ack；
7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。?
标红的就是和读流程不一样的地方
Rowkey设计原则
rowkey唯一原则
????????同一表插入相同RowKey，则原先的数据会被覆盖掉;并且rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，可以充分利用这个排序的特点，将经常读取的数据存储到一块
rowkey长度原则
?????????以byte[] 形式保存，实际应用中一般为10-100bytes，建议越短越好，不要超过16个字节（目前操作系统都是64位系统，内存8字节对齐，控制在16个字节，8字节的整数倍利用了操作系统的最佳特性）
rowkey散列原则
????????将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡，就不会造成热点问题
????????哈希
????????直接将低位的时间戳信息换为hash值，这样会导致每次扫描的时候会扫描全表，但是有点也一样明显，即够散列，是一种解决热点问题的优秀的分布策略
????????加盐
????????假设你在读取的时候知道时间范围，但是不想做全表扫描；这时候如果使用散列方式是个极其低效的行为，这个时候我们就可以直接在时间戳上加一个相应的随机数前缀，之后会根据随机生成的前缀分部到各个region上
????????反转
????????针对固定长度的Rowkey反转后存储，这样就可以使经常改变的部分放在最前面，可以有效的随机Rowkey，例如手机号等