hbase入门到精通

1、提高Hbase API写入操作效率：

• Write Buffer Size
• Hbase Client会在数据累积到设置的阈值后才提交RegionServer。这样做的好处在于可以减少RPC连接次数
• Compression 压缩
  HColumnDescriptor hcd = new HColumnDescriptor(familyName);
  hcd.setCompressionType(Algorithm.SNAPPY); 数据量大，边压边写也会提升性能的，毕竟IO是大数据最严重的瓶颈，哪怕使用了SSD也一样。压缩方式推荐使用SNAPPY。从压缩率和压缩速度来看，性价比最高。
• 预分区和rowkey散列：防止热点写

2、hbase为什么快？

• 1）数据横切为多个region，类似于分区，无需全表扫描
• 2）列式存储，一个列族的数据在同一个文件里（store），只要数据不跨列族访问，就能避免磁盘io
• 3）合理利用内存缓冲热数据：在memstore中合理规划热数据，让查询只需去内存查

3、面向行数据库：每次操作都是操作整行整行的数据库。
面向列数据库：操作若干字段（若干列），这样能减少寻址时间，加快磁盘读写速度。适合大数据
行式存储：一行数据为一个单元去存储
列式存储：一列数据为一个单元去存储，所以存储的单元都是同一种数据，可以压缩，这样不管是存储和查询，效率都会更好
4、一个hbase表列族不超过5个，但是一个列族中的列是没有限制的，而且可以动态增加，也就是说可以随时插入一列新的数据。并且如果某个列的某个值为空，是不占用空间的。不像mysql，需要给空值赋予null或者空的字符串，造成资源浪费
5、列的存储有多个版本号，比如一个人的地址，就可以有多处，就可以以多版本的形式存进去
6、HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。所以这里要配置HBase高可用的话，只需要启动两个HMaster，让Zookeeper自己去选择一个Master Acitve。
7、hbase数据存储模块（也可以理解为hbase写的优化）
regionServer包含多个region，每个region包含多个store（store数目和列族数目一致），store由memStore+storeFile组成，其中storeFile是Hfile的封装。
写入hbase的数据，1.先写入memStore，memStore达到阈值后，2.就会写到磁盘，即形成hfile文件，3.此时会有很多个hfile小文件，所以需要合并压缩
这三层结构也是LSM存储思想的结构。其中第3步：HBase 中实现了两种 compaction 的方式：minor and major（合并成一个大文件）
真正的hbase写过程，在第1步之前还有一个WAL过程：写操作（包括操作命令和数据）都会先写到WAL日志文件中（磁盘），写完之后才会去写入memStore，这种模式可以保证HRegionServer宕机后，我们依然可以从该Log文件中读取数据，Replay所有的操作，而不至于数据丢失
8、LSM树的设计思想非常朴素：
将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。极端的说，基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级
9、hbase读取数据只能根据rowkey去读取，只有get（获取一条记录）和scan方法（传入startRowKey和endRowKey）
10、HBase 宕机如何处理
宕机分为HMaster宕机和HRegionserver宕机，如果是HRegionserver宕机，HMaster会将其所管理的region 新分布到其他活动的RegionServer上，由于数据和日志都持久在 HDFS中，该操作不会导致数据丢失。所以数据的一致性和安全性是有保障的。如果是HMaster宕机， HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master运行。即ZooKeeper会保证总会有一个HMaster在对外提供服务。
11、通常一个HBase集群存在多个HMaster节点，其中一个为Active Master,其余为Backup Master.
Hbase只有一个hmaster主服务器程序在运行，hmaster将region分配给region服务器，协调region服务器的负载并维护集群的状态。
Hmaster不会对外提供数据服务（即不会跟client端交互），而是由region server负责所有regions的读写请求及操作。
由于hmaster只维护表和region的元数据（位置，大小），而不参与数据的输入/输出过程，hmaster失效仅仅会导致所有的元数据无法被修改，但表的数据读/写还是可以正常进行的。 HMaster的作用：
1）为Region server分配region
2）负责Region server的负载均衡
3）发现失效的Region server并重新分配其上的region
4）表的元数据管理
12、zk的作用：
1）在Client中写一个Java类运行，客户端只需连接zk，客户端会从zk中得到Regionserver的映射信息，之后客户端会直接连接到Region Server，
2）RegionServer在启动之后会向zookeeper汇报信息（通过心跳RPC）：本身有多少Region，有哪些数据，当前机器的运行状况等等。
3）master启动后也会向zk汇报信息，并且从zk中得到Region Server的一些信息。例如当一台Region Server宕掉之后，zk会得知，之后Master也会通过zookeeper得到该Region Server宕掉的信息，发现失效的Region server并重新分配其上的region
13、Hbase是分布式、面向列的数据库（其实准确的说是面向列族）。HDFS为Hbase提供可靠的底层数据存储服务，MapReduce为Hbase提供高性能的计算能力。 Zookeeper为Hbase提供稳定服务和Failover机制，因此我们说Hbase是一个通过大量廉价的机器解决海量数据的高速存储和读取的分布式数据库解决方案
14、一个HRegionServer管理多个表，一个表下有多个Region，一个HRegion有多少个列族就有多少个Store，Store下有多个StoreFile文件，StoreFile中有多个Hfile，hfile是HBase中最小的存储单元
15、逻辑存储模型
HBase以表的形式存储数据，表由行和列组成。列划分为若干个列族，如下图所示

