Hbase架构

下面这个图展示了Hbase是如何与Hadoop文件系统协作完成数据存储的

Hbase体系结构
一个HMaster 有多个HRegionServer
一个HRegionServer有多个HRegion
写入过程
Hlog(操作数据)—>MemStore(一个column family对应一个memstore,这个是内存，当到了值的时候 会flush到磁盘形成storefile)—->StoreFile—>HFile—->HDFS
1、client
包含访问hbase的接口并维护cache来加快对hbase的访问
2、zookeeper
保证任何时候，集群中只有一个master
存放所有Region的寻址入口
实时监控Region Server的上线和下线信息，并实时通知给master
存储hbase的schema和table元数据
3、master
为Region Server分配region
负责Region server 的负载均衡
发现失效的region Sever 并重新分配其上的region
管理用户对table的增删改查操作
4、Region Server
负责维护region 处理对这些region的IO请求
负责切分在运行过程中变得过大的region

从上面这个图我们可以看出Hbase主要处理两种文件:一种是预写日志文件(Write-Ahead Log,WAL)，另一种是实际的数据文件，这两种文件主要由HRegionServer管理，在某些情况下，HMaster也可以进行一些底层的文件操作,当存储数据到HDFS中时，用户可能注意到实际的数据文件会被切分成更小的块，也正是这一点，用户可以配置系统来更好的处理较大或较小的文件，

一个基本的流程是客户端首先联系zookeeper子集群查找行键，上述过程的通过zookeeper获取含有-ROOT-的region服务器名来完成的，通过含有-ROOT-的region服务器可以查询到含有.META.表中对应的region服务器名，其中包含了请求的行键信息。这两处的主要内容都被缓存下来了，并且都只查询一次，最终，通过查询.META.服务器来获取客户端查询的行键数据所在的region的服务器名。一旦知道了数据的实际位置，即region的位置，HBase会缓存这次查询的信息，同时直接联系管理实际数据的HRegionServer。所以，之后客户端可以通过缓存信息很好地定位所需的数据位置，而不用再次查找.META.表。

  注意：启动HBase时，HMaster负责将所有region分配到每个HRegionServer上，其中也包括特别的-ROOT-和.META.表

HRegionServer负责打开region，并创建对应的HRegion实例，当HRegion被打开后，它会为每个表的HColumnFamily创建一个Store实例，这些列族是用户之前创建表时定义的，每个Store实例包含一个或者多个StoreFile实例，这些是实际数据存储文件HFile的轻量级封装，每个store还有其对应的一个MemStore，一个HRegionServer分享了一个HLog实例。

写路径
当用户向HRegionServer发起HTable.put(put)请求时，其会将请求交给对应的HRegion实例来处理，第一步是要决定数据是否需要写到由HLog类实现的预写日志中，WAL是标准的Hadoop SequenceFile，并且存储了HLogKey实例，这些键包括序列号和实际数据，所以在服务器崩溃时可以回滚还没有持久化的数据。
一旦数据被写入到WAL中，数据就会被放到Memstore中，同时还会检查Menstore是否已经满了，如果满了，就会被请求刷写到磁盘中去，刷写请求由另外一个HRegionServer的线程处理，它会把数据写成HDFS中的一个新HFile。同时也会保存最后写入的序号，系统就知道哪些数据现在被持久化了。

关闭前预刷写
memstore被刷写到磁盘的第二个理由是：预刷写(prefushing),当region服务器被要求关闭时，会首先检查memstore，任何大于配置值hbase.hregion.preclose.flush.size的memstore会刷写到磁盘，然后在最后一轮阻塞正常访问的刷写后关闭region。
另一方面，关闭region服务器会强制所有的memstore被刷写到磁盘，而不会关心memstore是否达到了配置的最大值，可以使用配置项hbase.hregion.memstore.flush.size或者通过创建表来进行设置，一旦所有的memstore都被刷写到了磁盘，region会被关闭，且在转移到其他region服务器时不会重做WAL。