Hbase基础
Hbase数据的读取流程:
1.Client访问zookeeper,获取元数据存储所在的regionServer
2.通过刚刚获取的地址访问对应的regionServer,拿到对应的表存储的regionServer
3.去表所在的regionServer进行数据的读取
4.查找对应的region,在region中寻找列簇,先找到memstore,找不到去blockcache中寻找,再找不到就进行storefile的遍历
5.找到数据之后会先缓存到blockcache中,再讲结果返回
Hbase数据的写入流程:
1.Client访问zookeeper,获取元数据存储所在的regionServer
2.通过刚刚获取的地址访问对应的regionServer,拿到对应的表存储的regionServer
3.去表所在的regionServer进行数据的添加
4.查找对应的region,在region中寻找列簇,先向memstore中写入数据
5.当memstore写入的值变多时,触发溢写操作(flush),进行文件的溢写,成为一个storefile
6.当溢写的文件过多时,会触发文件的合并(compact)操作
Hbase的组件包括Client,Zookeeper,HMaster,HRegionServer,HRegion,Store,MemStore,StoreFile,HFile,HLog等
Client
HBase有两张特殊表:
.META:记录了用户所有表拆分出来的Region映射信息, .META.可以有多个Region
-ROOT-:记录了.META.表的region信息,-ROOT-只有一个region,无论如何不会分裂
Client访问用户数据前需要先访问ZoopKeeper,找到-ROOT-表的Region所在的位置,然后访问-ROOT-表,接着访问.META.表,最后才能找到用户数据的位置去访问
ZooKeeper
1.为Hbase提供Failover机制,选举Master,避免单点Master单点故障问题
2.存储所有Region的寻址入口:-ROOT-表在哪台服务器上,-ROOT这张表的位置信息
3.实时监控RegionServer的状态,将RegionServer的上线和下线信息实时通知给Master
4.存储Hbase的Schema,包括有哪些Table,每个表有哪些column Family
Master
1.为RegionServer分配Region
2.负责RegionServer的负载均衡
3.发现失效的regionServer并重新分配其上的region
regionServer
1.维护Master分配给他的Region,处理这些region的io请求
2.负责spilt在运行过程中变得过大的region,负责compact操作
HRegion
table在运行的方向上分隔为多个Region,region是hbase中分布式存储和负载均衡的最小单元,即不同的region可以分别在不同的regionServer上,但同一个region是不会拆分到多个server上的
Region按大小分隔,每个表一般是只有一个region,随着数据的不断插入表,region不断增大,当region的某个列簇达到一个阈值时就会拆分成两个新的region
Store
每一个region由一个或多个store组成,至少是一个store,hbase会把一起访问的数据放在一个store里面,即每个columnFamily建一个store,如果有几个columnFamily,也就有几个Store,一个Store由一个memStore和0个或者多个storefile组成,hbase以stre的大小来判断是否需要切分region
Memstore
放在内存里的,保存修改的数据即keyValues,当memStore的大小达到一个阈值(默认128M)时,memStore会被flush到文件,即生成一个快照
storefile
memStore内存中的数据写到文件后就是StoreFile,StoreFile底层是以Hfile的格式保存,当storeFile文件的数据增长到一定阈值后,系统会进行合并,在合并的过程中会进行版本合并和删除工作,形成更大的storeFile
HFile
是hbase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即storefile的底层就是hfile
HLog
HLog(WAL log):WAL write ahead log,用来做灾难恢复使用,HLog记录数据的所有变更,一旦regionServer 宕机,就可以从log中恢复
Hbase和hive的区别?
hive和hbase是两种基于hadoop的不同技术,hive是一种类sql的引擎,并且运行mapreduce任务,hbase是一种在hadoop之上的nosql的 key/value 数据库
Hbase 的rowKey的设计原则?
长度原则
Rowkey是一个二进制码流,建议越短越好,不要超过16字节
原因如下:
1.数据的持久化文件HFile中是按照KeyValue存储的,如果Rowkey过长比如100个字节,1000万列数据光Rowkey就要占用100*1000万=10亿个字节,将近1G数据,这会极大的影响HFile的存储效率
2.memStore将缓存部分数据到内存,如果Rowkey字段过长,会导致内存的有效利用率降低,系统无法存储更多的数据,这会降低检索效率
散列原则
如果没有散列字段,首字段是时间信息将产生所有新数据都在RegionServer上堆积的热点现象,这样在做数据检索的时候负责将会集中在个别的regionServer,降低查询效率
比如:region中的rowkey是有序存储,如时间比较集中,就会存储到一个region中,这样一个region的数据变多,其他region的数据很少,加载数据就会很慢,直到region分裂,问题才能得到缓解
唯一原则
必须在设计上保证其唯一性
如何解决Hbase中region太小和region太大带来的冲突?
region过大会发生多次compact,将数据读一遍并重写一遍到hdfs上,占用IO,region过小会造成多个spilt,region会下线,影响访问服务,最佳的解决方法是调整hbase.master.max.filesize为256m
hbase中数据一开始会写入到memstore,满128m(默认配置)以后,会flush到disk上成为storefile,当storefile数量超过触发因子(配置),会启动compaction过程,将他们合并成为一个storefile,对集群性能有一定影响,而当合并后的storefile大于max.filesize,会触发分隔动作将他们切成两个region.
当hbase.hregion.max.filesize比较小时,触发spilt的几率更大,系统的整体访问服务会出现不稳定现象.
当hbase.hregion.max.filesize比较大时,由于长期得不到spilt,因此同一个region内发生多次compact的机会增加,这样会降低系统的性能,稳定性,因此平均吞吐量会受到一些影响而下降
