详解 HBase 的架构和基本原理

2024-06-17 16:20

本文主要是介绍详解 HBase 的架构和基本原理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、基本架构

在这里插入图片描述

  • StoreFile:保存实际数据的物理文件,StoreFile 以 HFile 的格式 (KV) 存储在 HDFS 上。每个 Store 会有一个或多个 StoreFile(HFile),数据在每个 StoreFile 中都是有序的
  • MemStore:写缓存,由于 HFile 中的数据要求是有序的,所以数据是先存储在 MemStore 中,排好序后,等到达刷写时机才会刷写到 HFile,每次刷写都会形成一个新的 HFile
  • WAL:由于数据要经 MemStore 排序后才能刷写到 HFile,但把数据保存在内存中会有很高的概率导致数据丢失,为了解决这个问题,数据会先写在一个叫做 Write-Ahead logfile 的文件中,然后再写入 MemStore 中。所以在系统出现故障的时候,数据可以通过这个日志文件重建

二、写流程原理

HBase 的读操作比写操作慢,且读写流程没有 master 参与

在这里插入图片描述

  • 老版本:Zookeeper 中存储的是 -root- 表的位置信息,-root- 表存储的 meta 表的位置信息(防止 meta 表进行切分)
  • Client 先访问 Zookeeper,获取 hbase:meta 表位于哪个 Region Server
  • 访问对应的 Region Server,获取 hbase:meta 表数据,根据写请求的 namespace:table/rowkey 信息查询出目标数据位于哪个 Region Server 中的哪个 Region 中,并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache,方便下次快速访问
  • 与目标表所在的 Region Server 进行通讯
  • 将写请求命令顺序写入(追加)到内存的 WAL,此时 wal 没有同步到 HDFS
  • 将数据写入对应的 MemStore,数据会在 MemStore 进行排序
  • 同步 wal 到 HDFS,若失败则回滚清空 MemStore 写入的数据
  • 向客户端发送 ack,此时的写请求已经完成
  • 等达到 MemStore 的刷写时机后,将数据刷写到 HFile

三、MemStore Flush

在这里插入图片描述

  • MemStore Flush:刷写,将 Region 中存储在内存中的数据刷写到 HDFS 的磁盘中
  • Flush 时机:
    • RegionServer 级别:
      • 当 RegionServer 中 memstore 的总大小达到 javaHeapSize × hbase.regionserver.global.memstore.size(默认 0.4) × hbase.regionserver.global.memstore.size.lower.limit(默认 0.95) 时,所有 region 会按照其所有 memstore 的大小顺序 (由大到小) 依次进行刷写。直到 RegionServer 中所有 memstore 的总大小减小到上述值以下;当 RegionServer 中 memstore 的总大小达到javaHeapsize × hbase.regionserver.global.memstore.size 时,会停止继续往所有的 memstore 写数据操作
      • 当 memstore 中最后一条数据的写入时间达到hbase.regionserver.optionalcacheflushinterval(默认 1h) 的值时,触发 memstore flush
      • 当 WAL 文件的数量超过 hbase.regionserver.max.logs,region 会按照时间顺序依次进行刷写,直到 WAL 文件数量减小到 hbase.regionserver.max.log 以下 (该属性名已经废弃,现无需手动设置,最大值为 32),该参数用于防止生产上内存配置过大导致刷写时数据积累过大
    • Region 级别:
      • 当某个 region 的 memstore 的大小达到了 hbase.hregion.memstore.flush.size(默认 128M) 时,这个 region 的所有 memstore 都会刷写
      • 当某个 region 的 memstore 的大小达到了 hbase.hregion.memstore.flush.size(默认 128M) × hbase.hregion.memstore.block.multiplier(默认 4)时,会停止继续往该 memstore 写数据

四、读流程原理

在这里插入图片描述

  • Client 先访问 Zookeeper,获取 hbase:meta 表位于哪个 Region Server
  • 访问对应的 Region Server,获取 hbase:meta 表,根据读请求的 namespace:table/rowkey 信息查询出目标数据位于哪个 Region Server 中的哪个 Region 中,并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache,方便下次访问
  • 与目标 Region Server 进行通讯
  • 分别在 BlockCache (读缓存),MemStore 和 StoreFile (HFile) 中查询目标数据,并将查到的所有数据进行合并 (merge)。此处所有数据是指同一条数据的不同版本 (timestamp) 或者不同的类型 (Put/Delete)
  • 将从 StoreFile 中查询到的数据块 (Block,HFile 数据存储单元,默认大小为 64KB) 缓存到 BlockCache
  • 将合并后 timestamp 最大的数据返回给客户端

五、StoreFile Compaction

在这里插入图片描述

  • 背景:由于 memstore 每次刷写都会生成一个新的 HFile,且同一个字段的不同版本 (timestamp) 和不同类型 (Put/Delete) 有可能会分布在不同的 HFile 中,因此查询时需要遍历所有的 HFile
  • 为了减少 HFile 的个数,以及清理掉过期和删除的数据,HBase 会进行 StoreFile Compaction
  • StoreFile Compaction 分为两种:
    • Minor Compaction:会将临近的若干个较小的 HFile 合并成一个较大的 HFile,但不会清理过期和删除的数据,shell 命令为 compact
    • Major Compaction:会将一个 Store 下的所有的 HFile 合并成一个大 HFile,并且会清理掉过期和删除的数据,shell 命令为 major_compact
  • Major Compaction 触发条件:
    • HFile 存储时长达到 hbase.hregion.majorcompaction(默认 7 天) 的值时自动进行 Major Compaction,但生产上一般会关闭 (设置为 0)
    • 当一个 store 中的 hfile 个数达到或超过 hbase.hstore.compactionThreshold(默认 3) 的值时自动进行 Major Compaction,或手动执行 compact 命令时也进行 Major Compaction

