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.

Table中Family和Qualifier的关系与区别

就像用MySQL一样，我们要做的是表设计，MySQL中的表，行，列的在HBase已经有所区别了，在HBase中主要是Table和Family和Qualifier，这三个概念。Table可以直接理解为表，而Family和Qualifier其实都可以理解为列，一个Family下面可以有多个Qualifier，所以可以简单的理解为，HBase中的列是二级列，也就是说Family是第一级列，Qualifier是第二级列。两个是父子关系。

测试发现：

在实际应用场景中，对于单column qualifier和多column qualifier两种情况，

如果value长度越长，row key长度越短，字段数（column qualifier数）越少，前者和后者在实际传输数据量上会相差小些；反之则相差较大。

如果采用多column qualifier的方式存储，且客户端采取批量写入的方式，则可以根据实际情况，适当增大客户端的write buffer大小，以便能够提高客户端的写入吞吐量。

从性能的角度谈table中family和qualifier的设置
　　对于传统关系型数据库中的一张table，在业务转换到hbase上建模时，从性能的角度应该如何设置family和qualifier呢？
　　最极端的，①每一列都设置成一个family，②一个表仅有一个family，所有列都是其中的一个qualifier，那么有什么区别呢？

　　从读的方面考虑：
　　family越多，那么获取每一个cell数据的优势越明显，因为io和网络都减少了。
　　如果只有一个family，那么每一次读都会读取当前rowkey的所有数据，网络和io上会有一些损失。
　　当然如果要获取的是固定的几列数据，那么把这几列写到一个family中比分别设置family要更好，因为只需一次请求就能拿回所有数据。

　　从写的角度考虑：
　　首先，内存方面来说，对于一个Region，会为每一个表的每一个Family分配一个Store，而每一个Store，都会分配一个MemStore，所以更多的family会消耗更多的内存。
　　其次，从flush和compaction方面说，目前版本的hbase，在flush和compaction都是以region为单位的，也就是说当一个family达到flush条件时，该region的所有family所属的memstore都会flush一次，即使memstore中只有很少的数据也会触发flush而生成小文件。这样就增加了compaction发生的机率，而compaction也是以region为单位的，这样就很容易发生compaction风暴从而降低系统的整体吞吐量。
　　第三，从split方面考虑，由于hfile是以family为单位的，因此对于多个family来说，数据被分散到了更多的hfile中，减小了split发生的机率。这是把双刃剑。更少的split会导致该region的体积比较大，由于balance是以region的数目而不是大小为单位来进行的，因此可能会导致balance失效。而从好的方面来说，更少的split会让系统提供更加稳定的在线服务。而坏处我们可以通过在请求的低谷时间进行人工的split和balance来避免掉。
因此对于写比较多的系统，如果是离线应该，我们尽量只用一个family好了，但如果是在线应用，那还是应该根据应用的情况合理地分配family。

Rowkey 设计

Rowkey散列原则
Rowkey唯一原则
Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。

原因如下：

（1）数据的持久化文件HFile中是按照KeyValue存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000万=10亿个字节，将近1G数据，这会极大影响HFile的存储效率；

（2）MemStore将缓存部分数据到内存，如果Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好。

（3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

热点

hbase 中的行是以 rowkey 的字典序排序的，这种设计优化了scan 操作，可以将相关的行以及会被一起读取的行存取在临近位置，便于 scan 。然而，糟糕的 rowkey 设计是热点的源头。热点发生在大量的客户端直接访问集群的一个或极少数节点。访问可以是读，写，或者其他操作。大量访问会使热点region 所在的单个机器超出自身承受能力，引起性能下降甚至是 region 不可用。这也会影响同一个 regionserver 的其他 regions，由于主机无法服务其他region 的请求。设计良好的数据访问模式以使集群被充分，均衡的利用。

为了避免写热点，设计 rowkey 使得不同行在同一个 region,但是在更多数据情况下，数据应该被写入集群的多个region，而不是一个。下面是一些常见的避免热点的方法以及它们的优缺点：

