HBase分布式数据库概述

一、HBase概述

HBase 是一个面向列式存储的分布式数据库，其设计思想来源于 Google 的 BigTable 论文。HBase 底层存储基于 HDFS 实现，集群的管理基于 ZooKeeper 实现。

HBase 良好的分布式架构设计为海量数据的快速存储、随机访问提供了可能，基于数据副本机制和分区机制可以轻松实现在线扩容、缩容和数据容灾，是大数据领域中 Key-Value 数据结构存储最常用的数据库方案。

二、HBase应用场景

HBase通常应用在 订单/消息存储、用户画像、搜索推荐、社交Feed流、安全风控、以及物联网时序数据等诸多场景。
如果业务场景里需要存储海量数据，并发读写非常高，而且并不需特别复杂的数据分析，那么强烈建议使用HBase。
HBase八大应用场景例举如下：
1、对象存储：不少的头条类、新闻类的的新闻、网页存储在HBase之中，一些病毒公司的病毒库也是存储在HBase之中。
2、时序数据：HBase之上有OpenTSDB模块，可以满足时序类场景的需求。
3、推荐画像：特别是用户的画像，是一个比较大的稀疏矩阵，蚂蚁的风控就是构建在HBase之上。
4、时空数据：主要是轨迹、气象网格之类，滴滴打车的轨迹数据主要存在HBase之中，另外在大一点的数据量的车联网企业，数据都是存在HBase之中。
5、CubeDB OLAP：Kylin一个cube分析工具，底层的数据就是存储在HBase之中，不少客户自己基于离线计算构建cube存储在HBase之中，满足在线报表查询的需求。
6、消息/订单：在电信领域、银行领域，不少的订单查询底层的存储，另外不少通信、消息同步的应用构建在HBase之上。
7、Feeds流：典型的应用就是xx朋友圈类似的应用。
8、NewSQL：之上有Phoenix的插件，可以满足二级索引、SQL的需求，对接传统数据需要SQL非事务的需求。

三、HBase特点

3.1易扩展

Hbase 的扩展性主要体现在两个方面，一个是基于运算能力（RegionServer） 的扩展，通过增加 RegionSever 节点的数量，提升 Hbase 上层的处理能力；另一个是基于存储能力的扩展（HDFS），通过增加 DataNode 节点数量对存储层的进行扩容，提升 HBase 的数据存储能力。

3.2 海量存储

HBase作为一个开源的分布式 Key-Value 数据库，其主要作用是面向 PB 级别数据的实时入库和快速随机访问。这主要源于上述易扩展的特点，使得 HBase 通过扩展来存储海量的数据。HBase单表可以很庞大，加上其分布式、高伸缩性的特点，使得HBase特别适合海量数据的永久性存储。

3.3 列式存储

HBase是根据列族来存储数据的。列族下面可以有非常多的列。列式存储的最大好处就是，其数据在表中是按照某列存储的，这样在查询只需要少数几个字段时，能大大减少读取的数据量。

3.4 高可靠性

WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失，Replication 机制保证了在集群出现严重的问题时，数据不会发生丢失或损坏。而且 Hbase底层使用 HDFS，HDFS本身就有多副本机制，保证了数据的可靠性。

3.5 稀疏性

在 HBase的列族中，可以指定任意多的列，null值的列不占用存储空间，表可以设计得非常稀疏。

3.6多版本

HBase支持多版本，每一个单元格包含timestamp时间戳，标识着数据的版本号。

四、HBase劣势

4.1数据分析能力弱

数据分析是HBase的弱项，比如聚合运算、多维度复杂查询、多表关联查询等。一般通过在HBase之上架设Phoenix或Spark等组件，增强HBase数据分析处理的能力。

4.2原生不支持二级索引

默认HBase只对rowkey做了单列索引，因此正常情况下对非rowkey列做查询比较慢。一般会选择一个HBase二级索引解决方案，目前比较成熟的解决方案是Phoenix，此外还可以选择Elasticsearch/Solr等搜索引擎自己设计实现。

4.3 原生不支持SQL

SQL查询也是HBase的一个弱项，好在这块可以通过引入Phoenix解决，Phoenix是专为HBase设计的SQL层。

五、HBase架构

5.1 HBase架构组成

HBase 可以将数据存储在本地文件系统，也可以存储在 HDFS 文件系统。在生产环境中，HBase 一般运行在 HDFS 上，以 HDFS 作为基础的存储设施。HBase 通过 HBase Client 提供的 Java API 来访问 HBase 数据库，以完成数据的写入和读取。
HBase 的核心架构由五部分组成，分别是 HBase Client、HMaster、Region Server、ZooKeeper 以及 HDFS。

HBase整体生态架构组成如下：

HBase构成图

5.2 HBase组件构成

5.2.1 HBase Client

Hbase Client为用户提供了Shell命令行接口、原生Java API编程接口、Thrift/REST API编程接口以及MapReduce编程接口，支持常见的DML（增删改查）操作和DDL（表的维护）操作
在客户端访问数据行之前，先通过元数据表定位所要访问的数据所在的RegionServer，同时将元数据缓存在Client本地，如果数据发生了迁移，需要重新请求并缓存。

5.2.2 Master

Master是HBase集群的主节点，是所有Region Server的管理者，以及管理Region给谁维护，其实现类为 HMaster，类似于管理关系型数据库的DDL。
主要作用如下：
1) 为HRegionServer分配HRegion
    负责启动的时候分配HRegion到具体的HRegionServer。
    在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上。

