HBase摘抄内容

一、HBase的特点

高并发、稀疏型

二、HBase架构
底层是HDFS的DataNode。
HMaster集群、RegionServer。
ZK做服务器心跳检测。
HRegionServer实际上是一个进程，不实际存储数据，掌握的元数据。
包括HLOG、写数据先进入HLOG中。

一个表对应多个Region，一个Region仅对应一张表。
一个列镞对应多个Store，一个Store。合并仅合并一个列镞，多个不同的HFILE。不会针对不同列镞进行合并。
每个Store都有一个MemStore。

三、HBase写操作

1.client->发送请求到ZK集群，获取meta表所在RS，ZK集群返回meta表所在RS(1).
2.RS(1)获取meta表，返回meta表数据。
3.发送写入数据请求。数据先写入HLOG，再往MemStore内存中写入数据。写完内存数据之后
直接返回client写入成功。不会等数据真正写入HDFS。
4.meta表中存的是表的rowkey范围在具体某个regionServer上。
Hmaster挂掉，而Hbase仍然能够正常的读写。Hmaster负责数据的拆分。
5.
6.数据flush
在Hbase-default.xml中配置了数据flush的时间和大小。即数据从内存(MemStore)写入到磁盘中。

6.1 hbase.regionserver.global.memstore.size
regionServer的全局memstore大小，超过该大小会触发flush到磁盘的操作。默认是堆
大小的40%，而且regionserver级别的flush会堵塞客户端读写。

6.2 内存中的文件在自动刷新之前能够存活的最长时间。默认为1h
hbase.regionserver.optionalcacheflushinterval
即使内存大小没有达到(hbase.regionserver.global.memstore.size)，当数据时间超过
此参数的时间，仍然会进行数据的flush。
且当一个regionServer中的一个memSotre达到此时间，所有的memStore都会flush。

6.3 hbase.hregion.memstore.flush.size(128M)
单个region里的memstore的缓存大小，超过参数值则整个HRegion就会flush。默认为128M。

以上的Flush会产生小数据文件问题，HBase会对小文件进行合并。
hbase.hregion.majorcompaction.
一个region进行major compaction合并的周期，在这个点的时候，这个region下的所有
hfile会进行合并，默认为7天。major compaction非常耗资源，建议生产进行关闭，
在应用空闲时间进行手工触发。

hbase.hstore.compactionThreshold 
一个store里面允许存在的hfile个数，超过这个数会被写到一个hfile里面。
也即使每个region每个列族对应的memstore flush为hfile的时候，默认情况下当超过
3个hfile的时候就会合并重写为一个新文件，设置越大可以减少触发合并的时间。
但是每次合并的时间就会越长。
当合并文件的时候，对打了删除标记的数据进行删除。
--------------------------------------------------------------------------------------
HBASE优化
一、Hmaster高可用
Hmaster负责RegionServer的生命周期，均衡RegionServer的负载。不参与读写，发送数据的切分指令，合并等。


二、预分区
每一个Region维护着startRow和endRowKey，如果加入的数据符合某个region维护的rowKey范围，
则该数据交给这个region维护，那么依据这个原则，我们可以将数据说要投放的分区提前大致规划好，
以提高HBASE性能。
不采用预分区，Hbase的自身拆分策略会导致Region之间数据不均衡，存在数据倾斜的问题。
建议针对一张表，一个RegionServer放2-3个Region比较合适。

1.手动设定预分区
CREATE 'staff1','info','partition1',SPLITS=>['1000','2000','3000','4000']
2.生成16进制序列预分区(用的比较少)
CREATE 'staff2','info','partition2',{NUMREGIONS=>15,SPLITALGO=>'HexStringSplit'}
3.按照文件中设置的规则预分区
创建splits.txt文件内容如下：
aaaa
bbbb
cccc
dddd
然后执行
CREATE 'staff3','partition3',SPLITS_FILE=>'splits.txt'
4.使用JavaAPI创建预分区
//自定义算法，产生一系列Hash散列值存储在二维数组中
byte[][] splitKeys = 某个散列值函数
//创建HBaseAdmin示例
HBaseAdmin admin = new HBaseAdmin(HBaseConfiguration.CREATE());
//创建HTableDescriptor实例
HTableDescriptor tableDesc = new HtableDescriptor(tableName);
//通过HtableDescriptor实例和散列值二维数组创建带有预分区HBase表
hAdmin.createtable(tableDesc,splitKeys);


三、RowKey设计
一条数据的唯一标识就是rowkey，那么这条数据存储哪个分区，取决于rowkey处于哪个预分区的区间内，
涉及rowkey的主要目的，就是让数据均匀的分布于所有的region中，在一定程度防止数据倾斜。
rowkey最大为64k，一般70~100个字节就可以了。
1.生成随机数、hash、散列值。
比如1001 SHA1后变成xxxxxxxx。
2.字符串反转
比如20170524000001转成10000042507102
3.字符串拼接

rowkey键设置，若采用随机数，可以分布的比较均匀，但无法获取数据，最好采用数据的value值，采用mod或者hash
函数获取其值。

rowkey的设计主要四个原则：
唯一性
长度
散列(即均匀分布)
同时查询数据时，尽量保障数据处于一个region中，若跨region，则性能较差。


电信需求：统计某个人(具体电话号)每年，每月，每天的通话记录、包括通话时长、通话次数。
rowkey
预分区键：01,02,03,04,05。
定位到月，一个客户号一个月的数据存放在一个region中。
rowkey设计：mod(hash(手机号_年月),5)_手机号_年月日_时间戳
保证相同的手机号、相同年月处于同一个region中。

四、内存基础优化
HBase操作过程中需要大量的内存开销，毕竟Table是可以缓存在内存中的，一般分配整个可用内存的70%给
HBase的Java堆。但不建议分配非常大的堆内存，因为GC过程持续太久会导致RegionServer处于长期不可用状态，
一般16~48G内存就可以了。如果因为框架占用内存过高导致内存不足，框架一样被系统服务拖死。
基础优化
1.允许在HDFS的文件中追加内容。
2.优化DataNode允许的最大文件打开数
3.优化延迟高的数据操作的等待时间
4.优化数据的写入效率
5.设置RPC监听数量
6.优化HStore文件大小
7.优化hbase客户端缓存。
8.指定scan.next扫描HBase所获取的行数。