一文初探Hbase

一、Hbase是什么

1.HBase官网介绍

参考官网hbase.apache.org

注：本文加入了自己的理解，与官网有部分不一致。且本人也只是在学习的路上，不是布道者，可先参阅官网，对照解读。

官网的解读非常的简略，一共就那么几句话，短的让人心碎。

apache HBase 是Hadoop中一个支持分布式的、可扩展的大数据存储的数据库，

当您需要对大数据进行随机、实时读/写访问时，请使用 Apache HBase。 该项目的目标是在商用硬件集群上托管非常大的表(数十亿行 X 数百万列) 。

Apache HBase是一个开源的，分布式的，版本化的，非关系数据库，以Chang等人的Google的Bigtable：结构化数据的分布式存储系统为模型。

正如Bigtable利用Google文件系统提供的分布式数据存储一样，Apache HBase在Hadoop和HDFS之上提供了类似Bigtable的功能。

从官网简短优雅的介绍来看，透露了HBase的关键信息。

1. HBase是Hadoop体系 中的一员，承担数据库的角色。
2. Hbase在能存储大数据表的前提下，还做到了数据库的随机、实时读写访问。
3. HBase参考谷歌的BigTable 论文，HBase基于HDFS 实现这个分布式的非关系数据库。

不用我说，分布式意味着易拓展，海量数据，基于规模化的集群。

透过官网简短的介绍，大致能了解到HBase是个基于HDFS的支持大数据随机实时随机读写的数据库，接下来讲讲HBase是基于什么样的困境出现，以及Hbase的发展历程。

2.Hbase 发展史

在大数据时代，海量数据的存储和管理显得尤为重要。HBase，作为Apache基金会的Hadoop项目的一部分，使用Java语言实现，将HDFS作为底层文件存储系统，在此基础上运行MapReduce进行分布式的批量处理数据，为Hadoop提供海量数据管理的服务。

1. 起源：HBase的诞生

2006年，Google公司发表了论文"Bigtable: A Distributed Storage System for Structured Data"，详细描述了一种分布式的数据存储系统，可以存储结构化数据。然而，源码并没有开放。2007年2月，根据Bigtable的技术论文，Powerset公司提出了作为Hadoop模块的HBase原型，介绍了HBase的基本概念、数据库表、行键和底层数据存储结构的设计等。

2. 发展：从Hadoop模块到顶级项目

由于HBase依赖HDFS，它的版本发布都与Hadoop同步。2007年10月，第一个可用的HBase版本随同Hadoop 0.15.0版本发布，此版本只实现了最基本的模块和功能。2008年1月，Hadoop升级为Apache的顶级项目，HBase也作为Hadoop的子项目存在。其后HBase的发展非常活跃，两年间追随Hadoop的主版本发布了多个版本。

3. 成熟：成为顶级项目

然而，在2010年6月发布0.89.x版本后，HBase不再与Hadoop发布关联，因为Hadoop的版本相对比较成熟，更新步伐减慢，而HBase处于活跃期，版本发布更加频繁。同时，在2010年HBase成为Apache的顶级项目，此时的HBase已经基本实现了Bigtable论文中提出的功能。

4. 未来：持续发展和优化

2015年2月发布了足够成熟的HBase 1.0.0版本。从Apache官网上来看，十多年来HBase发布了很多版本，包括高可用性、可扩展性和容错性等方面的改进。此外，HBase还在持续发展中，不断优化其性能和稳定性，以满足不断增长的数据存储和管理需求。

二、Hbase为什么出现

1. 大数据随机读写难题

在HBase出现之前是Hadoop生态圈中情况是这样的：分布式存储有HDFS,分布式运算有MapReduce,任务调度有Yarn。

之前遇到的业务场景是：这个网站用户访问产生的数据太多了，存储管理出现问题了。催生出了hadoop以上的存储、运算、调度体系。

但是时代在发展嘛，随着互联网用户的增长，一些实时性要求比较高的数据也开始大量增长，这个时候就面临一个两难的困境：

1. 大数据存储放得下，但是，实时性太差了，一个商品的价格一分钟才能刷新出来体验太差了。
2. 传统数据库实时性虽然也不是多强，但是也算勉强能用，可最大的问题是，数据存储放不下这么大量的数据。

由此我们想到了两种应对方式：

