之前的文章《更高的压缩比,更好的性能–使用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中包含了每个columnmin/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) AS id,
  10. pcid
  11. FROM lxw1234_text
  12. DISTRIBUTE BY id sort BY id;

直接执行下面的查询(未使用索引):

  1. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 1382 AND id <= 1399;

很明显,扫描了所有记录。再使用索引查询:

  1. set hive.optimize.index.filter=true;
  2. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 1382 AND id <= 1399;

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

假如有下面的查询:

  1. SET hive.optimize.index.filter=true;
  2. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 0 AND id <= 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) AS id,
  11. pcid
  12. FROM lxw1234_text
  13. DISTRIBUTE BY id sort BY id;

然后执行上面的查询:

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


您可以关注 lxw的大数据田地 ,或者 加入邮件列表 ,随时接收博客更新的通知邮件。

通过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中包含了每个columnmin/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) AS id,
  10. pcid
  11. FROM lxw1234_text
  12. DISTRIBUTE BY id sort BY id;

直接执行下面的查询(未使用索引):

  1. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 1382 AND id <= 1399;

很明显,扫描了所有记录。再使用索引查询:

  1. set hive.optimize.index.filter=true;
  2. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 1382 AND id <= 1399;

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

假如有下面的查询:

  1. SET hive.optimize.index.filter=true;
  2. SELECT COUNT(1) FROM lxw1234_orc1 WHERE id >= 0 AND id <= 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) AS id,
  11. pcid
  12. FROM lxw1234_text
  13. DISTRIBUTE BY id sort BY id;

然后执行上面的查询:

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


您可以关注 lxw的大数据田地 ,或者 加入邮件列表 ,随时接收博客更新的通知邮件。

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

转:Hive性能优化之ORC索引–Row Group Index vs Bloom Filter Index的更多相关文章

  1. Hive性能优化

    1.概述 继续<那些年使用Hive踩过的坑>一文中的剩余部分,本篇博客赘述了在工作中总结Hive的常用优化手段和在工作中使用Hive出现的问题.下面开始本篇文章的优化介绍. 2.介绍 首先 ...

  2. Hive性能优化上的一些总结

    https://blog.csdn.net/mrlevo520/article/details/76339075 1.介绍 首先,我们来看看Hadoop的计算框架特性,在此特性下会衍生哪些问题? 数据 ...

  3. MySQL性能优化(三):索引

    原文:MySQL性能优化(三):索引 版权声明:本文为博主原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/vbi ...

  4. Hive性能优化(全面)

    1.介绍 首先,我们来看看Hadoop的计算框架特性,在此特性下会衍生哪些问题? 数据量大不是问题,数据倾斜是个问题. jobs数比较多的作业运行效率相对比较低,比如即使有几百行的表,如果多次关联多次 ...

  5. SqlServer性能优化 查询和索引优化(十二)

    查询优化的过程: 查询优化: 功能:分析语句后最终生成执行计划 分析:获取操作语句参数 索引选择 Join算法选择 创建测试的表: select * into EmployeeOp from Adve ...

  6. 数据库性能优化:SQL索引

    SQL索引在数据库优化中占有一个非常大的比例, 一个好的索引的设计,可以让你的效率提高几十甚至几百倍,在这里将带你一步步揭开他的神秘面纱. 1.1 什么是索引? SQL索引有两种,聚集索引和非聚集索引 ...

  7. SQL Server 性能优化之——重复索引

    原文 http://www.cnblogs.com/BoyceYang/archive/2013/06/16/3139006.html 阅读导航 1. 概述 2. 什么是重复索引 3. 查找重复索引 ...

  8. MySQL性能优化,MySQL索引优化,order by优化,explain优化

    前言 今天我们来讲讲如何优化MySQL的性能,主要从索引方面优化.下期文章讲讲MySQL慢查询日志,我们是依据慢查询日志来判断哪条SQL语句有问题,然后在进行优化,敬请期待MySQL慢查询日志篇 建表 ...

  9. 性能优化之mysql索引优化

    sql及索引优化 如何通过慢查询日志发现有问题的sql? 查询次数多且每次查询占用时间长的sql通常为pt-query-digest分析的前几个查询 IO大的sql注意pt-query-digest分 ...

随机推荐

  1. 我的Android进阶之旅------>解决DownloadManager报错java.lang.SecurityException: Invalid value for visibility: 2

    1.问题描述 今天使用Android系统的DownloadManager进行下载操作时,爆了如下所示的错误: java.lang.RuntimeException: Unable to start s ...

  2. Hibernate框架ORM的实现原理

    1. 什么是ORM ORM的全称是Object Relational Mapping,即对象关系映射.它的实现思想就是将关系数据库中表的数据映射成为对象,以对象的形式展现,这样开发人员就可以把对数据库 ...

  3. mysq查询语句包含中文以及中文乱码,字符集 GBK、GB2312、UTF8的区别

    一.查看mysql 字符集设置情况 使用Navicat for Mysql查看工具,打开命令列界面,输入show variables like '%char%';如下图,查看当前mysql字符集设置情 ...

  4. Unity3d 面向对象设计思想(六)(Unity3d网络异步数据)

    在MonoBehavior类中有一个方法是StartCoroutine.里面要求的是一个接口为IEnumerator协同的返回值, 在Unity3d中,协同的作用是马上返回结果的.而不影响其它程序的运 ...

  5. 添加github ssh 公钥

    1.在控制台输入命令: ssh-keygen -t rsa -C "github上的邮箱地址" 2.将公匙复制后添加到github网站:    id_rsa.pub文件 3.测试是 ...

  6. iptables练习题(四)

    设有一台Linux服务器,利用iptables作为防火墙,要求新建一条名为MYCHAIN的新链,来实现只允许开放本机的http服务,其余协议和端口均拒绝. 脚本: [root@miyan ~]# ca ...

  7. java多线程总结(二)

    线程一般有6个状态: 新建状态:NEW 可运行状态:RUNNABLE 休眠状态:TIMED_WAITING 等待状态:WAITING 阻塞状态:BLOCKED 终止状态“TERMINATED 当我们使 ...

  8. Nodejs学习计划

    此文章已经发表于本人博客. 由于公司要求这段时间在学习Nodejs,基本靠自摸一路走来踩了很多坑浪费很多时间,今天就来这里说下,顺便计划一下接下来的学习计划,目前自己做个博客,项目过程中学习了js类以 ...

  9. HDU - 6315 Naive Operations (线段树+思维) 2018 Multi-University Training Contest 2

    题意:数量为N的序列a和b,a初始全为0,b为给定的1-N的排列.有两种操作:1.将a序列区间[L,R]中的数全部+1:2.查询区间[L,R]中的 ∑⌊ai/bi⌋(向下取整) 分析:对于一个位置i, ...

  10. WINDOWS和UNIX换行符的理解

    # WINDOWS和UNIX换行符的理解 **file1.txt**17.143.161.37   其他    美国54.163.255.40   其他    美国 弗吉尼亚州 亚马逊公司 **[ro ...