Hbase，
HBase是什么? (有道云:书籍:HBase笔记)
HBase是一个在HDFS上开发的面向列的分布式数据库,可以实时的访问超大规模数据集.
Apache HBase是Hadoop数据库，一个分布式的、可伸缩的大数据存储。
Apache HBase是一个开源的、分布式的、版本化的、非关系的数据库
结构图:
https://wenku.baidu.com/view/b2bd94946bd97f192379e941.html
一.应用场景
随着数据量越来越大，传统的关系型数据库已经不能满足要求。hive虽然能满足存储，但是不能满足非结构化的存储和高效查询
当需要对大数据进行随机的,实时的读/写访问时,可以使用HBase
二.rowkey设计
1 Rowkey长度设计原则：Rowkey是一个二进制码流，建议是越短越好，不要超过16个字节。
2 Rowkey的唯一原则:必须在设计上保证其唯一性。
3 Rowkey的散列原则
必须要保证所有的rowkey那个均匀的分布在各个hbase节点上，后来我们把rowkey加上时间戳然后做了md5的加密来解决此问题。
如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，
低位放时间字段，这样将提高数据均衡分布在每个RegionServer实现负载均衡的几率。如果没有散列字段，
首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，
这样在做数据检索的时候负载将会集中在个别RegionServer ，降低查询效率。
三.二级索引
rowkey在HBase中是以B+ tree结构化有序存储的，所以scan起来会比较效率。
单表以row key存储索引，column value存储id值或其他数据 ，这就是Hbase索引表的结构。
由于HBase本身没有二级索引（Secondary Index）机制，基于索引检索数据只能单纯地依靠RowKey，
为了能支持多条件查询，开发者需要将所有可能作为查询条件的字段一一拼接到RowKey中，
这是HBase开发中极为常见的做法
二级索引的本质就是建立各列值与行键之间的映射关系
四.协处理器
协处理器有两种：observer和endpoint
Observer允许集群在正常的客户端操作过程中可以有不同的行为表现
Endpoint允许扩展集群的能力，对客户端应用开放新的运算命令
五.hbase和hive,hdfs的关系
Hive：
Hive不支持更改数据的操作，Hive基于数据仓库，提供静态数据的动态查询。其使用类SQL语言，底层经过编译转为MapReduce程序，
在Hadoop上运行，数据存储在HDFS上。
HDFS:
HDFS是GFS的一种实现，他的完整名字是分布式文件系统，类似于FAT32，NTFS，是一种文件格式，是底层的。
Hive与Hbase的数据一般都存储在HDFS上。Hadoop HDFS为他们提供了高可靠性的底层存储支持。
Hbase:
Hbase是Hadoop database，即Hadoop数据库。它是一个适合于非结构化数据存储的数据库，HBase基于列的而不是基于行的模式。
HBase是Google Bigtable的开源实现，类似Google Bigtable利用GFS作为其文件存储系统，HBase利用Hadoop HDFS作为其文件存储系统；
Google运行MapReduce来处理Bigtable中的海量数据，HBase同样利用Hadoop MapReduce来处理HBase中的海量数据。
Hadoop HDFS为HBase提供了高可靠性的底层存储支持，Hadoop MapReduce为HBase提供了高性能的计算能力，
Zookeeper为HBase提供了稳定服务和failover机制。Pig和Hive还为HBase提供了高层语言支持，
使得在HBase上进行数据统计处理变的非常简单。 Sqoop则为HBase提供了方便的RDBMS（关系型数据库）数据导入功能，
使得传统数据库数据向HBase中迁移变的非常方便。
六. hbase的架构及各组件的功能
1 client
HBase Client使用HBase的RPC机制与HMaster和HRegionServer进行通信,
对于管理类操作,Client与HMaster进行RPC;
对于数据读写类操作,Client与HRegionServer进行RPC.
2 Zookeeper
Zookeeper Quorum中除了存储了-ROOT-表的地址和HMaster的地址,HRegionServer也会把
自己以Ephemeral方式注册到Zookeeper中,使得HMaster可以随时感知到各个HRegionServer
的健康状态,此外,Zookeeper也避免了HMaster的单点问题.
3 HMaster
管理用户对Table的增删改查操作
管理HRegion Server的负载均衡,调整Region分布
在Region Split后,负责新Region的分配
在HRegion Server停机后,负责失效HRegion Server上的Regions迁移
4 Region
当表的大小超过设置值的时候，HBase会自动地将表划分为不同的区域，
每个区域包含所有行的一个子集。对用户来说，每个表是一堆数据的集合，
靠主键来区分。从物理上来说，一张表被拆分成了多块，每一块就是一个Region。
我们用表名+开始/结束主键，来区分每一个Region，一个Region会保存一个表里面某段连续的数据，
从开始主键到结束主键，一张完整的表格是保存在多个Region上面。
5 HRegion Server
所有的数据库数据一般是保存在Hadoop HDFS分布式文件系统上面，
用户通过一系列HRegion Server获取这些数据，一台机器上面一般只运行一个HRegion Server，
且每一个区段的HRegion也只会被一个HRegion Server维护。
HRegion Server主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。
HRegion Server内部管理了一系列HRegion对象，每个HRegion对应了Table中的一个Region，
Region中由多个Store组成。每个Store对应了Table中的一个Column Family的存储，
可以看出每个Column Family其实就是一个集中的存储单元，因此最好将具备共同IO特性的column放在一个Column Family中，
这样最高效。
七.hbase的优化
客户端的优化
1、关闭自动刷新
ht.setAutoFlush(false, true); //设置是否自动刷新，默认是自动刷新
2、尽量批量写入 (put或者delete的时候尽量批量写入) 3、谨慎关闭写Hlog：
hd.setDurability(Durability.SKIP_WAL);
4、尽量把数据放到缓存里面：
hc.setInMemory(true);
5、尽量不要太多的列簇，最多两个。
因为在hbase刷新数据的时候将会引起该列簇附近的列簇刷新。 6、rowkey的长度尽量短。最大64KB 7、尽量将该关闭的对象关闭
比如：admin 、table 、 ResultScaner 、 HbaseAdmin 等。
八.宽表高表的选择
hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；
高表是指很多行较少列，即 行多列少，一行中的数据量较少，行数大。
hbase的row key是分布式的索引，也是分片的依据。
hbase的row key + column family + column qualifier + timestamp + value 是HFile中数据排列依据。
HFile据此，对数据的索引到data block级别，而不是行级别。所以 这种key是HFile内部的粗粒度（data block粒度）本地索引的主键。
据此，在HBase中使用宽表、高表的优劣总结如下：
1 查询性能：高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。
高表一行中的数据较少。 所以查询缓存BlockCache能缓存更多的行，以行数为单位的吞吐量会更高。
2 分片能力：高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。 HBase按行来分片。
3 元数据开销：高表元数据开销更大。高表行多，row key多，可能造成region数量也多，- root -、 .meta表数 据量更大。
过大的元数据开销，可能引起HBase集群的不稳定、master更大的负担（这方面后续再好好总 结）。
4 事务能力：宽表事务性更好。HBase对一行的写入（Put）是有事务原子性的，一行的所有列要么全部写入成功，要么全部没有写入。
但是多行的更新之间没有事务性保证。
5 数据压缩比：如果我们对一行内的数据进行压缩，宽表能获得更高的压缩比。因为宽表中，一行的数据量较大，
往往存在更多相似的二进制字节，有利于提高压缩比。通过压缩，缓解了宽表一行数据量太大，并导致 分片大小不均匀的问题。
查询时，我们根据row key找到压缩后的数据，进行解压缩。而且解压缩可以通过协 处理器（coproesssor）在HBase服务器上做，
而不是在业务应用的服务器上做，以充分应用HBase集群的 CPU能力。
设计表时，可以不绝对追求高表、宽表，而是在两者之间做好平衡。
根据查询模式，需要分布式索引、分片、有很 高选择度（即能据此查询条件迅速锁定很小范围的一些行）的查询用字段，
应该放入row key；能够均匀地划分数 据字节数的字段，也应该放入row key，作为分片的依据。
选择度较低，并且不需要作为分片依据的查询用字段， 放入column family和column qualifier，不放入row key。
HBase之表的设计原则:
1、列族的数量及列族的势
建议将HBase列族的数量设置的越少越好。当强，对于两个或两个以上的列族HBase并不能处理的很好。
这是由于HBase的Flushing和压缩是基于Region的。当一个列族所存储的数据达到Flushing的阈值时，
该表中所有列族将同时进行Flushing操作。这将带来不必要的I/O开销，列族越多，该特性带来的影响越大。
此外，还要考虑到同一个表中不同列族所存储的记录数量的差别，即列族的势(Cardinality)。
当两个列族数量差别过大时会使包含记录数量较少列族的数据分散在多个Region上，
而Region有可能存储在不同的RegionServer上。这样，当进行查询或scan操作的时候，系统效率将会受到影响。
2、行键(RowKey)的设计
首先应该避免使用时序或单调(递减/递增)行键。
因为当数据到来的时候，HBase首先需要根据记录的行键来确定存储的位置，即Region的位置，
如果使用时序或单调行键，那么连续到来的数据将被分配到同一个Region中，
而此时系统的其他Region/RegionServer处于空闲状态，这是分布式最不希望看到的状态。
3、尽量最小化行键和列族的大小
在HBase中，一个具体的值由存储该值的行键、对应的列(列族：列)以及该值的时间戳决定。
HBase中索引是为了加速随即访问的速度，索引的创建是基于“行键+列族：列+时间戳+值”的，
如果行键和列族的大小过大，甚至超过值本身的大小，纳闷将会增加索引的大小。
并且在HBase中数据记录往往非常之多，重复的行键、列将不但使索引的大小过大，也将加重系统的负担.
4、版本的数量
默认情况下为3个，可以通过HColumnDescriptor进行设置，建议不要设置的过大
---------------------
扩展:
一.HBase的读写流程:
读流程:
版本一:
1,Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息。
2,根据namespace、表名和rowKey在meta表中找到对应的region信息
3,找到这个region对应的regionServer
4,查找对应的region
5,先从MemStore找数据，如果没有，再到StoreFile上读(为了读取的效率)。
---------------------
版本二:
1.client先去访问zookeeper,从zookeeper上获取meta表的位置信息
2.client向meta表的region所在的regionServer发起访问,读取meta表的数据,获取了HBase集群上所有的表的元数据
3.根据meta表的元数据信息(某张表有几个region,region如何分配,每个region的startKey和stopKey),client找到
当前要读取的表对应的region及所在的regionServer信息
4.client向对应的RegionServer发起读请求
5.regionServer收到客服端的读请求,会先扫描memstore,再扫描blockcache(读缓存),没有找到数据后再去读取
storeFile文件
6.regionServer将数据响应给client
写流程:
1.client先去访问zookeeper,从meta表获取相应region信息,然后找到meta表的数据
2.根据namespace,表名和rowKey根据meta表的数据找到写入数据对应的region信息
3.找到对应的regionServer
4.把数据分别写到HLog和MemStore上一份,MemStore达到一个阈值后则把数据刷成一个
StoreFile文件.(若MemStore数据丢失,可从总HLog上恢复)
5.当多个StoreFile文件达到一定的大小后,会触发Compact合并操作,合并为一个StoreFile
(这里同时进行版本的合并和数据删除)
6.当StoreFile大小超过一定阈值后,会把当前的Region分为两个(Split),并由HMaster分配到相应的
HRegionServer,实现负载均衡.
二.HBase的热点问题: https://blog.csdn.net/WYpersist/article/details/79826838
HBase中的行是按照RowKey的字典顺序排序的,这种设计优化了scan操作,可以将相关的行以及会被一起读取的行存取在临近位置,便于
scan,然而糟糕的RowKey设计是热点的源头.
热点问题产生原因:
检索habse的记录首先要通过row key来定位数据行。当大量的client访问hbase集群的一个或少数几个节点，造成少数Regionserver
的I/O请求过多、负载过大，而其他Regionserver负载却很小，就造成了“热点”现象
1.没有提前创建分区,HBase创建表默认只有一个分区
2.RowKey设计不合理,例如,只有一个RegionServer,然后所有的RowKey都往该region里写数据,最后RegionServer就会承受不了压力,
就会出现单点故障,热点问题.
有大量连续编号的row key ==> 大量row key相近的记录集中在个别region
==> client检索记录时,对个别region访问过多 ==> 此region所在的主机过载
==> 热点
明白了热点原因就可以从row key着手解决，下面几个方法可以使用，目的就一个：尽量均衡地把每一条记录分散到不同的region里去！
解决方案:
HBase创建表时指定分区
合理设计RowKey
HBase常见避免热点问题方法:
加盐:
rowKey前缀,决定了在哪一个分区.在RowKey的前面加随机数,即分配一个随机前缀;降低了热点问题,但是读效率下降.
哈希:
哈希会使同一行永远用一个前缀加盐.哈希也可以使负载分散到整个集群,但是哈希读是可预测的,读效率没有下降.
反转:
以手机号为RowKey,可以将手机号反转后的字符串作为RowKey,这样就避免了手机号固定开头导致的热点问题;反转虽然
可以有效的随机RowKey,但是牺牲了RowKey的有序性.
时间戳反转
尽量减少行和列的大小