HBase（九）HBase表以及Rowkey的设计

一 命名空间

1 命名空间的结构

1) Table&＃xff1a;表&＃xff0c;所有的表都是命名空间的成员&＃xff0c;即表必属于某个命名空间&＃xff0c;如果没有指定&＃xff0c; 则在 default 默认的命名空间中。

2) RegionServer group&＃xff1a;一个命名空间包含了默认的 RegionServer Group。

3) Permission&＃xff1a;权限&＃xff0c;命名空间能够让我们来定义访问控制列表 ACL&＃xff08;Access Control List&＃xff09;。例如&＃xff0c;创建表&＃xff0c;读取表&＃xff0c;删除&＃xff0c;更新等等操作。

4) Quota&＃xff1a;限额&＃xff0c;可以强制一个命名空间可包含的 region 的数量。&＃xff08;属性&＃xff1a;hbase.quota.enabled&＃xff09;

2 命名空间的使用 

1) 创建命名空间

hbase(main):002:0> create_namespace &＃39;ns_school&＃39;

2) 创建表时指定命名空间 

hbase(main):004:0> create &＃39;ns_school:tbl_student&＃39;,&＃39;info&＃39;

3) 观察 HDFS 中的目录结构的变化 

二. 建表高级属性

　　下面几个 shell 命令在 hbase 操作中可以起到很大的作用&＃xff0c;且主要体现在建表的过程中&＃xff0c;看 下面几个 create 属性

1. BLOOMFILTER

　　默认是 NONE 是否使用布隆过虑及使用何种方式&＃xff0c;布隆过滤可以每列族单独启用 使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 对列族单独启用布隆

　　Default &＃61; ROW 对行进行布隆过滤

　　对 ROW&＃xff0c;行键的哈希在每次插入行时将被添加到布隆

　　对 ROWCOL&＃xff0c;行键 &＃43; 列族 &＃43; 列族修饰的哈希将在每次插入行时添加到布隆

　　使用方法: create &＃39;table&＃39;,{BLOOMFILTER &＃61;>&＃39;ROW&＃39;}

　　作用&＃xff1a;用布隆过滤可以节省读磁盘过程&＃xff0c;可以有助于降低读取延迟

2. VERSIONS

　　默认是 1 这个参数的意思是数据保留 1 个 版本&＃xff0c;如果我们认为我们的数据没有这么大 的必要保留这么多&＃xff0c;随时都在更新&＃xff0c;而老版本的数据对我们毫无价值&＃xff0c;那将此参数设为 1 能 节约 2/3 的空间

　　使用方法: create &＃39;table&＃39;,{VERSIONS&＃61;>&＃39;2&＃39;}

　　附&＃xff1a;MIN_VERSIONS &＃61;> &＃39;0&＃39;是说在 compact 操作执行之后&＃xff0c;至少要保留的版本

3. COMPRESSION

　　默认值是 NONE 即不使用压缩&＃xff0c;这个参数意思是该列族是否采用压缩&＃xff0c;采用什么压缩算 法&＃xff0c;方法: create &＃39;table&＃39;,{NAME&＃61;>&＃39;info&＃39;,COMPRESSION&＃61;>&＃39;SNAPPY&＃39;} &＃xff0c;建议采用 SNAPPY 压缩算 法 &＃xff0c;HBase 中&＃xff0c;在 Snappy 发布之前&＃xff08;Google 2011 年对外发布 Snappy&＃xff09;&＃xff0c;采用的 LZO 算法&＃xff0c;目标是达到尽可能快的压缩和解压速度&＃xff0c;同时减少对 CPU 的消耗&＃xff1b;

　　在 Snappy 发布之后&＃xff0c;建议采用 Snappy 算法&＃xff08;参考《HBase: The Definitive Guide》&＃xff09;&＃xff0c;具体 可以根据实际情况对 LZO 和 Snappy 做过更详细的对比测试后再做选择。

　　如果建表之初没有压缩&＃xff0c;后来想要加入压缩算法&＃xff0c;可以通过 alter 修改 schema

4. TTL

　　默认是 2147483647 即&＃xff1a;Integer.MAX_VALUE 值大概是 68 年&＃xff0c;这个参数是说明该列族数据的存活时间&＃xff0c;单位是 s

　　这个参数可以根据具体的需求对数据设定存活时间&＃xff0c;超过存过时间的数据将在表中不在 显示&＃xff0c;待下次 major compact 的时候再彻底删除数据

