Hbase——详解
产生背景
自 1970 年以来,关系数据库用于数据存储和维护有关问题的解决方案。大数据的出现后, 好多公司实现处理大数据并从中受益,并开始选择像 Hadoop 的解决方案。Hadoop 使用分 布式文件系统,用于存储大数据,并使用 MapReduce 来处理。Hadoop 擅长于存储各种格式 的庞大的数据,任意的格式甚至非结构化的处理。
Hadoop 的限制
Hadoop 只能执行批量处理,并且只以顺序方式访问数据。这意味着必须搜索整个数据集, 即使是最简单的搜索工作。 当处理结果在另一个庞大的数据集,也是按顺序处理一个巨大的数据集。在这一点上,一个 新的解决方案,需要访问数据中的任何点(随机访问)单元。
Hadoop 随机存取数据库
应用程序,如 HBase,Cassandra,CouchDB,Dynamo 和 MongoDB 都是一些存储大量数据和 以随机方式访问数据的数据库。
总结:
- 1、海量数据量存储成为瓶颈,单台机器无法负载大量数据
- 2、单台机器 IO 读写请求成为海量数据存储时候高并发大规模请求的瓶颈
- 3、随着数据规模越来越大,大量业务场景开始考虑数据存储横向水平扩展,使得存储服 务可以增加/删除,而目前的关系型数据库更专注于一台机器
一、Hbase的概念
Hbase 官网:hbase.apache.org
HBase是Hadoop的生态系统,是建立在Hadoop文件系统(HDFS)之上的分布式、面向列的数据库,通过利用Hadoop的文件系统提供容错能力。如果你需要进行实时读写或者随机访问大规模的数据集的时候,请考虑使用HBase!
HBase作为Google Bigtable的开源实现,Google Bigtable利用GFS作为其文件存储系统类似,则HBase利用Hadoop HDFS作为其文件存储系统;Google通过运行MapReduce来处理Bigtable中的海量数据,同样,HBase利用Hadoop MapReduce来处理HBase中的海量数据;Google Bigtable利用Chubby作为协同服务,HBase利用Zookeeper作为对应。
HBase 是一个高可靠、高性能、面向列、可伸缩的分布式数据库,主要用来存储非结构化和半结构化的松散数据,设计它的目的就是用于处理非常庞大的表——通过水平扩展的方式,用计算机集群就可以处理由超过 10 亿行数据和数百万列元素所组成的数据表。
HBase 数据库的要点
-
它介于 NoSQL 和 RDBMS 之间,仅能通过主键(rowkey)和主键的 range 来检索数据
-
HBase 查询数据功能很简单,不支持 join 等复杂操作
-
不支持复杂的事务,只支持行级事务(可通过 hive 支持来实现多表 join 等复杂操作)。
-
HBase 中支持的数据类型:byte[](底层所有数据的存储都是字节数组)
-
主要用来存储结构化和半结构化的松散数据。
结构化、半结构化和非结构化
-
结构化:数据结构字段含义确定,清晰,典型的如数据库中的表结构
-
半结构化:具有一定结构,但语义不够确定,典型的如 HTML 网页,有些字段是确定的(title), 有些不确定(table)
-
非结构化:杂乱无章的数据,很难按照一个概念去进行抽取,无规律性。
与 Hadoop 一样,HBase 目标主要依靠横向扩展,通过不断增加廉价的商用服务器,来增加 计算和存储能力。
HBase 中的表特点
-
1、大:一个表可以有上十亿行,上百万列
-
2、面向列:面向列(族)的存储和权限控制,列(簇)独立检索。
-
3、稀疏:对于为空(null)的列,并不占用存储空间,因此,表可以设计的非常稀疏。
-
4、无模式:每行都有一个可排序的主键和任意多的列,列可以根据需要动态的增加,同一 张表中不同的行可以有截然不同的列。

HBase 与关系型数据库的简要比较

