HBase组件

在物理上，HBase是由三种类型的servers组成的主从型架构。Region servers服务于数据的读取和写入。客户端在访问数据时，直接与HBase Region servers 进行通信。区域分配、DDL（创建、删除表）操作由HBase主进程处理。Zookeeper是HDFS的一部分，它维护着一个活的集群状态。

Hadoop DataNode存储的是 Region servers 管理的数据。所有HBase的数据都存储在HDFS文件中。 Region servers 与HDFS DataNode对接，这使得 Region servers 所服务的数据能够实现数据定位（将数据放在需要的地方附近）。HBase的数据在写入时是本地的，但当区域被移动时，直到compaction之前，数据都不是本地的。

NameNode维护由文件组成的所有物理数据块的元数据信息。

Regions

HBase表按行键范围横向划分为 "Regions"。一个region包含该区域的开始键和结束键之间的表中的所有记录。Regions被分配给集群中的节点，称为 "Region Servers"，这些节点为数据的读取和写入服务。一个Region Servers可以服务于大约1000个region。

HBase Master

Region分配、DDL（创建、删除表）操作由Hbase Master处理。

一个 master 负责：

• 协调region servers
  • 在启动时分配region，重新分配region用于恢复或负载平衡。
  • 监控集群中的所有 RegionServer 实例（监听来自 zookeeper 的通知）。
• 管理功能
  • 创建、删除、更新tables

ZooKeeper: The Coordinator

HBase使用ZooKeeper作为分布式协调服务来维护集群中的服务器状态。Zookeeper维护哪些服务器是活的、可用的，并提供服务器故障通知。Zookeeper使用共识(consensus)来保证共同的共享状态。需要注意的是，应该有三台或五台机器进行共识。

How the Components Work Together：各组件如何共同工作

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

每个Region Server都会创建一个临时节点。HMaster监控这些节点以发现可用的Region Server，同时它还监控这些节点是否有服务器故障。HMasters 创建临时节点。Zookeeper确定第一个并使用它来确保只有一个master是活动的。活动的HMaster向Zookeeper发送心跳，非活动的HMaster监听活动的HMaster故障通知。

如果Region Server或活动中的HMaster未能发送心跳，则会话过期，并删除相应的临时节点。 更新的监听者会收到被删除节点的通知。活动的HMaster监听Region Server，并在失败时恢复区域服务器。Inactive HMaster监听active HMaster失败，如果active HMaster失败，则Inactive HMaster变为active HMaster。

HBase First Read or Write：HBase第一次读或写

有一个特殊的HBase目录表，叫做META表，它保存了集群中regions的位置。ZooKeeper存储了META表的位置。

这是客户端第一次读取或写入HBase时发生的事情：

1. 客户端从ZooKeeper中获得托管META表的Region server。
2. 客户端将查询.META.服务器，以获得它想要访问的row key对应的Region server。客户端会将此信息与META表的位置一起缓存。
3. 它将从对应的Region server中获取该行。

对于未来的读取，客户端使用缓存来检索META位置和之前读取的row keys。随着时间的推移，它不需要查询META表，除非因为某个Region 移动而没有命中，否则它将重新查询并更新缓存。

HBase Meta Table

• 这个meta表是一个HBase表，它保留了系统中所有区域的列表。
• .meta.表就像一个b树。
• .META.表的结构如下：
  • Key: region start key,region id
  • Values: RegionServer

Region Server Components

Region Server运行在一个HDFS数据节点上，有以下组件。

• WAL：Write Ahead Log是分布式文件系统中的一个文件。WAL是用来存储还没有被持久化到永久存储的新数据；它用于故障时的恢复。
• BlockCache：是读取缓存。它将频繁读取的数据存储在内存中。最近最少使用的数据在满时被驱逐。
• MemStore：是写缓存。它存储还没有写到磁盘的新数据。它在写到磁盘之前会被排序。每个列族每个区域有一个MemStore。
• Hfiles将行作为排序的KeyValues存储在磁盘上。

