hbase多个过滤器

1. HBase是什么呢，都有哪些特点呢

Hbase是一种NoSQL数据库，这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库，技术上来讲，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待

那Hbase有什么特性呢？如下：

• 强读写一致，但是不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合

• 自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配

• 自动的故障转移

• Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接

• 丰富的“简洁，高效”API，Thrift/REST API，Java API

• 块缓存，布隆过滤器，可以高效的列查询优化

• 操作管理，Hbase提供了内置的web界面来操作，还可以监控JMX指标

什么时候用Hbase？

Hbase不适合解决所有的问题：

• 首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态

• 其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。

• 最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。

Hbase在单机环境也能运行，但是请在开发环境的时候使用。

内部应用

• 存储业务数据:车辆GPS信息，司机点位信息，用户操作信息，设备访问信息。。。

• 存储日志数据:架构监控数据（登录日志，中间件访问日志，推送日志，短信邮件发送记录。。。），业务操作日志信息

• 存储业务附件：UDFS系统存储图像，视频，文档等附件信息

不过在公司使用的时候，一般不使用原生的Hbase API，使用原生的API会导致访问不可监控，影响系统稳定性，以致于版本升级的不可控。

HFile

HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer 1GB也是常见的。

探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。

Hfile生成方式

起初，HFile中并没有任何Block，数据还存在于MemStore中。

Flush发生时，创建HFile Writer，第一个空的Data Block出现，初始化后的Data Block中为Header部分预留了空间，Header部分用来存放一个Data Block的元数据信息。

而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中：

注：如果配置了Data Block Encoding，则会在Append KeyValue的时候进行同步编码，编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。

2. HBase条件查询（多条件查询）

转 https://blog.csdn.net/PirateLeo/article/details/7956965

文中可能涉及到的API：

Hadoop/HDFS: http://hadoop.apache.org/common/docs/current/api/

HBase: http://hbase.apache.org/apidocs/index.html?overview-summary.html

Begin！

HBase的查询实现只提供两种方式：

1、按指定RowKey获取唯一一条记录，get方法（org.apache.hadoop.hbase.client.Get）

2、按指定的条件获取一批记录，scan方法（org.apache.hadoop.hbase.client.Scan）

实现条件查询功能使用的就是scan方式，scan在使用时有以下几点值得注意：

1、scan可以通过setCaching与setBatch方法提高速度（以空间换时间）；

2、scan可以通过setStartRow与setEndRow来限定范围。范围越小，性能越高。

通过巧妙的RowKey设计使我们批量获取记录集合中的元素挨在一起（应该在同一个Region下），可以在遍历结果时获得很好的性能。

3、scan可以通过setFilter方法添加过滤器，这也是分页、多条件查询的基础。

下面举个形象的例子：

我们在表中存储的是文件信息，每个文件有5个属性：文件id（long，全局唯一）、创建时间（long）、文件名（String）、分类名（String）、所有者（User）。

我们可以输入的查询条件：文件创建时间区间（比如从20120901到20120914期间创建的文件），文件名（“中国好声音”），分类（“综艺”），所有者（“浙江卫视”）。

假设当前我们一共有如下文件：

内容列表
ID CreateTime Name Category UserID
1 20120902 中国好声音第1期 综艺 1
2 20120904 中国好声音第2期 综艺 1
3 20120906 中国好声音外卡赛 综艺 1
4 20120908 中国好声音第3期 综艺 1
5 20120910 中国好声音第4期 综艺 1
6 20120912 中国好声音选手采访 综艺花絮 2
7 20120914 中国好声音第5期 综艺 1
8 20120916 中国好声音录制花絮 综艺花絮 2
9 20120918 张玮独家专访 花絮 3
10 20120920 加多宝凉茶广告 综艺广告 4

这里UserID应该对应另一张User表，暂不列出。我们只需知道UserID的含义：

1代表 浙江卫视； 2代表 好声音剧组； 3代表 XX微博； 4代表 赞助商。
调用查询接口的时候将上述5个条件同时输入find(20120901,20121001,"中国好声音","综艺","浙江卫视")。

