HBase入门教程，Java400道面试题通关宝典助你进大厂_Java

4.regionandcolumnfamilies

keyvalue

keyvalue的设计不是源自bigtable，而是要追溯至论文”the log-structured merge-tree(lsm-tree)”。每一行中的每一列数据，都被包装成独立的拥有特定结构的keyvalue，keyvalue中包含了丰富的自我描述信息:

5.keyvalue

看的出来，keyvalue是支撑”稀疏矩阵”设计的一个关键点：一些key相同的任意数量的独立keyvalue就可以构成一行数据。但这种设计带来的一个显而易见的缺点：每一个keyvalue所携带的自我描述信息，会带来显著的数据膨胀。

适用场景

在介绍完了hbase的数据模型以后，我们可以回答本文一开始的前两个问题：

hbase的数据模型比较简单，数据按照rowkey排序存放，适合hbase存储的数据，可以简单总结如下：

以实体为中心的数据

实体可以包括但不限于如下几种：

自然人／账户／手机号／车辆相关数据
用户画像数据（含标签类数据）
图数据（关系类数据）

描述这些实体的，可以有基础属性信息、实体关系(图数据)、所发生的事件(如交易记录、车辆轨迹点)等等。

以事件为中心的数据
监控数据
时序数据
实时位置类数据
消息/日志类数据

上面所描述的这些数据，有的是结构化数据，有的是半结构化或非结构化数据。hbase的“稀疏矩阵”设计，使其应对非结构化数据存储时能够得心应手，但在我们的实际用户场景中，结构化数据存储依然占据了比较重的比例。由于hbase仅提供了基于rowkey的单维度索引能力，在应对一些具体的场景时，依然还需要基于hbase之上构建一些专业的能力，如：

opentsdb 时序数据存储，提供基于metrics+时间+标签的一些组合维度查询与聚合能力
geomesa 时空数据存储，提供基于时间+空间范围的索引能力
janusgraph 图数据存储，提供基于属性、关系的图索引能力

hbase擅长于存储结构简单的海量数据但索引能力有限，而oracle等传统关系型数据库(rdbms)能够提供丰富的查询能力，但却疲于应对tb级别的海量数据存储，hbase对传统的rdbms并不是取代关系，而是一种补充。

hbase与hdfs

我们都知道hbase的数据是存储于hdfs里面的，相信大家也都有这么的认知：

理解了这一点，我们先来粗略回答本文已开始提出的其中两个问题：

集群角色

我们假设集群环境已经ready了，先来看一下集群中的关键角色：

clusterroles

相信大部分人对这些角色都已经有了一定程度的了解，我们快速的介绍一下各个角色在集群中的主要职责(注意：这里不是列出所有的职责)：

zookeeper

在一个拥有多个节点的分布式系统中，假设，只能有一个节点是主节点，如何快速的选举出一个主节点而且让所有的节点都认可这个主节点？这就是hbase集群中存在的一个最基础命题。

利用zookeeper就可以非常简单的实现这类”仲裁”需求，zookeeper还提供了基础的事件通知机制，所有的数据都以 znode的形式存在，它也称得上是一个”微型数据库”。

namenode

hdfs作为一个分布式文件系统，自然需要文件目录树的元数据信息，另外，在hdfs中每一个文件都是按照block存储的，文件与block的关联也通过元数据信息来描述。namenode提供了这些元数据信息的存储。

datanode

hdfs的数据存放节点。

regionserver

hbase的数据服务节点。

master

hbase的管理节点，通常在一个集群中设置一个主master，一个备master，主备角色的”仲裁”由zookeeper实现。 master主要职责：

负责管理所有的regionserver
建表/修改表/删除表等ddl操作请求的服务端执行主体
管理所有的数据分片(region)到regionserver的分配
如果一个regionserver宕机或进程故障，由master负责将它原来所负责的regions转移到其它的regionserver上继续提供服务
master自身也可以作为一个regionserver提供服务，该能力是可配置的

集群部署建议

如果基于物理机/虚拟机部署，通常建议：

regionserver与datanode联合部署，regionserver与datanode按1:1比例设置。

这种部署的优势在于，regionserver中的数据文件可以存储一个副本于本机的datanode节点中，从而在读取时可以利用hdfs中的”短路径读取(short circuit)“来绕过网络请求，降低读取时延。

deployment

管理节点独立于数据节点部署

如果是基于物理机部署，每一台物理机节点上可以设置几个regionservers/datanodes来提升资源使用率。

也可以选择基于容器来部署，如在hbasecon asia 2017大会知乎的演讲主题中，就提到了知乎基于kubernetes部署hbase服务的实践。

对于公有云hbase服务而言，为了降低总体拥有成本(tco)，通常选择”计算与存储物理分离“的方式，从架构上来说，可能导致平均时延略有下降，但可以借助于共享存储底层的io优化来做一些”弥补”。

hbase集群中的regionservers可以按逻辑划分为多个groups，一个表可以与一个指定的group绑定，可以将regionserver group理解成将一个大的集群划分成了多个逻辑子集群，借此可以实现多租户间的隔离，这就是hbase中的regionserver group特性。

示例数据

给出一份我们日常都可以接触到的数据样例，先简单给出示例数据的字段定义：

data-sample-definition

如上定义与实际的通话记录字段定义相去甚远，本文力求简洁，仅给出了最简单的示例。如下是”虚构”的样例数据：

data-sample

在本文大部分内容中所涉及的一条数据，是上面加粗的最后一行”mobile1“为”13400006666“这行记录。

写数据之前：建立连接

login

在启用了安全特性的前提下，login阶段是为了完成用户认证(确定用户的合法身份)，这是后续一切安全访问控制的基础。

当前hadoop/hbase仅支持基于kerberos的用户认证，zookeeper除了kerberos认证，还能支持简单的用户名/密码认证，但都基于静态的配置，无法动态新增用户。如果要支持其它第三方认证，需要对现有的安全框架做出比较大的改动。

创建connection

connection可以理解为一个hbase集群连接的抽象，建议使用connectionfactory提供的工具方法来创建。因为hbase当前提供了两种连接模式：同步连接，异步连接，这两种连接模式下所创建的connection也是不同的。我们给出connectionfactory中关于获取这两种连接的典型方法定义：

completablefuture createasyncconnection(configuration conf,

user user);

connection createconnection(configuration conf, executorservice pool, user user)

throws ioexception;

connection中主要维护着两类共享的资源：