HBASE分布式存储架构

强大的HBase架构比单独的HBase涉及更多的部分。至少，涉及用于配置和同步的基础分布式集中式服务。

图下描述了该体系结构的概述。

HBase 部署遵循主工作线程模式。因此，通常有一个主服务器和一组工作线程，通常称为范围服务器。当 HBase 启动时，主服务器将一组范围分配给范围服务器。每个区域存储一组有序的行，其中每行由唯一的行键标识。当存储在区域中的行数增长到超过配置的阈值时，该范围将一分为二，行将在两个新范围之间划分。

与大多数列数据库一样，HBase 将列系列中的列存储在一起。因此，每个区域为每个表中的每个列系列维护一个单独的存储区。每个存储依次映射到存储在底层分布式文件系统中的物理文件。对于每个存储，HBase 借助充当存储和底层物理文件之间的中介的精简包装器抽象对底层文件系统的访问。

每个区域都有一个内存中存储或缓存，以及一个预写日志 （WAL）系统。

WAL是各种数据库系统中使用的常用技术，包括流行的关系数据库系统，如PostgreSQL和MySQL。在 HBase 中，客户端程序可以决定打开或关闭 WAL。

关闭它会提高性能，但在发生故障时会降低可靠性和恢复能力。

将数据写入区域时，会首先将其写入预写日志（如果已启用）。不久之后，它将被写入该区域的内存中存储。如果内存中存储已满，数据将刷新到磁盘并保留在基础分布式存储中。

请参阅下图，其中概述了区域服务器和区域的核心方面。

如果使用像Hadoop分布式文件系统（HDFS）这样的分布式文件系统，那么主工作线程模式也会扩展到底层存储方案。在 HDFS 中，名称节点和一组数据节点形成一种结构，类似于 HBase 等列数据库遵循的主服务器和范围服务器的配置。因此，在这种情况下，HBase 列系列存储的每个物理存储文件最终驻留在 HDFS 数据节点中。

HBase 利用文件系统 API 来避免与 HDFS 的强耦合，因此此 API 充当 HBase 存储和相应 HDFS 文件之间对话的中介。该 API 还允许 HBase 与其他类型的文件系统无缝协作。例如，HBase可以与CloudStore一起使用，以前称为Kosmos FileSystem（KFS），而不是HDFS。

除了具有用于存储的分布式文件系统之外，HBase 群集还利用外部配置和协调实用程序。

在关于Bigtable的开创性论文中，谷歌将这个配置程序命名为Chubby。

Hadoop作为Google基础设施的克隆，创建了一个精确的对应物，并称之为ZooKeeper。Hypertable调用类似的基础设施部分Hyperspace。

ZooKeeper 群集通常为新客户端前端 HBase 群集并管理配置。

要首次访问HBase，客户端通过ZooKeeper访问两个目录。这些目录名为 -ROOT- 和 .META。目录维护所有区域的州和位置信息。

-ROOT- 保留所有的信息.META表

.META File 保留用户空间表（即保存数据的表）的记录。

当客户端想要访问特定行时，它首先向 ZooKeeper 请求 -ROOT- 目录。-ROOT- 目录定位 .META与行相关的目录，该目录又提供用于访问特定行的所有区域详细信息。使用此信息访问行。下次客户端请求行数据时，不会重复访问行的三步过程。列数据库严重依赖缓存此三步查找过程中的所有相关信息。这意味着客户端下次需要行数据时会直接联系区域服务器。仅当缓存中的区域信息过时或区域已禁用且无法访问时，才会重复长循环查找。

每个区域通常由它存储的最小行键标识，因此查找行通常就像验证特定行键是否大于或等于区域标识符一样简单。

到目前为止，已经介绍了列数据库存储的基本概念和物理模型。数据写入和读取这些存储的幕后机制也已暴露出来

---

本文正在参加「金石计划 . 瓜分6万现金大奖」