　　注意的是 TTL 设定之后 MIN_VERSIONS&＃61;>&＃39;0&＃39; 这样设置之后&＃xff0c;TTL 时间戳过期后&＃xff0c;将全部 彻底删除该 family 下所有的数据&＃xff0c;如果 MIN_VERSIONS 不等于 0 那将保留最新的 MIN_VERSIONS 个版本的数据&＃xff0c;其它的全部删除&＃xff0c;比如 MIN_VERSIONS&＃61;>&＃39;1&＃39; 届时将保留一个 最新版本的数据&＃xff0c;其它版本的数据将不再保存。

5. alter

使用方法&＃xff1a;

　　如 修改压缩算法

disable &＃39;table&＃39;
alter &＃39;table&＃39;,{NAME&＃61;>&＃39;info&＃39;,COMPRESSION&＃61;>&＃39;snappy&＃39;}
enable &＃39;table&＃39;

但是需要执行 major_compact &＃39;table&＃39; 命令之后 才会做实际的操作。 

6. describe/desc

　　这个命令查看了 create table 的各项参数或者是默认值。

　　使用方式&＃xff1a;describe &＃39;user_info&＃39;

7. disable_all/enable_all

　　disable_all &＃39;toplist.*&＃39; disable_all 支持正则表达式&＃xff0c;并列出当前匹配的表的如下&＃xff1a;

toplist_a_total_1001toplist_a_total_1002toplist_a_total_1008toplist_a_total_1009toplist_a_total_1019toplist_a_total_1035...Disable the above 25 tables (y/n)? 并给出确认提示

8. drop_all

　　这个命令和 disable_all 的使用方式是一样的

9. hbase 预分区

　　默认情况下&＃xff0c;在创建 HBase 表的时候会自动创建一个 region 分区&＃xff0c;当导入数据的时候&＃xff0c; 所有的 HBase 客户端都向这一个 region 写数据&＃xff0c;直到这个 region 足够大了才进行切分。一 种可以加快批量写入速度的方法是通过预先创建一些空的 regions&＃xff0c;这样当数据写入 HBase 时&＃xff0c;会按照 region 分区情况&＃xff0c;在集群内做数据的负载均衡。

命令方式&＃xff1a;

# create table with specific split points
hbase>create &＃39;table1&＃39;,&＃39;f1&＃39;,SPLITS &＃61;> [&＃39;\x10\x00&＃39;, &＃39;\x20\x00&＃39;, &＃39;\x30\x00&＃39;, &＃39;\x40\x00&＃39;]
# create table with four regions based on random bytes keys
hbase>create &＃39;table2&＃39;,&＃39;f1&＃39;, { NUMREGIONS &＃61;> 8 , SPLITALGO &＃61;> &＃39;UniformSplit&＃39; }
# create table with five regions based on hex keys
hbase>create &＃39;table3&＃39;,&＃39;f1&＃39;, { NUMREGIONS &＃61;> 10, SPLITALGO &＃61;> &＃39;HexStringSplit&＃39; }

也可以使用 api 的方式: 

hbase org.apache.hadoop.hbase.util.RegionSplitter test_table HexStringSplit -c 10 -f infohbase org.apache.hadoop.hbase.util.RegionSplitter splitTable HexStringSplit -c 10 -f info

参数&＃xff1a;

　　test_table 是表名

　　HexStringSplit 是split 方式

　　-c 是分 10 个 region

　　-f 是 family

可在 UI 上查看结果&＃xff0c;如图&＃xff1a;

　　这样就可以将表预先分为 15 个区&＃xff0c;减少数据达到 storefile 大小的时候自动分区的时间 消耗&＃xff0c;并且还有以一个优势&＃xff0c;就是合理设计 rowkey 能让各个 region 的并发请求平均分配(趋 于均匀) 使 IO 效率达到最高&＃xff0c;但是预分区需要将 filesize 设置一个较大的值&＃xff0c;设置哪个参数 呢 hbase.hregion.max.filesize 这个值默认是 10G 也就是说单个 region 默认大小是 10G

　　这个参数的默认值在 0.90 到 0.92 到 0.94.3 各版本的变化&＃xff1a;256M--1G--10G

　　但是如果 MapReduce Input 类型为 TableInputFormat 使用 hbase 作为输入的时候&＃xff0c;就要注意 了&＃xff0c;每个 region 一个 map&＃xff0c;如果数据小于 10G 那只会启用一个 map 造成很大的资源浪费&＃xff0c; 这时候可以考虑适当调小该参数的值&＃xff0c;或者采用预分配 region 的方式&＃xff0c;并将检测如果达到 这个值&＃xff0c;再手动分配 region。

三. 表设计

1. 列簇设计

　　追求的原则是&＃xff1a;目前Hbase官方建议不超过2~3个column family。因为某个column family在flush的时候&＃xff0c;它邻近的column family也会因关联效应被触发flush&＃xff0c;最终导致系统产生更多的I/O。

