0


大数据 | HBase基本工作原理

前文回顾:MapReduce基本原理

📚HBase基本介绍

HBase 是一种分布式、可扩展、支持海量数据存储的 NoSQL(not only SQL) 数据库。

🐇HBase的设计目标和功能特点

Hadoop主要是实现批量数据的处理,并且通过顺序方式访问数据。要查找数据必须搜索整个数据集,如果要进行随机读取数据,压根就不支持。即Hadoop仅适合存储大批量的数据,进行顺序化读取数据,并不支持随机读取数据操作。

  • 针对HDFS缺少结构化半结构化数据存储访问能力的缺陷,提供一个分布式数据管理系统,解决大规模的结构化和半结构化数据存储访问问题
  • 提供基于列存储模式的大数据表管理能力。可存储管理数十亿以上的数据记录,每个记录可包含百万以上的数据列。
  • HBase试图提供随机和实时的数据读写访问能力。
  • 具有高可扩展性、高可用性、容错处理能力、负载平衡能力、以及实时数据查询能力。

🐇HBase在Hadoop中的生态环境

  • 构建于分布式文件系统HDFS之上。HBase的数据(底层数据)实际上是放在HDFS里的。
  • 为上层应用提供结构化半结构化海量数据存储访问能力。

  • 可与MapReduce协同工作,为MapReduce提供数据输入输出,以完成数据的并行化处理。

📚HBase的数据模型

🐇逻辑数据模型

HBase是一个分布式多维表,表中的数据通过:一个行关键字(row key),一个列关键字(column family + column name),一个时间戳(time stamp)进行索引和查询定位。

  • region- 类比于关系型数据库的表概念。不同的是,HBase 定义表时只需要声明列族,不需要声明具体的列。这意味着,往 HBase 写入数据时,字段可以动态、按需指定。因此,和关系型数据库相比,HBase 能够轻松应对字段变更的场景。
  • 行关键字- HBase一张表可以有上亿行记录,每一行都是由一个行关键字来标识的。和关系型数据库中的主键不同,HBase的row key只能是一个字段而不可以是多个字段的组合。- HBase保证对所有行按照row key进行字典排序。也就是说,HBase保证相邻row key的行在存储时必然是相邻存放的。(row key是最大长度为64KB的byte数组,实际应用中长度一般为10bytes~100bytes。由于HBase只允许单字段的row key,因此在实际应用中需要时经常把多个字段组合成一个复合row key。)
  • 列族和列名- HBase每张表都有一个或者多个列族。列族必须在使用表之前定义。- 从本质来说,HBase的列族就是一个容器。HBase表中的每个列,都必须归属于某个列族。- 列名都以列族作为前缀,列如courses:history,courses:math都属于courses这个列族。- 在具体实现上,一张表中的不同列族是分开独立存放的。就是说,如果有两个列族family1和family2,那么在HDFS存储时,family1是一组文件,family2是另外一组文件,两者不能混合存储。- HBase的访问控制、磁盘和内存的使用统计等都是在列族层面进行的。- 在每个列族中,可以存放很多的列,而每行每列族中的列数量是可以不同的,数量可以很大。简单来说,可以认为每行每列族中保存的是一个Map映射表
  • 时间戳- HBase中每个存储单元都保存着同一份数据的多个版本。版本通过时间戳来索引。- 每个存储单元中,不同版本的数据按照时间戳的大小倒序排序,即最新的数据排在最前面。这样在读取时,将先读取到最新的数据。(时间戳可以由HBase(当数据写入时自动用当前系统时间)赋值,也可以由用户显示赋值。如果应用程序要避免数据版本冲突,可以自己生成具有唯一性的时间戳。)

优秀网图

🐇物理存储格式

  • 对于HBase来说,它根本不认为存在行列这样的概念,在实现时只认为存在键值对这样的概念。键值对的存储是排序的,行概念是通过相邻的键值对比较而构建出来的。
  • 也就是说,HBase在物理实现上并不存在传统数据库中的二维表概念。因此二维表中字段值的空洞,对于HBase来说在物理实现上并不存在,而不是所谓的值为null
  • 按列存储的稀疏行/列矩阵。物理存储格式上按逻辑模型中的行进行分割,并按照列族存储。
  • 值为空的列不予存储,节省存储空间。

