分布式存储数据库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、Region Server、ZooKeeper 以及 HDFS。它的架构组成如下图所示。

HBase Client

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

HMaster

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

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

Region Server

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

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

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

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

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

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

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

ZooKeeper

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

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

HDFS

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

HBase 的数据模型

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

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

Row Key

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

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

Row key行键 (Row key)可以是任意字符串(最大长度是 64KB，实际应用中长度一般为 10-100bytes)，在HBase内部，row key保存为字节数组。存储时，数据按照Row key的字典序(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由{row key, 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)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。

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

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

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

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

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

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

HLog File

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

HBase 读写流程

写入数据的流程

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

读取数据的流程

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

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

如果再次读取，客户端将从缓存中获取行键所在的 Region Server。这样客户端就不需要再次查询 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)