六、数据真正删除

  • 触发数据删除的条件:MemStore Flush 和 Major Compaction
  • 当同一个字段的不同版本数据都在内存中, MemStore Flush 会删除版本小的数据,只将最大版本的数据刷写到磁盘;当同一个字段的不同类型数据都在内存中, MemStore Flush 只会删除 put 类型的数据 (delete 类型可能还要限制磁盘中的同字段数据);当同一个字段的不同版本数据在不同的文件,此时 MemStore Flush 不会删除数据
  • Major Compaction 会删除需要保留的版本数之外的所有过时版本和 delete 类型的数据

七、Region Split

在这里插入图片描述

  • 默认情况下,每个 Table 起初只有一个 Region,随着数据的不断写入增加,Region 会触发自动进行拆分。刚拆分时,两个子 Region 都位于当前的 Region Server,但处于负载均衡的考虑,HMaster 有可能会将某个 Region 转移给其他的 Region Server
  • Region Split 触发时机:
    • 0.94 版本之前:当 1 个 region 中的某个 Store 下所有 StoreFile 的总大小超过 hbase.hregion.max.filesize(默认 10G),该 Region 就会进行拆分
    • 0.94 版本之后:当 1 个 region 中的某个 Store 下所有 StoreFile 的总大小超过 min(R^2 × hbase.hregion.memstore.flush.size, hbase.hregion.max.filesize), 该 Region 就会进行拆分,其中 R 为当前 Region Server 中属于该 Table 的 region 个数
  • 自动切分会造成数据倾斜,产生数据热点问题,在生产上一般不使用,而是在建表时先进行预分区,后续插入数据时轮询的插入到不同的分区
  • 官方建议使用一个列族,避免切分全局 flush 时产生大量小文件

这篇关于详解 HBase 的架构和基本原理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1069940

相关文章

Linux换行符的使用方法详解

《Linux换行符的使用方法详解》本文介绍了Linux中常用的换行符LF及其在文件中的表示,展示了如何使用sed命令替换换行符,并列举了与换行符处理相关的Linux命令,通过代码讲解的非常详细,需要的... 目录简介检测文件中的换行符使用 cat -A 查看换行符使用 od -c 检查字符换行符格式转换将

详解C#如何提取PDF文档中的图片

《详解C#如何提取PDF文档中的图片》提取图片可以将这些图像资源进行单独保存,方便后续在不同的项目中使用,下面我们就来看看如何使用C#通过代码从PDF文档中提取图片吧... 当 PDF 文件中包含有价值的图片,如艺术画作、设计素材、报告图表等,提取图片可以将这些图像资源进行单独保存,方便后续在不同的项目中使

Android中Dialog的使用详解

《Android中Dialog的使用详解》Dialog(对话框)是Android中常用的UI组件,用于临时显示重要信息或获取用户输入,本文给大家介绍Android中Dialog的使用,感兴趣的朋友一起... 目录android中Dialog的使用详解1. 基本Dialog类型1.1 AlertDialog(

C#数据结构之字符串(string)详解

《C#数据结构之字符串(string)详解》:本文主要介绍C#数据结构之字符串(string),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录转义字符序列字符串的创建字符串的声明null字符串与空字符串重复单字符字符串的构造字符串的属性和常用方法属性常用方法总结摘

Java中StopWatch的使用示例详解

《Java中StopWatch的使用示例详解》stopWatch是org.springframework.util包下的一个工具类,使用它可直观的输出代码执行耗时,以及执行时间百分比,这篇文章主要介绍... 目录stopWatch 是org.springframework.util 包下的一个工具类,使用它

Java进行文件格式校验的方案详解

《Java进行文件格式校验的方案详解》这篇文章主要为大家详细介绍了Java中进行文件格式校验的相关方案,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、背景异常现象原因排查用户的无心之过二、解决方案Magandroidic Number判断主流检测库对比Tika的使用区分zip

Java实现时间与字符串互相转换详解

《Java实现时间与字符串互相转换详解》这篇文章主要为大家详细介绍了Java中实现时间与字符串互相转换的相关方法,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、日期格式化为字符串(一)使用预定义格式(二)自定义格式二、字符串解析为日期(一)解析ISO格式字符串(二)解析自定义

springboot security快速使用示例详解

《springbootsecurity快速使用示例详解》:本文主要介绍springbootsecurity快速使用示例,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录创www.chinasem.cn建spring boot项目生成脚手架配置依赖接口示例代码项目结构启用s

Python中随机休眠技术原理与应用详解

《Python中随机休眠技术原理与应用详解》在编程中,让程序暂停执行特定时间是常见需求,当需要引入不确定性时,随机休眠就成为关键技巧,下面我们就来看看Python中随机休眠技术的具体实现与应用吧... 目录引言一、实现原理与基础方法1.1 核心函数解析1.2 基础实现模板1.3 整数版实现二、典型应用场景2

一文详解SpringBoot响应压缩功能的配置与优化

《一文详解SpringBoot响应压缩功能的配置与优化》SpringBoot的响应压缩功能基于智能协商机制,需同时满足很多条件,本文主要为大家详细介绍了SpringBoot响应压缩功能的配置与优化,需... 目录一、核心工作机制1.1 自动协商触发条件1.2 压缩处理流程二、配置方案详解2.1 基础YAML