一文入门HBase架构

前言

      谈到HBase的设计，可以讲的东西太多了，本文从HBase的架构设计以及存储设计来简单说明下HBase到底是怎么玩的，帮大家入门，为后续深入的学习以及研究起到提纲挈领的作用。

HBase架构设计

      借用这张经典的架构图，虚线以上代表的HBase相关的实现，虚线以下则代表着HBase依赖的底层HDFS相关的实现。

      HBase的角色有两种，即HMaster以及HRegionServer：

HMaster

      HMaster是Master Server的实现，负责监控和管理集群中的RegionServer实例，同时是所有metadata改变的入口，在集群中，通常运行在NameNode上面。

      HMaster可以配置多个来达到Master高可用，用以解决SPOF问题；但是为了避免出现脑裂问题，所有的master中只有一个是active状态的，其余都是standby状态，如果active状态的master failover了，那么standby的master会通过zookeeper来竞争上岗，成为active的master，如果曾经的active的master再次上线后，发现有active的master，则自己成为standby的master存在于集群中。

      此处划重点：如果master节点不可用，大部分情况下是不会耽误数据的读写，因为读写的入口是zookeeper，直到region的大小达到了split的阈值或者其他相关的元数据或者集群状态管理操作触发的时候

      Master运行的后台线程：LoadBalancer线程，控制region来平衡集群的负载。CatalogJanitor线程，周期性的检查hbase:meta表。

HRegionServer

     HRegionServer是RegionServer的实现，服务和管理Regions，真正的业务数据就存储在RegionServer中，也是对外提供读写服务的主体。在RegionServer上数据处理和存储使用的是LSM模型，即Memory-Flush-Compact流程，能够保证HBase的高并发和高吞吐量。集群中RegionServer运行在DataNode上，底层使用HDFS进行存储，集成HDFS的所有特点。

     RegionServer后台线程：CompactSplitThread，MajorCompactionChecker，MemStoreFlusher，LogRoller

     Regions：HBase逻辑上最小的单位，默认是10G大小（不同版本可能不同），超过改大小会进行split，分成两个大小相等的region，Region存储Table数据，里面的数据按字典序存储在硬盘上（部分数据在内存中）

     Table有多个Store(列簇)，Store有一个Memstore和多个StoreFiles(HFiles)，StoreFiles会在规则和配置下进行各种compact（minor和major），minor compact 会将StoreFiles的个数控制在一定范围内，major compact则会将一个region中所有的StoreFiles合并成一个，并在过程中处理部分动作（如数据真删，HBase属性修改如压缩方式修改等），所以该操作会消耗大量的资源，建议在业务低峰期定时执行。

      StoreFiles的底层是Block，Block是HBase物理上的最小单位。Block默认大小是64K，改大小可以根据业务场景进行调整。如get多于scan，则可以将该值适当减小；反之如果scan多于get，则可以适当增大该值。但是不建议随便修改该值，除非必要，否则保持默认即可，默认的值可以满足大部分场景需求。

存储设计

      在Hbase中，表被分割成多个更小的块然后分散的存储在不同的服务器上，这些小块叫做Regions，存放Regions的地方叫做RegionServer。Master进程负责处理不同的RegionServer之间的Region的迁移以及均衡。在Hbase实现中HRegionServer和HRegion类代表RegionServer和Region。HRegionServer除了包含一些HRegions之外，还处理两种类型的文件用于数据存储

        HLog：预写日志文件，也叫做WAL(write-ahead log)

        HFile ：真实的数据存储文件

HLog

       预写日志是在数据写入时优先写入的操作日志，用来做灾备处理，在集群节点宕机或者服务出现异常时，可以通过回放预写日志来将未成功写入到数据库的数据重新写入到HBase中，此操作进行完毕后HBase才会重新对外提供服务，保证了HBase数据的安全性。在某些场景下为了提高写入效率并且对数据的偶尔丢失不是很敏感，可以考虑禁用HLog。HBase会周期性检查HLog中过期的日志（已经完成入库的数据），并对这部分日志进行删除从而释放存储空间。

MasterProcWALs：HMaster记录管理操作，比如Region迁移，表创建和其它DDL操作到它的WAL文件中。HMaster的WAL也支持弹性操作，如果Master服务器挂了，其它的Master接管的时候继续操作这个文件。

WALs：该目录记录所有RegionServer的WAL日志，存储了HBase所有的数据改变。目录里面按照regionserver/region的层级对WAL日志进行了分组，方便在不同级别的组件失效再上线后能快速的取到对应的WAL进行重放。如果一个RegionServer在MemStore进行FLush的时候挂掉了，WAL可以保证数据的改变在该RegionServer上原有的所有Region在其他RegionServer上重新上线时被重放执行，保证数据不会丢失。如果写WAL失败了，那么修改数据的完整操作就是失败的。

通常情况，每个RegionServer只有一个WAL实例。在2.0之前，WAL的实现叫做HLog

WAL默认位于HDFS的/hbase/目录下，其中HMaster的HLog存储在MasterProcWALs目录下，而不是RegionServer的Hlog存储在WALs目录下。

MultiWAL: 如果每个RegionServer只有一个WAL，由于HDFS必须是连续的，导致必须写WAL连续的，然后出现性能问题。MultiWAL可以让RegionServer同时写多个WAL并行的，通过HDFS底层的多管道，最终提升总的吞吐量，但是不会提升单个Region的吞吐量。

HFile

HFile是HBase在HDFS中存储数据的格式，它包含多层的索引，这样在HBase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，每个RegionServer底层使用的HDFS的Block大小设置为1GB也是常见的。此处需要区分HDFS的Block以及RegionServer的Block（上面HRegionServer章节已经介绍）

Hfile生成方式

起初，HFile中并没有任何Block，数据还存在于MemStore中。

Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。

而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：

注：此处HFile提供了两种优化处理方式：Data Block Encoding以及Column Family Compress，详情参见HBase数据压缩 Column family Compress & Data Block Encoding

总结

        上述就是HBase的相关设计，还有很多这里没讲，需要的话大家可以自己去研究，另外很多细节设计HBase替我们都完成了，对用户透明，降低了HBase的使用成本。当今，HBase已经广泛的运用在很多场景下，HBase的很多思想也被其他后来的数据库采用并发扬光大，所以HBase还是很值得大家学习和研究一下的，但是HBase的使用门槛还是有的，希望大家努力的用好HBase，成为大家业务和数据处理中的利器。

 

传送门：HBase完整文档：HBase生产环境从入门到熟练使用，这一篇文章就够了