　　最优设计是&＃xff1a;将所有相关性很强的 key-value 都放在同一个列簇下&＃xff0c;这样既能做到查询效率 最高&＃xff0c;也能保持尽可能少的访问不同的磁盘文件。

　　以用户信息为例&＃xff0c;可以将必须的基本信息存放在一个列族&＃xff0c;而一些附加的额外信息可以放在 另一列族。

2. 预分区

每一个region 维护着startRow 与endRowKey&＃xff0c;如果加入的数据符合某个region 维护的rowKey范围&＃xff0c;则该数据交给这个 region 维护。那么依照这个原则&＃xff0c;我们可以将数据索要投放的分区提前大致的规划好&＃xff0c;以提高 HBase 性能。

1) 手动设定预分区

hbase> create &＃39;staff&＃39;,&＃39;info&＃39;,&＃39;partition1&＃39;,SPLITS &＃61;> [&＃39;1000&＃39;,&＃39;2000&＃39;,&＃39;3000&＃39;,&＃39;4000&＃39;]

2) 生成 16 进制序列预分区 

create &＃39;staff2&＃39;,&＃39;info&＃39;,&＃39;partition2&＃39;,{NUMREGIONS &＃61;> 15, SPLITALGO &＃61;> &＃39;HexStringSplit&＃39;}

3) 按照文件中设置的规则预分区

创建 splits.txt 文件内容如下&＃xff1a;

aaaa
bbbb
cccc
dddd

然后执行&＃xff1a; 

create &＃39;staff3&＃39;,&＃39;partition3&＃39;,SPLITS_FILE &＃61;> &＃39;splits.txt&＃39;

4) 使用 JavaAPI 创建预分区 

//自定义算法&＃xff0c;产生一系列 Hash 散列值存储在二维数组中
byte[][] splitKeys &＃61; 某个散列值函数
//创建 HBaseAdmin 实例
HBaseAdmin hAdmin &＃61; new HBaseAdmin(HBaseConfiguration.create());
//创建 HTableDescriptor 实例
HTableDescriptor tableDesc &＃61; new HTableDescriptor(tableName);
//通过 HTableDescriptor 实例和散列值二维数组创建带有预分区的 HBase 表
hAdmin.createTable(tableDesc, splitKeys);

3. RowKey 设计

　　HBase 中&＃xff0c;表会被划分为 1...n 个 Region&＃xff0c;被托管在 RegionServer 中。Region 二个重要属性&＃xff1a;StartKey 与 EndKey 表示这个 Region 维护的 rowKey 范围&＃xff0c;当我们要读/写数据时&＃xff0c;如果 rowKey 落在某个 start-end key 范围内&＃xff0c;那么就会定位到目标 region 并且读/写到相关的数据&＃xff0c;那怎么快速精准的定位到我们想要操作的数据&＃xff0c;就在于我们的 rowkey 的设计了。

四. Rowkey 设计三原则

        一条数据的唯一标识就是 rowkey&＃xff0c;那么这条数据存储于哪个分区&＃xff0c;取决于 rowkey 处于哪个一个预分区的区间内&＃xff0c;设计 rowkey 的主要目的 &＃xff0c;就是让数据均匀的分布于所有的 region 中&＃xff0c;在一定程度上防止数据倾斜。接下来我们就谈一谈 rowkey 常用的设计方案。

1. rowkey 长度原则

　　Rowkey 是一个二进制码流&＃xff0c;Rowkey 的长度被很多开发者建议说设计在 10~100 个字节&＃xff0c;不过建议是越短越好&＃xff0c;不要超过 16 个字节&＃xff0c;存为byte[]字节数组&＃xff0c;一般设计成定长的。

　　原因如下&＃xff1a;

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

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

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

2. rowkey 散列原则

　　如果 Rowkey 是按时间戳的方式递增&＃xff0c;不要将时间放在二进制码的前面&＃xff0c;建议将 Rowkey 的高位作为散列字段&＃xff0c;由程序循环生成&＃xff0c;低位放时间字段&＃xff0c;这样将提高数据均衡分布在每个 Regionserver 实现负载均衡的几率。如果没有散列字段&＃xff0c;首字段直接是时间信息将产生所有 新数据都在一个 RegionServer 上堆积的热点现象&＃xff0c;这样在做数据检索的时候负载将会集中 在个别 RegionServer&＃xff0c;降低查询效率。

      row key是按照字典序存储&＃xff0c;因此&＃xff0c;设计row key时&＃xff0c;要充分利用这个排序特点&＃xff0c;将经常一起读取的数据存储到一块&＃xff0c;将最近可能会被访问的数据放在一块。

