Habase系统架构

ps：先了解hbase的整体架构，有些看不明白的可以先看后面，再回过头来看。

• 系统架构

1. hbase可以启动多个 master（老大），但只有一个处于active状态，其他的则处于backup状态。
2. 会有多个regionServer（小弟）
3. Zookeepr为hbase提供集群协调

• zookeeper

1. 保证任何时候集群只有一个Master
2. 监控regionServer的状态 将其上线下线信息通知master
3. 存储meta表对应的region的地址
4. 存储hbase的元数据信息 包括 有哪些表 有哪些列族等等

• Master

1. 为RegionServer分配Region
2. 为RegionServer进行负载的均衡
3. GFS上的垃圾回收
4. 处理对Schema数据的更新请求

• RegionServer

1. 维护Master分配给它的region，处理对这些region的IO请求
2. 负责切分在运行过程中变得过大的region

逻辑存储

• 前面讲过，行健，列族，列，单元格，时间戳
• hbase底层会通过行健来对数据进行排序，排序规则就是把行健作为字符串排序

物理存储

• hbase在行的维度还会进行切分，切为一个个的Hregion（region）
• region是hbase里分布式存储和负载均衡的最小单元

master会给regionServer分配Hregion，regionServer会负责外部对这些Hregion的读写IO。

一个Hregion会完整的分配给一个regionServer，不会被拆分。

查询不同Hregion中的数据时，会请求不同的regionServer，达到负载均衡的目的。

• hregion是分布式存储的最小单元，但不是存储的最小单元

hregion存储单元又是由若干个store组成，每个store对应一个列族。一个列族中的数据往往数据很类似，压缩后节省存储空间。

每个store里都有且仅有一个memStore（基于内存存储），及0个或多个storeFile（对应着hdfs上的一个文件：hfile）。

• StoreFile（Hfile）的结构

1. Data Blocks 段–保存表中的数据，这部分可以被压缩
2. Meta Blocks 段 (可选的)–保存用户自定义的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进行压缩和解压缩。