HBase架构理解_wal hbase类似于 mysql binlog

HBase架构理解

client
	hbase有两张特殊的表
	.META:记录了用户所有表拆分出来的region映射信息，.META 可以有多个region
	-ROOT-:记录了.META表的region信息，-ROOT-只有一个Region,无论如何不会分裂
	client 访问用户数据前需要先访问zookeeper,找到-ROOT-表的Region所在的位置，然后访问-ROOT-表，接着访问.META表，最后才能找到用户数据的位置去访问，中间需要多次网络操作
	不过client端会做cache缓存
Zookeeper
	1、zookeeper为hbase提供failover机制，选举master,避免单点master单点故障问题
	2、存储所有region的寻址入口：-ROOT-表在哪台服务其上，—ROOT-这张表的位置信息
	3、实时监控RegionServer的状态，将RegionServer的上线和下线信息实时通知给Master
	4、存储HBase的Schema,包括有哪些Table,每个Table有哪些Column Family
Master
	1、为RegionServer分配Region
	2、负责RegionServer的负载均衡
	3、发现失效的RegionServer并重新分配其上的Region
	4、HDFS上的垃圾文件(Hbase)回收
	5、处理Schema更新请求(表的创建，删除，修改，列簇的增加等等)
RegionServer
	1、RegionServer维护Master分配的Region,处理对这些Region的io请求
	2、RegionServer负责split在运行过程中变得过大的Region,负责Compact操作
	client 访问HBase上的数据并不需要Master参与，(寻址访问zookeeper和RegionServer,数据读写访问RegsionServer,
	,Master仅仅维护Table和Region的元数据信息，负载很低。)
	.META村的是所有的Region 信息，当RegionServer中的Region在进行分裂之后新产生的Region,是由
	Master来决定发到哪个RegionServer,意味着，只有Master知道new Region的位置信息，
	所以，由MAster来管理.META这个表的增删改查
	综上所述：在没有Region分裂的情况，Master宕机一段时间时可以忍受的。
HRegion
	table在行的方向分为多个region,region时hbase中分布式存储和负载存储的最小单元，即不同的region可以分别在不同的RegionServer上，
	但同一个Region时不会拆分到多个server上。
	Region按大小分割，每个表一般是只有一个region.随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值，就会分成两个新的region
store
	每一个region由一个或多个store，一个hlog组成，hbase会把一起访问的数据放在一个store里面，即为每个ColumnFaily建一个store,
	如果有几个ColumnFamily，也就有几个store，一个store由一个memstore和0或多个StoreFile组成，hbase以当前region下的store总量的大小来判断是否需要切分region
memstore
	memstore是放在内存里面的。保存修改的数据即KV数据。当memstore的大小达到阈值(默认129M)时，memstore里的数据就会被flush到文件中
	，生成一个快照。目前hbase会有一个线程来负责memStore的flush操作
StoreFile
	memstore内存中的数据写到文件后就是StoreFile,StoreFile底层是以HFile的格式保存。当StoreFile文件的数量增长到一定阈值后，
	系统会进行合并，在合并过程中会进行版本合并和删除工作，形成更大的storeFile
HFile
	Hbase中keyvalue数据的存储格式，Hfile是Hadoop的二进制格式文件，实际上storefile就是对hfile做了轻量级的包装，即 storefiel底层就是Hfile
HLog
	HLog(WAL Log):Write ahead log,用来做灾难恢复使用，Hlog记录所有数据的变更，一旦regionserver宕机，数据可以从Hlog中恢复
	

1、table的数据存储按照rowkey的hash字典序来进行排列
2、table在行的方向分为多个region
3、HRegion按大小分割(默认10G)，每个表一开始只有一个HRegion,随着数据不断插入表，HRegion不断增大，当增大到一个程度后，HRegsion
就会分为两个新的Hregion。
4、HRegion是HBASE中分布式存储和负载均衡的最小单元，最小单元表示不同的HRegion可以分布在不同的HRegionServer上，但一个HRegion是不会分布到多个server上的。
5、HRegion虽然是负载均衡的最小单元，但并不是物理存储的最小单元，事实上，HRegion由一个或者多个store组成，每个store保存一个Column Failly即每个store保存一个列簇。每个store又是一个memstore和0至多个storefile组成，当写入memstore中的数据达到128M时刷入到一个storefile,因此，每个storefile的大小为128M

StoreFile和HFile的结构
StoreFile以Hfile的格式保存在HDFS上

Trailer中有指针指向其他数据块的起始点
FileInfo中记录了文件的一些meta信息
HFile文件分为6部分：
DataBlock :保存表中的数据，可以被压缩
MetaBlock :保存用户自定义的KV堆，可以被压缩
FileInfo :HFile的元信息
Data Block INdex :datablock的索引，每条索引的key是被索引的block的第一条记录的key
metaBlock index :meta block的索引
Trailer段：这一段是定长的，保存了每一段的偏移量，读取一个Hfile时，会先读取Trailer,Trailer中保存了每个段的起始位置,然后将datablockindex读取到内存中，检索某个key时，不需要扫描整个Hfile，而只需要从内存中找到key对应的block，然后通过一次磁盘io将整个block数据读取到内存中，再找到需要的key.datablockindex 采用LRU机制淘汰。
	
	
因此HFile的dataBlock,meta Block通常采用压缩方式存储，减少网络io和磁盘io,当然增大cpu的消耗
HFile目前压缩方式Gzip,lzo

