我会不间断的更新,维护,希望可以对正在找大数据工作的朋友们有所帮助.
第六章目录
第六章 HBASE
hbase是一个分布式、海量存储、快速响应的非关系型数据库
6.1 Hbase 原理
6.1.1 meta表和root表
0.96以下版本的三层架构
meta表的rowKey由表名、起始key、时间戳组成，如果起始key为空，则表示第一个region，按照起始key排序使得行键不需要终止key就能表示范围。
值则是终止Key、列族、列值，该RegionServer的地址等等。
meta表由于数据量过大可能被分割由多个RS存储，因此又设置了root表存放meta表中所有的region，以及该region所属的meta表的位置。
因此三层架构需要三次跳转才能获取到HRegion，如果缓存失效则需要6次，理论上三层架构最少都能存储2ZB的数据。
0.96以上版本的双层架构
三层架构使hbase最少存2ZB的数据，事实上根本用不到这么多，于是删除了root表，只使用meta表定位，meta表的一个region最多可以定位16TB的行键范围，假设一个行键范围包括10条数据，就已经是160TB了，假如一个region大于128M，则更多了，因此根本不需要root表。
6.1.2 写数据
- 客户端从zk中获取meta表位置，到对应regionServer上获取该表，或直接从缓存中读取该表。
- 客户端从meta表中获取要写的数据存放的region和所在的regionServer。
- 客户端给数据设置版本（默认当前时间），往该regionServer的hlog上写日志数据
客户端同时往该regionServer的memstore上写入数据，memstore溢写到磁盘，溢写的小文件达到阀值数量时会合并成一个storefileregion体积达到阀值时拆分成两个region
由Hmaster负责均衡负载，拆分规则为保留连续行键，根据前缀判断
写原子性
写操作必须保证Hlog和memstore都写入完成才会返回成功，而且使用读写行锁保证一次对行写入期间其它读写请求会阻塞等待。
6.1.3 读数据
- 客户端从zk中获取meta表位置，到对应regionServer上获取该表，或直接从缓存中读取该表。
- 客户端从meta表中获取行键所在的region位置
- 先从memstore读取，再从blockcache读取，最后才到hfile中查找，查找hfile前先用布隆过滤器筛选出可能存在该行键的hfile，从hfile读取到的数据会复制一份到blockcache中。
6.1.4 合并数据
min compact
文件数量达到一定阀值会触发min compact将多个storefile合并成一个，只是简单的合并，不会有数据的删除
major compact
默认7天执行一次，将多个storefile合并，会将过期的，超出版本数量的、标记为删除的数据都进行删除（一般要在系统空闲的时候去做，因为需要大量的磁盘IO），一般会设置手动执行
6.1.5 删数据
hbase可以指定行键的列版本、列、列族、整行进行删除。
删除不是立刻删掉，而是插入一条新的数据，将该行标记为删除。当执行major_compact时，会逐条遍历数据，将删除的数据真正地删除。
6.1.6 HMaster 作用
1.负责meta表的维护2.为hregionserver分配region，负载均衡重新分配region3.发现失效的regionserver时重新分配该节点上的region4.处理schema更新请求
6.1.7 HRegionServer作用
1.维护分配到的region，处理对这些region的IO请求2.负责切分达到阀值的region3.每个RegionServer各自保管自己的Hlog
6.2 HBASE 热点问题
6.2.1 原理
hbase在hdfs中的路径结构如下：名空间/表名/region名/列族名/文件名
从这个路径可以看出，每张表会被划分为多个region，实际上这些region会被平均分配到多个节点上，如果某个时间点有大量的请求都落在某个单一region上，则会加重该节点的负担，严重时甚至导致死机。
region将表按rowkey进行固定大小的划分，范围内的数据到达一个阀值就会生成一个新的region，因此hbase的热点问题也可以说是行键的热点问题。
6.2.2 解决方案
rowkey按照字典顺序从左到右逐字节排序，因此解决热点问题的方法就有三种：
- 加前缀：按照ASCII码一个前缀最多能有128种字节，可以根据业务需求限制随机范围，128种前缀对应128个节点随机分配，一般生产环境已经足够使用。
- hash变换：将行键按照固定规则进行转换，同一个行键会被转换为同一个哈希值，这样做可以避开业务行键常见的前缀大量相同的问题。
- 行键反转：反转行键使变化幅度最大的业务键尾做键首，对行键连续性要求不高时可以使用（反转后行键整个都变了，失去有序性）。
6.3 Hbase 高可用（宕机恢复）
HMaster通过zk保持对外单服务，HReigionServer则通过Hlog保证以外宕机时内存数据丢失恢复。
HRegionServer意外宕机时，HMaster首先把原本分配给该节点的region（存储在hdfs上的文件都会有备份）分配给其它节点，然后尝试读取宕机节点的Hlog，将数据写入region。
读取日志进行恢复的机制随版本不断变化，一开始是性能最低的LogSplitting机制，后来采用Distributed Log Splitting机制，最后是Distributed Log Replay机制。
6.4 Hbase 优化
6.4.1 行键
唯一原则、长度原则、散列原则
长度尽量小，因为列式存储导致每行都必带行键，控制在byte的整数倍，因为是二进制存储
行键连续性：hbase按照字典顺序将连续的行键存储在一个region中，因此应该将经常同批访问的数据放到一起，将不同批访问的热点数据分开来存储。
6.4.2 列族
长度尽量小，最好单字节。因为列式存储必带列族名
数量尽量少，控制在2个以内。因为hbase按region拆表，而region按列族把列拆成多个store，当region整体达到阀值时会拆分region，因此当两个列族数据大小差距悬殊时会导致数据量很小的列族数据也被迫参与拆分，该列族数据分散太多。最终查询该列族数据时，不得不请求多个region。
6.4.3 协处理器 Coprocessor
hbase0.92版本之后支持协处理器，可以为表埋钩子代码，当条件符合时自动触发钩子，大幅降低用户端的维护难度。
如：可以利用协处理器建立hbase的二级索引
创建一个类继承观察者类，重写其中的preput方法，在插入数据到本表前会先执行该方法，自定义地将数据插入到索引表。
打包上传到hdfs上，用hbase shell命令加载该协处理器到表中。
6.4.4 预分区
提前划分region，避免单节点region一次性写入大量数据频繁分裂
6.4.5 其它优化
关闭自动刷写：HTable.setAutoFlushTo(false)
增加写入缓存：HTable.setWriteBufferSize(writeBufferSize)
不使用WAL：Put.setWriteToWAL(false)
压缩传输：hcd.setCompressionType(Algorithm.SNAPPY)
设置最大版本数：HColumnDescriptor.setMaxVersions(int maxVersions)
设置生命周期：HColumnDescriptor.setTimeToLive(int timeToLive)
6.4.6 phoenix
Phoenix是一个HBase的开源SQL引擎，它使开发者可以像访问普通数据库那样使用jdbc访问HBase
优缺点
优点
- 支持SQL查询hbase，自动转换SQL为最佳并行scan语句
- 将where子句交给过滤器处理，将聚合查询交给协处理器处理
- 支持直接创建二级索引来提升非主键的查询性能
- 跳过扫描过滤器来优化IN、Like、OR查询
- 优化写操作
缺点
- 不支持事务、不支持复杂查询
- 严格的版本限制，每个phoenix对应一个版本hbase
- 与hbase强相关，可能导致元数据被破坏
性能
使用where子句时，phoenix几乎是即时返回，普通的hive on hbase则需要等待一段时间;不使用where子句时，hive的延迟约是phoenix的3-40倍;进行聚合计算时，性能远超Impala（CDH提供的hdfs查询引擎），约为30-70倍。
6.5 Hbase和传统数据库的区别
hbase是海量数据的分布式存储，响应时间为秒级，列式存储，二进制行键。
hbase最大的优势就是存储TB级别的数据量时增删改查速度几乎不变，而传统数据库则会随着数据量增加，性能成倍地下降。
hbase只有string类型
hbase只支持增删改查，没有join和子查询
hbase元数据区分大小写
企业博客