HBase的存储结构和关系型数据库不一样，HBase面向半结构化数据进行存储。所以，对于结构化的SQL语言查询，HBase自身并没有接口支持。在大数据应用中，虽然也有SQL查询引擎可以查询HBase，比如Phoenix、Drill这类。但是阅读这类SQL查询引擎的底层实现，依然是调用了HBase的Java API来实现查询，写入等操作。这类查询引擎在业务层创建Schema来映射HBase表结构，然后通过解析SQL语法数，最后底层在调用HBase的Java API实现。
本篇内容，笔者并不是给大家来介绍HBase的SQL引擎，我们来关注HBase更低层的东西，那就是HBase的存储实现。以及跨集群的HBase集群数据迁移。
2.内容HBase数据库是唯一索引就是RowKey，所有的数据分布和查询均依赖RowKey。所以，HBase数据库在表的设计上会有很严格的要求，从存储架构上来看，HBase是基于分布式来实现的，通过Zookeeper集群来管理HBase元数据信息，比如表名就存放在Zookeeper的/hbase/table目录下。如下图所示：
HBase是一个分布式存储系统，底层数据存储依赖Hadoop的分布式存储系统（HDFS）。HBase架构分三部分来组成，它们分别是：ZooKeeper、HMaster和HRegionServer。
ZooKeeper：HBase的元数据信息、HMaster进程的地址、Master和RegionServer的监控维护（节点之间的心跳，判断节点是否下线）等内容均需要依赖ZooKeeper来完成。是HBase集群中不可缺少的核心之一。
HMaster：HMaster进程在HBase中承担Master的责任，负责一些管理操作，比如给表分配Region、和数据节点的心跳维持等。一般客户端的读写数据的请求操作不会经过Master，所以在分配JVM内存的适合，一般32GB大小即可。
HRegionServer：HRegionServer进程在HBase中承担RegionServer的责任，负责数据的存储。每个RegionServer由多个Region组成，一个Region维护一定区间的RowKey的数据。如下图所示：
图中Region（dn2:16030）维护的RowKey范围为0001～0002。HBase集群的存储结构如下图所示：
Zookeeper通常由奇数个组成，便于分布式选举，可参考《分布式系统选举算法剖析》一文了解，这里不多赘述细节。HBase为了保证高可用性（HA），一般都会部署两个Master节点，其中一个作为主，另一个作为Backup节点。这里谁是主，谁是Backup取决于那个HMaster进程能从Zookeeper上对应的Master目录中竞争到Lock，持有该目录Lock的HMaster进程为主Master，而另外一个为Backup，当主Master发生意外或者宕机时，Backup的Master会立刻竞争到Master目录下的Lock从而接管服务，成为主Master对外提供服务，保证HBase集群的高可用性。
2.2 RegionServerHBase负责数据存储的就是RegionServer，简称RS。在HBase集群中，如果只有一份副本时，整个HBase集群中的数据都是唯一的，没有冗余的数据存在，也就是说HBase集群中的每个RegionServer节点上保存的数据都是不一样的，这种模式由于副本数只有一份，即是配置多个RegionServer组成集群，也并不是高可用的。这样的RegionServer是存在单点问题的。虽然，HBase集群内部数据有Region存储和Region迁移机制，RegionServer服务的单点问题可能花费很小的代价可以恢复，但是一旦停止RegionServre上含有ROOT或者META表的Region，那这个问题就严重，由于数据节点RegionServer停止，该节点的数据将在短期内无法访问，需要等待该节点的HRegionServer进程重新启动才能访问其数据。这样HBase的数据读写请求如果恰好指向该节点将会收到影响，比如：抛出连接异常、RegionServer不可用等异常。
3.日志信息HBase在实现WAL方式时会产生日志信息，即HLog。每一个RegionServer节点上都有一个HLog，所有该RegionServer节点上的Region写入数据均会被记录到该HLog中。HLog的主要职责就是当遇到RegionServer异常时，能够尽量的恢复数据。