HBase数据存储

HRegionServer


HBase的数据文件都存储在HDFS上,格式主要有两种:
- HFile:HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制文件,实际上StoreFile就是对HFile做了轻量级的包装,即StoreFile底层就是HFile
- HLog File:HBase中WAL(Write Ahead Log)的存储格式,物理上是Hadoop的Sequence File带项目符号的内容


- HRegionServer管理一些列HRegion对象
- 每个HRegion对应Table中一个Region,Hegion由多个HStore组成
- 每个HStore对应Table中一个Column Family存储
- Column Family就是一个集中的存储单元,故将具有相同IO的Column放在一个Column Family会更高效

HStore(MemStore和StoreFile)


- Client写入:存入MemStore,一直到MemStore满了->Flush成一个StoreFile,直至增长到一定阈值->发出Compact合并操作->多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除->当StoreFiles compact后,逐步形成越来越大的StoreFile->单个StoreFile大小超过一定阈值之后,触发Split操作,会把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到响应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上。
- HBase只是增加数据,所有的更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入内存即可立即返回,从而保证IO高性能


- StoreFile以HFile格式保存在HDFS上
- Data Block段保存表中的数据,这部分可以被压缩
- Meta Block段(可选)保存用户自定义的KV对,可以被压缩
- File Info段–HFile的元信息,不压缩,用户可以在这一部分添加自己的元信息
- Data Block Index段 -Data Block的索引。每条索引的Key是被索引的block的第一条记录的Key
- Meta Block Index段(可选)-Meta Block的索引
- Trailer -这一段是定长的,保存的是每一段的偏移量

压缩
- HFile的Data Block.Meta Block通常采用压缩方式存储;
好处:压缩之后可以大大减少网络IO和磁盘IO
坏处:需要花费cup进行压缩和解压缩
-HFlie支持的压缩格式:Gzip,Lzo,Snappy…

KeyValue存储结构



- HFile里面的每个KeyValue对就是一个简单的byte数组
- KeyLength和ValueLength:两个固定的长度,分别代表Key和Value的长度
- Key部分:Row Length是固定长度的数值,表示RowKey的长度,Row就是RowKey
- Column Family Length是固定长度的数值,表示Family的长度,接着就是Column Family,再接着是Qualifier,然后是两个固定长度的数值,表示TimeStamp和Key Type(Put/Delete)
- Value部分没有那么复杂的结构,就是纯粹的二进制数据

HLog文件结构



时间: 2024-09-20 18:54:29

HBase数据存储的相关文章

云时代的大数据存储-云HBase

为什么 纵观数据库发展的几十年,从网状数据库.层次数据库到RDBMS数据库,在最近几年的NewSQL的兴起,加上开源的运动,再加上云的特性,可以说是日新月异.在20世纪80年代后,大部分的业务确定使用RDBMS数据为存储基础.新世纪开始,随着互联网的发展,数据量的增大,慢慢RDBMS数据库撑不住,就出现了读写分离策略.随着压力增加,Master撑不住,这时就要分库,把关联不大的数据分开部署,一些join查询不能用,需要借助中间层.随着数据量的进一步增加,一个表的记录越来越大,查询就变得很慢,于是

基于HBase的大数据存储的应用场景分析

引言 HBase是一个高可靠性.高性能.面向列.可伸缩的分布式存储系统,适用于结构化的存储,底层依赖于Hadoop的HDFS,利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群.因此HBase被广泛使用在大数据存储的解决方案中. 为何使用HBase HBase的优点: 列可以动态增加,并且列为空就不存储数据,节省存储空间. Hbase自动切分数据,使得数据存储自动具有水平scalability. Hbase可以提供高并发读写操作的支持. HBase的缺点: 不能支持条件查询,

吞噬大数据存储领域新机制——NoSQL模式解析

在过去几年,一种新兴的大型数据存储机制正吞噬大数据存储市场.这种存储解决方案与传统的RDBMS有显著的区别,它们被称之为NoSQL. 在NoSQL世界中有以下关键的成员,包括 ●Google BigTable.HBase.Hypertable ●Amazon Dynamo.Voldemort.Cassendra.Riak ●Redis ●CouchDB.MongoDB 而这些解决方案又有一些共同的特点 ●基于键-值存储 ●系统运行在海量的普通机器上 ●数据在经过分区和复制后分布在集群中 ●放宽对

