@Arslan6and6 2016-08-29T02:39:11.000000Z 字数 4370 阅读 685

【作业二十六】殷杰

HBase 高级使用

---HBase 表设计及管理

作业描述：
1） HBase Shell 创建表的方式，指定属性和多个列簇
2）依据【话单数据】查询需求如何设计表和ROWKEY、索引表的设计
3） HBase 表中压缩的配置及测试
4） HBase Compaction深入理解及RegionServer内存的使用、CacheBlock机制
5） HBase 常见管理集群和表的工具（数据迁移案例的分析整理）

1） HBase Shell 创建表的方式，指定属性和多个列簇

创建表时有三种方式预分区，HBase的表的数据是存在Region里面的，Region有[startkey,endkey)，并且是包头不包尾的，每个Region都有一个范围。默认情况下，创建一个HBase表，会自动只为表分配1个Region。
方式1：利用HBase建表命令
hbase(main):039:0> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
1
region Start Key End Key
region1 10
region2 10 20
region3 20 30
region4 30 40
region5 40

方式2：利用文件存放Rowkey及使用建表命令
[beifeng@hadoop-senior ~]$ cat region.txt
20160601
20160602
20160603
20160604
20160605
create 't2', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'

方式3：设置15个region,用HexStringSplit这个来生成Region，HDFS根据16进制来生成的,HexStringSplit表示16进制的一个字符串
hbase(main):042:0> create 't3', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

HBase表属性
't1',
{
NAME => 'cf',
DATA_BLOCK_ENCODING => 'NONE',
BLOOMFILTER => 'ROW',
REPLICATION_SCOPE => '0',
VERSIONS => '1',
COMPRESSION => 'NONE',
MIN_VERSIONS => '0',
TTL => 'FOREVER',
KEEP_DELETED_CELLS => 'false',
BLOCKSIZE => '65536',
IN_MEMORY => 'false',
BLOCKCACHE => 'true'
}
* VERSIONS 数值的版本默认值1
* COMPRESSION 是否压缩默认值NONE 常用snappy压缩数据压缩方式
* TTL 数据有效时间默认永久有效

2）依据【话单数据】查询需求如何设计表和 ROWKEY、索引表的设计

