hbase架构和表设计

架构

hbase存储原理

底层的存储是字节存储，按照字典排序，key-value格式存储：
key=ts+rowkey+cf+col，value=真正的值

物理模型

一个regionserver中管理多个region，region是负载均衡的最小单位
一个region里边有很多store，一个store对应一个列簇，但一般情况下只有一个store
一个store里边有一个memstore和多个storefile(对HFile(hadoop的二进制文件)的封装)
HFile和Hlog是HBase中两大文件存在格式，HFile用于存储数据，Hlog用于保证数据写入 HFile中。

表设计

rowkey的设计

1、业务原则
2、长度原则（开发人员建议是10-100bytes,但是最好不超过16bytes，最长为64k)
3、散列原则（避免热点问题）
补充：
对于单调递增的时间类型数据，很容易被散列到同一个Region中,这样它们会被存储在同一个服务器上,从而所有的访问和更新操作都会集中到这一台服务器上,从而在集群中形成一个hot spot,从而不能将集群的整体性能发挥出来。
4、唯一原则
场景：
hash_deviceId_createTime_type
根据deviceId获取gps所有的信息，和type信息
根据type，获取deviceId的全部信息

rowkey按照字典顺序排列

  原始         实际           预想
0       0              00
1       1       01
2       2       02
03      22      03
22      23      22
23      3       23
33      33          33

预分区

-》共有5个region
create ‘t1’, ‘f1’, SPLITS => [‘10’, ‘20’, ‘30’, ‘40’]
-》通过splits.txt进行预分区
create ‘t1’, ‘f1’, SPLITS_FILE => ‘splits.txt’
-》系统默认进行分区
create ‘t2’, ‘f1’, {NUMREGIONS => 15, SPLITALGO => ‘HexStringSplit’}
-》通过API进行进行分区
hbaseadmin.createTable(tablename,split[][])

读取数据三种方式

-》get：必须指明rowkey，查询最快的方式
-》scan：全局扫描，一般不用
只要不进行compact操作，对版本数进行整合的，之前的操作就不会丢失
-》scan+filter：最常用的方式

属性

解释：
BLOOMFILTER：布隆过滤器
VERSIONS：版本数
COMPRESSION：压缩
MIN_VERSIONS：最小版本数
TTL：存活时间
BLOCKSIZE：存储数据的block的大小，64K
IN_MEMORY：是否开启，作用是：有选择的column families放到RegionServer内存中，例如Meta元数据信息
BLOCKCACHE：是否开启缓存

BLOOMFILTER:布隆过滤器

row:行级，当查询数据时，检索storefile之前，判断这个storefile中是否有需要的 rowkey，如果没有，就查看另外一个storefile，查看所需要的rowkey
rowcol:行列级，是否有需要的rowkey+column
开启了以后，storefile中会存储一部分元数据，消耗一定的内存

blockcache块缓存

->IN_MEMORY (hbase的meta就在这里边存储的)
->BLOCKCACHE => ‘true’:不重要的列簇不要开启