1. 数据库分库分表，一个数据库撑不住，就多部署几个，将数据请求通过简单的hash的方式分给不同的数据库。
2. 在HDFS的基础上进行封装，提高实时读写能力，让他尽可能的具备数据库的随机实时读写能力。

一开始时采用的第一种，但是随着数据量的增大和业务对实时性要求的进一步增加，数据库分库分表已经疲于应对了。传统的数据库模型，虽然结构一致性强，但是在实时性的表现上并不是多么优秀。现在需要一个全新的架构，能够承载大量数据，并且能够更快速的响应，满足实时性的要求。

于是HBase出现了。

2. HBase解决了什么问题

1. 大数据量存储：传统的关系型数据库在存储和处理大规模数据集时存在瓶颈,难以横向扩展。HBase作为NoSQL数据库,通过分布式集群架构,可以线性扩展,支持海量数据的存储。

2. 高并发读写：Base建立在Hadoop和HDFS之上,通过数据的自动拆分,可以支持高并发的读写操作。同时,它的列式存储方式也很适合查询和计算。

3. 实时查询：关系型数据库对实时数据查询支持不好,HBase支持毫秒级的查询响应时间,适合实时数据查询和分析的需求。

4. 灵活的数据模型：HBase采用的是类似BigTable的灵活schema模式,可以动态变更表的schema,非常适合储存变化快速的非结构化和半结构化数据。

5. 海量时间序列数据：HBase的架构天生适合存储时间序列类型的数据,可以作为时序数据库,处理IoT等场景产生的海量时序数据。

6. 数据随机存取：HBase可以为Hadoop提供在线的随机存取能力,使Hadoop不仅可以批处理数据,还可以交互查询数据。

总结,HBase主要解决大数据量,高并发,灵活变化的非结构化数据存储问题,是大数据时代不可或缺的NoSQL数据库。

3. HBase如何支持海量数据的随机存取

1. HBase利用了HDFS的分布式存储和Hadoop的分布式计算能力，将数据存储在HDFS上，并利用Hadoop的MapReduce框架进行分布式计算，从而实现了高可扩展性和高并发性。
2. HBase将数据按照行和列族的方式存储在HDFS上，这种数据存储方式使得HBase能够实现高速的随机读写功能。
3. HBase利用了LSM（Log-Structured Merge-Tree）算法，该算法通过内存和顺序写磁盘的方式，使得随机写入成为可能，同时还能保证读取效率。
4. HBase还支持数据的自动分片和负载均衡，可以支持PB级别的数据存储和处理，从而满足大规模数据的实时处理需求。

综上所述，HBase在HDFS的基础上结合了分布式存储和分布式计算能力，并通过特定的数据存储和算法优化，实现了高并发实时随机读写的能力。

三、架构

1. HBase整体结构

• HMaster:HBase集群的主节点,负责监控RegionServer,处理Region分配和负载均衡。

• HRegionServer:管理 Region,处理对所分配Region的IO请求。Region是表的分片,由多个Store组成。

• Zookeeper:维护HBase的运行状态信息,如Region分布信息等。HMaster和RegionServer都依赖Zookeeper。

• HRegion:HBase表的分片,由一个或者多个Store组成,存储实际的表数据。

• Store:Store以Column Family为单位存储数据,主要组成是MemStore和StoreFile(HFile)。个Column Family的数据存放在一个Store中。一个Region包含多个Store。

• MemStore:内存存储,用于临时存放写数据,达到阈值后刷入StoreFile。通过内存，也加快了读写速度。

• StoreFile(HFile):磁盘上面真正存放数据的文件。

• HDFS: 用来持久化存储HFiles。

以上的架构是典型的主从架构，比较好理解。

2. HBase表结构

参考我终于看懂了HBase，太不容易了... - 知乎 (zhihu.com)

2.1 逻辑架构

以上为一个Hbase数据逻辑表。我们发现Hbase只是相比于我们常见的数据库多了一个列族。在HBase，列（Column ）都归属于列族（Column Family ）中。列族中用列修饰符（Column Qualifier）来标识每个列。

这里就引申出一个问题，Hbase为什么要有列族。

我们知道列族下面还有列，那为什么不去掉列族，只有列的话不会阻塞也HBase的任何功能，我们依然可以继续添加动态列，可以根据列做唯一的Key。