举个例子&＃xff1a;如果最近写入HBase表中的数据是最可能被访问的&＃xff0c;可以考虑将时间戳作为row key的一部分&＃xff0c;由于是字典序排序&＃xff0c;所以可以使用Long.MAX_VALUE - timestamp作为row key&＃xff0c;这样能保证新写入的数据在读取时可以被快速命中。

3. rowkey 唯一原则

　　必须在设计上保证其唯一性。rowkey 是按照字典顺序排序存储的&＃xff0c;因此&＃xff0c;设计 rowkey 的时候&＃xff0c;要充分利用这个排序的特点&＃xff0c;将经常读取的数据存储到一块&＃xff0c;将最近可能会被访问 的数据放到一块。

五. 数据热点

　　HBase 中的行是按照 rowkey 的字典顺序排序的&＃xff0c;这种设计优化了 scan 操作&＃xff0c;可以将相 关的行以及会被一起读取的行存取在临近位置&＃xff0c;便于 scan。然而糟糕的 rowkey 设计是热点 的源头。 热点发生在大量的 client 直接访问集群的一个或极少数个节点&＃xff08;访问可能是读&＃xff0c; 写或者其他操作&＃xff09;。大量访问会使热点 region 所在的单个机器超出自身承受能力&＃xff0c;引起性能 下降甚至 region 不可用&＃xff0c;这也会影响同一个 RegionServer 上的其他 region&＃xff0c;由于主机无法服 务其他 region 的请求。 设计良好的数据访问模式以使集群被充分&＃xff0c;均衡的利用。 为了避免写热点&＃xff0c;设计 rowkey 使得不同行在同一个 region&＃xff0c;但是在更多数据情况下&＃xff0c;数据 应该被写入集群的多个 region&＃xff0c;而不是一个。

防止数据热点的有效措施

　　加盐

　　这里所说的加盐不是密码学中的加盐&＃xff0c;而是在 rowkey 的前面增加随机数&＃xff0c;具体就是给 rowkey 分配一个随机前缀以使得它和之前的 rowkey 的开头不同。分配的前缀种类数量应该 和你想使用数据分散到不同的 region 的数量一致。加盐之后的 rowkey 就会根据随机生成的 前缀分散到各个 region 上&＃xff0c;以避免热点。

例&＃xff1a;生成随机数、hash、散列值

比如&＃xff1a;
原本 rowKey 为 1001 的&＃xff0c;SHA1 后变成&＃xff1a;dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本 rowKey 为 3001 的&＃xff0c;SHA1 后变成&＃xff1a;49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本 rowKey 为 5001 的&＃xff0c;SHA1 后变成&＃xff1a;7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前&＃xff0c;一般我们会选择从数据集中抽取样本&＃xff0c;来决定什么样的 rowKey 来 Hash
后作为每个分区的临界值。

哈希

　　哈希会使同一行永远用一个前缀加盐。哈希也可以使负载分散到整个集群&＃xff0c;但是读却是 可以预测的。使用确定的哈希可以让客户端重构完整的 rowkey&＃xff0c;可以使用 get 操作准确获取 某一个行数据

　　反转

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

　　反转 rowkey 的例子以手机号为 rowkey&＃xff0c;可以将手机号反转后的字符串作为 rowkey&＃xff0c;这 样的就避免了以手机号那样比较固定开头导致热点问题

例&＃xff1a; 字符串反转

20170524000001 转成 10000042507102
20170524000002 转成 20000042507102

这样也可以在一定程度上散列逐步 put 进来的数据。

例&＃xff1a; 字符串拼接

20170524000001_a12e
20170524000001_93i7

时间戳反转

　　一个常见的数据处理问题是快速获取数据的最近版本&＃xff0c;使用反转的时间戳作为 rowkey 的一部分对这个问题十分有用&＃xff0c;可以用 Long.Max_Value - timestamp 追加到 key 的末尾&＃xff0c;例 如 [key][reverse_timestamp] , [key] 的最新值可以通过 scan [key]获得[key]的第一条记录&＃xff0c;因 为 HBase 中 rowkey 是有序的&＃xff0c;第一条记录是最后录入的数据。比如需要保存一个用户的操 作记录&＃xff0c;按照操作时间倒序排序&＃xff0c;在设计 rowkey 的时候&＃xff0c;可以这样设计 [userId 反转][Long.Max_Value - timestamp]&＃xff0c;在查询用户的所有操作记录数据的时候&＃xff0c;直接指 定 反 转 后 的 userId &＃xff0c; startRow 是 [userId 反 转 ][000000000000],stopRow 是 [userId 反 转][Long.Max_Value - timestamp]

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