大数据 | HBase基本工作原理

前文回顾：MapReduce基本原理

目录

HBase基本介绍

HBase的设计目标和功能特点

HBase在Hadoop中的生态环境

HBase的数据模型

逻辑数据模型

物理存储格式

HBase基本构架

HBase数据存储管理方法

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

HBase数据的访问

HBase数据记录的查询定位

---

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简介