RowKey：Hbase使用Rowkey来唯一的区分某一行的数据。如图中"rk001"
列族：Hbase通过列族划分数据的存储，列族下面可以包含任意多的列，实现灵活的数据存取。Hbase的列族不是越多越好，我们使用的场景一般是1个列族
时间戳：TimeStamp对Hbase来说至关重要，因为它是实现Hbase多版本的关键。在Hbase中使用不同的timestame来标识相同rowkey行对应的不通版本的数据。
Cell：HBase 中通过 rowkey 和 columns 确定的为一个存储单元称为 cell。每个 cell 都保存着同一份 数据的多个版本。版本通过时间戳来索引。
16、当RegionServer(RS)收到写请求的时候(write request)，RS会将请求转至相应的Region。不同的CFs中的数据存储在各自的HStore中，HStore由一个Memstore及一系列HFile组成。Memstore位于RS的主内存中，而HFiles被写入到HDFS中。当RS处理写请求的时候，数据首先写入到Memstore，然后当到达一定的阀值的时候，Memstore中的数据会被刷到HFile中。
用到Memstore最主要的原因是：存储在HDFS上的数据需要按照row key 排序。而HDFS本身被设计为顺序读写(sequential reads/writes)，不允许修改。这样的话，HBase就不能够高效的写数据，因为要写入到HBase的数据不会被排序，这也就意味着没有为将来的检索优化。为了解决这个问题，HBase将最近接收到的数据缓存在内存中(in Memstore)，在持久化到HDFS之前完成排序，然后再快速的顺序写入HDFS。
17、rowkey设计原则
（1）rowkey长度原则：越短越好。

• 数据的持久化文件HFile是按照key-value存储的。其中key就是rowkey。如果rowkey过长，光rowkey都会霸占很大的Hile的存储
• memStore会存储部分数据到内存。rowkey过长，内存的有效利用率就会降低
  （2）唯一性
  （3）散列性：rowkey是一个二进制码流，可以是任意字符串。所以我们用程序随机生成rowkey的首字段（在原来rowkey基础上加上前缀）
  如果rowkey按照时间戳的方式递增，不要将时间放在二进制码的前面，建议将rowkey的高位作为散列字段，由程序随机生成，低位放时间字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。若无散列字段，首字段直接是时间信息，所有的数据都会集中在一个RegionServer上，这样在数据检索的时候负载会集中在个别的RegionServer上，造成热点问题
  18、热点写
  如果我们默认建表，表里不断的put数据，更严重的是我们的rowkey还是顺序增大的，是比较可怕的。 这样会造成以下问题：
  （1）首先是热点写，我们总是向最大的start key所在的region写数据，因为我们的rowkey总是会比之前的大，并且hbase的是按升序方式排序的。所以写操作总是被定位到无上界的那个region中；
  （2）其次，由于热点，我们总是往最大的start key的region写记录，之前分裂出来的region不会被写数据，有点打入冷宫的感觉，他们都处于半满状态，这样的分布也是不利的。
  比如将一个有100行的表切分成两个两个区域，那么再往表写入数据的时候，总是会写到startkey是row50的那个region
  预分区一开始就预建好了一部分region,这些region都维护着自已的start-end keys。再配合上随机散列，写数据能均等地命中这些预建的region，就能解决上面的那些缺点