2) 负责HRegionServer的负载均衡
   负责将用户的数据均衡地分布在各个HRegion Server上，防止HRegionServer数据倾斜过载。
   负责将用户的请求均衡地分布在各个HRegion Server上，防止HRegionServer请求过热。

3) 维护数据
   发现失效的HRegionServer并重新分配其上的HRegion到正常的RegionServer上。
   在HRegionSever 失效的时候，协调对应的HLog进行任务的拆分。

4) 用户操作管理
   管理用户对table的create, delete, alter操作。
   管理namespace和table的元数据。
   权限控制（ACL）。

5.2.3 HRegion Server

Region Server为 Region的管理者，RegionServer维护Master分配给它的Region，其实现类为 HRegionServer。Region里面为Store，存储实际的数据。一开始数据存在内存，到一定时机，存储到磁盘，即Storefile。对数据的增删改查，类似于管理关系型数据库的DML。
Region Server直接响应用户的读写请求(get/put/delete)，由WAL（HLog）和多个Region组成。

主要作用如下:
1) 管理HMaster为其分配的 Region。
2) HRegionServer维护HRegion，处理对这些HRegion的IO请求。
3) 读写HDFS，管理Table中的数据, HRegionserver负责切分在运行过程中变得过大的Region以及 StoreFile的合并工作。
4) Client直接通过HRegionServer读写数据（从HMaster中获取元数据，找到RowKey所在的HRegion/HRegionServer后）。
5) 与 HMaster 的协同：当某个RegionServer 宕机之后，ZK 会通知 Master 进行失效备援。下线的 RegionServer所负责的Region 暂时停止对外提供服务，Master 会将该 RegionServer 所负责的Region 转移到其他 RegionServer 上，并且会对所下线的 RegionServer 上存在 MemStore 中还未持久化到磁盘中的数据由 WAL 重播进行恢复。

5.2.4 HRegion

1) HRegion：数据表的一个分片，每个表开始只有一个HRegion，当数据表的HRegion大小达到一个阈值时会被HRegioServer水平切分成两个新的HRegion。
2) HRegion是Hbase中分布式存储和负载均衡的最小单元，但并不是存储的最小单元。
    通常一个表的HRegion分布在集群的多个HRegionServer上，一个HRegionServer有多个HRegion，一般来自不同的表。
3) 一个HRegion由一个或多个Store组成，Store的个数取决于列簇的数量，每个列簇的数据会集中存放。
4) Region：每一个HRegion都有起始RowKey和结束RowKey，代表了存储的Row的范围，保存着表中某段连续的数据。

5.2.5 Store

1) Store
   每一个HRegion 由多个Store 组成，每个Store都对应一个Column Family，Store包含MemStore 和 StoreFile，有几个列族，也就有几个Store。

2) StoreFile
   保存实际数据的物理文件， StoreFile 以 HFile 的形式存储在 HDFS 上。每个Store会有一个或多个StoreFile（HFile），数据在每个 StoreFile 中都是有序的。
   MemStore 内存中的数据写到文件后就是StoreFile，StoreFile底层是以 HFile 的格式保存。HBase以Store的大小来判断是否需要切分Region。

3) MemStore
   作为HBase的内存数据存储，数据的写操作会先写到 MemStore 中，当MemStore 中的数据增长到一个阈值（默认64M）后，HRegion Server 会启动 flasheatch 进程将 MemStore 中的数据写入 StoreFile 持久化存储，每次写入后都形成一个单独的 StoreFile。
   当客户端检索数据时，先在 MemStore中查找，如果MemStore 中不存在，则会在 StoreFile 中继续查找。
4) Hfile
    HFile是Hadoop的二进制格式文件。StoreFile底层是以HFile的格式保存。
    HFile 和 StoreFile 是同一个文件，站在 HDFS 的角度称这个文件为HFile，站在HBase的角度就称这个文件为StoreFile。

5) WAL(HLog)
实现数据的高可靠性
数据会先写入MemStore(缓存)，再异步刷新落盘，为防止缓存数据丢失，写入缓存之前先顺序写入HLog文件，当HBase出现故障时可以通过HLog日志来进行恢复。
HLog文件会定期滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。

实现HBase集群间的主从复制
通过将主集群的HLog日志进行回放来实现复制功能。

5.2.6 Zookeeper

Client客户端先请求到Zookeeper，再请求到RegionServer，Zookeeper分担HMaster给客户端请求表操作的功能。
HBase通过ZooKeeper 来完成选举HMaster、监控Region Server、维护元数据集群配置等工作。
1) 保证HMaster高可用
    通过zookeeper来保证集群中有一台HMaster在运行，如果HMaster宕机或异常，则会通过选举机制选举出新的HMaster提供服务，保证系统正常运转。

2) 监控Region Server
    监控 HRegion Server 的状态，通过心跳感知是否宕机，当HRegion Server 有异常的时候，通过回调的形式通知 HMaster 有关HRegion Server 上下线的信息。

3) 维护元数据和集群配置
    通过ZooKeeper储存信息并对外提供访问接口。

4) 实现分布式表锁
    对一个表进行操作时需要先加表锁，Zookeeper通过特定机制可以实现分布式表锁。

5.2.7 HDFS

HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的支持。
HDFS存储实际数据，HBase内部通过DFSClient组件来对HDFS的数据进行读写访问。