数据产品经理有必要了解的HBase

       本文是Hadoop生态体系组件之HBase的学习总结性文章。因本人非技术出身，所学均来源于网络，难免有不严谨甚至错误之处，恳请大家指正。

       在以前的文章中，提到了以文件形式存储数据的HDFS，但是在实际场景中，除了文件形式的数据外，还有大量结构化和半结构化的数据，这类数据通常需要支持更新操作，比如随机插入和删除，这使得HDFS很难满足要求。为了方便用户存取海量结构化和半结构化数据，HBase应运而生（全称：Hadoop Database）。它是一种NoSQL数据库，具有良好的扩展性、容错性。HBase是构建在分布式文件系统HDFS之上的、支持随机插入和删除的列簇式存储系统。

HBase特性

1、海量存储
       Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，HBase中真正能工作的机器量少，剩余的机器都处于空闲的状态，浪费资源。
2、列簇式存储
       Hbase是根据列簇来存储数据的。列簇下面可以有非常多的列，列簇在创建表的时候就必须指定。为了加深对Hbase列簇的理解，下面是一个简单的关系型数据库的表和Hbase的表对比图(CF即：Column Family，列簇，后续会详细讲)：

RDBMS表

Hbase表

3、极易扩展
       Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。
4、高并发
       由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多,能获得高并发、低延迟的服务。

HBase数据模型

       HBase数据模型包括逻辑数据模型和物理数据存储，其中逻辑数据模型是用户从数据库所看到的模型，它直接与HBase数据建模相关；物理数据模型是面向计算机物理表示的模型，描述了HBase数据在储存介质（包括内存和磁盘）上的组织结构，但是我们只讲数据模型。
       类似于常见关系型数据库中的database和table逻辑概念，HBase分别将之称为namespace和table，一个namespace中包含一组table, HBase内置了两个默认的namespace：
❑ hbase：系统内建表，包括namespace和meta表。
❑ default：用户建表时未指定namespace的表都创建在此。

       HBase的表由一系列行构成，每行数据有一个rowkey，以及若干column family构成，每个column family可包含无限列，具下图所示：

Hbase表

❑ rowkey：HBase表中的数据是以rowkey作为标识的，rowkey类似于关系型数据库中的“主键”，每行数据有一个rowkey，唯一标识该行，是定位该行数据的索引。同一张表内，rowkey是全局有序的。
❑ column family：Hbase表中数据是按照column family组织的，每行数据拥有相同的column family。column family属于schema的一部分，定义表时必须指定好，但每个column family可包含无数个动态列。column family是访问控制的基本单位，同一column family中的数据在物理上会存储在一个文件中。column family名称的类型是字符串，由一系列符合Linux路径名称规则的字符构成。
❑ column qualifier：column family内部列标识，Hbase每列数据可通过family:qualifier（比如CF1:col1）唯一标识，qualifier不属于schema的一部分，可以动态指定，且每行数据可以有不同的qualifier。跟rowkey一样，column qualifier也是没有数据类型的，以字节数组（byte[]）形式存储。
❑ cell：通过rowkey, column family和column qualifier可唯一定位一个cell，它内部保存了多个版本的数值，默认情况下，每个数值的版本号是写入时间戳。cell内的数值也是没有数据类型的，以数组形式保存。
❑ timestamp：cell内部数据是多版本的，默认将写入时间戳作为版本号。每个columnfamily保留最大版本数可单独配置，默认是3，如果读数据时未指定版本号，HBase只会返回最新版本的数值；如果一个cell内数据数目超过最大版本数，则旧的版本将自动被剔除。

HBase基本架构

       为了将数据表分布到集群中以提供并行读写服务，HBase按照rowkey将数据划分成多个固定大小的有序分区，每个分区被称为一个“region”，这些region会被均衡地存放在不同节点上。HBase是构建在HDFS之上的，所有的region均会以文件的形式保存到HDFS上，以保证这些数据的高可靠存储。
       HBase采用了经典的master/slave架构，如下图所示，与HDFS不同的是，它的master与slave不直接互连，而是通过引入ZooKeeper让两类服务解耦，这使得HBase master变得完全无状态，进而避免了master宕机导致整个集群不可用，HBase各个服务功能如下：

HBase基本架构

HMaster：可以存在多个，主HMaster由ZooKeeper动态选举产生，当主HMaster出现故障后，系统可由ZooKeeper动态选举出的新HMaster接管。HMaster本身是无状态的（所有状态信息均保存在ZooKeeper中），主HMaster挂掉后，不会影响正常的读写服务。HMaster主要有以下职责：
❑ 协调RegionServer：包括为RegionServer分配region，均衡各RegionServer的负载，发现失效的RegionServer并重新分配其上的region。
❑ 元信息管理：为用户提供table的增删改查操作。Client读写操作过程是不需要与HMaster进行交互的，而是直接与RegionServer通信来完成。
RegionServerRegionServer：负责单个Region的存储和管理（比如Region切分），并与Client交互，处理读写请求。
ZooKeeper：内部存储着有关HBase的重要元信息和状态信息，担任着Master与RegionServer之间的服务协调角色，具体职责如下：
❑ 保证任何时候，集群中只有一个master。
❑ 存储所有Region的寻址入口。
❑ 实时监控Region Server的上线和下线信息，并实时通知给Master。
❑ 存储HBase的schema和table元数据。
Client：提供HBase访问接口，与RegionServer交互读写数据，并维护cache加快对HBase的访问速度。

**好了，就简单的摘抄（本文很多是copy的）到这里。个人认为作为产品经理，只需要了解以上的内容即可。更多详细内容可以去查看原书。

参考资料：《大数据技术体系详解：原理、架构与实践》 作者：董西成**