HBase01

1. HBase基本介绍

a. 介绍

Hbase是一个nosql的列式存储的数据库。实际来源于Google发表的论文bigtable。构建在hdfs基础之上。

1. 提供高可用，高性能，列储存，可伸缩，实时读写nosql的数据库系统。
2. 按照key-value的形式进行数据的存储：rowkey(行键)，通过行键完成数据的检索。
3. Hbase仅支持简单的事务（行级操作），不支持复杂的操作（不能join等操作）。
4. Hbase的数据类型单一：byte[]
5. 和hadoop一样，Hbase依靠横向拓展，增加服务器，提高计算能力。

b. Hbase的特点

1. 大：数据量大
2. 面向列：数据按照列式的方式进行储存。
3. 稀疏：habase中null的数据不会占用存储空间

2. Hbase和hadoop的关系

a. hdfs

1. 为分布式存储提供文件系统
2. 针对存储大尺寸的文件进行优化，不需要对HDFS上的文件进行随机读写
3. 直接使用文件
4. 数据模型不灵活
5. 使用文件系统和处理框架
6. 优化一次写入，多次读取的方式

b. Hbase

1. 提供列式存储
2. 可以对数据进行随机读取按照key-value形式操作数据
3. 支持mr，依赖hdfs
4. 优化多次读或者写

总结：紧耦合关系，Hbase依赖于hdfs

3. RDBMS和Hbase对比

Hbase：

• 结构：

1. 1. 数据库以region的形式存在
   2. 支持hdfs
   3. 使用WAL存储日志（写前日志）
   4. 参考系统的zookeeper（耦合）
   5. 使用行键（rowkey）
   6. 支持分片
   7. 使用行 列 列族（column family） 单元格

4. Hbase的简要特征

• 海量存储：适合存储PB级别的数据
• 列式存储：数据按照列存储，再进一步，按照列族形式存储
• 极易拓展：
  • RegionServer：针对reginserver管理的拓展
  • 针对数据存储的拓展

高并发：hbase的IO操作不会降低

稀疏：对于null的数据不进行储存

5. Hbase的整体架构

HMaster：

1. 监控RegionServer
2. 处理RegionServer的故障转移
3. 处理元数据的变更
4. 处理region的分配或移除
5. 在空闲时间进行数据的负载均衡

RegionServer：

1. 负责存储HBase的实际数据
2. 处理分配给它的Region 
3. 刷新缓存到HDFS 
4. 维护HLog 
5. 执行压缩
6. 负责处理Region分片

相关组件：

1. WAL：用于数据恢复，当Hbase读写数据的时候，不是直接写进磁盘，他会在内存中保留一点时间，数据在内存中可能会丢失，为了解决这个问题，会先卸载write-ahead-logfile中，然后在写入内存，出现故障时，可以通过日志恢复
2. HFile：hbase数据的存储文件，实际的存储文件
3. Store：Hifile存在store中，一个store对应一个column对应一个column family（列族）
4. memestore：缓存存储，默认128M
5. region：一张表的部分或者全部数据

6. Hbase的安装

https://blog.csdn.net/oschina_41140683/article/details/82752115

7. Hbase底层原理

client：包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如region的位置信息、

zookeeper：

1. 保证任何时候，集群中只有一个master。
2. 存储所有的Region的寻址入口
3. 实时监控Region Server的状态，将Region Server的上线和下线通知给Master

Master：

1. 为Region Server分配Region
2. 负责Region server的负载均衡
3. 发现失效的Region Server并重新分配其上面的region到正常上的Region Server
4. Hdfs上面的垃圾回收
5. 处理schema更新请求

Region Server：

Region server负责维护Master分配给它的region，处理对这些region的io请求

Region server负责切分在运行过程中变得过大的region。

总结：可以看到client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问region server），master仅仅维护着table和region的元数据信息，负载很低。

a. Hbase的表数据模型