memstore和StoreFile
一个HRegion由多个Store组成，每个Store对应一个列簇的所有数据
Store包括位于内存的一个memstore和位于硬盘的多个Storefile组成。
写操作先写入memstore,当数据达到128M默认阈值时候，写入storefile，每次写入形成单独的Hfile，当总storefile超过一定阈值后，会把当前的
region分成两个，并由HMaster分配给相应地region服务器实现负载均衡。
当客户端检索数据时，先在memstore中找，找不到再去storefile中找。

HBASE wal Hlog
该log类似于mysql中的binlog用来做灾难恢复，Hlog记录数据的所有变更，一旦数据修改，就可以从log中修复

每个regionServer上维护一个Hlog,而不是每个Region一个。这么做虽然会让日志变得混杂，但是可以减少磁盘寻址次数，
因此可以提高对table的写性能，

region寻址机制
1、老的寻址方式
	—ROOT-表和.META.表，其中—ROOT-的位置存储在zookeeper中，—ROOT-本身存储了.META.Table的RegionInfo的信息，并且-ROOT-不会分裂
	只有一个region.而.META.表可以被切分成多个Region.
	详细步骤：
	1.client请求zookeeper获得-ROOT-所在的RegionServer地址
	2.client请求-ROOT-所在的RegionServer地址，获取.META.表的地址，cient或将-ROOT-的相关信息cache下来，以便下次快速访问
	3.client请求.META.表的RegionServer获取数据所在的RegionServer的地址，client会将.META.的相关信息cache下来，以便下次快速访问
	4.client请求访问RegionServer的地址
	5.首先去对应的memstore中取，取不到的情况下，读取storefile的Trailer,cache datablockindex到内存中，找到对应的data block,然后将整个block数据读入内存，找到所需的数据。
2、新的寻址方式(因为两层读取即能满足寻找大批量的数据，切两层会提高性能，因此将-ROOT-表给去掉了)
	1.client请求zookeeper获得.META.所在的RegionServer地址
	2.client请求.META.所在的RegionServer,获取数据所在的REgionServer地址，client会缓存.META.相关信息缓存下来
	4.client请求访问RegionServer的地址
	4.首先去对应的memstore中取，取不到的情况下，读取storefile的Trailer,cache datablockindex到内存中，找到对应的data block,然后将整个block数据读入内存，找到所需的数据。

client会缓存.META.或者-ROOT-,但是如果发生了分裂等变动，那么client就会出错，当异常达到阈值就会重新会获取最新的位置信息。

读写过程：
1.读请求
	client-->-ROOT-/.META.找到目标数据的regionServer--->对应的目标数据的RegionServer--->定位region,发出查询请求---->memstore---storefile
2.写请求
	1、client根据rowkey找到对应的region所在的RegionServer,因为hbase是按照rowkey字典序排列的
	2、client向regionServer提交写请求
	3、regionServer找到对应region
	4、region检查数据是否与表的schema一致（即列簇一致）
	5、如果客户端没有指定版本，则获取当前系统时间作为数据版本
	6、将更新写入 wal log
	7、将更新写入memstore
	8、判断memstore是否需要flush为storefile文件

	根据rowkey定位regionServer (因为.META.表存储了每张表每个region的起始rowkey了)
	
	数据在更新的时候先写入Hlog,让后写入memstore,memstore中的数据是排序的，当memstore累计到一定阈值的时候，就会创建一个新的memstore，并且将老的memStore添加到flush队列中，
由单独的线程flush到磁盘中，成为一个storefile.同时，系统会在zookeeper中记录一个 checkpoint,便是这个时刻之前的数据已经持久化了，当系统
发生异常，可能导致memstore数据丢失，此时，用Hlog来恢复checkpoint之后的数据
	同样的，HLog会定期滚动删除旧的数据文件(已经持久化到storefile上的数据)，
	
	
RegionServer工作机制：
1.region分配
	任何时刻，一个region只能分配给一个regionServer,master记录了当前可用的regionServer,y以及当前哪些region分配给了哪些regionserver
	哪些region还没有分配，当需要分配新的region,  会把它分配给一个有可用空间的regionServer.

2.RegionServer上线
	master使用zookeeper来跟踪regionServer的状态，当某个RegionServer启动时，会首先在zookeeper的server目录下建立znode,由于master订阅了
	该server目录的变更，因此master能够得到zookeeper的实时感知。

3.regionServer下线
	regionServerx下线，会断开和zookeeper的会话,master就会认为regionServer 不可用，就会删除server目录下的对应znode数据，并重新分配这台
RegionSErver的region给其它或者的RegionServer.

Master工作机制
1.master上线
	1.从zookeeper上获取唯一一个代表active master的锁，用来阻止其他master成为master
	2.扫描zookeeper上的server目录的znode获取当前可用的regionServer列表
	3.和每个regionServer通信，获取当前以分配的region和regionSErver的对应关系。
	4.扫描.META. region的集合，计算当前未分配的region,放入待分配列表进行分配。
2.master下线
	由于master只参与region的分裂和regionserver 以及维护.META.表，因此，master下线不会影响正常的读写，但是此时不能创建表，修改该表
	region分裂，regionServer上下线等。
	下线完毕，zookeeper会释放该master的active master锁，另外一个备用的master上线
	因此一个hbase集群中总是有两个master,一个是active状态，一个是standby状态
	
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146