Hbase Scan的重要参数

Posted 2021-01-30 qfjavabd

　　Scan是操作Hbase中非常常用的一个操作，虽然前面的Hbase API操作简单的介绍了Scan的操作，但不够详细，由于Scan非常常用，关于其详细的整理也是很有必要的。

　　Scan

　　HBase中的数据表通过划分成一个个的Region来实现数据的分片，每一个Region关联一个RowKey的范围区间，而每一个Region中的数据，按RowKey的字典顺序进行组织。

　　正是基于这种设计，使得HBase能够轻松应对这类查询：“指定一个RowKey的范围区间，获取该区间的所有记录”， 这类查询在HBase被称之为Scan。

　　1 . 构建Scan，指定startRow与stopRow，如果未指定的话会进行全表扫描

　　2 . 获取ResultScanner

　　3 . 遍历查询结果

　　4 . 关闭ResultScanner

　　public void stringFilter() throws IOException { Configuration conf = HBaseConfiguration.create(); // 获取Table实例 HTable table = new HTable(conf, user); // 构建Scan Scan scan = new Scan(); scan = scan.setStartRow(Bytes.toBytes(startRowxxx)).setStopRow(Bytes.toBytes(StopRowxxx)); RowFilter filter = new RowFilter( CompareFilter.CompareOp.EQUAL, new BinaryComparator(Bytes.toBytes(224382618261914241)) ); scan.setFilter(filter); // 获取resultScanner ResultScanner scanner = table.getScanner(scan); Result result = null; // 处理结果 while ((result = scanner.next()) != null) { byte[] value = result.getValue(Bytes.toBytes(ship), Bytes.toBytes(addr)); if (value == null || value.length == 0) { continue; } System.out.println( new String(value) ); System.out.println(hello World); } // 关闭ResultScanner scanner.close(); table.close(); }

　　其它的设置参数

　　Caching: 设置一次RPC请求批量读取的Results数量

　　下面的示例代码设定了一次读取回来的Results数量为100：

　　scan.setCaching(100);

　　Client每一次往RegionServer发送scan请求，都会批量拿回一批数据(由Caching决定过了每一次拿回的Results数量)，然后放到本次的Result Cache中：

　　

 

　　应用每一次读取数据时，都是从本地的Result Cache中获取的。如果Result Cache中的数据读完了，则Client会再次往RegionServer发送scan请求获取更多的数据。

　　Batch: 设置每一个Result中的列的数量

　　下面的示例代码设定了每一个Result中的列的数量的限制值为3：

　　scan.setBatch(3);

　　该参数适用于一行数据过大的场景，这样，一行数据被请求的列会被拆成多个Results返回给Client。

　　举例说明如下：

　　假设一行数据中共有十个列：

　　{Col01，Col02，Col03，Col04，Col05，Col06，Col07，Col08，Col09, Col10}

　　假设Scan中设置的Batch为3，那么，这一行数据将会被拆成4个Results返回：

　　Result1 - {Col01，Col02，Col03}Result2 - {Col04，Col05，Col06}Result3 - {Col07，Col08，Col09}Result4 - {Col10}

　　关于Caching参数，我们说明了是Client每一次从RegionServer侧获取到的Results的数量，上例中，一行数据被拆成了4个Results，这将会导致Caching中的计数器被减了4次。结合Caching与Batch，我们再列举一个稍复杂的例子：

　　假设，Scan的参数设置如下：

　　final byte[] start = Bytes.toBytes(“Row1”);

　　final byte[] stop = Bytes.toBytes(“Row5”);

　　Scan scan = new Scan();

　　scan.withStartRow(start).withStopRow(stop);

　　scan.setCaching(10);

　　scan.setBatch(3);

　　待读取的数据RowKey与所关联的列集如下所示：

　　Row1: {Col01，Col02，Col03，Col04，Col05，Col06，Col07，Col08，Col09，Col10}

　　Row2: {Col01，Col02，Col03，Col04，Col05，Col06，Col07，Col08，Col09，Col10，Col11}

　　Row3: {Col01，Col02，Col03，Col04，Col05，Col06，Col07，Col08，Col09，Col10}

　　再回顾一下Caching与Batch的定义：

　　Caching: 影响一次读取返回的Results数量。

　　Batch: 限定了一个Result中所包含的列的数量，如果一行数据被请求的列的数量超出Batch限制，那么这行数据会被拆成多个Results。

　　那么， Client往RegionServer第一次请求所返回的结果集如下所示：

　　Result1 - Row1: {Col01，Col02，Col03}

　　Result2 - Row1: {Col04，Col05，Col06}

　　Result3 - Row1: {Col07，Col08，Col09}

　　Result4 - Row1: {Col10}

　　Result5 - Row2: {Col01，Col02，Col03}

　　Result6 - Row2: {Col04，Col05，Col06}

　　Result7 - Row2: {Col07，Col08，Col09}

　　Result8 - Row2: {Col10，Col11}

　　Result9 - Row3: {Col01，Col02，Col03}

　　Result10 - Row3: {Col04，Col05，Col06}

　　Limit: 限制一次Scan操作所获取的行的数量

　　同SQL语法中的limit子句，限制一次Scan操作所获取的行的总量：

　　scan.setLimit(10000);

　　注意：Limit参数是在2.0版本中新引入的。但在2.0.0版本中，当Batch与Limit同时设置时，似乎还存在一个BUG，初步分析问题原因应该与BatchScanResultCache中的numberOfCompletedRows计数器逻辑处理有关。因此，暂时不建议同时设置这两个参数。

　　CacheBlock: RegionServer侧是否要缓存本次Scan所涉及的HFileBlocks

　　scan.setCacheBlocks(true);

　　e) Raw Scan: 是否可以读取到删除标识以及被删除但尚未被清理的数据

　　scan.setRaw(true);

　　MaxResultSize: 从内存占用量的维度限制一次Scan的返回结果集

　　下面的示例代码将返回结果集的最大值设置为5MB：

　　scan.setMaxResultSize(5 * 1024 * 1024);

　　Reversed Scan: 反向扫描

　　普通的Scan操作是按照字典顺序从小到大的顺序读取的，而Reversed Scan则恰好相反：

　　scan.setReversed(true);

　　带Filter的Scan

　　Filter可以在Scan的结果集基础之上，对返回的记录设置更多条件值，这些条件可以与RowKey有关，可以与列名有关，也可以与列值有关，还可以将多个Filter条件组合在一起，等等。

　　最常用的Filter是SingleColumnValueFilter，基于它，可以实现如下类似的查询：

　　“返回满足条件{列I:D的值大于等于10}的所有行”

　　示例代码如下：

　　Filter丰富了HBase的查询能力，但使用Filter之前，需要注意一点：Filter可能会导致查询响应时延变的不可控制。因为我们无法预测，为了找到一条符合条件的记录，背后需要扫描多少数据量，如果在有效限制了Scan范围区间(通过设置StartRow与StopRow限制)的前提下，该问题能够得到有效的控制。这些信息都要求使用Filter之前应该详细调研自己的业务数据模型。

　　

?