二、HBase 特点
1、海量存储
- HBase适合存储PB级别的海量数据,在PB级别的数据以及采用廉价PC存储的情况下,能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性,才为海量数据的存储提供了便利。
- Hbase单表可以有百亿行、百万列,数据矩阵横向和纵向两个维度所支持的数量级都非常具有弹性。
2、列式存储
HBase是根据列族来存储数据的。这里的列式存储其实说的是列族存储,Hbase是根据列族来存储数据的。列族下面可以有非常多的列,列族在创建表的时候就必须指定。
3、多版本
Hbase每一列的数据存储有多个Version。
4、面向列
Hbase是面向列的存储和权限控制,并支持独立检索。列式存储,其数据在表中按照某列存储的,这样在查询只需要少数几个字段时,能大大减少读取的数据量。(实时动态增加列;单独对某一列做一些操作)
5、高并发
由于目前大部分使用HBase的架构,都是采用的廉价PC,因此单个IO的延迟其实并不小,一般在几十到上百ms之间。这里说的高并发,主要是在并发的情况下,Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
6、稀疏性
稀疏主要是针对HBase列的灵活性,在列族中,你可以指定任意多的列,在列数据为空的情况下,是不会占用存储空间的。
7、极易扩展
HBase的扩展性主要体现在两个方面,一个是基于上层处理能力(RegionServer)的扩展,一个是基于存储的扩展(HDFS)。
通过横向添加RegionSever的机器,进行水平扩展,提升Hbase上层的处理能力,提升Hbsae服务更多Region的能力。
基于存储的扩展(HDFS),如果磁盘空间不够时,增加datanode节点或增加datanode节点的存储即可。
备注:RegionServer的作用是管理region、承接业务的访问,这个后面会详细的介绍通过横向添加Datanode的机器,进行存储层扩容,提升Hbase的数据存储能力和提升后端存储的读写能力。
8、高可靠性:WAL机制保证了数据写入时不会因集群异常而导致写入数据丢失:Replication机制保证了在集群出现严重问题时,数据不会发生丢失或损坏。而且Hbase底层使用hdfs,hdfs本身也有备份机制。
9、高性能:
底层的LSM数据结构和RowKey有序排列等架构上的独特设计,使得Hbase写入性能非常高。
Region切分、主键索引、缓存机制使得Hbase在海量数据下具备一定的随机读取性能,该性能针对Rowkey的查询能够到达毫秒级别。
LSM树,树形结构,最末端的子节点是以内存的方式进行存储的,内存中的小树会flush到磁盘中(当子节点达到一定阈值以后,会放到磁盘中,且存入的过程会进行实时merge成一个主节点,然后磁盘中的树定期会做merge操作,合并成一棵大树,以优化读性能。)
支持过期:HBase支持TTL( Time To Live)过期特性,用户只需要设置过期时间,超过TTL的数据就会被自动清理,不需要用户写程序手动删除。
三、HBase 数据模型
逻辑上,HBase的数据模型同关系型数据库很类似,数据存储在一张表中,有行有列。但从HBase的底层物理存储结构(K-V)来看,HBase更像是一个多维度map(multi-dimensional map)
3.1 逻辑结构

Row_Key是必需有的,而且是唯一的,personal_info、office_info是列族,不同的列族是分开存储的。列族下面才是存储数据的列,而列是可以随便增加的。
上图是HBase表的逻辑结构,实际存储中,一个表可能是放在不同的服务器节点上面。另外存储是基于HDFS集群的,所以要先了解HDFS。
3.2、HBase的物理存储结构
以上只是一个基本的逻辑结构,底层的物理存储结构才是重中之重的内容,看下图

对于 HBASE 时间戳 用于标记 数据有效,默认情况下,每次查询数据只返回最新的时间戳标记的数据;
3.3、数据模型
NameSpace
-
命名空间,类似关系型数据库 DatabBase 概念,每个命名空间下有多个表。HBase有两个自带的命名空间,分别是hbase和default,hbase 中存放的是 HBase 内置的表,default 表是用户默认使用的命名空间。
-
命名空间的结构
-
Table:表,所有的表都是命名空间的成员,即表必属于某个命名空间,如果没有指定,则在 default 默认的命名空间中。
-
RegionServer group:一个命名空间包含了默认的 RegionServer Group。
-
Permission:权限,命名空间能够让我们来定义访问控制列表 ACL(Access Control List)。例如,创建表,读取表,删除,更新等等操作。
-
Quota:限额,可以强制一个命名空间可包含的 region 的数量。

