一、索引优化步骤
- 了解数据和查询: 在创建索引之前,了解数据和查询类型至关重要。识别查询中经常使用的列以及用于过滤、连接和排序的列。
- 选择正确的存储格式: Hive支持各种存储格式,如ORC(优化行列式)、Parquet等。这些格式提供了用于数据检索的内置优化。根据数据和查询模式选择适当的格式可以在不需要额外索引的情况下提高性能。
- 分区: 分区数据可以通过限制需要扫描的数据量显著减少查询时间。这是一种优化查询的有效方法,特别是对于大型数据集。分区也可以作为一种索引。
- 桶化: 桶化是另一种将数据组织成更易管理部分的技术。它根据列值的哈希将数据分成桶。这可以改善某些类型查询的性能,特别是涉及连接和聚合的查询。
- 索引: Hive支持位图索引和紧凑索引。位图索引适用于基数较低的列,而紧凑索引适用于基数较高的列。在经常用于WHERE子句或JOIN条件的列上创建索引。
- 启用基于成本的优化(CBO): Hive的基于成本的优化可帮助更好地决策查询执行计划。它考虑统计信息、数据分布和查询模式等因素来优化查询计划。
- 定期更新统计信息: 保持有关数据的统计信息最新。Hive使用这些统计信息来进行查询优化。使用类似ANALYZE TABLE的命令收集表和分区的统计信息。
- 考虑使用Hive Tez或Spark: 根据用例,使用Tez或Spark作为执行引擎的Hive可能会比传统的MapReduce提供性能优势。
- 查询调优: 有时,优化查询本身可以显著提高性能。审查和优化SQL查询以提高效率。
- 测试和监控: 持续监视查询的性能,并根据实际性能指标迭代优化策略。
二、索引优化类型
2.1、原始索引
在Hive中,通常使用的索引技术是基于列的索引,而不是传统数据库中常见的基于行的索引。在Hive中,称为“原始索引”的索引技术并不常见,因为Hive的主要设计目标是处理大规模数据,而不是快速的随机访问。在传统数据库中,原始索引通常指的是直接指向数据行的索引结构。但在Hive中,数据通常以列式存储,并且针对每个列的索引在整体性能上并不一定比其他优化技术更有效。然而,在Hive中仍然可以通过使用PARTITION和BUCKET等技术来优化查询性能,而不是依赖于原始索引。PARTITION允许将数据划分成更小的部分,而BUCKET允许将数据分成更易管理的块。这些技术的组合通常可以提供比单独使用原始索引更好的性能优势。
总的来说,在Hive中,针对大规模数据处理的优化更倾向于使用分区、桶化、适当的存储格式和基于列的索引,而不是传统数据库中常见的原始索引技术。
在HIVE3.x版本后, 已经直接将这种索引废弃掉了, 无法使用
2.2、Row Group Index索引
行组索引
条件:
- 要求表的存储类型为ORC存储格式
- 在创建表的时候, 必须开启 row group index 索引支持
'orc.create.index'='true'
- 在插入数据的时候, 必须保证按照where过滤的字段进行数据的顺序插入
适用于: 数值类型的, 并且对数值类型进行 不等的过滤操作
-- 建表时定义
create table tb (
字段 字段类型
)
stored AS ORC
TBLPROPERTIES (
'orc.compress'='SNAPPY',
-- 开启行组索引
'orc.create.index'='true'
)
-- 插入数据 需要按照where过滤的字段顺序写入
insert table tb select * from tb_ods order by id
-- 查询是设置
set hive.optimize.index.filter=true;
SELECT COUNT(1) FROM tb WHERE id >= 1382 AND id <= 1399;
2.3、Bloom Fliter Index索引
布隆索引
条件:
- 要求表的存储类型为 ORC存储方案
- 在建表的时候, 必须设置为那些列构建布隆索引
- 仅能适合于等值过滤查询操作
-- 建表时定义
create table tb (
字段 字段类型
)
stored AS ORC
TBLPROPERTIES (
'orc.compress'='SNAPPY',
-- 开启行组索引
'orc.create.index'='true',
-- 开启BloomFilter索引
'orc.bloom.filter.columns'='city,字段3...'
)
-- 查询是设置
set hive.optimize.index.filter=true;
SELECT COUNT(1) FROM tb WHERE city = '北京'
2.4、小结
1- 对于行组索引, 我们建议只要数据存储格式为ORC, 就将这种索引全部打开, 至于导入数据的时候, 如果能保证有序, 那最好, 如果保证不了, 也无所谓, 大不了这个索引的效率不是特别好
2- 对于布隆过滤索引: 建议将后续会大量的用于等值连接的操作字段, 建立成布隆索引, 比如说: JOIN的字段 经常在where后面出现的等值连接字段。