此时我们应该得到记录应该有第1、2、3、4、5、7条。第6条由于不属于“浙江卫视”应该不被选中。

我们在设计RowKey时可以这样做：采用UserID + CreateTime + FileID组成rowKey，这样既能满足多条件查询，又能有很快的查询速度。

需要注意以下几点：

1、每条记录的RowKey，每个字段都需要填充到相同长度。假如预期我们最多有10万量级的用户，则userID应该统一填充至6位，如000001，000002...

2、结尾添加全局唯一的FileID的用意也是使每个文件对应的记录全局唯一。避免当UserID与CreateTime相同时的两个不同文件记录相互覆盖。

按照这种RowKey存储上述文件记录，在HBase表中是下面的结构：

rowKey（userID 6 + time 8 + fileID 6） name category ....

00000120120902000001

00000120120904000002

00000120120906000003

00000120120908000004

00000120120910000005

00000120120914000007

00000220120912000006

00000220120916000008

00000320120918000009

00000420120920000010

怎样用这张表？

在建立一个scan对象后，我们setStartRow(00000120120901)，setEndRow(00000120120914)。

这样，scan时只扫描userID=1的数据，且时间范围限定在这个指定的时间段内，满足了按用户以及按时间范围对结果的筛选。并且由于记录集中存储，性能很好。

然后使用SingleColumnValueFilter（org.apache.hadoop.hbase.filter.SingleColumnValueFilter），共4个，分别约束name的上下限，与category的上下限。满足按同时按文件名以及分类名的前缀匹配。

（注意：使用SingleColumnValueFilter会影响查询性能，在真正处理海量数据时会消耗很大的资源，且需要较长的时间。

在后续的博文中我将多举几种应用场景下rowKey的，可以满足简单条件下海量数据瞬时返回的查询功能）

如果需要分页还可以再加一个PageFilter限制返回记录的个数。

以上，我们完成了高性能的支持多条件查询的HBase表结构设计。

3. hbase shell 中有版本过滤器吗

进入hbase shell console
$HBASE_HOME/bin/hbase shell
如果有kerberos认证，需要事先使用相应的keytab进行一下认证（使用kinit命令），认证成功之后再使用hbase shell进入可以使用whoami命令可查看当前用户！

4. hbase的核心数据结构是什么

hbase的核心数据结构为LSM树。

LSM树分为内存部分和磁盘部分。

内存部分是一个维护有序数据集合的数据结构。一般来讲，内存数据结构可以选择平衡二叉树、红黑树、跳跃表（SkipList）等维护有序集的数据结构，由于考虑并发性能，HBase选择了表现更优秀的跳跃表。

磁盘部分是由一个个独立的文件组成，每一个文件又是由一个个数据块组成。对于数据存储在磁盘上的数据库系统来说，磁盘寻道以及数据读取都是非常耗时的操作（简称IO耗时）。为了避免不必要的IO耗时，可以在磁盘中存储一些额外的二进制数据，这些数据用来判断对于给定的key是否有可能存储在这个数据块中，这个数据结构称为布隆过滤器（BloomFilter）。

LSM树介绍：

LSM树是一种磁盘数据的索引结构。LSM树的索引对写入请求更友好。因为无论是何种写入请求，LSM树都会将写入操作处理为一次顺序写，而HDFS擅长的正是顺序写（且HDFS不支持随机写）。

一个LSM树的索引内存部分是一个ConcurrentSkipListMap，Key是rowkey、column family、qualifier、type以及timestamp， Value是字节数组。随着数据不断写入MemStore，一旦内存超过阈值会将数据flush到磁盘，生产HFile；多个小HFile文件会compact成一个大HFile。

5. 深入理解HBASE（4）HFile

1）HFile由DataBlock、Meta信息(Index、BloomFilter)、Info等信息组成。

2）整个DataBlock由一个或者多个KeyValue组成。