HBase Write Steps (1)

当客户端发出Put请求时，第一步是将数据写到 write-ahead日志，即WAL。

• - Edits被附加到存储在磁盘上的WAL文件的末尾。
• - WAL是用来恢复未被写入的数据，以备服务器崩溃时恢复未被写入的数据。

HBase Write Steps (2)

一旦数据被写入WAL，就会被放置到MemStore中。然后，put请求确认返回给客户端。

HBase MemStore

MemStore以排序的KeyValues的形式在内存中存储更新，就像在HFile中存储一样。每个列族有一个MemStore。更新是按照每个列族进行排序的。

HBase Region Flush

当MemStore积累了足够的数据后，整个排序后的数据集被写入HDFS中的新HFile。HBase在每个列族中使用多个HFile，其中包含实际的单元格，或KeyValue实例。这些文件是随着时间的推移而创建的，因为在MemStores中排序的KeyValue edits作为文件被刷新到磁盘上。

注意，这就是为什么HBase中的列族数量有限制的原因之一。每个CF只有一个MemStore；当一个CF满了，它们都会被刷新。它还会保存最后写的***，这样系统就知道到现在为止持久化了什么。

最高的***被存储为每个HFile中的元字段，以反映持久化的位置和继续持久化的位置。在region启动时，***被读取，最高的***作为新edits的***。

HBase HFile

数据存储在一个HFile中，其中包含排序的Key/Value。当MemStore积累了足够的数据后，整个排序的KeyValue集被写入HDFS中的新HFile。这是一种顺序写法。它的速度非常快，因为它避免了移动磁盘驱动器头。

HBase HFile Structure

一个HFile包含一个多层索引，它允许HBase在不读取整个文件的情况下寻找数据。多层索引就像一个b+树。

• 键值对的存储顺序依次递增
• 按行键指向64KB "块 "中的键值数据的键值索引
• 每个块都有自己的叶子索引
• 每个块的最后一个键被放在中间索引中。
• 根索引指向中间索引

trailer指向元数据块，并在持久化数据到文件的最后写入。trailer中还有Bloom过滤器和时间范围信息等信息。bloom过滤器有助于跳过不包含特定行键的文件。如果文件不在读取所要寻找的时间范围内，时间范围信息可以帮助跳过该文件。

HFile Index

我们刚才讨论的索引，是在HFile被打开时加载并保存在内存中。这样一来，就可以用一次磁盘查找的方式进行查找。

HBase Read Merge

我们看到一个行对应的KeyValue单元格可以在多个地方，已经持久化的行单元格在Hfiles中，最近更新的单元格在MemStore中，最近读取的单元格在Block缓存中。那么当你读取一行时，系统是如何获取对应的单元格返回的呢？读取将块缓存、MemStore和HFiles中的关键值合并在一起，具体步骤如下：

1. 首先，扫描器在块缓存--读缓存中寻找Row单元格。最近读取的关键值被缓存在这里，而最近最少使用费的需要内存不足时被释放。
2. 接下来，扫描器在MemStore中查找，MemStore是内存中的写缓存，包含了最近的写入量。
3. 如果扫描器没有找到MemStore和Block Cache中的所有行单元格，那么HBase将使用Block Cache索引和bloom过滤器将HFiles加载到内存中，其中可能包含目标行单元格。

HBase Read Merge

如前所述，每个MemStore可能有许多HFiles，这意味着对于一个读取，可能需要检查多个文件，这可能会影响性能。这就是所谓的读取放大（read amplification）。

HBase Minor Compaction

HBase会自动挑选一些较小的HFiles，并将其重写成更少的大HFiles。这个过程被称为次要压缩（minor compaction.）。Minor compaction通过将较小的文件重写成较少但较大的文件，执行合并排序，减少了存储文件的数量。

