Hbase相关总结

HBase 架构组件

物理上，Hbase 是由三种类型的 server 组成的的主从式（master-slave）架构：

Region Server 负责处理数据的读写请求，客户端请求数据时直接和 Region Server 交互。
HBase Master 负责 Region 的分配，DDL（创建，删除 table）等操作。
Zookeeper，作为 HDFS 的一部分，负责维护集群状态。
当然底层的存储都是基于 Hadoop HDFS 的：

Hadoop DataNode 负责存储 Region Server 所管理的数据。所有的 HBase 数据都存储在 HDFS 文件中。Region Server 和 HDFS DataNode 往往是分布在一起的，这样 Region Server 就能够实现数据本地化（data locality，即将数据放在离需要者尽可能近的地方）。HBase 的数据在写的时候是本地的，但是当 region 被迁移的时候，数据就可能不再满足本地性了，直到完成 compaction，才能又恢复到本地。
Hadoop NameNode 维护了所有 HDFS 物理 data block 的元信息。

 

 Regions

HBase 表（Table）根据 rowkey 的范围被水平拆分成若干个 region。每个 region 都包含了这个region 的 start key 和 end key 之间的所有行（row）。Regions 被分配给集群中的某些节点来管理，即 Region Server，由它们来负责处理数据的读写请求。每个 Region Server 大约可以管理 1000 个 regions。

 

 

HBase Master

也叫 HMaster，负责 Region 的分配，DDL（创建，删除表）等操作：

统筹协调所有 region server：

启动时分配 regions，在故障恢复和负载均衡时重分配 regions
监控集群中所有 Region Server 实例（从 Zookeeper 获取通知信息）
管理员功能：

提供创建，删除和更新 HBase Table 的接口

 

 

Zookeeper

HBase 使用 Zookeeper 做分布式管理服务，来维护集群中所有服务的状态。Zookeeper 维护了哪些 servers 是健康可用的，并且在 server 故障时做出通知。Zookeeper 使用一致性协议来保证分布式状态的一致性。注意这需要三台或者五台机器来做一致性协议。

 

 

这些组件是如何一起工作的

Zookeeper 用来协调分布式系统中集群状态信息的共享。Region Servers 和 在线 HMaster（active HMaster）和 Zookeeper 保持会话（session）。Zookeeper 通过心跳检测来维护所有临时节点（ephemeral nodes）。

 

每个 Region Server 都会创建一个 ephemeral 节点。HMaster 会监控这些节点来发现可用的 Region Servers，同样它也会监控这些节点是否出现故障。

HMaster 们会竞争创建 ephemeral 节点，而 Zookeeper 决定谁是第一个作为在线 HMaster，保证线上只有一个 HMaster。在线 HMaster（active HMaster） 会给 Zookeeper 发送心跳，不在线的待机 HMaster （inactive HMaster） 会监听 active HMaster 可能出现的故障并随时准备上位。

如果有一个 Region Server 或者 HMaster 出现故障或各种原因导致发送心跳失败，它们与 Zookeeper 的 session 就会过期，这个 ephemeral 节点就会被删除下线，监听者们就会收到这个消息。Active HMaster 监听的是 region servers 下线的消息，然后会恢复故障的 region server 以及它所负责的 region 数据。而 Inactive HMaster 关心的则是 active HMaster 下线的消息，然后竞争上线变成 active HMaster。

（涉及到分布式系统设计中的一些核心概念，包括集群状态、一致性等。可以看到 Zookeeper 是沟通一切的桥梁，所有的参与者都和 Zookeeper 保持心跳会话，并从 Zookeeper 获取它们需要的集群状态信息，来管理其它节点，转换角色，这也是分布式系统设计中很重要的思想，由专门的服务来维护分布式集群状态信息。）

 

第一次读和写操作

有一个特殊的 HBase Catalog 表叫 Meta table（它其实是一张特殊的 HBase 表），包含了集群中所有 regions 的位置信息。Zookeeper 保存了这个 Meta table 的位置。

当 HBase 第一次读或者写操作到来时：

• 客户端从 Zookeeper 那里获取是哪一台 Region Server 负责管理 Meta table。
• 客户端会查询那台管理 Meta table 的 Region Server，进而获知是哪一台 Region Server 负责管理本次数据请求所需要的 rowkey。客户端会缓存这个信息，以及 Meta table 的位置信息本身。
• 然后客户端回去访问那台 Region Server，获取数据。

对于以后的的读请求，客户端从可以缓存中直接获取 Meta table 的位置信息（在哪一台 Region Server 上），以及之前访问过的 rowkey 的位置信息（哪一台 Region Server 上），除非因为 Region 被迁移了导致缓存失效。这时客户端会重复上面的步骤，重新获取相关位置信息并更新缓存。

 

 客户端读写数据，实际上分了两步：第一步是定位，从 Meta table 获取 rowkey 属于哪个 Region Server 管理；第二步再去相应的 Region Server 读写数据。这里涉及到了两个 Region Server，要理解它们各自的角色功能。关于 Meta table 下面会详细介绍。

HBase Meta Table

Meta table 是一个特殊的 HBase table，它保存了系统中所有的 region 列表。这张 table 类似一个 b-tree，结构大致如下：

Key：table, region start key, region id

Value：region server

 

 

Region Server 组成

Region Server 运行在 HDFS DataNode 上，由以下组件组成：

WAL：Write Ahead Log 是分布式文件系统上的一个文件，用于存储新的还未被持久化存储的数据，它被用来做故障恢复。

BlockCache：这是读缓存，在内存中存储了最常访问的数据，是 LRU（Least Recently Used）缓存。

MemStore：这是写缓存，在内存中存储了新的还未被持久化到硬盘的数据。当被写入硬盘时，数据会首先被排序。注意每个 Region 的每个 Column Family 都会有一个 MemStore。

HFile 在硬盘上（HDFS）存储 HBase 数据，以有序 KeyValue 的形式。

 

 

Apache HBase 架构的优点

• 强一致性：

  - 当 write 返回时，所有的 reader 都会读到同样的值。

• 自动扩展性

  - 数据变大时 region 会分裂。
  - 使用 HDFS 存储备份数据。

• 内置恢复功能

  - 使用 Write Ahead Log （类似于文件系统中的日志）

• 与 Hadoop 结合：

   

  - 使用 MapReduce 处理 HBase 数据会非常直观。

• Apache HBase 也有问题

  • 业务持续可靠性：

     

    - WAL 回放很慢。
    - 故障恢复很慢。
    - Major Compaction 时候 I/O 会飙升。

https://segmentfault.com/a/1190000019959411