cassandra hbase 你想要的 HBase 原理都在这了

cassandra hbase 你想要的 HBase 原理都在这了

在里，介绍过 HBase 的入门操作知识，但对于正考虑将 HBase 用于生产系统的项目来说还是远远不够。

一般在对 HBase 做选型之前，还需要学习一些它的架构原理、弹性扩展及可靠性方面的知识。本文来自笔者此前对 HBase 做的学习概括，可方便于对 HBase 的技术全景进行快速的掌握。

一、 集群架构

尽管HBase可以工作在本地文件系统之上，但在生产环境中，HBase需要依托 HDFS 作为其底层的数据存储，而HDFS提供了默认的3副本来实现数据文件的高可靠。整个HBase 集群主要由 、、、HDFS所组成，如下图：

集群角色

HBase 用于管理多个 ，包括监测各个 的状态、分配 及自动均衡等。具体职责包括：

HBase 允许多个 节点共存，当多个 节点共存时，只有一个 是提供服务的，这种主备角色的”仲裁”由 实现。

是真正的数据读写服务器，即客户端会直接连接 进行操作。一个 会包括了多个 ，这里的 则是真正存放 HBase 数据的区域单元，当一个表很大时，会拆分成很多个 进行存放。可以说， 是 HBase 分布式的基本单位。

对于 HBase的作用是至关重要的。

就目前来说， 已经成为了分布式系统架构中最常用的标准框架之一。除了 HBase之外，有许多分布式大数据相关的开源框架，都依赖于 实现 HA。

HDFS HDFS 是 的分布式文件系统，提供了高可靠高扩展的文件存储能力。其内部也是一个集群结构，包含 、 角色。其中 存储的是 HDFS文件目录树的元数据，包含文件与Block的关联信息，而 则是HDFS的数据存放节点。

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

工作机制

在一个完整的HBase 分布式集群中，各个组件的交互工作如下图所示：

首先 维护了 与各个 之间的关系及状态。当一个 需要访问 HBase 集群时，会先和 进行通信，并得到 和 的地址信息。对于创建表/删除表/修改表来说，客户端会通过 来进行操作，而正常的表数据读写，则是通过找到对应的 来操作。

的作用

每一个 会管理很多个 (区域), 这个就是之前提到的 HBase 数据分布式及高可靠的一个单元。每个 只会存储一个表中的的一段数据，这是按 的区间来分隔的。而且，一个 的存储空间有一个上限()，当存放数据的大小达到该上限时， 就会进行分裂并产生多个新的 ，随着一个 上的 越来越多， 可以监测到不均衡的情况，并自动将进行重新分配。因此，数据可以源源不断的写入到 HBase时，通过这种 的分裂、自动均衡来支持海量数据的存储。

对于一个来说，其内部是由 多个Store构成的，而一个Store 对应于一个(列族)。在实现上一个Store对象会包含一个以及多个。当数据写入 时，先写入(保持有序)。当 写满了之后就会 Flush 到，这里的 就对应了一个HDFS中的 HFile文件。最终 会对应到多个 持久化的 HFile，当这些 HFile 越来越多时， 会执行合并操作()来合并为一个大的HFile，以此来优化读取性能，这个机制则是基于LSM的原理实现的。

HLog 和可靠性

HBase 提供了HLog来保证数据写入的可靠性，HLog 本质上就是一种 WAL(事务机制中常见的预写日志)，其同样是通过HDFS来持久化的(对应于一个文件)。每个 都包含一个HLog，其中记录了所有发生在 上的数据变更操作。当数据发生写入时，会先记录日志到 HLog中，然后再写入 ，最终才持久化到 HFile中。这样当 宕机时，尽管 中的数据会丢失，但还可以通过 HLog来恢复之前的数据，从而保证了高可靠。那么，HFile 是否可靠呢？这点则是由 HDFS 来保证的，一个HFile 默认会有3个副本。

除此之外，HLog 也是HBase 实现集群同步复制的关键手段。

二、存储机制

接下来，我们看看HBase中的数据是怎样被存储及管理的。

A. 存储模型

首先需要澄清的一点是， 和 (简称CF) 的区别。

是HBase 分布式存储的基本单位，其本质上是一种水平切分单位，可以理解为数据的分片；而 (列族)则是垂直切分的单位，可理解为一种列的分组。这两者的区别可以参考下图：

无论是、还是CF，都是逻辑上的一个概念，对于物理上的实现则如下图所示：

存储模块说明

HFile 结构

HFile 是HDFS 的存储单元，其结构如下图：

HFile 由很多个数据块（Block）组成，并且有一个固定的结尾块。其中的数据块是由一个 和多个 Key-Value 的键值对组成。在结尾的数据块中包含了数据相关的索引信息，系统也是通过结尾的索引信息找到 HFile 中的数据。

HFile 中的数据块大小默认为 64KB。如果访问 HBase 数据库的场景多为有序的访问，那么建议将该值设置的大一些。如果场景多为随机访问，那么建议将该值设置的小一些。一般情况下，通过调整该值可以提高 HBase 的性能

