物理上看, HBase 系统有3种类型的后台服务程序, 分别是 Region Server, Master Server 和 ZooKeeper。Region Server 负责实际数据的读写. 当访问数据时, 客户端与 HBase 的 Region Server 直接通信。Master Server 管理 Region 的位置, DDL（新增和删除表结构）。ZooKeeper 负责维护和记录整个 HBase 集群的状态。

所有的 HBase 数据都存储在 HDFS 中. 每个 Region Server 都把自己的数据存储在 HDFS 中。如果一个服务器既是 Region Server 又是 HDFS 的 Datanode。那么这个 Region Server 的数据会在把其中一个副本存储在本地的 HDFS 中，加速访问速度。

但是, 如果是一个新迁移来的 Region Server，这个 Region Server 的数据并没有本地副本。直到 HBase 运行 compaction，才会把一个副本迁移到本地的 Datanode 上面。

HDFS 的 NameNode 存储着组成文件的所有数据块（Data Blocks）的元数据信息。

HBase 的表根据 Row Key 的区域分成多个 Region，一个 Region 包含这这个区域内所有数据。而 Region Server 负责管理多个 Region，负责在这个 Region Server 上的所有 Region 的读写操作. 一个 Region Server 最多可以管理1000个 Region。

1. RegionServer 就是 HBase 的各个节点，针对的是机器而言。
2. Region 是 HBase 数据存储和管理的基本单位，一个表中可以包含一个或多个 Region，Region 针对 HBase 中的数据表。
3. 每个 Region 只能被一个 RegionServer 提供服务，RS 可以同时服务多个 Region，来自不同 RS上 的 Region 组合成表格的整体逻辑视图。
4. Region Server 和 Region 只是逻辑上的关系，某个节点的 Region Server 并不仅仅管理本节点上的 Region。

HBase Maste 主要负责分配 Region 和操作 DDL（如新建和删除表）等。

HBase Master的主要功能：

• 协调 RegionServer
  • 集群启动时分配 Region，数据恢复或者动态调整负载（Load Balance）时，重新分配 Region
  • 监控集群中所有 RegionServer 的状态（监听 ZooKeeper 的通知）
• 管理功能
  • 提供 DDL 相关的 API，新建（create），删除（delete）和更新（update）表结构。

HBase 使用 ZooKeeper 作为分布式协调服务来维护集群中的服务器状态。Zookeeper 维护哪些服务器处于活跃和可用状态，并提供服务器故障通知。ZooKeeper 使用一致性（consensus）来保证共同的共享状态。需要注意的是，需要3台以上的服务器节点来保证 ZooKeeper 的一致性。

Zookeeper 用于协调分布式系统成员的共享状态信息。Region Servers 和主 HMaster 通过会话连接到 ZooKeeper。ZooKeeper 通过心跳维护活动会话的临时节点。

每个 Region Server 创建一个临时节点。HMaster 监视这些节点以便发现可用的 Region Servers，并监视这些节点以防服务器故障。为了高可用需求, HMaster 也有多个, 这些节点也同时向 Zookeeper 注册临时节点。Zookeeper 把第一个成功注册的 HMaster 节点设置成 active 状态，而其他 HMaster 节点处于 inactive 状态。

如果 Zookeeper 在规定时间内没有收到 active 的 HMaster 节点的心跳，连接会话超时，对应的临时节也自动删除。之前处于 inactive 的 HMaster 节点得到通知，马上变成 active 状态，立即提供服务。

同样，如果 Zookeeper 没有及时收到 Region Server 的心跳，会话过期，临时节点删除。HMaster 得知 Region Server 宕机，启动数据恢复方案。

HBase 把各个 Region 的位置信息存储在一个特殊的表中，这个表叫做 META 表。Zookeeper 里面存储了这个 Meta 表的位置信息。

这是客户端第一次读取或写入 HBase 时的过程：

1. 客户端访问 Zookeepr, 得到了具体 META 表的位置；
2. 客户端再访问真正的 META 表, 从 META 表里面得到 Row Key 所在的 Region Server，同时缓存 META 表的位置和 Row Key 的位置信息；
3. 访问 Row Key 所在的 Region Server，得到需要的真正数据。

再次读取时，客户端将使用缓存来检索 META 表的位置和以前读取过的 Row Key。这样的话，客户端就不需要重复查询 META 表，除非 Region Server 由于宕机等原因迁移到其他节点导致客户端访问失败，客户端才会重新查询并更新缓存。

