HBase架构理解

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状态