HBase Major Compaction

主要压缩（Major compaction）将一个region内的所有HF文件合并并重写为每个列族的一个HFile，并在此过程中删除已删除或过期的单元格。这提高了读取性能；但是，由于主要压缩（Major compaction）会重写所有的文件，所以在这个过程中可能会出现大量的磁盘I/O和网络流量。这就是所谓的写入放大（write amplification）。由于写入放大，主要的压缩通常安排在周末或晚上进行。

Region = Contiguous Keys

让我们对regions做一个简单的回顾：

• 一个表可以被水平地划分成一个或多个区域。一个区域包含一个开始键和结束键之间的连续的、排序的记录范围。
• 每个区域的大小为1GB（默认值）。
• 表的一个区域由RegionServer提供给客户端
• 一个region server可以服务于大约1000个regions （可能属于同一个表或不同的表）。

Region Split

最初每个表有一个region。当一个region变大时，它会分裂成两个子region。这两个子region代表原始region的二分之一，在同一台Region server上并行打开，然后将拆分情况报告给HMaster。出于负载均衡的原因，HMaster可能会安排新的区域移到其他服务器上。

Read Load Balancing

分割最初发生在同一个 region server上，但出于负载平衡的原因，HMaster可能会计划将新的region移到其他服务器上。这将导致新的region server从远程HDFS节点上服务数据，直到一个major compaction 将数据文件移动到region server的本地节点。HBase数据在写入时是本地的，但当region被移动时（为了负载平衡或恢复），在主要压缩之前，它不是本地的。

HDFS Data Replication

所有的写入和读取都是向/从主节点进行的。HDFS 复制 WAL 和 HFile 块。HFile块的复制是自动发生的。HBase依靠HDFS来提供数据安全，因为它存储文件时，HDFS提供了数据安全。当数据在HDFS中写入时，在本地写入一个副本，然后复制到二级节点，再写入第三个副本到三级节点。

HDFS Data Replication (2)

WAL文件和Hfiles是在磁盘上持久化并复制的，那么HBase如何恢复没有持久化到HFiles的MemStore更新？请看下节的答案。

HBase Crash Recovery

当RegionServer发生故障时，崩溃的Region是不可用的，直到检测和恢复步骤发生。Zookeeper会在失去region server心跳时判断Node失败。然后，HMaster将被通知region server失败。

当HMaster检测到region server崩溃时，HMaster会将崩溃的region server上的区域重新分配到活动的region server上。为了恢复已崩溃的region server的memstore编辑，没有被刷新到磁盘上的region server。HMaster将属于已崩溃的region server的WAL分割成单独的文件，并将这些文件存储在新的region server的数据节点中。然后，每个region server从各自拆分的WAL中复制WAL，重建该区域的memstore。

 

Data Recovery

WAL文件包含一个编辑列表，一个编辑代表一个单一的置入或删除。编辑是按时间顺序写的，因此，为了持久性，添加的内容会被附加到存储在磁盘上的WAL文件的末尾。

如果数据还在内存中，没有持久化到HFile中，如果出现故障，会怎样？WAL会被重放。重放WAL是通过读取WAL，将包含的编辑内容添加并排序到当前的MemStore来完成的。最后，MemStore被刷新以将更改写入HFile。

 

Apache HBase Architecture Benefits

HBase提供了以下好处:

• 强一致性模式
  • 当一个写法返回时，所有的读者都会看到相同的值。
• 自动扩容
  • 当数据增长过大时，Regions分裂
  • 使用HDFS来传输和复制数据
• 内置恢复功能
  • 使用Write Ahead Log（类似于文件系统上的日志）。
• 与Hadoop集成
  • 在HBase上的MapReduce是直接的

Apache HBase Has Problems

业务连续性的可靠性：

• - WAL重放慢
• - 缓慢复杂的崩溃恢复
• - Major Compaction I/O风暴