分布式存储数据库Hbase

Hbase简介

产生背景

Apache HBase的产生背景可以追溯到对大规模数据存储和处理需求的迅速增长，尤其是在互联网公司和其他需要处理海量数据的行业中。

• 大数据需求的增长：随着互联网的快速发展，尤其是社交媒体、电子商务和物联网的普及，企业需要存储和处理比以往任何时候都要多的数据。这些数据不仅规模庞大，而且多样化，传统的关系型数据库在处理这些需求时面临挑战。
• Google Bigtable的影响：HBase的设计灵感主要来自于Google的Bigtable。Bigtable是Google开发的一个分布式存储系统，专为处理大规模结构化数据而设计。Bigtable在论文中描述了一个可以扩展到数千台机器的存储系统，这激发了开源社区开发类似的系统。
• Hadoop生态系统的扩展：Hadoop项目在大数据领域的成功使得需要一个与之紧密集成的分布式数据库系统。HBase作为Hadoop的一部分，利用了Hadoop分布式文件系统（HDFS）来提供可靠的存储和高可用性。
• NoSQL运动的兴起：传统关系型数据库在扩展性和性能上遇到瓶颈，这推动了NoSQL数据库的兴起。NoSQL数据库通常提供更好的水平扩展能力和灵活的数据模型，HBase就是其中之一，专注于提供高吞吐量和快速随机访问。
• 社区和企业的推动：大型互联网公司和开源社区的推动，加速了HBase的开发和成熟。公司如Facebook和Yahoo在其早期发展中起到了重要作用，推动了其在生产环境中的应用和改进。
• 需要强一致性的分布式存储：在许多应用场景中，特别是金融和电信行业，数据一致性是至关重要的。HBase提供了行级别的强一致性，这使其在需要强一致性的分布式存储中有一定的优势。

Apache HBase的开发和引入为处理大规模、结构化和半结构化数据提供了一种有效的解决方案。尽管随着技术的发展和新技术的引入，HBase的使用场景有所变化，但它仍然是许多大数据解决方案的重要组成部分。

特点和优势

• 高可扩展性：通过增加RegionServer节点，HBase可以水平扩展以处理更大的数据集。
• 强一致性：HBase提供行级别的强一致性，确保对单个行的原子性操作。
• 快速随机读写：支持低延迟的随机读写操作，适合需要高吞吐量的应用场景。
• 时间版本控制：HBase支持多版本存储，每个单元格可以存储多个时间戳版本的数据。
• 与Hadoop的深度集成：运行在HDFS之上，与Hadoop生态系统中的其他组件（如MapReduce、Hive、Pig）无缝集成。

使用场景

• 实时分析：适用于需要实时数据访问和分析的应用，如点击流分析、物联网数据处理。
• 大数据存储：用于存储和检索海量数据集，如社交媒体数据、日志数据。
• 时序数据存储：适合存储和查询时间序列数据，如监控数据、传感器数据。
• 内容管理系统：用于存储和检索非结构化或半结构化数据，如文档、图片元数据。

Hbase的架构

Apache HBase是一个开源的、分布式的、面向列的NoSQL数据库，运行在Hadoop分布式文件系统（HDFS）之上。它是为了处理大规模数据集而设计的，特别适用于需要快速随机读写的场景。

Hbase的核心架构

HBase的核心架构由五部分组成，分别是HBase Client、HMaster、RegionServer、ZooKeeper以及HDFS。它的架构组成如下图所示。

HBase Client

HBase Client为用户提供了访问HBase的接口，可以通过元数据表来定位到目标数据的RegionServer，另外HBase Client还维护了对应的cache来加速Hbase的访问，比如缓存元数据的信息。

HMaster

HMaster是HBase集群的主节点，负责整个集群的管理工作，主要工作职责如下：