按定义来说，一个 table 是逻辑上应该在一起的数据的组织单元。而列族提供了一种方法，让你在table中创建子结构，以优化你的访问模式的性能，相当于多加了一层索引，定位速度会更快,所以列族的设计，主要是处于性能考虑。

2.2 物理架构

HBase的物理架构比较好理解，就是以key-valu形式存储。

定位的Key由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳--版本）+KeyType（类型）组成。

而Value嘛就是实际上的值。

2.3 HBase的列族存储

我们都知道，HBase是列式存储，他在列这里又做了这么抽象的列族设计，总感觉他在列上搞了不得了的事。

还记得我们在上面Store 介绍中重点圈出来的。个Column Family的数据存放在一个Store中。一个Region包含多个Store。

与传统的数据库以行为单位存储的结构不同，HBase采用了以列族为单位存储数据。

所以，事实上，我觉得Hbase准确来说应该是列族存储。

为什么叫做列族存储，首先我们需要搞明白什么是行式存储和列式存储。

数据库存储组织的两种常见方式：行式存储和列式存储

数据库是复杂的数据管理工具，其内部表结构通常是二维的，具有行和列两个维度。在内存和磁盘等物理存储设备上，数据通常需要以线性顺序组织。为此，有两种常见的数据库存储组织方式：基于行的存储和基于列的存储。

2.3.1基于行的存储

基于行的存储，是将整行数据连续存在一起。在基于行存储的表中，即使只需要读取指定列时，也需要先将对应行的数据读取到内存，然后再过滤目标列，这样会导致过多的磁盘IO、内存和时间开销，所以行式存储比较适用于每次需要访问完整行的场景。

2.3.2基于列的存储

基于列的存储方式则将列数据连续地存储在一起。由于相同类型的数据被存储在一起，这种方式通常具有较高的压缩比，可以降低磁盘IO、内存和时间开销。因此，它比较适用于仅在单列或少数列上执行的查询操作。

然而，对于获取整行数据的请求，基于列的存储方式的效率就没那么高了。这是因为需要多次IO读取多个列的数据，然后再合并返回。

在大数据时代，数据的列和行都较多的情况下，基于列的存储方式的优势会更加明显。

2.3.3HBase的列族存储

HBase是一种特殊的表数据模型，可以简单理解为具有行和列的二维表，但其列被称为"列族"，且在数据写入时可以指定多个子列。

在物理存储上，HBase将整个列族的数据存储在一起。因此，如果HBase中的一张表只有一个列族，那么这个列族就包含了该表的所有列，数据将会以行的方式连续存储。反之，如果一张表有多个列族，且每个列族下仅有一列（尽管HBase不建议这样做），那么数据就会以列的方式连续存储。

数据库表的物理存储组织方式对于数据访问的性能有着重要影响。基于行的存储方式适合访问整行数据，而基于列的存储方式在单列或少数列的访问中表现出更好的性能。HBase的数据模型则提供了行列混合存储的灵活性。

简单理解就是对于一个列族来说是行式存储 ，对于整个数据表来说是以列族为单位的列式存储。所以列族存储可以说是在一定程度上结合了行式和列式两种存储的优点。

2.3.4HBase采用列式存储的其他考虑:

1. 方便存储结构化和非结构化数据： 列式存储非常适合存储属性值对的非结构化和半结构化数据。每一列可以看作一个属性,没有刚性的表结构要求。

2. 突出重要数据： 列式存储可以把重要的属性数据组合存储在一起,方便查询。无关的数据则可以分开存储,减少无效访问。

3. 更新高效： 对列式存储的数据进行更新时,只需要更新相应列的数据即可,不影响其他列的数据,所以更新效率很高。

4. 横向扩展能力强： 在分布式环境下,可以方便地在多台服务器上拆分存储不同的列,实现横向扩展。

5. 压缩率高： 列式存储可以对每个列进行分别压缩,由于列通常数据类型单一,压缩率很高。

6. 查询优化： 只需要读取查询涉及的列,避免无效的数据访问,减少IO,提高查询效率。并且压缩可以进一步加速查询。

7. 支持快速时间序列访问： 时间序列数据可以存储在一列内,数据定位更方便,可以高效完成时间范围查询。

综上,列式存储模型非常适合HBase需要处理的大规模分布式非结构化数据,能够发挥HBase的 querying和scaling能力。这也是大数据时代列式数据库发展迅速的重要原因之一。