hbase region, store, storefile和列簇,的关系

先来一张大图。

Hbase上Regionserver的内存分为两个部分,一部分作为Memstore,主要用来写;另外一部分作为BlockCache,主要用于读数据;这里主要介绍写数据的部分,即Memstore。当RegionServer(RS)收到写请求的时候(writerequest),RS会将请求转至相应的Region。每一个Region都存储着一些列(a set of rows)。根据其列族的不同,将这些列数据存储在相应的列族中(Column Family,简写CF)。不同的CF中的数据存储在各自的HStore中,HStore由一个Memstore及一系列HFile组成。Memstore位于RS的主内存中,而HFiles被写入到HDFS中。当RS处理写请求的时候,数据首先写入到Memstore,然后当到达一定的阀值的时候,Memstore中的数据会被刷到HFile中。

用到Memstore最主要的原因是:存储在HDFS上的数据需要按照row key 排序。而HDFS本身被设计为顺序读写(sequential reads/writes),不允许修改。这样的话,HBase就不能够高效的写数据,因为要写入到HBase的数据不会被排序,这也就意味着没有为将来的检索优化。为了解决这个问题,HBase将最近接收到的数据缓存在内存中(in Memstore),在持久化到HDFS之前完成排序,然后再快速的顺序写入HDFS。(这里参考:http://www.cnblogs.com/shitouer/archive/2013/02/05/configuring-hbase-memstore-what-you-should-know.html)

这里就留下个问题,MemStore何时刷写成HFile?

个人总结如下:

1.Region级别的触发刷写。

(1)hbase.hregion.memstore.flush.size

单个region内所有的memstore大小总和超过指定值时,flush该region的所有memstore。这里为什么是所有memsotre?因为一张表可能有多个CF,其对应的一个Region自然包含多个CF(即HStore),每个Store都有自己的memstore,这个配置值是所有的store的memstore的总和。当这个总和达到配置值时,即针对每个HSotre,都触发其Memstore,刷写成storefile(HFile的封装)文件。

(2)hbase.hstore.blockingStoreFiles 默认值:7

说明:在flush时,当一个region中的Store(Coulmn Family)内有超过7个storefile时,则block所有的写请求进行compaction,以减少storefile数量。

调优:block写请求会严重影响当前regionServer的响应时间,但过多的storefile也会影响读性能。从实际应用来看,为了获取较平滑的响应时间,可将值设为无限大。如果能容忍响应时间出现较大的波峰波谷,那么默认或根据自身场景调整即可。这个值设置比较大,会增加客户端的负载处理能力(即影响读取性能),但是如果你的服务器一直处于一个高的水平,那说明你的机器已经达到性能瓶颈,需要其他方式解决。

(3)hbase.hregion.memstore.block.multiplier默认值:2

说明:当一个region里总的memstore占用内存大小超过hbase.hregion.memstore.flush.size两倍的大小时,block该region的所有请求,进行flush,释放内存。虽然我们设置了region所占用的memstores总内存大小,比如64M,但想象一下,在最后63.9M的时候,我Put了一个200M的数据,此时memstore的大小会瞬间暴涨到超过预期的hbase.hregion.memstore.flush.size的几倍。这个参数的作用是当memstore的大小增至超过hbase.hregion.memstore.flush.size2倍时,block所有请求,遏制风险进一步扩大。

调优:这个参数的默认值还是比较靠谱的。如果你预估你的正常应用场景(不包括异常)不会出现突发写或写的量可控,那么保持默认值即可。如果正常情况下,你的写请求量就会经常暴长到正常的几倍,那么你应该调大这个倍数并调整其他参数值,比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperLimit/lowerLimit,以预留更多内存,防止HBase server OOM。

2.RegionServer全局性的触发刷写。

(1)hbase.regionserver.global.memstore.upperLimit

当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时,HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。

(2)hbase.regionserver.global.memstore.lowerLimit

同upperLimit,只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时,不flush所有的memstore。它会找一个memstore内存占用最大的region,做个别flush,此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中,表现为“** Flush thread woke up with memory above low water.”。

调优:这是一个Heap内存保护参数,默认值已经能适用大多数场景。

3. HLog (WAL)引起的regionserver全局性的触发刷写。

当数据被写入时会默认先写入Write-ahead Log(WAL)。WAL中包含了所有已经写入Memstore但还未Flush到HFile的更改(edits)。在Memstore中数据还没有持久化,当RegionSever宕掉的时候,可以使用WAL恢复数据。

若是关闭WAL,则在hbase-site.xml新增hbase.regionserver.hlog.enabled配置,设为false即可,不建议关闭。

当WAL(在HBase中成为HLog)变得很大的时候,在恢复的时候就需要很长的时间。因此,对WAL的大小也有一些限制,当达到这些限制的时候,就会触发Memstore的flush。Memstore flush会使WAL减少,因为数据持久化之后(写入到HFile),就没有必要在WAL中再保存这些修改。有两个属性可以配置:

(1)hbase.regionserver.hlog.blocksize

(2)hbase.regionserver.maxlogs

WAL的最大值由hbase.regionserver.maxlogs*hbase.regionserver.hlog.blocksize (2GB by default)决定。一旦达到这个值,Memstore flush就会被触发。所以,当你增加Memstore的大小以及调整其他的Memstore的设置项时,你也需要去调整HLog的配置项。否则,WAL的大小限制可能会首先被触发,因而,你将利用不到其他专门为Memstore而设计的优化。抛开这些不说,通过WAL限制来触发Memstore的flush并非最佳方式,这样做可能会会一次flush很多Region,尽管“写数据”是很好的分布于整个集群,进而很有可能会引发flush“大风暴”。

提示:最好将hbase.regionserver.hlog.blocksize* hbase.regionserver.maxlogs设置为稍微大于hbase.regionserver.global.memstore.lowerLimit* HBASE_HEAPSIZE.

(这里参考:http://www.cnblogs.com/shitouer/archive/2013/02/05/configuring-hbase-memstore-what-you-should-know.html)

原文地址:https://www.cnblogs.com/wzj4858/p/9051582.html

时间: 2024-10-11 05:55:14

hbase region, store, storefile和列簇,的关系的相关文章

HBase 通过myeclipce脚本来获取固定columns(获取列簇中的列及对应的value值)

第一步:关联Jar包 1. 配置hadoop-env.sh文件添加Hbase关联jar包 /opt/modules/hadoop-2.5.0-cdh5.3.6/etc/hadoop下编辑hadoop-env.sh文件添加下列变量 export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/opt/modules/hbase-0.98.6-cdh5.3.6/lib/* 2. 配置临时或者永久环境变量 /opt/modules/hbase-0.98.6-cdh5.3.6/c

使用MapReduce查询Hbase表指定列簇的全部数据输入到HDFS(一)

package com.bank.service; import java.io.IOException; import org.apache.hadoop.conf.Configuration;import org.apache.hadoop.conf.Configured;import org.apache.hadoop.fs.Path;import org.apache.hadoop.hbase.HBaseConfiguration;import org.apache.hadoop.hba

为什么不建议在 HBase 中使用过多的列族

我们知道,一张 HBase 表包含一个或多个列族.HBase 的官方文档中关于 HBase 表的列族的个数有两处描述: A typical schema has between 1 and 3 column families per table. HBase tables should not be designed to mimic RDBMS tables. 以及 HBase currently does not do well with anything above two or thre

HBase基础知识,面向列的实时分布式数据库

Hbase是运行在Hadoop上的NoSQL数据库,它是一个分布式的和可扩展的大数据仓库,也就是说HBase能够利用HDFS的分布式处理模式,并从Hadoop的MapReduce程序模型中获益. 1.HBase定义 HBase是一个分布式的.面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”.就像Bigtable利用了Google文件系统(File System)所提供的分布式数据存储一样,HBase在Hadoop之

Hbase Region Server整体架构

Region Server的整体架构 本文主要介绍Region的整体架构,后续再慢慢介绍region的各部分具体实现和源码 RegionServer逻辑架构图 RegionServer职责 1.      监听协作,通过zk来侦听master.meta位置.集群状态等信息的变化,更新本地数据. 2.      管理region的offline.online.open.close等操作,这些操作是和hmaster配合这来做的,region的状态有如下这些 offline.opening.open.

HBase Region的flush过程

触发region flush的因素有很多,如手动触发,memstore压力触发,memstore到达限制触发,flush时间触发等. regionserver的flush由 flush实际操作步骤为 1.获得region写锁,将region的所有store执行prepare,产生snapshort,释放region写锁 2.将region的所有store执行flushcache,将数据写入hdfs中的一个或多个临时文件中 3.将临时文件移到region/store相应的目录下,删除memstor

关于hbase的read操作的深入研究 region到storefile过程

这里面说的read既包括get,也包括scan,实际底层来看这两个操作也是一样的.我们将要讨论的是,当我们从一张表读取数据的时候hbase到底是怎么处理的.分二种情况来看,第一种就是表刚创建,所有put的数据还在memstore中,并没有刷新到hdfs上:第二种情况是,该store已经进行多次的flush操作,产生了多个storefile了.在具体说明两种情况前,先考虑下表的region的问题,如果表只有一个region,那么没有说的,肯定是要扫描这个唯一的region.假设该表有多个regio

hbase 各个概念,region,storefile

HBase中有两张特殊的Table,-ROOT-和.META. .META.:记录了用户表的Region信息,它可以有多高region(这的意思是说.META.表可以分 裂成多个region,和用户表一样) -ROOT-:记录了.META.表的Region信息,-ROOT-只有一个region(也就是说它不可分割) Zookeeper中记录了-Root-表的location region大小: 更大的Region可以使你集群上的Region的总数量较少. 一般来言,更少的Region可以使你的集

HBASE REGION SPLIT策略

hbase 0.94.0版本中,对于region的split方式引入了一个非常方便的SplitPolicy,通过这个SplitPolicy,可以主动的干预控制region split的方式.在org.apache.Hadoop.hbase.regionserver包中,可以找到这么几个自带的splitPolicy: ConstantSizeRegionSplitPolicy, IncreasingToUpperBoundRegionSplitPolicy, and KeyPrefixRegion