加盐

这里的加盐不是密码学中的加盐，而是在rowkey 的前面增加随机数。具体就是给 rowkey 分配一个随机前缀以使得它和之前排序不同。分配的前缀种类数量应该和你想使数据分散到不同的 region 的数量一致。如果你有一些热点 rowkey 反复出现在其他分布均匀的 rwokey 中，加盐是很有用的。考虑下面的例子：它将写请求分散到多个 RegionServers，但是对读造成了一些负面影响。

假如你有下列 rowkey，你表中每一个 region 对应字母表中每一个字母。以 'a' 开头是同一个region, 'b'开头的是同一个region。在表中，所有以 'f'开头的都在同一个 region，它们的 rowkey 像下面这样：

foo0001
foo0002
foo0003
foo0004

现在，假如你需要将上面这个 region 分散到 4个 region。你可以用4个不同的盐：'a', 'b', 'c', 'd'.在这个方案下，每一个字母前缀都会在不同的 region 中。加盐之后，你有了下面的 rowkey:

a-foo0003
b-foo0001
c-foo0004
d-foo0002

所以，你可以向4个不同的 region 写，理论上说，如果所有人都向同一个region 写的话，你将拥有之前4倍的吞吐量。

现在，如果再增加一行，它将随机分配a,b,c,d中的一个作为前缀，并以一个现有行作为尾部结束：

a-foo0003
b-foo0001
c-foo0003
c-foo0004
d-foo0002

因为分配是随机的，所以如果你想要以字典序取回数据，你需要做更多工作。加盐这种方式增加了写时的吞吐量，但是当读时有了额外代价。

哈希

除了加盐，你也可以使用哈希，哈希会使同一行永远用同一个前缀加盐。哈希也可以使负载分散到整个集群，但是读却是可以预测的。使用确定的哈希可以让客户端重构完成的 rowkey，使用Get 操作获取正常的获取某一行数据。

哈希例子

像在加盐方法中给出的那个例子，你可以使用某种哈希方法使得 foo0003 这样的 rowkey 的前缀永远是 ‘a',然后，为了取得某一行，你可以通过哈希获得相应的 rowkey. 你也可以优化哈希方法，使得某些rowkey 永远在同一个 region.

翻转key

第三种防止热点的方法是翻转固定长度或者数字格式的rowkey。这样可以使得rowkey中经常改变的部分（最没意义的部分）放在前面。这样可以有效的随机 rowkey,但是牺牲了 rowkey 的有序性。

单调递增 rwokey(时间连续序列)

在《Hadoop 权威指南》中，有一个优化的注意点：当所有客户端一段时间内一致写入某一个region,然后再接着写入下一个 region。例如：像单调递增的 rowkey（时间戳），就会发生这种现象。可以查看 Kai Lan的漫画 monotonically increasing values are bad. 说明了为什么单调递增的rowkey 在分布式表格系统（Hbase）中是有问题的。这种单调递增的rowkey 堆积在同一个region 的问题可以通过随机化输入记录来缓和。但通常来讲我们应该避免使用时间戳或者序列（1，2，3）来作为主键。

如果你的确需要在Hbase存储时间序列数据，可以学习 OpenTSDB，它是个成功的例子。链接schema有一页描述了OpenTSDB在hbase中使用的模式。OpenTSDB中的key模式是：[元数据类型][时间戳]，初看起来这似乎违反了不使用时间戳作为rowkey的原则，然而，区别是时间戳并没有在rowkey的关键位置，而且这个设计假设拥有许多元数据类型。因此，即使有连续的混合着元数据的输入数据，它们也会Put进入表中不同的regions.

尽量减少行和列的大小

