HBase入门:实现原理

文章目录

说明

  • 本文参考自林子雨老师的《大数据技术原理与应用(第三版)》教材内容,仅供学习和交流

HBase的实现原理

HBase功能组件

  • HBase 的实现包括 3 个主要的功能组件:库函数,链接到每个客户端;一个 Master 主服务器(也称为 Master);多个 Region 服务器。
  • Region 服务器负责存储和维护分配给自己的 Region,处理来自客户端的读写请求。
  • Master 主服务器负责管理和维护HBase 表的分区信息,同时也负责维护 Region 服务器列表。Master 会实时监测集群中的 Region 服务器,把特定的 Region 分配到可用的 Region 服务器上,并确保整个集群内部不同 Region 服务器之间的负载均衡。当某个 Region 服务器因出现故障而失效时,Master 会把该故障服务器上存储的 Region 重新分配给其他可用的 Region 服务器。除此以外,Master 还处理模式变化,如表和列族的创建。
  • 客户端并不是直接从 Master 主服务器上读取数据,而是在获得 Region 的存储位置信息后,直接从 Region 服务器上读取数据。
  • 注意,HBase 客户端并不依赖于 Master 而是借助于 ZooKeeper 来获得 Region 的位置信息的,所以大多数客户端从来不和 Master 主服务器通信,这种设计方式使 Master 的负载很小。

表和 Region

  • 对于每个 HBase 表而言,表中的行是根据行键的值的字典序进行维护的,表中包含的行的数量可能非常庞大,无法存储在一台机器上,需要分布存储到多台机器上。因此,需要根据行键的值对表中的行进行分区。每个行区间构成一个分区,被称为"Region"。

  • Region 包含了位于某个值域区间内的所有数据,是HBase负载均衡和数据分发的基本单位。这些 Region 会被分发到不同的 Region 服务器上。

  • 初始时,每个表只包含一个 Region,随着数据的不断插入,Region 会持续增大。当一个 Region中包含的行数量达到一个阈值时,就会被自动等分成两个新的 Region,随着表中行的数量继续增加,就会分裂出越来越多的 Region

  • 每个 Region 的默认大小是 100~200 MB。Master主服务器会把不同的 Region 分配到不同的 Region 服务器上,同一个 Region 不会被拆分到多个 Region 服务器上。

  • 每个 Region 服务器负责管理一个 Region 集合,通常在每个 Region服务器上会放置 10~1000 个 Region。

Region 的定位

  • 一个 HBase 的表可能非常庞大,会被分裂成很多个 Region,这些 Region 可被分发到不同的Region 服务器上。因此,必须设计相应的 Region 定位机制,保证客户端可以定位所需数据的Region服务器地址
  • 每个 Region 都有一个 RegionID 来标识它的唯一性,一个 Region 标识符就可以表示成"表名+开始主键+RegionID"。
  • 为了定位每个 Region 所在的位置,可以构建一张映射表。映射表的每个条目(或每行)包含两项内容,一个是 Region 标识符,另一个是 Region 服务器标识。这个映射表包含了关于 Region 的元数据(即 Region和 Region 服务器之间的对应关系),因此也被称为"元数据表",又名".META.表"。
  • 当一个 HBase 表中的 Region 数量非常庞大的时候,.META.表的条目就会非常多,一个服务器保存不下,也需要分区存储到不同的服务器上,因此.META.表也会被分裂成多个 Region。为了定位这些 Region,需要构建新的映射表,记录所有元数据的具体位置,新的映射表就是"根数据表",又名"-ROOT-表"。-ROOT-表不能被分割,永远只存在一个 Region 用于存放-ROOT-表。用来存放-ROOT-表的唯一一个Region,它的名字是在程序中被"写死"的,Master 主服务器永远知道它的位置。
  • HBase 使用类似 B+树的三层结构来保存 Region 位置信息。
  • HBase 三层结构中各层次的名称和作用
层次 名称 作用
第一层 ZooKeeper文件 记录了-ROOT-表的位置信息
第二层 -ROOT-表 记录.META.表的Region位置信息,-ROOT-表只能有一个 Region,通过-ROOT-表访问.META.表中的数据
第三层 .META.表 记录用户数据表的Region位置信息,.META.表可以有多个 Region,保存HBase 中所有用户数据表的 Region 位置信息
  • 为了加快访问速度,.META.表的全部 Region 都会被保存在内存中

  • 客户端访问流程:客户端访问用户数据前,首先访问 ZooKeeper,获取-ROOT-表的位置信息,然后访问-ROOT-表,获得.META.表的信息,接着访问.META.表,找到所需的 Region 具体的Region服务器,最后才会到该 Region 服务器读取数据。该过程需要多次网络操作,为加速寻址过程,一般会在客户端把查询过的位置信息缓存起来,访问相同的数据时,直接从客户端缓存中获取 Region 的位置信息,不需要每次都经历一个"三级寻址"过程。

  • 注意:随着 HBase 中表的不断更新,Region 的位置信息可能会发生变化,但是客户端缓存并不会本地检测 Region 位置信息是否失效,而是在需要访问数据时,从缓存中获取 Region 位置信息发现不存在时,才会判断出缓存失效。这时,客户端会再次经历"三级寻址"过程,重新获取最新的 Region 位置信息访问数据,并替换缓存中失效信息。

  • 客户端从 ZooKeeper 服务器上获取-ROOT-表地址后,通过"三级寻址"获取用户数据表所在的 Region 服务器,并直接访问该 Region 服务器获得数据,没有必要再连接Master 主服务器。因此,减轻了Master 主服务器的负载。

相关推荐
摇滚侠6 小时前
《On Java 中文版 基础卷》阅读笔记 实现隐藏 12
java·数据库·笔记
川石课堂软件测试6 小时前
学习软件测试需掌握的一些知识
数据库·python·sql·功能测试·网络协议·mysql·http
HRaitest6 小时前
秋招技术岗招聘提效:三类 AI 招聘方案的技术底层与选型逻辑
大数据·人工智能·求职招聘·ai-native
2501_937767167 小时前
自建 SQL 数据库定时备份踩坑复盘与落地思路
数据库·sql
starzy19908 小时前
Kafka源码深度剖析:消息有异常是如何处理的
大数据·kafka
silvamux_8 小时前
10款模型写种草笔记:可发布性、返工来源与成本数据缺口复盘
java·数据库·笔记
大大大大晴天8 小时前
每天认识一个组件:ClickHouse
大数据
zwjapple10 小时前
skill总结
大数据·elasticsearch·搜索引擎
I Am a robert girl10 小时前
从 GameHorizon 拆解多时间尺度游戏评测:数据管线、离线基准与在线回放的三层设计
数据库·游戏·多时间尺度·数据管线·游戏评测·离线基准·在线回放
躺柒10 小时前
读数据安全架构设计与实践17安全架构案例(下)
数据库·安全·零信任·安全架构·防火墙·无边界