- 合并一个表中的所有`HFiles`
- 会彻底删除标记为删除的数据
- 通常是手动触发
+ compact后的数据【实际存储】在HDFS上,小的`HFile`应该远小于128M
+ 分布式架构
- HBase表:抽象概念,物理存储上被细分为多个Region。
- Region:数据存储和访问的基本单元。
- RegionServer:运行在集群中的服务器,负责管理和服务其上存储的一个或多个Region。
- HBase采用的是典型的Master/Slave架构。HBase Master负责管理表和Region的元数据信息,以及RegionServer的负载均衡。而RegionServers负责处理客户端的读写请求,并管理存储在其上的Regions。
+ 可用性
- ZooKeeper实现了Client和HMaster之间的协调管理
- HLog(WAL:Write Ahead Log 当数据写入具体的磁盘之前,先将其写一份在日志文件上)
* HLog能够将死去的RegionServer"复活",获取其原来的表数据。
* 当HRegionServer死的时候,则将HLog的数据迁移到另一台服务器上。
* 而数据迁移又依靠HMaster,因此HMaster也需要容灾机制,则出现了HMaster Backup和ZooKeeper进行协调管理。
* 如果ZooKeeper和HMaster之间心跳"断"了,则启用HMaster Backup.
- 事务性
-
NoSQL 更加注重 性能、扩展性、灵活性,不像RDBMS一样强调原子性或一致性。
-
一致性问题
- 发生场景:通常发生在实时数仓。
- 批处理:规定记录数达到一定值才发送,可能导致时效性差(前后两条记录的时间间隔长)。
- 流处理:采用每隔一段时间(水位线)就进行数据发送的策略。面临的挑战是如何确保在时间范围内的数据都被纳入处理。
- 解决方案:允许一定的延迟(例如,计算3秒内的数据,但结果会在5秒内出来),这是为了等待那些符合时间范围但尚未被处理的数据。
- 流批一体:流处理和批处理结合的处理模式(Flink)
- 侧输出流:
- 为了保证最终一致性,对因延迟未能纳入批次的数据放入侧输出流中。
- 例如:如果在一个设定的时间窗口(如秒级窗口)内,某些数据未能被处理,这些数据就可以被放入侧输出流中。随后,可以在一个更长的时间窗口(如分钟窗口)内对这些数据进行处理。
- 实时数仓 VS 离线数仓
- 数据准确性:离线数仓高于实时数仓
- 时间范围:
- 实时数仓的时间范围:秒、分、时、天
- 离线数仓的时间范围:天、周、月、年
- 数据校准:
- 可以使用离线数仓的数据去校准实施数仓中同维度的数据(如天),以检测实时数仓的实时性。
- 这种校准通常使用大量模拟数据进行。
-
三、NoSQL、BI、大数据的关系
- BI:商务智能
- 它是一套完整的解决方案
- BI应用设计模型,模型依赖于模式
- BI主要支持标准SQL(RDB)
- 难在业务掌握和熟悉的能力
- NoSQL和大数据相关性较高,但是NoSQL!=大数据
- NoSQL主要帮助大数据解决数据存储问题
四、HBase概述
-
定义
- 是一个面向列存储的NoSQL数据库
- 是一个分布式HashMap,底层数据是Key-Value格式
- 使用HDFS作为存储并利用其可靠性什么是【分布式HashMap】?
HashMap的本质是用一个简单的值形式映射一个复杂的值形式。
HBase通过一个RowKey提取该RowKey下多个列族下多个列的多个值。
-
特点
- 数据访问速度快,响应时间约2~20ms。
- 实时数仓和离线数仓都会用到HBase:
- 实时数仓
- 响应速度快
- 离线数仓
- 宽表列存储
- 实时数仓
- 支持随机读写,每个节点20k~100k+ ops/s
- 哈希表也可以随机读写
- 可扩展性
- 对Hadoop,1个NameNode只能带1024(实际1009)台DataNode
- 但是HBase可以扩展到20000+节点
- 高并发
-
HBase的物理架构
这张图描述了HBase的物理架构,主要包括以下几个部分:
- Client: 客户端,用于与Zookeeper和HMaster进行交互。
- Zookeeper: 用于维护HBase集群的状态和元数据信息。(协调 管理)
- HMaster: HBase集群的主控制节点,负责监控集群状态和管理区域服务器(RegionServer)。
- HRegionServer: 区域服务器,负责存储和管理HBase数据。每个RegionServer管理着多个HRegion。
- HRegion: 表的水平分区,一个Region包含一个或多个MemStore和多个StoreFile。
- MemStore: 内存存储区,用于缓存新写入的数据。
- StoreFile: 持久化存储文件,用于存储从MemStore刷新的数据。
- HFile: StoreFile中的底层物理文件,实际存储数据。
- DFS Client: 与底层HDFS集群交互的客户端。
- HDFS: 底层的分布式文件系统,用于持久化存储HBase数据。
箭头表示各组件之间的交互和数据流向:
- Client与Zookeeper和HMaster交互,用于读写数据。
- HMaster管理和监控RegionServer。
- RegionServer管理MemStore和StoreFile,用于读写数据。
- MemStore中的数据定期刷新到StoreFile。
- StoreFile的数据持久化存储在HDFS上
各组件的作用
-
HMaster
- 是HBase集群的主节点,可以配置多个,用来实现HA
- 一般backup-masters并不配置主机器(master01)
- 处理元数据的变更
- HBase元数据:
- 命名空间名字、表名字、列族的名字、列族内部的schema…
- HBase元数据:
- 监控RegionServer
- 负责RegionServer的负载均衡(分裂时告知将新增数据迁移到哪台RegionServer)
- 处理RegionServer故障转移
- 通过ZooKeeper发布自己的位置到客户端
- 是HBase集群的主节点,可以配置多个,用来实现HA
-
RegionServer
-
负责管理维护Region,负责存储HBase实际数据
- 一个RegionServer包含一个Hlog,一个BlockCache,多个Region(可以是一张表,也可以是不同的表)
- HFile和HLog作为序列化文件保存在HDFS上
- Client直接与RegionServer进行交互
-
功能
- 负责管理HBase的实际数据
- 处理分配给它的Region
- 刷新缓存到HDFS
- 维护HLog
- 执行Compaction
- 负责处理Region分片
-
读写缓存
- 读缓存:BlockCache
- 将最近或频繁访问的数据块(blocks)缓存到内存中,HBase可以快速响应读请求。
- 写缓存:MemStore
- 暂存写入数据,直至达到一定的阈值,然后批量写入磁盘,形成新的StoreFile(HFile)
- 读缓存:BlockCache
-
-
Bloom Filter
- 快速确定数据是否不在StoreFile中,如果不在,读操作即刻终止。
- 工作原理:
- 初始化:创建一个m位的位数组(bit array),初始时将所有位都设为0
- 添加元素:当一个元素(如URL1、URL2、URL3)被加入集合时,通过k个哈希函数生成k个位置索引,并将这些位设置为1。
- 查询元素:要检查一个元素是否存在于集合中,再次通过相同的k个哈希函数生成k个位置索引。
如果所有这些位置的位都是1,那么该元素可能在集合中(存在误判可能)。如果任何一个位置的位时0,则该元素绝对不在集合中。
- 为什么要使用多个哈希函数?
- 降低误判率,避免哈希冲突。
- 快速确定数据是否不在StoreFile中,如果不在,读操作即刻终止。
-
Region和Table
- 单个Table被分区成大小大致相同的Region
- 一个Region只能分配给一个RegionServer
-
HBase逻辑架构
-
Row
- Rowkey(行键)是唯一的并已排序
- Schema可以定义何时插入数据、要保留多少历史版本、分区策略如何、列族叫什么名字
- 每个Row都可以定义自己的列,即使其他Row不使用
- 相关列定义为列族
- 使用唯一时间戳维护多个Row版本
- 在不同版本中值类型可以不同(但不建议)
- HBase数据全部以字节存储
-
RowKey的设计
- 越短越好,不超过16个字节
- 在前缀加随机数使数据均匀地分布到不同的RegionServer。
- 保证RowKey的唯一
-
热点问题
- HBase中的行是按照RowKey的字典顺序排序的,但可能会导致大量的client直接访问集群的一个或极少数个节点
- 大量的访问会使热点Region所在的单个机器超出自身承受能力,引起性能下降甚至Region不可用。
-
常见的设计RowKey的手段("_"的意义是让其分布均匀又不破坏实际意义)
- 加盐
给RowKey加上随机前缀
“456165181_henry@hotmail.com” - 哈希
给RowKey加上哈希前缀
“hashcode(“henry”)_henry@hotmail.com”
- 加盐
-
-
HBase的读流程
- 读取:如果Bloom Filter检查通过,或者没有Bloom Filter参与,HBase会从相应的StoreFile读取数据。
- 合并:从不同的StoreFile和MemStore中读取的数据需要被合并,以获得最终的结果,因为一个键的多个版本可能分布在不同的文件和MemStore中。
- Scanner Cache:合并后的数据可以被Scanner Cache暂存,以便快速响应相同的后续读请求。
- 客户端:最后,合并后的数据被发送到客户端。
-
HBase元数据管理
- 数据管理目录
- 系统目录表 hbase:meta(命名空间和表、字段和列族之间都是用":"分开的)
- 存储元数据
- ZooKeeper存储hbase:meta表的位置信息
- 系统目录表 hbase:meta(命名空间和表、字段和列族之间都是用":"分开的)
- HBase实际数据存储在HDFS上
- 数据管理目录
-
HBase Shell
详见HBase Shell汇总
五、HBase应用场景
-
增量数据——时间序列数据
- 高容量、高速写入
- HBase之上有OpenTSDB模块,可以满足时序类场景,比如传感器,系统监控,股票行情监控等。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!