Hbase架构
Hbase架构
#hadoop/hbase
物理存储结构：
一： 整体结构
-
Table 中的所有的行都按照row key的字典序列排列
-
Table 在行的方向上分割为多个region
-
region按大小分割的（10G），每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阈值的时候，region
就会等分为两个新的region。当table中行不断增多，就会有越来越多的region -
region是hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的region可以分布在不同的regionserver上。但一个region是不会拆分到多个server上
-
::region虽然是负载均衡最小单元，但不是物理存储的最小单元。::
事实上。region由一个或者多个store组成，每个store保存一个column family。
每个store又由一个memstore和0至多个storeFile组成
Write-Ahead-log（WAl）机制：（高可靠和容错体现）
该机制用于数据的容错和恢复：
每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write-Ahead-Log的类，在用户操作写入MemStore的同时，也会写一份数据放到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。
当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应的region的目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load Region的过程中，会有历史HLog需要处理，因此会Replay HLog中的数据打拼MemStore中，然后有StoreFiles。完成数据恢复
Hbase总体架构图如下
storeFile & HFile结构
store以HFile格式保存在hdfs上。
HFile的格式为：
首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和FileInfo。正如图中所示的，Trailer中有指针指向其他数，据块的起始点。
FileInfo中记录了文件的一些Meta信息，例如：avg_key_len,avg_value_len,last_key,comparator,max_seq_id_key 等
DataIndex和MetaIndex块记录了每个Data块和Meta块的起始点。
Memstore 与storefile
一个region由多个store组成，每个store包含一个列族的所有的数据
store包括位于内存的memstore和位于硬盘的storefile
写操作先写入memstore,当memstore中的数据量达到某个阈值，Hregionserver启动flashcache进程写入storefile,每次写入形成单独一个storefile
当storefile大小超过一定阈值后，会把当前的region分割成两个，并由Hmaster分配给相应的region服务器，实现负载均衡
客户端检索数据时，先在memstore找，找不到再找storefile
Hlog
WAl（Write ahead log）类似mysql中的hinlog，用来做灾难恢复y用，Hlog记录数据的所有变更，一旦数据修该，就可以从log中进行恢复
每个Region server维护一个Hlog，而不是每个region一个，这样不同region（来自不同table）
的日志会混在一起，这样做的目的是不断追加单个文件相对同时写多个文件而言，可以减少磁盘的寻址次数，因此可以提高对table的写性能。
带来麻烦的是，如果一台region server下线，为了恢复其上的region，需要将regionServer的log进行拆分，然后分发到其他region server
上进行恢复
HLog文件就是一个普通的Hadoop Sequence File：
HLog Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是”写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number。
HLog Sequece File的Value是HBase的KeyValue对象，即对应HFile中的KeyValue，可参见上文描述。
Hbase容错性
-
Maser容错：zookeeper重新选择一个新的Master
无master过程中。数据读取仍照常进行 ，但是region切分，负载均衡等无法进行 -
RegionServer容错：定时向zookeeper汇报心跳，如果一段时间内未出现心跳，Madster 将RegionServer 上的Region重新分配到其他的RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer
-
zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个zookeeper实例
Master
- master上线
master启动进行一下步骤：
1.从zookeeper上获取唯一一个代表active master 的锁，用来阻止其他master成为master
2.扫描zookeeper上的server父节点，获得当前可用的region server 的对应列表
3.和每个region server通信，获得当前已分配的region 和region server的对应关系
4.扫描 .META.region 的集合，计算得到当前还未分配的region，将他们放入待分配region列表 - master下线
由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有的元数据的
修改被冻结（无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region
上下线，无法进行region的合并，，唯一例外的是region的split可以正常运行，因为只有region server
参与），表的数据读写还可以正常进行。因此master下先短时间对整个hbase集群没有影响。
从上下线过程看到，mater保存的信息全是可以冗余信息（都可以从系统其他地方收集到或者计算出来）
因此，一般hbase集群总总是有一个master在提供服务，还有一个以上的master在等待时机抢占她的位置
Master工作机制：
1.感知regionser的在线情况
2.分配region给region server
3.感知regionServer的负载情况，进行region均衡分配、转移
Hbase组件
第一层：client ,zookeeper.hmaster
第二层：hregionserver：hregion ,hlog ,hregion:store ,memstore,storefile,hfile
client :
hbase的客户端，包含访问hbase的接口（linux shell，java api）
client维护者一些cache来加快对hbase的访问，比如region的位置信息
zookeeper：
监控master的状态，保证有且仅有一个active的master，达到高可用
存储所有的region的寻址入口 —root表在哪台服务器上
实时监控hregionserver的状态，将regionserver的上下线信息实时的通知给master
存储hbase的所有表信息（hbase的schema），包括表名，列簇（column family）
hmaster：（hbase的老大）
为regionserver分配region（新建hbase表等）
负责region的负载均衡
负责hregion的重新分配（regionserver异常，hregion变大时的一分为二）
hdfs上的垃圾文件回收
处理schema的更新请求
hregiionserver：（hbase小弟）
regionserver维护master分配给它的region（管理region）
处理client对region的io请求，并和hdfs进行交互
regionserver 负责切分 在运行过程中变大的region
hregion：表或者表的一部分
hlog：对hbase的操作进行记录，使用wal写数据，优先写去到hlog里面，然后写到memstore，以防数据丢失可以进行回滚
hfile：hbase中数据以hfile的形式存储到hdfs中。
store:相当于一个列簇
-
memstore：内存缓冲区，用于进行批量刷新数据到hdfs上
-
hstorefile：hbase中的数据已hfile的形式储存到hdfs中
-
各组件之间的数量关系：
hmaster：hregionserver=1：n
和regionserver：hlog=1：1
hregionserver：hregion=1：n
hregion：store=1：n
store：memstore=1：1
store：storefile=1：n
storefile：hfile=1：1
Region管理
region分配
任何时刻，一个region只能分配给一个region server。master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。当需要分配的新的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。region server得到请求后，就开始对此region提供服务。
region server上线
master使用zookeeper来跟踪region server状态。当某个region server启动时，会首先在zookeeper上的server目录下建立代表自己的znode。由于master订阅了server目录上的变更消息，当server目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息。
region server下线
当region server下线时，它和zookeeper的会话断开，zookeeper而自动释放代表这台server的文件上的独占锁。master就可以确定：
1 region server和zookeeper之间的网络断开了。
2 region server挂了。
无论哪种情况，region server都无法继续为它的region提供服务了，此时master会删除server目录下代表这台region server的znode数据，并将这台region server的region分配给其它还活着的同志。
hbase的特点：
模式：无模式
数据版本：单一 byte[]
多版本：每个值可以保存多个版本
列式存储：每个列簇的数据存储到一个文件里
稀疏存储：如果key value为null时，整个数据不会占用存储空间
hbase的关键字：
rowkey:相当于mysql的主键，不允许重复，有顺序
column family:列簇（列的集合）
column:列
timestamp：时间（时间显示最新的时间戳）
version：版本号
cell：单元格