Hive索引的兴衰与现代替代方案

我们来深入探讨一下 Hive 中的索引。这是一个非常重要但经常被误解的话题，尤其是在 Hive 3.0 之后，其地位发生了显著变化。

核心结论先行

在深入细节之前，必须明确一个核心观点：在现代 Hive（尤其是 3.0 及以上版本）的生产环境中，传统的 Hive 索引几乎不再被推荐使用。其功能已被更强大、更高效的特性所取代，主要是物化视图和基于 CBO 的自动查询重写。

然而，理解索引的工作原理、优缺点和演变过程，对于深入理解 Hive 的查询优化至关重要。

---

一、为什么需要索引？

与传统关系型数据库（如 MySQL）类似，索引的核心目的是为了加速查询，特别是基于特定列的 WHERE 条件过滤。如果没有索引，Hive 只能进行全表扫描，这对于巨大的数据集来说成本极高。

二、Hive 索引的类型及其工作机制

Hive 提供了两种主要的索引类型：

1. 紧凑索引

• 原理：存储的是索引列的原始值与该值对应的 HDFS 文件块地址的映射关系。
• 特点：
  • 粒度较粗：索引的不是具体的行，而是 HDFS 的块（Block）。这意味着即使使用索引，Hive 仍然需要读取整个块，然后在块内进行扫描。
  • 适用于：重复值较多、数据在块内聚集分布的列。例如，对日期 dt 列建立紧凑索引，如果同一天的数据都存储在连续的几个块中，那么查询 WHERE dt = '2023-10-27' 时，索引可以快速定位到存储了 ‘2023-10-27’ 数据的那些块，避免扫描其他无关的块。
• 创建命令示例：

  -- 创建索引
  CREATE INDEX idx_employee_id ON TABLE employees (employee_id)
  AS 'COMPACT'
  WITH