3）在文件内按照Key排序。

这里只介绍V2版本的，HFileV1的数据格式在0.92版本升级到V2版本。

1）文件分为三部分：Scanned block section,Non-scanned block section,以及Opening-time data section

Scanned block section：表示顺序扫描HFile时（包含所有需要被读取的数据）所有的数据块将会被读取，包括Leaf Index Block和Bloom Block；

Non-scanned block section：HFile顺序扫描的时候该部分数据不会被读取，主要包括Meta Block即BloomFilter和Intermediate Level Data Index Blocks两部分；

Load-on-open-section：这部分数据在HBase的region server启动时，需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index；

Trailer：这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。

Leaf index block具体存储了DataBlock的offset、length、以及firstkey的信息。

RootDataIndex 存储的是每个Leaf index block的offset、length、Leaf index Block记录的第一个key，以及截至到该Leaf Index Block记录的DataBlock的个数。

假定DataBlock的个数足够多，HFile文件又足够大的情况下，默认的128KB的长度的ROOTDataIndex仍然存在超过chunk大小的情况时，会分成更多的层次。这样最终的可能是ROOT INDEX –> IntermediateLevel ROOT INDEX(可以是多层) —〉Leaf index block

在ROOT INDEX中会记录Mid Key所对应的信息，帮助在做File Split或者折半查询时快速定位中间Row的信息。

HFile V2的写操作流程：

1）Append KV到 Data Block。在每次Append之前，首先检查当前DataBlock的大小是否超过了默认的设置，如果不超出阈值，写入输出流。如果超出了阈值，则执行finishBlock()，按照Table-CF的设置，对DataBlock进行编码和压缩，然后写入HFile中。//以Block为单位进行编码和压缩，会有一些性能开销，可以参考 HBase实战系列1—压缩与编码技术

2）根据数据的规模，写入Leaf index block和Bloom block。

Leaf index Block，每次Flush一个DataBlock会在该Block上添加一条记录，并判断该Block的大小是否超过阈值(默认128KB)，超出阈值的情况下，会在DataBlock之后写入一个Leaf index block。对应的控制类：HFileBlockIndex，内置了BlockIndexChunk、BlockIndexReader和BlockIndexWriter(实现了InlineBlockWriter接口)。

Bloom Block设置：默认使用MURMUR hash策略，每个Block的默认大小为128KB，每个BloomBlock可以接收的Key的个数通过如下的公式计算，接收的key的个数 与block的容量以及errorRate的之间存在一定的关系，如下的计算公式中，可以得到在系统默认的情况下，每个BloomBlock可以接纳109396个Key。

注意：影响BloomBlock个数的因素，显然受到HFile内KeyValue个数、errorRate、以及BlockSize大小的影响。可以根据应用的需求合理调整相关控制参数。

每一个BloomBlock会对应index信息，存储在Meta Index区域。

这样在加载数据的时候，只需加载不超过128KB的RootDataIndex以及IntermediateLevelRootIndex，而避免加载如HFile V1的所有的Leaf index block信息，同样，也只需要加载BloomBlockIndex信息到内存，这样避免在HFile V1格式因为加载过大的DataBlockIndex造成的开销，加快Region的加载速度。

在HFile中根据一个key搜索一个data的过程：

1、先内存中对HFile的root index进行二分查找。如果支持多级索引的话，则定位到的是leaf/intermediate index，如果是单级索引，则定位到的是data block

2、如果支持多级索引，则会从缓存/hdfs（分布式文件系统）中读取leaf/intermediate index chunk，在leaf/intermediate chunk根据key值进行二分查找（leaf/intermediate index chunk支持二分查找），找到对应的data block。

3、从缓存/hdfs中读取data block

4、在data block中遍历查找key。

1、 首先读取文件尾的4字节Version信息（FileTrailer的version字段）。

2、 根据Version信息得到Trailer的长度（不同版本有不同的长度），然后根据trailer长度，加载FileTrailer。