1. 1. row key：行键，一行的主键，唯一值，最大长度64，建议10-100个字节，按照字典进行排序。设计时，要考虑排序存储这个特性，将经常一起读取的行存储到一起。
   2. column family（列族）：列族是表的schema的一部分，必须在使用表之前定义，列名都是以列族作为前缀courses：math，courses：history都属于这个列族。访问控制，磁盘和内存的使用统计都在列族的层面上进行的。列族越多，在取一行数据时，所参与的io，搜寻的文件就越多。一般三个左右的列族。
   3. qualifier：列，一个列族下面的字段。
   4. version：数据的版本。每条数据有多个版本号，默认是系统时间戳，类型Long
   5. timestamp：版本通过时间戳来索引，时间戳，在数据写入时自动赋值，类型是64位整形。
   6. Cell：由{row key, column( =<family> + <label>), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

b. 整体结构

 

1. table中的所有行都按照row key的字典排序
2. table在行的方向上分割为多个Hregion
3. region按大小分割（默认是10g）,每一个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一定的阀值的时候，hregion就会等分为两个新的Hregion，当table中国的行不断增多的时候，就会有多个Hregion。
4. Hregion是Hbase中分布式存储和负载均衡的最小单元，最小单元表示，不同的Hregion可以分布到不同的Region Server上面。一个Region不会拆分到多个Server上的。
5. HRegion、虽然是负载均衡的最小单元，但并不是物理存储的最小单元。Hregion由一个或多个Store组成，每个store保存着一个column family。每个store又由一个memStore和0至多个StoreFile组成。

 c. Store File和HFile：Store File以HFile格式保存在HDFS上

1. 1. Data Block 段–保存表中的数据，这部分可以被压缩
   2. Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。
   3. File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
   4. Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
   5. Meta Block Index段 (可选的)–Meta Block的索引。
   6. Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先 读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个 block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。
   7. HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。
   8. 目标Hfile的压缩支持两种方式：Gzip，Lzo。

d. MemStore和Storefile

 　　一个region由多个store组成，每个store包含一个列族的所有数据。store包括位于内存memestore和位于磁盘的storefile。写操作写入memstore，当memestore达到一定阈值的时候，Hregion server启动flush写入storefile，当storefile大小超过一定阈值后，会把当前的region分割成两个，并分割成两个，并由Hmaster分配给相应的region服务器，实现负载均衡。客户端检索数据时，会现在memestore中寻找，找不到再去storefile。

e. HLog

　　每个Region Server维护一个Hlog,而不是每个Region一个。这样不同region(来自不同table)的日志会混在一起，这样做的目的是不断追加单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高对table的写性能。带来的麻烦是，如果一台region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其它region server上进行恢复。

HLog文件就是一个普通的Hadoop Sequence File：

1. HLog Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
2. HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。

f. 读请求过程

1. Client先访问zookeeper，找到meta表，并获取meta数据
2. 确定当前要写入数据的HRegion和HRegionServer
3. Client向该HReginServer发起写入请求，然后HRegionServer收到请求并响应
4. Client先把数据写到HLOG再将数据写到MemStore
5. 如果HLog和Metastore都写入成功，则这条数据写入成功
6. 如果Memstore达到阈值，会flush到StoreFile中
7. 当StoreFile越来越多，会触发Compact合并操作，把过多的StoreFile合成一个StoreFile
8. 当StoreFile越来越大，Region也会越来越大，达到阈值时，会触发split操作，将Region一分为二。

• 细节描述：

1. hbase使用MemStore和StoreFile存储对表的更新。
2. 数据在更新时首先写入Log(WAL log)和内存(MemStore)中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并 且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了。
3. 当系统出现意外时，可能导致内存(MemStore)中的数据丢失，此时使用Log(WAL log)来恢复checkpoint之后的数据。
4. StoreFile是只读的，一旦创建后就不可以再修改。因此Hbase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并(minor_compact, major_compact),将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对 StoreFile进行split，等分为两个StoreFile。
5. 由于对表的更新是不断追加的，compact时，需要访问Store中全部的 StoreFile和MemStore，将他们按row key进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

g. Region管理

1. region分配：任何时刻，一个region只能分配给一个region server。master会记录当前有哪些可用的region server，以及当前的region分配给了哪些region server，哪些region还没有分配，当需要分配region的时候，并且有一个region server上面有可用的空间时，master就会给这个region server 发送一个装载请求把region分配给regin server。regin server收到请求后，对此region进行服务。
2. Region Server上线：master使用zookeeper跟踪region server状态，当某个region server启动时，会在zookeeper上的server创建znode的代表自己，由于master订阅了server目录上的变更消息，当server目录下文件新增或者删除时候，master就能收到zookeeper的实时通知。
3. Region Server下线：当Region server下线时候，和zookeeper的会话会断开，zookeeper而自动释放代表这台server的文件上的独占锁，master就可以确定：region server下线了，region server 挂了。无论哪种情况，region server无法为他的region服务了，master会删除server目录下代表这台region server的znode数据，并将这台region server的region分配给其他活着的region server。

h. Master工作机制

1. master上线

• 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。
• 扫描zookeeper上的server父节点，获得当前可用的region server列表。
• 和每个region server通信，获得当前已分配的region和region server的对应关系。
• 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。

2. master下线

• 由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。

3. 从上线过程可以看到，master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来）

4. 因此，一般hbase集群中总是有一个master在提供服务，还有一个以上的‘master’在等待时机抢占它的位置。