之前的文章《更高的压缩比，更好的性能–使用ORC文件格式优化Hive》中介绍了Hive的ORC文件格式，它不但有着很高的压缩比，节省存储和计算资源之外，还通过一个内置的轻量级索引，提升查询的性能。这个内置的轻量级索引，就是下面所说的Row Group Index。

其实ORC支持的索引不止这一种，还有一种BloomFilter索引，两者结合起来，更加提升了Hive中基于ORC的查询性能。

说明一下：本文使用Hive2.0.0 + hadoop-2.3.0-cdh5.0.0作为测试环境。表lxw1234_text为text格式保存，总记录数为12000920。

Row Group Index

由之前的文章知道，一个ORC文件包含一个或多个stripes(groups of row data)，每个stripe中包含了每个column的min/max值的索引数据，当查询中有<,>,=的操作时，会根据min/max值，跳过扫描不包含的stripes。

而其中为每个stripe建立的包含min/max值的索引，就称为Row Group Index，也叫min-max Index，或者Storage Index。在建立ORC格式表时，指定表参数’orc.create.index’=’true’之后，便会建立Row Group Index，需要注意的是，为了使Row Group Index有效利用，向表中加载数据时，必须对需要使用索引的字段进行排序，否则，min/max会失去意义。另外，这种索引通常用于数值型字段的查询过滤优化上。

看下面的例子：

1. CREATE TABLE lxw1234_orc2 stored AS ORC 
2. TBLPROPERTIES
3. ('orc.compress'='SNAPPY',
4. 'orc.create.index'='true',
5. 'orc.bloom.filter.fpp'='0.05',
6. 'orc.stripe.size'='10485760',
7. 'orc.row.index.stride'='10000')
8. AS 
9. SELECT CAST(siteid AS INT),
10. pcid 
11. FROM lxw1234_text 
12. DISTRIBUTE BY id sort BY id;

直接执行下面的查询（未使用索引）：

1. SELECT COUNT(1)>=1382<=1399;
很明显，扫描了所有记录。再使用索引查询：
1. set.optimize.index.filter=true;
2. SELECT COUNT(1)>=1382<=1399;
可以看到，只扫描了部分记录，即根据Row Group Index中的min/max跳过了WHERE条件中不包含的stripes，索引有效果。
假如有下面的查询：
1. SET hive.optimize.index.filter=true;
2. SELECT COUNT(1)>=0<=1000
3. AND pcid IN ('0005E26F0DCCDB56F9041C','A');

执行的过程大概是这样的：

先根据Row Group Index中的min/max，判断哪些stripes/file包含在内，接着逐行扫描，过滤pcid IN (‘0005E26F0DCCDB56F9041C’,’A’)的记录。

可以看到，没有全表扫描，跳过了一部分stripes。这样看来，如果where后面的id范围很大，完全可能会包含所有的文件，再根据pcid过滤时候，又相当于全表扫描了。

对于这种查询场景的优化策略，就是下面的BloomFilter索引。

Bloom Filter Index

之前有篇文章《大数据去重统计之BloomFilter》，介绍过BloomFilter的原理和Java版的例子。Hive的ORC中基于此，提供了BloomFilter索引，用于性能优化。

在建表时候，通过表参数”orc.bloom.filter.columns”=”pcid”来指定为那些字段建立BloomFilter索引，这样，在生成数据的时候，会在每个stripe中，为该字段建立BloomFilter的数据结构，当查询条件中包含对该字段的=号过滤时候，先从BloomFilter中获取以下是否包含该值，如果不包含，则跳过该stripe.

看下面的建表语句，为pcid字段建立BloomFilter索引：

1. CREATE TABLE lxw1234_orc2 stored AS ORC 
2. TBLPROPERTIES
3. ('orc.compress'='SNAPPY',
4. 'orc.create.index'='true',
5. "orc.bloom.filter.columns"="pcid",
6. 'orc.bloom.filter.fpp'='0.05',
7. 'orc.stripe.size'='10485760',
8. 'orc.row.index.stride'='10000')
9. AS 
10. SELECT CAST(siteid AS INT),
11. pcid 
12. FROM lxw1234_text 
13. DISTRIBUTE BY id sort BY id;
然后执行上面的查询：
1. SET hive.optimize.index.filter=true;
2. SELECT COUNT(1)>=0<=1000
3. AND pcid IN ('0005E26F0DCCDB56F9041C','A');

 

通过Row Group Index和Bloom Filter Index的双重索引优化，这条语句最终执行，只扫描了60000条记录，大大节省了MapTask的执行时间和资源。

