hbase系统架构
Client
1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。
Zookeeper
1 保证任何时候，集群中只有一个master
2 存贮所有Region的寻址入口
3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master
4 存储Hbase的schema,包括有哪些table，每个table有哪些column family
Master职责
1 为Region server分配region
2 负责region server的负载均衡
3 发现失效的region server并重新分配其上的region
4 HDFS上的垃圾文件回收
5 处理schema更新请求
Region Server职责
1 Region server维护Master分配给它的region，处理对这些region的IO请求
2 Region server负责切分在运行过程中变得过大的region
可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。
HBase的表数据模型
Row Key
row key是用来检索记录的主键，访问hbase table中的行，只有三种方式：
1 通过单个row key访问
2 通过row key的range
3 全表扫描
Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组。
Hbase会对表中的数据按照rowkey排序(字典顺序)
列族Column Family
hbase表中的每个列，都归属与某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。
列名都以列族作为前缀。例如courses:history ， courses:math 都属于 courses 这个列族。
访问控制、磁盘和内存的使用统计都是在列族层面进行的。
列族越多，在取一行数据时所要参与IO、搜寻的文件就越多，所以，如果没有必要，不要设置太多的列族
列 Column
列族下面的具体列，属于某一个ColumnFamily,类似于我们mysql当中创建的具体的列
时间戳
时间戳可以由
hbase(
在数据写入时自动
)
赋值，工程师也可以自己设置时间戳。
不同版本的数据按照时间倒序排序。
Cell
由{row key, column( =<family> + <label>), version} 唯一确定的单元。
cell中的数据是没有类型的，全部是字节码形式存贮。
VersionNum
数据的版本号，每条数据可以有多个版本号，默认值为系统时间戳，类型为Long
hbase物理存储结构
1 Table中的所有行都按照row key的字典序排列。
2 Table 在行的方向上分割为多个Hregion。
3 region按大小分割的(默认10G)，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阈值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。
4 Hregion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。
5 HRegion虽然是负载均衡的最小单元，但并不是物理存储的最小单元。
事实上，HRegion由一个或者多个Store组成，每个store保存一个column family。
每个Strore又由一个memStore和0至多个StoreFile组成。
一个regionserver
内可以存储多个表的
region
一个表内的region,
只属于这个表。但是这个表的
region,
可能分配到不同的节点（
regionserver
）上。
Memstore与storefile
一个region由多个store组成，每个store包含一个列族的所有数据
Store包括位于内存的memstore和位于硬盘的storefile
写操作先写入memstore,当memstore中的数据量达到某个阈值，Hregionserver启动flashcache进程写入storefile,每次写入形成单独一个storefile，输出多个storefile后，当storefile数量达到阈值时，将多个合并成一个大的storefile。
当storefile大小超过一定阈值后，会把当前的region分割成两个，并由Hmaster分配给相应的region服务器，实现负载均衡
客户端检索数据时，先在memstore找，找不到再找storefile
HLog(WAL log)
WAL log类似mysql中的binlog,用来 做灾难恢复时用，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。
每个
Region Server
维护一个
Hlog,
而不是每个
Region
一个。
弊端：数据的写入速度相对较慢，慢的原因是数据写操作执行两次。
Hlog
日志可以关闭，关闭后写入速度能够加快，但是存在数据丢失的风险。
Hlog
日志的拆分
1
、放数据写入日之后，如果发生异常，那么就会关闭当前日志文件，
2
、日志人间大小维度：当日志文件大小达到 一定的量时，就会关当前日志，生成新的日志。
日志的大小是
HDFS
数据块大小的
0.95
倍。
3
、时间维度：默认的时间为
1
小时，即一个小时生成一个日志文件
读写过程
读请求过程：
1
、首先
Client
先去访问
zookeeper
，从
zookeeper
里面获取
meta
表所在的位置信息
2
、
Client
通过刚才获取到的
IP
来访问
Meta
，读取
Meta
内的数据，
3
、
Client
通过元数据（
meta
表内的数据
）中存储的信息，找到
region
在哪个
HRegionServer
，访问对应的 HRegionServer读取数据
写请求过程：
1 Client
先访问
zookeeper
，找到
Meta
表，并获取
Meta
表元数据。确定将要写入的数据所对应的
HRegion
和 HRegionServer服务器。
2 Client
向该
HRegionServer
服务器发起写入数据请求
3 Client
先把数据写入到
HLog
，以防止数据丢失。
4
然后将数据写入到
Memstore
。
5
若
Memstore
达到阈值，会把
Memstore
中的数据
flflush
到
Storefifile
中
6 Storefifile
数量达到阈值（默认
3
个）时，会触发
Compact
合并操作，把过多的
Storefifile
合并成一个大的Storefifile
说明
:
支持数据更新（伪更新），这里的更新实际上时数据的新添加。
region 的管理
前提：一个region只能分配给一个region server。
1
、
master
记录了当前有哪些可用的
region server
。以及当前哪些
region
分配给了哪些
region server
，哪些
region 还没有分配。
2
、当需要分配的新的
region
，并且有一个region server
上有可用空间时，
master
就给这个
region server
发送一个 装载请求，把region
分配给这个
region server
。
3
、
region server
得到请求后，就开始对此
region
提供服务。
regionserver的上线
前提：
master
使用
zookeeper
来跟踪
region server
状态
1
、
region server
启动时，会首先在
zookeeper
上的
/hbase/rs
目录下建立代表自己的
znode
。
2
、
master
订阅了
/hbase/rs
目录上的变更消息，当
/hbase/rs
目录下的文件出现新增或删除操作时，
master
可以得 到来自zookeeper
的实时通知。
3
、一旦region server
上线，
/hbase/rs
有新增
node, zookeeper
通知
master,master
能马上得到消息
.
regionserver的下线
1
、当
region server
下线时，它和
zookeeper
的会话断开
2
、
zookeeper
而自动释放代表这台
server
的文件上的
node
3
、
zookeeper
通知
master, master
得知那个节点下线。
4
、
master
将这台
region server
的
region
分配给其它还活着的
regionserver.
Hmaster的上线
1
从
zookeeper
上获取唯一 一个代表active master
的锁，用来阻止其它
master
成为真正你的
master
。
2
扫描
zookeeper
上的
/hbase/rs
节点，获得当前可用的
region server
列表。
3
和每个
region server
通信，获得当前已分配的
region
和
region server
的对应关系。
4
描.META.表数据，计算得到当前还未分配的region
，将他们放入待分配
region
列表
Hmaster下线
master
只维护表和
region
的元数据，不参与表数据
IO
的过程，
master
下线短时间内对整个
hbase
集群没有影响。
长时间下线的影响：
无法创建删除表，无法修改表的
schema
，无法进行
region
的负载均衡，无法处理
region
上下线，无法进行
region
的合并，（region
的
split
可以正常进行）
master
下线，启用
Zookeeper
的选举机制，确定新的
master,
新
master
执行上线流程