在Hbase中，value永远是和它的key一起传输的。当具体的值在系统间传输时，它的rowkey,列名，时间戳也会一起传输。如果你的rowkey和列名很大，甚至可以和具体的值相比较，那么你将会遇到一些有趣的情况。HBase storefiles中的索引（有助于随机访问）最终占据了HBase 分配的大量内存，因为具体的值和他的key很大。可以增加 block 大小使得 storefiles 索引在更大的时间间隔增加，或者修改表的模式以减小rowkey 和列名的大小。压缩也有助于更大的索引。

大多时候较小的低效率是无关紧要的，但是在这种情况下，任何访问模式都需要列族名，列名，rowkey，所以它们会被访问数十亿次在你的数据中。

列族

尽可能使列族名越短越好，最好是一个字符。（例如：'d' 代表data/default）。

属性

冗长的属性名（"myVeryImportantAttribute"）是易读的,但是更短的属性名("via")存储在HBase中更好。

Rowkey 长度

让 Rowkey 越短越好是合理的，这对必需的数据访问（get,scan）是有益的。但是当短 key 对数据访问是无用时它不及长 key 拥有更好的get/scan属性。当设计 rowkey 时，我们需要权衡，折中。

翻转时间戳

一个常见的数据处理问题是快速获取数据的最近版本，使用反转的时间戳作为rowkey的一部分对这个问题十分有用，可以用Long.Max_Value - timestamp追加到key的末尾，例如[key][reverse_timestamp],[key]的最新值可以通过scan [key]获得[key]的第一条记录，因为HBase中rowkey是有序的，第一条记录是最后录入的数据。

比如需要保存一个用户的操作记录，按照操作时间倒序排序，在设计rowkey的时候，可以这样设计
[userId反转][Long.Max_Value - timestamp]，在查询用户的所有操作记录数据的时候，直接指定反转后的userId，startRow是[userId反转][000000000000],stopRow是[userId反转][Long.Max_Value - timestamp]

如果需要查询某段时间的操作记录，startRow是[user反转][Long.Max_Value - 起始时间]，stopRow是[userId反转][Long.Max_Value - 结束时间]

Hbase中Rowkey设计对入库效率的影响

建表预分区原则
Hbase Region在大小达到一定阈值后（目前是10G），就会Splite(分裂)两个Region，而当一个Region的Hfile个数达到一定的阈值（目前为4个），就会对这些Hfile进行Compact(合并)。Splite和Compact都会比较消耗IO，所以要尽量减少Region分裂和合并的次数。这就需要对数据的大小进行评估，建表时预先分区。如果不预分区，默认就只有一个分区，在导入数据时就只会起一个Reduce任务处理，而且Region达到阈值大小后会不断分裂，非常影响入库效率。所以需要合理估算分区数，过小会导致Region不断分裂，过大又会增加MasterServer管理的压力。计算分区数原则如下：
N = TotalSize/hbase.hregion.max.filesize(目前是10G)
例如目前http接口信令数据一天的大小约为6.5T，那么分区数为：6.5*1024/10=665.6，因为建表时一般会指定压缩方式，入库后的数据会变小，故分区数设置为600就足够了。DNS接口每天大小约2T，分区数为：2*1024/10=204.8，分区数设置为了200就可以了。
建议Hbase按以下方式来建表：

create 'ns_boco:test ', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 600, SPLITALGO => 'HexStringSplit'}

该建表语句指定了表ns_boco:test Region split策略为按固定大小分裂(ConstantSizeRegionSplitPolicy),压缩方式采用SNAPPY，表预分600（需按业务实际情况估算）个Region，列族为info

下面测试Rowkey在有散列字段和无散列字段对HDFS文件入库Hbase效率的影响。

1、使用bulkload方式把HDFS的文件导入Hbase，大小均为340.7G。建表均采用预分40个Region。

create 'ns_boco:import_test1', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 40, SPLITALGO => 'HexStringSplit'}
create 'ns_boco:import_test2', {METADATA => {'SPLIT_POLICY' => 'org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy'}},{NAME => 'info', COMPRESSION => 'SNAPPY' },{NUMREGIONS => 40, SPLITALGO => 'HexStringSplit'}