之前的文章《更高的压缩比，更好的性能–使用ORC文件格式优化Hive》中介绍了Hive的ORC文件格式，它不但有着很高的压缩比，节省存储和计算资源之外，还通过一个内置的轻量级索引，提升查询的性能。这个内置的轻量级索引，就是下面所说的Row Group Index。

其实ORC支持的索引不止这一种，还有一种BloomFilter索引，两者结合起来，更加提升了Hive中基于ORC的查询性能。

说明一下：本文使用Hive2.0.0 + hadoop-2.3.0-cdh5.0.0作为测试环境。表lxw1234_text为text格式保存，总记录数为12000920。

Row Group Index

由之前的文章知道，一个ORC文件包含一个或多个stripes(groups of row data)，每个stripe中包含了每个column的min/max值的索引数据，当查询中有<,>,=的操作时，会根据min/max值，跳过扫描不包含的stripes。

而其中为每个stripe建立的包含min/max值的索引，就称为Row Group Index，也叫min-max Index，或者Storage Index。在建立ORC格式表时，指定表参数’orc.create.index’=’true’之后，便会建立Row Group Index，需要注意的是，为了使Row Group Index有效利用，向表中加载数据时，必须对需要使用索引的字段进行排序，否则，min/max会失去意义。另外，这种索引通常用于数值型字段的查询过滤优化上。

看下面的例子：

1. CREATE TABLE lxw1234_orc2 stored AS ORC 
2. TBLPROPERTIES
3. ('orc.compress'='SNAPPY',
4. 'orc.create.index'='true',
5. 'orc.bloom.filter.fpp'='0.05',
6. 'orc.stripe.size'='10485760',
7. 'orc.row.index.stride'='10000')
8. AS 
9. SELECT CAST(siteid AS INT),
10. pcid 
11. FROM lxw1234_text 
12. DISTRIBUTE BY id sort BY id;
直接执行下面的查询（未使用索引）：
1. SELECT COUNT(1)>=1382<=1399;
很明显，扫描了所有记录。再使用索引查询：
1. set.optimize.index.filter=true;
2. SELECT COUNT(1)>=1382<=1399;

可以看到，只扫描了部分记录，即根据Row Group Index中的min/max跳过了WHERE条件中不包含的stripes，索引有效果。

假如有下面的查询：

1. SET hive.optimize.index.filter=true;
2. SELECT COUNT(1)>=0<=1000
3. AND pcid IN ('0005E26F0DCCDB56F9041C','A')
  1. ;

执行的过程大概是这样的：

先根据Row Group Index中的min/max，判断哪些stripes/file包含在内，接着逐行扫描，过滤pcid IN (‘0005E26F0DCCDB56F9041C’,’A’)的记录。

可以看到，没有全表扫描，跳过了一部分stripes。这样看来，如果where后面的id范围很大，完全可能会包含所有的文件，再根据pcid过滤时候，又相当于全表扫描了。

对于这种查询场景的优化策略，就是下面的BloomFilter索引。

Bloom Filter Index

之前有篇文章《大数据去重统计之BloomFilter》，介绍过BloomFilter的原理和Java版的例子。Hive的ORC中基于此，提供了BloomFilter索引，用于性能优化。

在建表时候，通过表参数”orc.bloom.filter.columns”=”pcid”来指定为那些字段建立BloomFilter索引，这样，在生成数据的时候，会在每个stripe中，为该字段建立BloomFilter的数据结构，当查询条件中包含对该字段的=号过滤时候，先从BloomFilter中获取以下是否包含该值，如果不包含，则跳过该stripe.

看下面的建表语句，为pcid字段建立BloomFilter索引：

1. CREATE TABLE lxw1234_orc2 stored AS ORC 
2. TBLPROPERTIES
3. ('orc.compress'='SNAPPY',
4. 'orc.create.index'='true',
5. "orc.bloom.filter.columns"="pcid",
6. 'orc.bloom.filter.fpp'='0.05',
7. 'orc.stripe.size'='10485760',
8. 'orc.row.index.stride'='10000')
9. AS 
10. SELECT CAST(siteid AS INT),
11. pcid 
12. FROM lxw1234_text 
13. DISTRIBUTE BY id sort BY id;
然后执行上面的查询：
1. SET hive.optimize.index.filter=true;
2. SELECT COUNT(1)>=0<=1000
3. AND pcid IN ('0005E26F0DCCDB56F9041C','A');

 

通过Row Group Index和Bloom Filter Index的双重索引优化，这条语句最终执行，只扫描了60000条记录，大大节省了MapTask的执行时间和资源。