Table(表)
- 表由一个或者多个列族构成。数据的属性如name、age、TTL(超时时间)等都在列族里边定义。定义完列族的表是个空表,只有添加了数据行以后,表才有数据。
Region(区域)
-
Region 就是若干行数据的集合。HBase 中的 Region 会根据数据量的大小动态分裂,Region是基于HDFS实现的,关于Region的存取操作都是调用HDFS客户端完成的。同一个行键的 Region 不会被拆分到多个 Region 服务器上。
-
Region 有一点像关系型数据的分区,数据存放在Region中,当然Region下面还有很多结构,确切来说数据存放在MemStore和HFile中。访问HBase 时先去HBase 系统表查找定位这条记录属于哪个Region ,然后定位到这个Region 属于哪个服务器,然后就到哪个服务器里面查找对应Region 中的数据。
RegionServer
- RegionServer 就是存放Region的容器,直观上说就是服务器上的一个服务。负责管理维护 Region。
Row(行)
- 一行包含多个列,这些列通过列族来分类。行中的数据所属的列族从该表所定义的列族中选取。由于HBase是一个面向列存储的数据库,所以一个行中的数据可以分布在不同的服务器上。
RowKey(行键)
- RowKey 类似 MySQL 中的主键,在 HBase 中 RowKey 必须有且 RowKey 是按照字典排序的,如果用户不指定 RowKey 系统会自动生成不重复字符串。查询数据时只能根据 RowKey 进行检索,所以 Table 的 RowKey 设计十分重要。
Column Family(列族)
- 多个列组合成一个列族。建表时不用创建列,在 HBase 中列是可增减变化的!唯一要确定的是列族,表有几个列族在开始创建时就定好的。表的很多属性,比如数据过期时间、数据块缓存以及是否使用压缩等都是定义在列族上的。
- HBase 会把相同列族的几个列数据尽量放在同一台机器上。
Column (列)
- HBase 中的每个列都由 Column Family(列族) 和 Column Qualifier(列限定符)进行限定,例如 info:name、info:age。建表时只需指明列族,而列限定符无需预先定义。
Cell
- 单元格,由 {rowkey, column Family:column Qualifier, time Stamp} 唯一确定的单元。cell 中的数据是没有类型的,全部是字节码形式存储。
TimeStamp
- 时间戳,用于标识数据的不同版本(version),每条数据写入时如果不指定时间戳,系统会自动添加为其写入 HBase 的时间。并且读取数据的时候一般只拿出数据的Type符合,时间戳最新的数据。之所以按照Type取数据是因为HBase的底层HDFS支持增删查,但不支持改。
四、系统架构


