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’在等待时机抢占它的位置。