B. LSM 与

HBase 在存储上是基于LSM树 实现的，与传统的B/B+树原理不同的是，LSM树非常适用于写入要求非常高的场景。

LSM 的原理

将一个大的B(B+)树拆分成N棵小树，数据首先写入内存中(有序)，随着数据写入越来越多，内存中的数据会被flush到磁盘中形成一个文件；在读取数据时，则需要合并磁盘中历史数据和内存中最近修改的操作后返回。由于数据是顺序写入的，因此 LSM 的写入性能非常高，但读取时可能会访问较多的磁盘文件，性能较差。为了缓解读性能低下的问题，LSM树会定时将磁盘中的多个文件(小树)进行合并，以优化读性能。

在HBase的实现中，内存中的数据则是对应于，而磁盘中的数据则对应于 (HFile实现)。当写满后会Flush到一个HFile 中。随着HFile 文件的不断增多， 的读性能就会受到影响(IOPS 增加)。因此 HBase 的 会定期进行操作，将多个HFile 合并为一个大的 有序的 HFile。HBase 中运行的 动作有两种：

具体的过程如下图所示：

图片出处：

Flush 性能影响

如果 很小，意味着Flush 的次数会很多，一旦的速度跟不上就会产生大量的HFile 文件，这会导致读性能恶化，为了减缓这个问题cassandra hbase 你想要的 HBase 原理都在这了，HBase 使用了 In Flush And 的方法，即数据在 中先经分段()、Flush、 过程，到达一定大小后再 Flush 到 HFile。在这里， 使用了 p(并发跳跃表) 来保证一定的读写并发能力。p 在容量超过一定大小后性能下降明显，因此 也不能设置得太大，当前的默认值在128MB。

触发Flush 行为的条件包括：

除此以外，为了保证的进度与Flush对齐，HBase会在HFile数量到达一定阀值后阻塞Flush操作，如下面的参数：

策略

的目的是优化读性能，但会导致 IO 放大，这是因为在合并过程中，文件需要不断的被读入、写出，加上 HDFS 的多副本复制，则会再一次增加多次的IO操作。此外cassandra hbase，利用了缓冲区合并来避免对已有的 HFile 造成阻塞cassandra hbase，只有在最后合并 HFile 元数据时会有一点点的影响，这几乎可以忽略不计。但 完成后会淘汰Block Cache，这样便会造成短期的读取时延增大。

在性能压测时通常可以看到由 导致的一些”毛刺”现象，但这是不可避免的，我们只能是根据业务场景来选择一些合理的 策略。

一般，Minor 会配置为按需触发，其合并的范围小，时间短，对业务性能的影响相对可控。但 Major 则建议是在业务闲时手动触发，以避免业务造成严重的卡顿。

关于如何选择合并文件的范围，HBase 提供了以下几种策略：

.ratio：最小待合并文件数

.min：最小待合并文件数

.max：最大待合并文件数

.min.size 最小合并文件总大小

一般由于旧文件都是经过的会比较大，因此通常会基于新文件来做合并。关于该策略的详细讨论可参考这里

C. 分裂

假设某个增长到了极限，将会切分为两个子 (原来的称为父)

该过程的步骤如下：

初始化两个子信息，写入一个ZK节点数据：/hbase/-in-/-name= 通过Watch机制获知该状态改变，此时可通过的UI界面观察到； 创建.split临时目录，用于保存split后的子信息； 关闭父并执行Flush操作，此后在短暂的时间内对于父的读写操作都会失败； 在.split文件夹下新建两个子的目录，同时分别生成拆分后的文件(仅仅是引用信息); 将.split文件夹下的子的目录拷贝到HBase根目录下，形成两个新的； 修改 hbase.meta 表(连接该元数据表对应的)，将父 标记为Split完成，=true，即表示分裂完成后下线； 打开两个子，表示可接收读写操作； 修改 hbase.meta 表，将子上线的信息写入； 修改ZK节点数据：/hbase/-in-/-name=SPLIT，此后获知分裂完成。如果有正在运行的均衡任务，则会考虑进一步处理；

可以发现，整个分裂过程仅仅是创建了一些数据文件的引用及元数据更新操作，对于业务的影响是非常微小的。那么，在分裂后的一段时间内，引用数据文件还会持续存在，一直到当子发生操作时，才会将父的HFile数据拷贝到子目录。

关于 切分的细节分析进一步参考

D. 自动均衡

HBase 的 分配和自动均衡是由 节点控制的，在初始化表时会先分配一个，然后指定给某个 。 如果使用预分区，那么 会按照轮询的方式平均分配到每个 。此后，随着不断的增大和裂变， 上的 数量开始变得不均衡。如果开启了自动均衡开关， 会通过定时器来检查集群中的在各个之间的负载是否是均衡。一旦检测到不均衡的情况，就会生成相应的迁移计划。

关于均衡的方式，HBase 提供以下两种策略：