2、 import_test2 Rowkey设计为MD5(MSISDN)取前4位+MSISDN+时间，高位使用MD5得到散列字段。如41c11877721065620170801142654645。

入库时间：09:23:35–08:51:53≈31分钟。

可以发现入库后各Region的数据量分布比较均衡，每个Region约分配到了7.5G的数据。

3、 import_test1 RowkeyRowkey设计为MSISDN（8-11位）+MSISDN+时间，高位直接取手机号码8-11位，没做散列处理，如06561877721065620170801142654645。

入库时间：10:20:12-09:25:54≈54分钟。
入库后各Region的数据量分布不均衡，40个Region中有19个（大小为63字节的目录）没有分配到数据，有些Region分配到的数据又比较大，大于20G。

由此可见，Rowkey设计时对高位进行散列处理，不仅能提高读写效率，还能让数据均衡的分布到各个Regions上，实现负载均衡

HbaseRowkey设计以及列族和列的关系相关推荐

在Hbase使用过滤器（行键过滤器、列族与列过滤器、值过滤器）
本文介绍Hbase中的过滤器: 1.行键过滤器 2.列族与列过滤器 3.值过滤器 4.其他过滤器格式如下: scan'表名',{FILTER=>过滤器(比较运算符,'比较器')"} ...
java获取列族的列_在cassandra-cli中如何获取表中的所有列名以及如何在java中使用hector获取它？...
我正在尝试获取列名,但无法获得仅列名称. 在cli我执行命令描述表节点,它返回结果: CREATE TABLE nodes ( key text PRIMARY KEY, id text, score ...
HBase系列--列族设计及影响
1.列族是什么? HBASE表中的每个列,都归属于某个列族.列族是表的schema的一部分(而列不是),必须在使用表之前定义.列名都以列族作为前缀.例如 courses:history,course ...
hbase数据库介绍，HBASE的特点，表结构逻辑视图，Row Key,列族，时间戳，Cell
HBASE数据库 1. Hbase基础 1.1 hbase数据库介绍 1.简介nosql hbase是bigtable的开源java版本.是建立在hdfs之上,提供高可靠性.高性能.列存储.可伸缩.实 ...
hbase 使用lzo_带你快速上手HBase | HBase列族优化
随着大数据的越来越普及,HBase也变得越来越流行.使用HBase并不困难,但是如何用好HBase,这确是一个难点.为了合理地使用HBase,尽可能发挥HBase的功能,我们需要根据不同的场景对HBa ...
NoSQL：列族数据库
列族数据库可以存储关键字及其映射值,并且可以把值分成多个列族,让每个列族代表一张数据映射表(map of data). 下表是关系型数据库Oracle和列族数据库Cassandra的术语对比: Ora ...
HBase 列族数据库
数据模型我们可以将一个表想象成一个大的映射关系,通过行健.行健+时间戳或行键+列(列族:列修饰符),就可以定位特定数据,HBase是稀疏存储数据的,因此某些列可以是空白的, Row Key Tim ...
Hbase按指定列族中指定列的列值查找数据Hbase命令
最近在做大数据的实验时,遇到需要类似于sql中 select XXX from where xxxxx=xxx的一个检索的需求,翻了好多博客都没有解决,最后通过查看hbase filte的文档,使用S ...
HBase - 列族定义 | 那伊抹微笑
博文作者: 妳那伊抹微笑 csdn 博客地址: http://blog.csdn.net/u012185296 itdog8 地址链接 : http://www.itdog8.com/thread-1 ...

HbaseRowkey设计以及列族和列的关系

Rowkey 设计

热点

单调递增 rwokey(时间连续序列)

尽量减少行和列的大小

Hbase中Rowkey设计对入库效率的影响

HbaseRowkey设计以及列族和列的关系相关推荐

最新文章

热门文章