我们访问 HBase 的时候，先去 META 表查找定位这条记录属于哪个 Region，然后定位到这个 Region 属于哪个 Region Server，然后就到哪个 Region Server 里面查找对应 Region 中的数据。

• META 表存储着所有 Region 的列表；
• META 表用类似于 Btree 的方式存储；
• META 表的结构如下:
  • Key: region start key, region id
  • Values: RegionServer

Region Server 运行在 HDFS 的 DataNode 上面，它有下面4个部分组成：

• WAL：写入日志（Write Ahead Log）是分布式文件系统上的一个文件。WAL 用于存储尚未被持久化到磁盘的新数据；它用于故障情况下的数据恢复。
• BlockCache：是读取缓存。它将经常读取的数据存储在内存中，最近最少使用（LRU）的数据在缓存容量满时被清楚。
• MemStore：是写入缓存。用来存储尚未写入磁盘的新数据。每个 Region 的每个列簇（Column Family）都有一个 MemStore。MemStore 的数据在写入硬盘前，会先根据 Key 排序，然后写入硬盘。
• HFiles: HDFS 上的数据文件, 里面存储着排序后的 KeyValue 对。

• 当 HBase 客户端发起 Put 请求, 第一步是将数据写入预写日志（WAL）；
• WAL 用于在服务器崩溃的情况下恢复尚未保存的数据。

数据写入预写日志（WAL）， 并存储在 Memstore 之后，向用户返回写成功。

MemStore 在内存按照 Key 的顺序，存储 Key-Value 对，一个 Memstore 对应一个列簇（column family）。同样在 HFile 里面，所有的 Key-Value 对也是根据 Key 有序存储。

译注：原文里面 Flush 的意思是，把缓冲的数据从内存 转存 到硬盘里, 这就类似与冲厕所（Flush the toilet），把数据比作是水，一下把积攒的水冲到下水道，想当于把缓存的数据写入硬盘。和 Flush 非常类似的英文还有 un-plug，比如有一浴缸的水，只要 un-plug 浴缸里面的塞子，浴缸的水就开始流进下水道，也类比把缓存数据写入硬盘

上个章节讨论的索引是在打开HFile时加载的，加载之后保存在内存中。 这也让这个查询工作在单个磁盘中执行。

我们发现 HBase 中的一个 Row 里面的数据，分配在多个地方。已经持久化存储的 Cell 在 HFile，最近写入的 Cell 在 Memstore 里，最近读取的Cell 在 Block cache 里。所以当你读 HBase 的一行时，混合了 Block cache，Memstore 和 HFiles 的读操作：

1. 首先，在 Block cache（读缓存）里面查找 Cell，因为最近的读取操作都会缓存在这里。如果找到就返回，没有找到就执行下一步；
2. 其次, 在 Memstore（写缓存）里查找 Cell，Memstore 里面存储里最近的新写入，如果找到就返回，没有找到就执行下一步；
3. 最后，在读写 Cache 中都查找失败的情况下，HBase 查询 Block cache 里面的 HFile 索引和布隆过滤器（bloom filters），查询有可能存在这个 Cell 的 HFile，最后在 HFile 中找到数据。

如前所述，每个 MemStore 可能会有许多 HFile，这意味着读取时可能需要检查多个文件，这可能会影响性能。这被称为读取放大（read amplification）。

HBase 将自动选择一些较小的 HFiles，并将其重写合并成更大的 HFiles。 这个过程被称为轻微压缩（minor compaction）。 轻度压缩通过将较小的文件重写为较少但较大的文件来减少存储文件的数量，采用归并排序（merge sort）算法。

主要压缩（Major compaction）将一个区域内的所有 HFiles 合并并重写为每列（per column family）一个 HFile，并在此过程中丢弃已删除或已过期的单元（cells）。这提高了读取性能；但是，由于重大压缩会重写所有文件，因此在此过程中可能会发生大量磁盘IO和网络通信。这被称为写放大（write amplification）。

主要压缩（Major compactions）可以设置为自动运行模式。 由于写放大（write amplification）的问题，major compactions 通常选择在周末或晚上进行。另外需要注意的是，MapR-DB 已经做了改进，不再需要进行压缩（compactions）。此外，major compaction 的过程中，如果发现 Region Server 负责的数据不在本地的 HDFS DataNode 上（可能由于服务异常或者正在进行负载均衡引起），major compaction 除了合并文件外，还会把其中一份数据转存到本地的 DataNode 上。

• An In-Depth Look at the HBase Architecture
• 深度分析HBase架构