胖子哥的大数据之路(二)- 大数据结构化数据存储应用模式

一.楔子 胖子哥是我网名,叫了很多年的网名,网名的来历与自己的沧桑和身材有关,不知是IT改变了我,显得苍老,还是我本就苍老,顺应了IT行业的需要.25岁那年,曾被跟我一样高的漂亮美眉叫叔叔,从此再也不敢打小姑娘的注意,走上了重口味热爱阿姨级别女性的不归路:曾被三十五.六岁的同事阿姨说苍老:看你也就三十五六吧,那年我25:周一的时候,还有一个60后的同事问及我的年龄,他很含蓄的,明显带着保留的口吻问我:你是75年的吧?因为他一直认为和我一般大.然后...然后泪奔.关于体型方面也是个悲剧.三围相等,

如何将本地开发的系统迁移到云端,数据存储问题 求大神

问题描述 如果我在本地开发了一个系统,想把它迁移到云端,请问如何将关系数据库(例如:mysql)中的格式化数据用Hbase.Bigtable这样的非关系型数据库存储?求大神 解决方案 解决方案二:内容追加:非关系型数据库可以存储关系型数据库中的格式化数据么?解决方案三:有个工具sqoop,可以把mysql的数据导入到hbase中但是,hbase只是一个nosql数据库,不支持sql语句.事务等特性,所以用它来取代mysql,你还得掂量掂量解决方案四:mysql导入到hbase很容易,但要让你的系

从Facebook看大数据存储怎么选

最近有位朋友向我咨询技术问题,他们的客户提出一个大数据系统的服务器硬件需求,其中元数据有xxTB左右.并给出了以下初步建议: 节点类型1(元数据节点) Xeon E5 14核CPU x2 256GB DDR4内存 600GB SAS 15K硬盘x5 RAID卡 节点类型2(数据节点) Xeon E5 14核CPU x2 128GB DDR4内存 4TB 7.2K近线硬盘x4 RAID卡 软件并非我擅长的方面,不过大数据概念炒了好几年,从各方面还是多少了解到一些Hadoop/HDFS硬件架构方面的

实时大数据存储及查询分析解决方案

问题描述 实时大数据存储及查询分析解决方案 上千辆设备每隔10秒上传一次数据,我要把数据存储起来,然后在基于这些数据进行查询分析, 担心传统的做法后期会有很大的性能问题,请教有做过这方面的经验的高手共享一下思路. 解决方案 你这种情况就非常适合使用基于Hadoop的HBase来存储数据,HBase不仅仅适合于做大数据的存储和处理,它的一个突出的性能优势就是写数据, 你的系统每隔10s就要写一次数据,Hbase就比较适合,最好不要使用传统的关系型数据库(例如MySql),这会让你的系统在后期出现许

HBase伪分布式安装(HDFS)+ZooKeeper安装+HBase数据操作+HBase架构体系

HBase1.2.2伪分布式安装(HDFS)+ZooKeeper-3.4.8安装配置+HBase表和数据操作+HBase的架构体系+单例安装,记录了在Ubuntu下对HBase1.2.2的实践操作,HBase的安装到数据库表的操作.包含内容1.HBase单例安装2.HBase伪分布式安装(基于Hadoop的HDFS)过程,3.HBase的shell编程,对HBase表的创建,删除等的命令,HBase对数据的增删查等操作.4.简单概述了Hbase的架构体系.5.zookeeper的单例安装和常用操

5大开源数据存储解决方案推荐

文章讲的是5大开源数据存储解决方案推荐,用于存储大数据的解决方案是当今面临的巨大技术挑战.当然,有很多不同的选择,如RDBMS,NoSQL,时间序列数据库等,本文分析了五个数据存储解决方案,这些方案是为不同目的而创建的,但所有方案都可用于保存基于时间的日志. 数据存储仅将事件保存到数据库是不够的,每个数据存储库都必须有一个接口以实时搜索,并具有良好的性能,每天至少能够存储40GB的数据,总数据大小至少约为20TB,搜索日志消息应该实时完成,搜索查询的响应时间小于10秒. 1.ClickHouse