• 分配Region：负责启动的时候分配Region到具体的RegionServer；
• 负载均衡：一方面负责将用户的数据均衡地分布在各个RegionServer上，防止RegionServer数据倾斜过载。另一方面负责将用户的请求均衡地分布在各个RegionServer上，防止RegionServer请求过热；
• 维护数据：发现失效的Region，并将失效的Region分配到正常的RegionServer上，并且在RegionSever失效的时候，协调对应的HLog进行任务的拆分。

RegionServer

RegionServer直接对接用户的读写请求，是真正的干活的节点，主要工作职责如下。

• 管理HMaster为其分配的Region；
• 负责与底层的HDFS交互，存储数据到HDFS；
• 负责Region变大以后的拆分以及StoreFile的合并工作。

与HMaster的协同：当某个RegionServer宕机之后，ZK会通知Master进行失效备援。下线的RegionServer所负责的Region暂时停止对外提供服务，Master会将该RegionServer所负责的Region转移到其他RegionServer上，并且会对所下线的RegionServer上存在MemStore中还未持久化到磁盘中的数据由WAL重播进行恢复。

RegionServe数据存储的基本结构，如下图所示。一个RegionServer是包含多个Region的，这里仅展示一个。

• Region：每一个Region都有起始RowKey和结束RowKey，代表了存储的Row的范围，保存着表中某段连续的数据。一开始每个表都只有一个Region，随着数据量不断增加，当Region大小达到一个阀值时，Region就会被RegioServer水平切分成两个新的Region。当Region很多时，HMaster会将Region保存到其他RegionServer上。
• Store：一个Region由多个Store组成，每个Store都对应一个ColumnFamily, Store包含MemStore和StoreFile。
  • MemStore：作为HBase的内存数据存储，数据的写操作会先写到MemStore中，当MemStore中的数据增长到一个阈值（默认64M）后，RegionServer会启动flashcache进程将MemStore中的数据写入StoreFile持久化存储，每次写入后都形成一个单独的StoreFile。当客户端检索数据时，先在MemStore中查找，如果MemStore中不存在，则会在StoreFile中继续查找。
  • StoreFile：MemStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。HBase以Store的大小来判断是否需要切分Region。

当一个Region中所有StoreFile的大小和数量都增长到超过一个阈值时，HMaster会把当前Region分割为两个，并分配到其他RegionServer上，实现负载均衡。

• HFile：HFile和StoreFile是同一个文件，只不过站在HDFS的角度称这个文件为HFile，站在HBase的角度就称这个文件为StoreFile。
• HLog：负责记录着数据的操作日志，当HBase出现故障时可以进行日志重放、故障恢复。例如，磁盘掉电导致MemStore中的数据没有持久化存储到StoreFile，这时就可以通过HLog日志重放来恢复数据。

ZooKeeper

HBase通过ZooKeeper来完成选举HMaster、监控RegionServer、维护元数据集群配置等工作，主要工作职责如下：

• 选举HMaster：通过ZooKeeper来保证集中有1个HMaster在运行，如果HMaster异常，则会通过选举机制产生新的HMaster来提供服务；
• 监控RegionServer：通过ZooKeeper来监控RegionServer的状态，当RegionServer有异常的时候，通过回调的形式通知HMaster有关RegionServer上下线的信息；
• 维护元数据和集群配置：通过ZooKeeper存储HBase信息并对外提供访问接口。

HDFS

HDFS为HBase提供底层数据存储服务，同时为HBase提供高可用的支持，HBase将HLog存储在HDFS上，当服务器发生异常宕机时，可以重放HLog来恢复数据。

HBase的数据模型

HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族(row family)

• RowKey：Table主键行键Table中记录按照RowKey排序
• Timestamp：每次对数据操作对应的时间戳，也即数据的version number
• ColumnFamily：列簇，一个table在水平方向有一个或者多个列簇，列簇可由任意多个Column组成，列簇支持动态扩展，无须预定义数量及类型，二进制存储，用户需自行进行类型转换

RowKey

与nosql数据库们一样, rowkey是用来检索记录的主键。访问HBase table中的行，只有三种方式：