3、 加载load-on-open部分到内存中，起始的文件偏移地址是trailer中的loadOnOpenDataOffset，load-on-open部分长度等于（HFile文件长度 - HFileTrailer长度）

Load-on-open各个部分的加载顺序如下：

依次加载各部分的HFileBlock（load-on-open所有部分都是以HFileBlock格式存储）：data index block、meta index block、FileInfo block、generate bloom filter index、和delete bloom filter。HFileBlock的格式会在下面介绍。

在hfile中，所有的索引和数据都是以HFileBlock的格式存在在hdfs中，

HFile version2的Block格式如下两图所示，有两种类型，第一种类型是没有checksum；第二种是包含checksum。对于block，下图中的绿色和浅绿色的内存是block header；深红部分是block data；粉红部分是checksum。

第一种block的header长度= 8 + 2 * 4 + 8;

第二种block的header长度=8 + 2 * 4 + 8 + 1 + 4 * 2；

BlockType：8个字节的magic，表示不同的block 类型。

CompressedBlockSize：表示压缩的block 数据大小（也就是在HDFS中的HFileBlock数据长度），不包括header长度。

UncompressedBlockSize：表示未经压缩的block数据大小，不包括header长度。

PreBlockOffset：前一个block的在hfile中的偏移地址；用于访问前一个block而不用跳到前一个block中，实现类似于链表的功能。

CheckSumType：在支持block checksum中，表示checksum的类型。

bytePerCheckSum：在支持checksum的block中，记录了在checksumChunk中的字节数；records the number of bytes in a checksum chunk。

SizeDataOnDisk：在支持checksum的block中，记录了block在disk中的数据大小，不包括checksumChunk。

DataBlock是用于存储具体kv数据的block，相对于索引和meta（这里的meta是指bloom filter）DataBlock的格式比较简单。

在DataBlock中，KeyValue的分布如下图，在KeyValue后面跟一个timestamp。

HFile中的index level是不固定的，根据不同的数据类型和数据大小有不同的选择，主要有两类，一类是single-level（单级索引），另一类是multi-level（多级索引，索引block无法在内存中存放，所以采用多级索引）。

HFile中的index chunk有两大类，分别是root index chunk、nonRoot index chunk。而nonRoot index chunk又分为interMetadiate index chunk和leaf index chunk，但intermetadiate index chunk和leaf index chunk在内存中的分布是一样的。

对于meta block和bloom block，采用的索引是single-level形式，采用single-level时，只用root index chunk来保存指向block的索引信息（root_index-->xxx_block）。

而对于data，当HFile的data block数量较少时，采用的是single level(root_index-->data_block)。当data block数量较多时，采用的是multi-level，一般情况下是两级索引，使用root index chunk和leaf index chunk来保存索引信息(root_index-->leaf_index-->data_block)；但当data block数量很多时，采用的是三级索引，使用root index chunk、intermetadiate index chunk和leaf index chunk来保存指向数据的索引（root_index-->intermediate_index-->leaf_index-->data_block）。

所有的index chunk都是以HFileBlock格式进行存放的，首先是一个HFileBlock Header，然后才是index chunk的内容。

Root index适用于两种情况：

1、作为data索引的根索引。

2、作为meta和bloom的索引。

在Hfile Version2中，Meta index和bloom index都是single-level，也都采用root索引的格式。Data index可以single-level和multi-level的这形式。Root index可以表示single-level index也可以表示multi-level的first level。但这两种表示方式在内存中的存储方式是由一定差别，见图。

对于multi-level root index，除了上面index entry数组之外还带有格外的数据mid-key的信息，这个mid-key是用于在对hfile进行split时，快速定位HFile的中间位置所使用。Multi-level root index在硬盘中的格式见图3.4。

Mid-key的信息组成如下：

1、Offset：所在的leaf index chunk的起始偏移量

2、On-disk size：所在的leaf index chunk的长度

3、Key：在leaf index chunk中的位置。

6. hbase中rowkey设置问题。