由于HBase的的数据(包括HLog、等)都是写入到HDFS文件系统中的， 因此 HBase 的 迁移是非常轻量级的。在做迁移时，所对应的HDFS文件是不变的，此时只需要将 的元数据重新分配到目标 就可以了。迁移过程的步骤包含：

创建 迁移计划，指定 、源 和目标 ；源 解绑，此时会关闭 ；目标 绑定，重新打开 ；三、访问机制

HBase 支持多种读写客户端访问方式，具体包括：

无论使用何种调用方式，始终还是离不开最基础的 RPC 调用流程。该流程的交互逻辑如下图所示：

连接 在进行数据操作之前，客户端首先需要接入，并初始化一个 。该由 与 端之间创建，并通过心跳机制保持长连接获取meta 路由信息HBase 将分布的元数据存放在hbase.meta这个表中，该表记录了每一个用户表的路由以及状态信息，它的 包含了表名 Table Name、 以及 ID。客户端通过 先找到 meta 所在的 ，然后获得 meta 信息。之后根据操作的 就可以定位到对应的 IDcassandra hbase，最后再通过 的映射表就可以得到 所在的 了。需要注意的是，客户端一般会对 meta 信息进行缓存，避免每次都要耗费时间读取。读写 在得到真实数据所在的 之后，客户端便通过RPC接口向目标 发起访问。对于一些批量请求，客户端会先通过 进行分组，再并发的向多个 发出请求。

对于使用 Rest 或是 等中间组件的情况，调用流程如下图：

四、 鉴权

HBase 的安全同时依赖于 、HDFS。

ACL权限

HBase 支持RWXCA权限模型设置：

需要以最小权限原则为数据库表配置对应的用户权限

同样，为了保证整体的安全性，需要对、HDFS都设定合理的ACL控制，包括文件系统。

身份认证和授权

HBase 集群中可使用来实现节点之间的身份鉴权，包括：

是一个常见的身份认证及鉴权协议系统，使用 的系统在设计上采用C/S结构及AES对称加密技术，并且能够进行双方认证。支持防止窃听、防止攻击、保护数据完整性等特性。 认证过程需要依赖于单独的 (KDC)，一个认证过程如下图：

: 客户端请求认证服务器(AS)，获得 (TGT) : 客户端通过TGT票据请求TGS(授权服务)，通过后会获得一个授权的 : 客户端使用 访问目标服务，目标服务会对 进行本地校验，如果通过则表示认证成功。

关于的详细原理，可以参考NoSQL漫谈-图解 这篇文章

对于HBase集群来说，各个节点使用认证时，需要先配置文件，该文件中就记录了实体ID()、以及密钥的信息。而这些实体ID及密钥都是由 服务生成并管理的。

传输层安全五、 高可靠1.集群高可靠 高可靠

本身是集群多节点的架构，其内部使用 Paxos 算法来实现选举和数据的强一致性。在部署上通常可以选择3节点的架构来保证可靠性。

高可靠

HBase 可以开启 来实现 节点高可用，同一时间内只有主 可以工作， 宕机后由 备 自动接管 的 HA 机制是借助 完成的

高可靠

通常会部署为多个节点，每个节点分别接管不同的 而 会对 的状态进行检测，一旦发现 宕机，则会将该 上的 列表重新指派给一个新的 。此外，还会将已宕机的 的HLog 做一定拆分，并分发到新的 上做数据恢复。

该过程不涉及数据迁移，只是元数据的变更，操作数据量少并不会对业务造成很大的影响。

数据高可靠

本身提供了 HLog(WAL) 来提供断电保护，当 异常宕机时，内丢失的数据可以通过 HLog 来回放恢复。

HDFS 高可靠

HDFS 本身提供了一系列的可靠性机制，包括：

2. 隔离性

在部署上，通常依据一些原则策略来保证可靠性：

3. 容灾

尽管HDFS提供了三副本的机制，但对于关键业务来说，往往需要支持跨机房的容灾能力。

HBase 支持 机制，该机制设计的主导思想是基于操作日志 (put/get/) 做数据同步的功能，这类似于MySQL的，或者是的OpLog。的关键就在于前面所提到过的 HLog，这个日志除了用作数据断电保护之外，还被用来实现集群复制的功能。

如下图：

客户端的 put/ 操作会先被 写入本地的 HLog ，之后由一个独立的线程将 HLog 内容以缓冲写的形式推送到 Slave 集群中的某个 上。整个复制的HLog信息、包括复制偏移量都会保存在 上，同时复制动作是异步的，即不会阻塞当前的客户端读写。

参考文档

HBase 深入浅出 详细介绍了HBase的由来以及特性，文中提供了HBase集群、存储机制的一些简介，非常适合入门阅读

HBase集群组件通讯端口(较全)

HBase-所有切分的细节都在这里了

一条数据的HBase之旅

深入理解HBase

HBase 实践

阿里Hbase的业务和容灾实践

关于HBase 的安全

图解