在表的Rowkey设计中要把握的核心思想:
依据Rowkey查询最快
在实际的应用当中，就是对Rowkey进行范围查询range，
Rowkey通常都是多个字段组成的。
Rowkey是前缀匹配的
满足需求场景，查询速度要快
尽量覆盖更多的业务场景，增加复用的可能性
离线设计，避免热点(数据倾斜
设计Rowkey
号码+开始时间——结束时间 telphone(电话号码)+teltime(通话时间)

3） HBase 表中压缩的配置及测试

# pwd
/opt/cloudera/parcels/CDH/bin
hadoop checknative
16/07/05 20:38:35 INFO bzip2.Bzip2Factory: Successfully loaded & initialized native-bzip2 library system-native
16/07/05 20:38:35 INFO zlib.ZlibFactory: Successfully loaded & initialized native-zlib library
Native library checking:
hadoop:  true /opt/cloudera/parcels/CDH-5.3.6-1.cdh5.3.6.p0.11/lib/hadoop/lib/native/libhadoop.so.1.0.0
zlib:    true /lib64/libz.so.1
snappy:  true /opt/cloudera/parcels/CDH-5.3.6-1.cdh5.3.6.p0.11/lib/hadoop/lib/native/libsnappy.so.1
lz4:     true revision:99
bzip2:   true /lib64/libbz2.so.1
openssl: true /usr/lib64/libcrypto.so
hbase(main):006:0> disable 'test01'
0 row(s) in 1.3300 seconds
hbase(main):007:0> alter 'test01',NAME => 'info',COMPRESSION => 'snappy'
Updating all regions with the new schema...
1/1 regions updated.
Done.
0 row(s) in 1.2430 seconds
hbase(main):008:0> desc 'test01'
DESCRIPTION                                                          ENABLED                             
 'test01', {NAME => 'info', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILT false                               
 ER => 'ROW', REPLICATION_SCOPE => '0', VERSIONS => '1', COMPRESSION                                     
  => 'SNAPPY', MIN_VERSIONS => '0', TTL => 'FOREVER', KEEP_DELETED_C                                     
 ELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', BLOCKC                                     
 ACHE => 'true'}                                                                                         
1 row(s) in 0.0510 seconds
# su hdfs
$ hbase org.apache.hadoop.hbase.util.CompressionTest hdfs://hadoop-senior02.ibeifeng.com:8020/path/to/hbase snappy
16/07/05 21:48:41 INFO Configuration.deprecation: hadoop.native.lib is deprecated. Instead, use io.native.lib.available
16/07/05 21:48:43 INFO util.ChecksumType: Checksum using org.apache.hadoop.util.PureJavaCrc32
16/07/05 21:48:43 INFO util.ChecksumType: Checksum can use org.apache.hadoop.util.PureJavaCrc32C
16/07/05 21:48:44 INFO compress.CodecPool: Got brand-new compressor [.snappy]
16/07/05 21:48:44 INFO compress.CodecPool: Got brand-new compressor [.snappy]
16/07/05 21:49:04 INFO compress.CodecPool: Got brand-new decompressor [.snappy]
SUCCESS

4） HBase Compaction深入理解及RegionServer内存的使用、CacheBlock机制

HRegoin Server上的storefile文件是被后台线程监控的，以确保这些文件保持在可控状态。磁盘上的storefile的数量会随着越来越多的memstore被刷新而变等于越来越多——每次刷新都会生成一个storefile文件。当storefile数量满足一定条件时（可以通过配置参数类调整），会触发文件合并操作——minorcompaction，将多个比较小的storefile合并成一个大的storefile文件，直到合并的文件大到超过单个文件配置允许的最大值时会触发一次region的自动分割，即regionsplit操作，将一个region平分成2个。

minor compaction，轻量级
将符合条件的最早生成的几个storefile合并生成一个大的storefile文件，它不会删除被标记
为“删除”的数据和以过期的数据，并且执行过一次minor合并操作后还会有多个storefile
文件。
major compaction，重量级
把所有的storefile合并成一个单一的storefile文件，在文件合并期间系统会删除标记为"删除"
标记的数据和过期失效的数据，同时会block所有客户端对该操作所属的region的请求直到
合并完毕，最后删除已合并的storefile文件。

HBase上Regionserver的内存分为两个部分，一部分作为Memstore，主要用来写；另外一部分作为BlockCache，主要用于读。

写请求会先写入Memstore，Regionserver会给每个region提供一个Memstore，当Memstore满64MB以后，会启动 flush刷新到磁盘。当Memstore的总大小超过限制时（heapsize*hbase.regionserver.global.memstore.upperLimit * 0.9），会强行启动flush进程，从最大的Memstore开始flush直到低于限制。

读请求先到Memstore中查数据，查不到就到BlockCache中查，再查不到就会到磁盘上读，并把读的结果放入BlockCache。由于BlockCache采用的是LRU策略，因此BlockCache达到上限(heapsize * hfile.block.cache.size * 0.85)后，会启动淘汰机制，淘汰掉最老的一批数据。

在注重读响应时间的应用场景下，可以将BlockCache设置大些，Memstore设置小些，以加大缓存的命中率。

5） HBase 常见管理集群和表的工具（数据迁移案例的分析整理）

(1) Hive Integration
hive-table -> hbase-table
数据存储在HBase中
(2) Sqoop Integration
sqoop： RDBMS <-> HDFS/Hive/HBase
(3) Hue Integration
Thrift Server
bin/hbase-daemon.sh start thrift
(4) Flume