主键设计成：现有的主键+频度+列，即h+1+hi，但是最好将每个都格式化成定长的字符串，当你需要取前5个记录时使用过滤器取出前5条记录即可。大体如此，具体细节可能还需要好好设计

7. hbase(一) : HTable

hbase1.3
HTable 是我们对数据读取,操作的入口, implements HTableInterface, RegionLocator

内部构造

有一个检查 的动作待详细查看.

关于BufferedMutator, 是用来缓存客户端的操作的, hbase 将客户端的DML抽象成了 Mutation , 子类有: Append, Delete, Increment, Put 操作.
put方法将Put对象包装成Mutation,交给BufferedMutator, 到达设置的大小限制,或者主动调用flush操作, 会触发 backgroundFlushCommits(boolean synchronous) 操作, 然后Mutation由 AsyncProcess 提交,详细查看 BufferedMutatorImpl 类.
由 AscncProcess 提交后, (注释:Action类是将行与对应操作结合的类), 由connection去寻找每一行对应的region位置, 包装action, server, region等信息添加到 MutiAction 中去, 这个类持有按照region分组的actions,

然后会对每个action都创建 SingleServerRequestRunnable (rpc caller 和rpc callable, caller call callable), 交给线程池去运行.

删除操作很简单: 创建 RegionServerCallable , 然后rpc工厂类创建rpc caller来调用它

get和scan都是继承了Query
get很简单:首先检查,这个get是否只是检查数据存在否, 并且检查是否指定了一致性等级(默认 (Consistency.STRONG) ), 之后创建rpc请求Request, 如果 不是强一致性Consistency.TIMELINE , 则调用 , 它可以从replica上读取, 返回的数据被标记为stale(读操作是通过 Consistency.TIMELINE ，然后读RPC将会首先发送到主region服务器上，在短时间内（hbase.client.primaryCallTimeout.get默认为10ms），如果主region没有响应RPC会被发送到从region。 之后结果会从第一个完成RPC的返回。如果响应是来自主region副本，我们就会知道数据是最新的，Result.isStale() API是检查过期数据，如果结果是 从region返回，那么Result.isStale()为true，然后用户就可以检查关于过期数据可能的原因。).

当replica_id=0的regin不可以时候, 给所有的replica region发送请求,获取第一个从这些replica返回的数据, 客户端可以 Result.isStale()检查是否是来自副本的数据

Scan 类可以设置一系列的属性, startkey,endkey, 过滤器, 版本,缓存,最大取回大小等等, 但是获取数据是由 getScanner(Scan)返回的 ResultScanner 操作的.
返回的 ResultScanner 有small, Reversed,big和纯client 的不同,

什么是small scan?

见 https://issues.apache.org/jira/browse/HBASE-7266

hbase里面有两种读操作:pread and seek+read.
pread是一个函数，用于带偏移量地原子的从文件中读取数据。
读路径: https://yq.aliyun.com/articles/602377/
seek + read is fast but can cause two problem:
(1) resource contention
(2) cause too much network io

另外,一些其他的解释:前者适合小于一个数据块（默认64k）的smallScan（openScanner, next, closeScanner将在同一次rpc中实现）；而后者则会使用hdfs预读取，在DN中缓存一些数据（HBASE-7266、HBASE-9488）

查看最普通的 ClientScanner , 初始化的时候调用 , 这个方法去调用 nextScanner() , 获取为下一个region准备的scanner , 这个scanner会发起rpc调用, 参数是 ScannerCallable 对象, 这是scanner 的动作的抽象, reversed 和 small 都有对应的 ScannerCallable 子类
ScannerCallable 在初始化后, 的prepare阶段, 会从对应的region,获取对应的server, 获取这个server的ClientService.BlockingInterface接口, 并设置, 以便被调用的时候知道该向谁发起rpc请求

call阶段, 在创建 RequestScan的时候, 参数nextCallSeq在client和server端都维持,,每次调用都会增加, 是为了client能正确获取下一批的数据 .