Hbase 是由 Client、Zookeeper、Master、HRegionServer、HDFS 等几个组件组成,HBase依赖于ZooKeeper和HDFS。
HBase客户端
- HBase客户端(Client)提供了Shell命令行接口、原生Java API编程接口、Thrift/REST API编程接口以及MapReduce编程接口。HBase客户端支持所有常见的DML操作以及DDL操作,即数据的增删改查和表的日常维护等。其中Thrift/REST API主要用于支持非Java的上层业务需求,MapReduce接口主要用于批量数据导入以及批量数据读取。
ZooKeeper
- HBase 通过 Zookeeper 来做 master 的高可用(通过 Zoopkeeper 来保证集群中只有 1 个 master 在运行,如果 master 异常,会通过竞争机制产生新的 master 提供服务。)、RegionServer 的监控(通过 Zoopkeeper 来监控 RegionServer 的状态,当 RegionSevrer 有异常的时候,通过回调的形式通知 Master RegionServer 上下线的信息)、元数据的入口以及集群配置的维护等工作。
Hmaster
- 监控 RegionServer,为 RegionServer 分配 Region(维护整个集群的负载均衡,在空闲时间进行数据的负载均衡 ) ,维护集群的元数据信息,处理 region 的分配或转移(发现失效的 Region,并将失效的 Region 分配到正常的 RegionServer 上 ;当 RegionSever 失效的时候,协调对应 Hlog 的拆分)
HregionServer
- HregionServer 直接对接用户的读写请求,是真正的“干活”的节点。它的功能概括如下: 管理 master 为其分配的 Region,处理来自客户端的读写请求 ,负责和底层 HDFS 的交互(存储数据到 HDFS),负责 Region 变大以后的拆分,负责 Storefile 的合并工作 ,刷新缓存到HDFS,维护Hlog。
HDFS
- 为 Hbase 提供最终的底层数据存储服务,同时为HBase 提供高可用(Hlog 存储在HDFS)的支持,具体功能概括如下:提供元数据和表数据的底层分布式存储服务,保证的高可靠和高可用性 (数据多副本)
MemStore
- 内存缓存,达到一定缓存大小或者时间节点触发一次 flush,文件系统中生成新的 HFile,每次 Flush 的最小单位是 Region。每个 Column family 维护一个 MemStore。
Write-Ahead logs(WAL,Hlog)
- 用来容灾。当对 HBase 写数据的时候,数据会在内存MemStore中保留一段时间,MemStore达到一定的数据量(时间以及数据量阈值可以设定),数据再写进磁盘。但把数据保存在内存中可能有更高的概率引起数据丢失,为了解决这个问题,数据会先写在一个叫做 Write-Ahead logfile 的文件中,然后再写入内存中,所以在系统出现故障的时候,数据可以通过这个日志文件重建。
Region
-
Hbase表的分片,HBase 表会根据 RowKey 值被切分成不同的 region 存储在 RegionServer中,在一个 RegionServer 中可以有多个不同的 region。同一个行键的 Region 不会被拆分到多个 Region 服务器上。 一个HBase表被划分成多个Region,开始只有一个Region,后台不断分裂。
一个表中包含多个列族,一个列族一个文件存储,region的切分是横向切分的,那么包含了多个列族。
Meta表
-
描述HBase表的表,元数据表。有了 Region 标识符,就可以唯一标识每个 Region。为了定位每个 Region 所在的位置,可以构建一张映射表。映射表的每个条目包含两项内容,一项是 Region 标识符,另一项是 Region 服务器标识。这个条目就表示 Region 和 Region 服务器之间的对应关系,从而就可以使用户知道某个 Region 存储在哪个 Region 服务器中。这个映射表包含了关于 Region 的元数据,因此也被称为“元数据表”,又名“Meta表”。使用 scan 命令可查看 Meta 表的结构,如图所示
-
Meta 表中的每一行记录了一个 Region 的信息。RowKey 包含表名、起始行键和时间戳信息,中间用逗号隔开,第一个 Region 的起始行键为空。时间戳之后用.隔开的为分区名称的编码字符串,该信息是由前面的表名、起始行键和时间戳进行字符串编码后形成的。
-
Meta 表里有一个列族 info。info 包含了三个列,分别为 Regioninfo、Server 和 Serverstartcode。Regionlnfo中记录了 Region 的详细信息,包括行键范围 StartKey 和 EndKey、列族列表和属性。
-
Server 记录了管理该 Region 的 Region 服务器的地址,如 localhost:16201。Serverstartcode 记录了 Region 服务器开始托管该 Region 的时间。
-
当用户表特别大时,用户表的 Region 也会非常多。Meta 表存储了这些 Region 信息,也变得非常大。Meta 表也需要划分成多个 Region,每个 Meta 分区记录一部分用户表和分区管理的情况。(有了meta表,就可以得到region和HRegionServer的对应关系,可以进行Region定位:客户端通过 ZooKeeper 获取 Meta 表(分区表)存储的地址,首先在对应的 Regionserver上获取 Meta 表的信息(meta表存在Regionserver上),得到所需的Region对应的Regionserver的信息,然后从Region 服务器上找到所需的数据)
Store
- HFile 存储在 Store 中,一个 Store 对应 HBase 表中的一个列族。
HFile
- 这是在磁盘上保存原始数据的实际的物理文件,是实际的存储文件。StoreFile 是以 Hfile的形式存储在 HDFS 的。
五、HBase 使用场景
-
1、时空数据:主要是轨迹、气象网格之类,比如滴滴打车的轨迹数据主要存在 HBase 之中,另外大数据量的车联网企业,数据也都是存在 HBase 中。比如互联网出行,智慧物流与外卖递送,传感网与实时 GIS 等场景。
-
2、推荐画像:别是用户的画像,是一个比较大的稀疏矩阵,蚂蚁的风控就是构建在 HBase 上。用户画像有用户数据量大,用户标签多,标签统计维度不确定等特点,适合 HBase 特性的发挥。
-
3、消息/订单:在电信领域、银行领域,不少的订单查询底层的存储,另外不少通信、消息同步的应用构建在 HBase 之上。
另外电商领域的订单数据,订单流程完结数据不在变动,超过一定时间的订单可以存储在HBase中,MySQL只存储最近三个月的订单数据即可,减轻MySQL的压力。
-
4、储存浏览记录:大型的视频网站,电商平台产生的用户点击行为、浏览行为等等存储在 HBase 中为后续的智能推荐做数据支撑。
-
5、对象存储:这里的对象存储实际是中等对象存储,是对 HDFS 存储文件的一个缓冲过度。HBase 提供了中等对现象的存储能力,中等对象的大小范围在 100k 至 10M 之间。
-
6、时序数据:时序数据就是分布在时间上的一系列数值。HBase 之上有 OpenTSDB 模块,可以满足时序类场景的需求。
比如我们有很多的设备、传感器,产生很多数据,如果规模不是特别大的厂家有几千个风机,每个风机有几百个指标,那么就会有一百万左右的时序数据,如果用采样每一秒会产生一百万个时间点,如果用传统数据库,那么每一秒会产生一百万次,持续地往 MQ 做一百万次,它会崩裂。并且查询也是个大问题,除了多维查询以外,我们还会额外地增加时间纬度,查看一段时间的数据。这时候 HBase 很好了满足了时序类场景的需求。
-
7、Cube 分析(KyLin):通过 KyLin 将 Hive 或 kafka 中的数据,来构建 Cube,这些 Cube 会存储在 HBase 中。
-
8、NewSQL:HBase 上有 Phoenix 的插件,可以满足二级索引、SQL 的需求,对接传统数据需要 SQL 非事务的需求。从 NoSQL 到 NewSQL,Phoenix 或许是新的趋势。
-
9、Feeds 流:Feed 流,是 RSS 中用来接收该信息来源更新的接口,简单的说就是持续更新并呈现给用户的内容。比如微信朋友圈中看到的好友的一条条状态,微博看到的你关注的人更新的内容,App 收到的一篇篇新文章的推送,都算是 feed 流。
更多的场景需要不断挖掘
HBase 可以说是一个数据库,也可以说是一个存储。拥有双重属性的 HBase 天生就具备广阔的应用场景。在最近的一些版本中,引入了 OffHeap 降低 gc 影响,优化链路延迟,提供 Replica 等可以满足在线的需求。引入 MOB,可以存储 10M 左右的对象,完全适应了对象存储。另外由于自身的并发能力、存储能力,可以说是具有最为竞争力的引擎
cassandra-vs-hbase:https://www.scnsoft.com/blog/cassandra-vs-hbase
参考:
https://blog.csdn.net/weixin_42011858/article/details/129299164
https://blog.csdn.net/weixin_44133605/article/details/124635627
https://www.cnblogs.com/qingyunzong/p/8665698.html
https://www.cnblogs.com/wdh01/p/16248799.html
https://blog.csdn.net/qq_33208851/article/details/105223419
https://blog.csdn.net/nmsLLCSDN/article/details/124088245
https://blog.csdn.net/llAl_lAll/article/details/122260638
https://blog.csdn.net/Shyllin/article/details/124386524
https://blog.csdn.net/lilygg/article/details/116790288
https://www.cnblogs.com/kyoner/p/14264470.html