优秀网图

📚HBase基本构架

由一个MasterServer和一组子表数据区服务器RegionServer构成,分别存储逻辑大表中的部分数据

  • HBase Master:Master是HBase集群的主控服务器,负责集群状态的管理维护。Master可以有多个,但只有一个是活跃的(负责人里的真正老大。- 为Region Server分配Region。- 负责Region Server的负载均衡。- 发现失效的Region Server并重新分配其上的Region。- HDFS上的垃圾文件回收。- 处理schema更新请求。
  • HBase Region Server:Region Server是HBase具体对外提供服务的进程。 - Region Server维护Master分配给它的Region,处理对这些Region的I/O请求。- Region Server负责切分在运行过程中变得过大的Region。

  • 当一个新的子表服务器注册时,主服务器让新的子表服务器装载子表。
  • 若主服务器与子表服务器连接超时,那么子表服务器将自动停止,并重新启动;而主服务器则假定该子表服务器已死机,将其上的数据转移至其它子表服务器,将其上的子表标注为空闲,并在重新启动后另行分配使用。

📚HBase数据存储管理方法

🐇HBase子表数据存储与子表服务器

大表被分为很多个子表(Region),每个子表存储在一个子表服务器RegionServer上

每个子表中的数据区Region由很多个数据存储块Store构成,而每个Store数据块又由存放在内存中的memStore和存放在文件中的StoreFile构成。

  • 每个列族就存储在一个Store中。
  • StoreFile以Hfile格式保存在HDFS上。

  • 每个表一开始只有一个Region,随着数据不断插入表,Region不断增大。当一个Region增大到一个阈值(由参数hbase.hregion.max.filesize指定,但这个阈值其实不是限制每个Region大小的,而是限制每个Store大小的)的时候,原来的Region会被分裂成两个新的Region(从而保证Region不会过大)。
  • 随着表中的行数不断增多,Region的数目也会逐渐增多。
  • 多个region共享一个日志(串行)

🐇HBase数据的访问

  • 当客户端需要进行数据更新时,先查到子表服务器,然后向子表提交数据更新请求。提交的数据并不直接存储到磁盘上的数据文件中,而是添加到一个基于内存的子表数据对象memStore中,当memStore中的数据达到一定大小时,系统将自动将数据写入到文件数据块StoreFile中。(就和抽血检测似的,抽满一板统一提交去检测)
  • 每个文件数据块StoreFile最后都写入到底层基于HDFS的文件中(Hfile)
  • 需要查询数据时,子表先查memStore。如果没有,则再查磁盘上的StoreFile。每个StoreFile都有类似B树的结构,允许进行快速的数据查询。StoreFile将定时压缩,多个压缩为一个。
  • 两个小的子表可以进行合并。

🐇HBase数据记录的查询定位

  • 描述所有子表和子表中数据块的元数据都存放在专门的元数据表中,并存储在特殊的子表中。子表元数据会不断增长,因此会使用多个子表来保存。
  • 所有元数据子表的元数据都保存在根子表中。主服务器会扫描根子表,从而得到所有的元数据子表位置,再进一步扫描这些元数据子表即可获得所寻找子表的位置。
  • 元数据子表采用三级索引结构

根子表->用户表的元数据表->用户表

  1. 按表的名字排序
  2. 大表里的行是按role-key作为代表
  3. 每个region里的第一行的role-key作为代表

参考教材:《深入理解大数据:大数据处理与编程实现》

参考博客:HBase简介

标签: 大数据 hbase

本文转载自: https://blog.csdn.net/m0_63398413/article/details/130070508
版权归原作者 啦啦右一 所有, 如有侵权,请联系我们删除。

“大数据 | HBase基本工作原理”的评论:

还没有评论