HBase
HBase是什么
HBase是Apache旗下一个高可靠性、高性能、面向列、可伸缩的一个分布式的基于列式存储的数据库,基于Hadoop的hdfs存储，zookeeper进行管理。
利用HBase技术可以在廉价的PC服务器上搭建大规模的存储化集群，使用HBase可以对数十亿级别的大数据进行实时性的高性能读写，在满足高性能的同时还保证了数据存取的原子性。
原子性属于事物四大特性之一。
原子性：
一个事物中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某环节。事物在执行过程中发生错误，会被回滚到事物开始前的状态，就像这个事物没有执行过一样。
一致性：
在事物开始之前、结束之后，数据库的完整性没有被破坏。
隔离性：
数据库允许多个并发事物，同时对其数据进行读写和修改的能力。隔离性可以防止多个并发事物执行，由于交叉执行，而导致的数据不一致。事物的隔离分为不同级别，包括读，未提交；读，提交；可重复读和串行化。
持久性：
事物处理结束后，对数据的修改就是永久的，即使系统故障也不会丢失数据。
事物主要用来管理insert、update、delete语句。
一般来说，事物必须满足四个条件：原子性、一致性、隔离性、持久性。
HBase的特点
1、大：一个表可以有数十亿行，上百万列。
2、无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列。
3、面向列：面向列（族）的存储和权限控制，列（族）独立检索。
4、稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏。
5、数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳。
6、数据类型单一：Hbase 中的数据都是字符串，没有类型。
CAP理论
Consistency（一致性）：数据一致更新，所有数据变动都是同步的。
假如数据在ABC 3个节点上都有备份，在A节点更新了，BC也会更新，否则就会出现不对应错乱的情况。
Availability（可用性）：良好的响应性能。
对外部请求可以及时作出反应，效率比较高。
Partition tolerance（分区容错性）：可靠性。
就是我们的数据一定要有备份，不能存放在一个节点上，如果发生宕机，就会发生数据丢失。
定理：任何分布式系统只可能同时满足两点，没法三者兼顾。
集群架构
Client：包含了访问HBase的接口，还有维护缓存加速HBase的访问。
Zookeeper：实现HMaster的高可用；监控HRegionServer的状态；存储.META.的地址。
HMaster：维护.META.；为HRegionServer分配Region；维护集群的负载均衡。
HRegionServer：处理客户端的读写请求；管理HMaster分配的Region。
HDSF：为HBase提供最终的底层数据存储服务。
Rowkey设计原则
1、Rowkey 长度原则
Rowkey 是一个二进制码流，Rowkey 的长度被很多开发者建议说设计在10~100 个字节，不过建议是越短越好，不要超过 16 个字节。
原因如下：
（1）数据的持久化文件 HFile 中是按照 KeyValue 存储的，如果 Rowkey 过长比如 100 个字节，1000 万列数据光 Rowkey 就要占用 100*1000 万=10 亿个字节， 将近 1G 数据，这会极大影响 HFile 的存储效率；
（2）MemStore 将缓存部分数据到内存，如果 Rowkey 字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。 因此 Rowkey 的字节长度越短越好。
（3）目前操作系统是都是 64 位系统，内存 8 字节对齐。控制在 16 个字节，8 字节的整数倍利用操作系统的最佳特性。
2、Rowkey 散列原则
如果 Rowkey 是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将 Rowkey 的高位作为散列字段，由程序循环生成，低位放时间字段， 这样将提高数据均衡分布在每个 RegionServer 实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer 上堆积的 热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。
3、Rowkey 唯一原则
必须在设计上保证其唯一性。
Hive与Hbase之间的区别
●Hive的定位是数据仓库，虽然也有增删改查，但其删改查对应的是整张表而不是单行数据，查询的延迟较高。其本质是更加方便的使用MapReduce的威力来进行离线分析的一个数据分析工具。
●HBase的定位是Hadoop的数据库，是一个典型的NoSQL，所以HBase是用来在大量数据中进行低延迟的随机查询的。
HBase的过滤器
单个列过滤器
列过滤器
列族过滤器
前缀过滤器
键值过滤器
HMaster的作用
HBase中的每张表都通过键按照一定的范围被分割成多个子表（HRegion），默认一个 HRegion超过256M就要被分割成两个，这个过程由HRegionServer管理，而HRegion的分配由HMaster管理。
1.为HRegionServer分配HRegion
2.负责HRegionServer的负载均衡
3.发现失效的HRegionServer并重新分配
4.HDFS上的垃圾文件回收
5.处理Schema更新请求
HRegionServer的作用
1.维护HMaster分配给它的HRegion，处理对这些HRegion的IO请求。
2.负责切分正在运行过程中变得过大的HRegion可以看到，Client访问HBase上的数据并不需要HMaster参与，寻址访问ZooKeeper和HRegionServer，数据读写访问HRegionServer，HMaster仅仅维护Table和Region的元数据信息，Table的元数据信息保存在ZooKeeper上，负载很低。HRegionServer存取一个子表时，会创建一个HRegion对象，然后对表的每个列簇创建一个Store对象，每个Store都会有一个MemStore和0或多个StoreFile与之对应，每个StoreFile都会对应一个HFile，HFile就是实际的存储文件。因此，一个HRegion有多少列簇就有多少个Store。
3 一个HRegionServer会有多个HRegion和一个HLog。
HRegion的作用
Table在行的方向上分割为多个HRegion，HRegion是HBase中分布式存储和负载均衡的最小单元，即不同的HRegion可以分别在不同的HRegionServer上，但同一个HRegion是不会拆分到多个HRegionServer上的。HRegion按大小分割，每个表一般只有一个HRegion，随着数据不断插入表，HRegion不断增大，当HRegion的某个列簇达到一个阀值（默认256M）时就会分成两个新的HRegion。
1、<表名，StartRowKey, 创建时间>
2、由目录表(-ROOT-和.META.)记录该Region的EndRowKey
HRegion的定位
HRegion被分配给哪个HRegionServer是完全动态的，所以需要机制来定位HRegion具体在哪个HRegionServer，HBase使用三层结构来定位HRegion。
1、通过zk里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一个region。
2、通过-ROOT-表查找.META.表的第一个表中相应的HRegion位置。其实-ROOT-表是.META.表的第一个region，.META.表中的每一个Region在-ROOT-表中都是一行记录。
3、通过.META.表找到所要的用户表HRegion的位置。用户表的每个HRegion在.META.表中都是一行记录。
-ROOT-表永远不会被分隔为多个HRegion，保证了最多需要三次跳转，就能定位到任意的region。Client会将查询的位置信息保存缓存起来，缓存不会主动失效，因此如果Client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的HRegion，其中三次用来发现缓存失效，另外三次用来获取位置信息。
HBase的优化
一、写入数据方面
1.Auto Flash
通过调用HTable.setAutoFlushTo(false)方法可以将HTable写客户端自动flush关闭，这样可以批量写入数据到HBase，而不是有一条put就执行一次更新，只有当put填满客户端写缓存的时候，才会向HBase服务端发起写请求。默认情况下auto flush是开启的。
2.Write Buffer
通过调用HTable.setWriteBufferSize(writeBufferSize)方法可以设置HTable客户端的写buffer大小，如果新设置的buffer小于当前写buffer中的数据时，buffer将会被flush到服务端。其中，writeBufferSize的单位是byte字节数，可以根基实际写入数据量的多少来设置该值。
3.WAL Flag
在HBase中，客户端向集群中的RegionServer提交数据时（Put/Delete操作），首先会写到WAL（Write Ahead Log）日志，即HLog，一个RegionServer上的所有Region共享一个HLog，只有当WAL日志写成功后，再接着写MemStore，然后客户端被通知提交数据成功，如果写WAL日志失败，客户端被告知提交失败，这样做的好处是可以做到RegionServer宕机后的数据恢复。
对于不太重要的数据，可以在Put/Delete操作时，通过调用Put.setWriteToWAL(false)或Delete.setWriteToWAL(false)函数，放弃写WAL日志，以提高数据写入的性能。
注：如果关闭WAL日志，一旦RegionServer宕机，Put/Delete的数据将会无法根据WAL日志进行恢复。
4.Compression 压缩
数据量大，边压边写也会提升性能的，毕竟IO是大数据的最严重的瓶颈，哪怕使用了SSD也是一样。众多的压缩方式中，推荐使用SNAPPY。从压缩率和压缩速度来看，性价比最高。
HColumnDescriptor hcd = new HColumnDescriptor(familyName);
hcd.setCompressionType(Algorithm.SNAPPY);
5.批量写
通过调用HTable.put(Put)方法可以将一个指定的row key记录写入HBase，同样HBase提供了另一个方法：通过调用HTable.put(List)方法可以将指定的rowkey列表，批量写入多行记录，这样做的好处是批量执行，只需要一次网络I/O开销，这对于对数据实时性要求高，网络传输RTT高的情景下可能带来明显的性能提升。
6.多线程并发写
在客户端开启多个 HTable 写线程，每个写线程负责一个 HTable 对象的 flush 操作，这样结合定时 flush 和写 buffer（writeBufferSize），可以既保证在数据量小的时候，数据可以在较短时间内被 flush（如1秒内），同时又保证在数据量大的时候，写 buffer 一满就及时进行 flush。
二、读数据方面
1.批量读
通过调用 HTable.get(Get) 方法可以根据一个指定的 row key 获取一行记录，同样 HBase 提供了另一个方法：通过调用 HTable.get(List) 方法可以根据一个指定的 row key 列表，批量获取多行记录，这样做的好处是批量执行，只需要一次网络 I/O 开销，这对于对数据实时性要求高而且网络传输 RTT 高的情景下可能带来明显的性能提升。
2.缓存查询结果
对于频繁查询 HBase 的应用场景，可以考虑在应用程序中做缓存，当有新的查询请求时，首先在缓存中查找，如果存在则直接返回，不再查询 HBase；否则对 HBase 发起读请求查询，然后在应用程序中将查询结果缓存起来。至于缓存的替换策略，可以考虑 LRU 等常用的策略。
三、数据及集群管理
1.预分区
默认情况下，在创建HBase表的时候会自动创建一个Region分区，当导入数据的时候，所有的HBase客户端都向Region写数据，知道这个Region足够大才进行切分，一种可以加快批量写入速度的方法是通过预先创建一些空的Regions，这样当数据写入HBase的时候，会按照Region分区情况，在进群内做数据的负载均衡。
2.Rowkey优化
rowkey是按照字典存储，因此设置rowkey时，要充分利用排序特点，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放到一块。
rowkey若是递增生成的，建议不要使用正序直接写入，可以使用字符串反转方式写入，使得rowkey大致均衡分布，这样设计的好处是能将RegionServer的负载均衡，否则容易产生所有新数据都在集中在一个RegionServer上堆积的现象，这一点还可以结合table的与分区设计。
减少Column Family数量：不要在一张表中定义太多的column family。目前HBase并不能很好的处理超过 2-3个column family的表，因为某个column family在flush的时候，它临近的column family也会因关联效应被触发flush，最终导致系统产生更过的I/O。
3.设置最大版本数
创建表的时候，可以通过 HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设setMaxVersions(1)。
4.缓存策略（setCaching）
创建表的时候，可以通过HColumnDEscriptor.setInMemory(true)将表放到RegionServer的缓存中，保证在读取的时候被cache命中。
5.设置存储生命期
创建表的时候，可以通过HColumnDescriptor.setTimeToLive(int timeToLive)设置表中数据的存储生命周期，过期数据将自动被删除。
6.磁盘配置
每台RegionServer管理10-1000个Regions。每个Region在1-2G，则每台server最少要10G，最大要1000*2G=2TB，考虑3备份，需要6TB。方案1是3块2TB磁盘，2是12块500G磁盘，带宽足够时，后者能提供更大的吞吐率，更细力度的冗余备份，更快速的单盘故障恢复。
分配何时的内存给RegionServer
在不影响其他服务的情况下，越大越好。在HBase的conf目录下的hbase-env.sh的最后添加export HBASE_REGIONSERVER_OPTS="- Xmx16000m $HBASE_REGIONSERVER_OPTS"其中16000m为分配给REgionServer的内存大小。
7.写数据的备份数
备份数与读性能是成正比，与写性能成反比，且备份数影响高可用性。有两种配置方式，一种是将hdfs-site.xml拷贝到hbase的conf目录下，然后在其 中添加或修改配置项dfs.replication的值为要设置的备份数，这种修改所有的HBase用户都生效。另一种方式是改写HBase代码，让HBase支持针对列族设置备份数，在创建表时，设置列族备份数，默认为3，此种备份数支队设置的列族生效。
客户端一次从服务器拉取的数量
通过配置一次拉取较大的数据量可以减少客户端获取数据的时间，但是他会占用客户端的内存，有三个地方可以进行配置
在HBase的conf配置文件中进行配置hbase.client.scanner.caching;
通过调用HTble.setScannerCaching(int scannerCaching)进行配置；
通过调用Sacn.setCaching(int caching)进行配置，三者的优先级越来越高。
8.客户端拉取的时候指定列族
scan是指定需要column family，可以减少网络传输数据量，否则默认scan操作会返回整行所有column family的数据
拉取完数据之后关闭ResultScanner
通过 scan 取完数据后，记得要关闭 ResultScanner，否则 RegionServer 可能会出现问题（对应的 Server 资源无法释放）。
9.RegionServer的请求处理IO线程数
较少的IO线程适用于处理单次请求内存消耗较高的Big Put场景（大容量单词Put或设置了较大cache的scan，均数据Big Put）或RegionServer的内存比较紧张的场景。
较多的IO线程，适用于单次请求内存消耗低，TPS要求（每次事务处理量）非常高的场景。这只该值的时候，以监控内存为主要参考在hbase-site.xml配置文件中配置项为hbase.regionserver.handle.count
10.Region大小设置
配置项hbase.hregion.max.filesize，所属配置文件为hbase-site.xml，默认大小是256m。在当前RegionServer上单个Region的最大存储空间，单个Region超过该值时，这个Region会被自动split成更小的Region。小Region对split和compaction友好，因为拆分Region或compact小Region里的StoreFile速度非常快，内存占用低。缺点是split和compaction会很频繁，特别是数量较多的小Region不同的split，compaction，会导致集群响应时间波动很大，Region数量太多不仅给管理上带来麻烦，设置会引起一些HBase个bug。一般 512M 以下的都算小Region。大 Region 则不太适合经常 split 和compaction，因为做一次 compact 和 split 会产生较长时间的停顿，对应用的读写性能冲击非常大。
此外，大 Region 意味着较大的 StoreFile，compaction 时对内存也是一个挑战。如果你的应用场景中，某个时间点的访问量较低，那么在此时做 compact和split，既能顺利完成 split 和 compaction，又能保证绝大多数时间平稳的读写性能。compaction 是无法避免的，split 可以从自动调整为手动。只要通过将这个参数值调大到某个很难达到的值，比如 100G，就可以间接禁用自动split(RegionServer 不会对未到达 100G 的 Region 做 split)。再配合RegionSplitter 这个工具，在需要 split 时，手动 split。手动 split 在灵活性和稳定性上比起自动 split 要高很多，而且管理成本增加不多，比较推荐 online 实时系统使用。内存方面，小 Region 在设置 memstore 的大小值上比较灵活,大 Region 则过大过小都不行，过大会导致 flush 时 app 的 IO wait 增高，过小则因 StoreFile 过多影响读性能。