• 通过单个rowkey访问
• 通过rowkey的range
• 全表扫描

Rowkey行键(Rowkey)可以是任意字符串(最大长度是64KB，实际应用中长度一般为10-100bytes)，在HBase内部，rowkey保存为字节数组。存储时，数据按照Rowkey的字典序(byte order)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)。需要注意的：字典序对int排序的结果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。要保持整形的自然序，行键必须用0作左填充。行的一次读写是原子操作(不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。

列族

HBase表中的每个列，都归属与某个列族。列族是表的schema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math都属于courses 这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

时间戳

HBase中通过row和columns确定的为一个存贮单元称为cell。每个cell都保存着同一份数据的多个版本。版本通过时间戳来索引。时间戳的类型是64位整型。时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫秒的当前系统时间。时间戳也可以由客户显式赋值。如果应用程序要避免数据版本冲突，就必须自己生成具有唯一性的时间戳。每个cell中，不同版本的数据按照时间倒序排序，即最新的数据排在最前面。为了避免数据存在过多版本造成的的管理(包括存贮和索引)负担，HBase提供了两种数据版本回收方式。一是保存数据的最后n个版本，二是保存最近一段时间内的版本（比如最近七天）。用户可以针对每个列族进行设置。Cell由{rowkey, column(= <family> + <label>), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

HBase的物理存储

HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种：

• HFile HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile
• HLog File，HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File

HFile

HFile的格式为：

HFile分为六个部分：

• Data Block段–保存表中的数据，这部分可以被压缩
• Meta Block段(可选的)–保存用户自定义的kv对，可以被压缩。
• File Info段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。
• Data Block Index段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。
• Meta Block Index段(可选的)–Meta Block的索引。
• Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，Data Block Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。Data Block Index采用LRU机制淘汰。

HFile文件不定长，长度固定的块只有两个：Trailer和File Info

• Trailer中指针指向其他数据块的起始点
• File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

HFile的 DataBlock，MetaBlock 通常采用压缩方式存储，压缩之后可以大大减少网络 IO 和磁盘 IO，随之而来的开销当然是需要花费 cpu 进行压缩和解压缩。目标 Hfile 的压缩支持两种方式：Gzip，Lzo。

DataIndex 和 MetaIndex 块记录了每个 Data 块和 Meta 块的起始点。DataBlock 是 HBase I/O 的基本单元，为了提高效率，HRegionServer 中有基于 LRU 的 BlockCache 机制。每个 Data 块的大小可以在创建一个 Table 的时候通过参数指定，大号的 Block 有利于顺序 Scan，小号 Block 利于随机查询。每个 Data 块除了开头的 Magic 以外就是一个个 KeyValue 对拼接而成, Magic 内容就是一些随机数字，目的是防止数据损坏。

HFile 里面的每个 KeyValue 对就是一个简单的 byte 数组。这个 byte 数组里面包含了很多项，并且有固定的结构。

• KeyLength 和 ValueLength：两个固定的长度，分别代表 Key 和 Value 的长度
• Key 部分：RowLength 是固定长度的数值，表示 RowKey 的长度，Row 就是 RowKey，ColumnFamilyLength 是固定长度的数值，表示 Family 的长度，接着就是 ColumnFamily，再接着是 Qualifier，然后是两个固定长度的数值，表示 TimeStamp 和 KeyType（Put/Delete）
• Value 部分没有这么复杂的结构，就是纯粹的二进制数据

HLogFile

HLog 文件就是一个普通的 Hadoop SequenceFile，SequenceFile 的 Key 是 HLogKey 对象，HLogKey 中记录了写入数据的归属信息，除了 table 和 region 名字外，同时还包括 sequence number 和 timestamp，timestamp 是“写入时间”，sequence number 的起始值为 0，或者是最近一次存入文件系统中 sequence number。HLog SequeceFile 的 Value 是 HBase 的 KeyValue 对象，即对应 HFile 中的 KeyValue。

HBase 读写流程

写入数据的流程

• Client 向 RegionServer 提交写请求；
• RegionServer 找到目标 Region；
• Region 检查数据是否与 Schema 一致；
• 如果客户端没有指定版本，则获取当前系统时间作为数据版本；
• 将更新写入 WAL Log；
• 将更新写入 Memstore；
• 判断 Memstore 存储是否已满，如果存储已满则需要 flush 为 StoreHfile 文件。

读取数据的流程

以下是客户端首次读写 HBase 上数据的流程：

• 客户端从 Zookeeper 获取 META 表所在的 RegionServer；
• 客户端访问 META 表所在的 RegionServer，从 META 表中查询到访问行键所在的 RegionServer，之后客户端将缓存这些信息以及 META 表的位置；
• 客户端从行键所在的 RegionServer 上获取数据。

如果再次读取，客户端将从缓存中获取行键所在的 RegionServer。这样客户端就不需要再次查询 META 表，除非 Region 移动导致缓存失效，这样的话，则将会重新查询并更新缓存。

注：META 表是 HBase 中一张特殊的表，它保存了所有 Region 的位置信息，META 表自己的位置信息则存储在 ZooKeeper 上。

Hbase 与 Hive 的区别

Apache HBase 和 Apache Hive 是两个不同的大数据处理工具，它们在设计目标、数据模型、使用场景等方面有显著的区别。以下是 HBase 和 Hive 的主要区别：

总结来说，HBase 和 Hive 都是 Hadoop 生态系统中的重要组件，但它们服务于不同的需求和应用场景。HBase 更适合需要实时性和高吞吐量的应用，而 Hive 则是用于批处理和数据分析的利器。选择使用哪一个工具，或者如何组合使用这两个工具，取决于具体的业务需求和数据处理模式。

Hbase 的未来

尽管 Apache HBase 在大数据生态系统中曾经非常流行，特别是在需要快速随机读写和高可扩展性的数据存储场景中，但近年来其使用率有所下降，主要原因包括以下几点：

• 复杂性和维护成本：HBase 的部署和管理相对复杂，需要专业的技能和经验来进行优化和维护。集群的配置、调优、故障排查都需要深入了解其内部机制，这对许多组织来说是一个挑战。
• 性能问题：在某些使用场景下，HBase 的性能可能无法达到预期，特别是在高并发和低延迟的需求下。虽然 HBase 在设计上支持高吞吐量，但在实际应用中可能会遇到瓶颈。
• 替代技术的崛起：近年来，其他分布式数据库和存储解决方案如 Apache Cassandra、Amazon DynamoDB、Google Bigtable 以及Apache Kudu等获得了广泛的关注和采用。这些技术在某些方面提供了更好的性能、更简单的管理或者更好的云服务支持。
• 云服务的普及云计算的普及使得许多组织倾向于使用云原生数据库解决方案，这些服务通常提供更好的易用性、扩展性和维护支持。相比之下，HBase的自建和运维成本显得较高。
• 数据模型限制：HBase的数据模型相对简单，虽然在某些场景中是优点，但在处理复杂数据结构时可能不如其他数据库灵活。
• 社区和生态系统的变化：虽然HBase仍然有一个活跃的开源社区，但与其他新兴技术相比，其创新和更新速度可能相对较慢。此外，企业用户和开发者社区的关注点逐渐转向其他更现代的解决方案。

尽管如此，HBase仍然在一些特定的应用场景中被使用，特别是在需要与Hadoop紧密集成的大数据环境中。选择使用哪种技术通常取决于具体的业务需求、技术团队的能力以及现有的技术栈。对于新项目或需要更高灵活性和易用性的场景，许多组织可能会选择更现代的替代方案。

参考链接：

• 深入理解HBase的系统架构-51CTO.COM
• BigData-Notes/notes/Hbase系统架构及数据结构.md at master heibaiying/BigData-Notes (github.com)
• HBase架构和技术原理介绍-业余砖家-博客园(cnblogs.com)