Hive 的软件架构是一个典型的 分层、模块化、可插拔 的设计,核心目标是将 类 SQL 查询(HiveQL) 转换为底层分布式计算引擎(如 MapReduce、Tez、Spark)可执行的任务,并利用 元数据服务(Metastore) 管理表结构与数据位置。
以下是 Hive 软件架构的详细拆解(基于 Apache Hive 官方设计):
一、整体架构图
graph TD
A[用户接口] --> B[Hive Driver]
B --> C[Compiler]
B --> D[Optimizer]
B --> E[Executor]
C --> F[Parser]
C --> G[Semantic Analyzer]
C --> H[Logical Plan Generator]
C --> I[Physical Plan Generator]
D --> J[Rule-Based Optimizer<br>(谓词下推、列裁剪等)]
E --> K[Execution Engine<br>(MapReduce / Tez / Spark)]
C & D & E --> L[Metastore]
L --> M[(RDBMS: MySQL/PostgreSQL)]
K --> N[HDFS / S3 / OBS]
二、核心组件详解
1. 用户接口(User Interfaces)
Hive 提供多种方式提交查询:
- CLI(Command Line Interface):早期交互式命令行(已逐步淘汰)
- Beeline:基于 JDBC 的轻量级 CLI,推荐使用
- JDBC/ODBC Server:支持 BI 工具(如 Tableau、Superset)连接
- Thrift Server:提供跨语言 RPC 接口(HiveServer2)
✅ HiveServer2 是现代部署的核心服务,支持多客户端并发、身份认证(Kerberos/LDAP)、会话管理。
2. Driver(驱动器)
- 是 Hive 的“大脑”,协调整个查询生命周期
- 主要职责:
- 接收用户查询
- 调用 Compiler 编译
- 调用 Optimizer 优化
- 调用 Executor 执行
- 返回结果给客户端
3. Compiler(编译器)
将 HiveQL 转换为可执行计划,包含四个阶段:
| 阶段 | 功能 |
|---|---|
| Parser(解析器) | 将 HiveQL 字符串解析为 抽象语法树(AST) |
| Semantic Analyzer(语义分析器) | 检查表/列是否存在、类型是否匹配、权限是否足够; 从 Metastore 获取元数据; 生成 逻辑执行计划(Operator Tree) |
| Logical Plan Generator | 构建逻辑操作符树(如 Filter → Select → GroupBy) |
| Physical Plan Generator | 将逻辑计划转换为 物理执行计划(如 MapReduce Job DAG) |
4. Optimizer(优化器)
- 对逻辑/物理计划进行优化,提升执行效率
- 主要优化策略(Rule-Based):
- 谓词下推(Predicate Pushdown):将 WHERE 条件尽量下推到数据读取层(减少 I/O)
- 列裁剪(Column Pruning):只读取 SELECT 中用到的列(尤其对列式存储有效)
- Map Join 自动转换:小表自动转为 Map-side Join,避免 Reduce
- 分区裁剪(Partition Pruning):根据 WHERE 条件跳过无关分区
- 合并小文件(CombineInputFormat)
💡 Hive 3.0+ 引入了 CBO(Cost-Based Optimizer),基于统计信息(如行数、列分布)做更智能优化。
5. Executor(执行器)
- 负责调度和监控物理计划的执行
- 将任务提交给底层 Execution Engine
- 监控任务状态、处理失败重试、收集日志
6. Execution Engine(执行引擎)—— 可插拔
Hive 支持多种计算引擎,通过 hive.execution.engine 配置:
| 引擎 | 特点 | 适用场景 |
|---|---|---|
| MapReduce | 默认引擎,稳定但慢 | 兼容性要求高、资源充足 |
| Tez | DAG 执行模型,减少中间落盘 | 推荐用于 Hive 数仓(Facebook 出品) |
| Spark | 内存计算,速度快 | 与 Spark 生态集成(如 Spark SQL + Hive Metastore) |
✅ Tez 是 Hive 性能提升的关键:将多个 MapReduce Job 合并为一个 DAG,避免不必要的 HDFS 写入。
7. Metastore(元数据服务)
- Hive 的“目录”,存储所有数据库、表、分区、列、SerDe、存储路径等元信息
- 不存储实际数据,只存储“数据在哪里、长什么样”
架构模式:
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Embedded(内嵌) | Metastore 与 Hive Driver 同进程,使用 Derby DB | 仅本地测试 |
| Local(本地) | Hive 与 Metastore 同进程,但连接 MySQL/PG | 开发环境 |
| Remote(远程) | Metastore 独立服务,Hive 通过 Thrift API 访问 | 生产环境(高可用、多客户端共享) |
📌 生产环境必须使用 Remote Metastore + MySQL/PostgreSQL,并配置主备或集群。
8. 数据存储层(Storage Layer)
-
实际数据存储在 HDFS / Amazon S3 / Aliyun OSS / Azure Blob 等分布式文件系统
-
Hive 表 = HDFS 目录 + 元数据描述
# 示例:Hive 表在 HDFS 的路径 /user/hive/warehouse/mydb.db/orders/dt=20241106/ -
支持多种 SerDe(Serializer/Deserializer) 解析不同格式:
LazySimpleSerDe:TextFileOrcSerDe:ORC 文件ParquetHiveSerDe:Parquet 文件JsonSerDe:JSON 日志
三、关键数据流示例(以 SELECT * FROM orders WHERE dt='20241106' 为例)
- 用户通过 Beeline 提交 HiveQL
- HiveServer2 接收请求,交给 Driver
- Compiler:
- Parser 生成 AST
- Semantic Analyzer 查询 Metastore,确认
orders表存在,dt是分区字段 - 生成逻辑计划:
TableScan → Filter → Select
- Optimizer:
- 分区裁剪:只扫描
dt='20241106'分区 - 列裁剪:因
SELECT *,保留所有列
- 分区裁剪:只扫描
- Physical Plan Generator:生成 Tez DAG
- Executor 提交 Tez 任务到 YARN
- Tez 从 HDFS 读取
/warehouse/orders/dt=20241106/数据 - 结果返回给 Beeline
四、Hive 架构优势与挑战
✅ 优势
- SQL 友好:降低大数据分析门槛
- 可扩展:支持自定义 UDF、Storage Handler、SerDe
- 生态兼容:与 Hadoop、Spark、Flink(通过 HMS)无缝集成
- 成熟稳定:经过超大规模生产验证(Facebook、阿里、腾讯)
⚠️ 挑战
- 延迟高:Job 启动开销大,不适合交互式查询
- Metastore 单点瓶颈:高并发时需分库分表或使用 HMS HA
- 小文件问题:分区过多导致 NameNode 压力大
- ACID 支持有限:虽有 Hive 3.0+ ACID,但性能和功能不如传统数据库
✅ 总结
Hive 的软件架构 = SQL 解析器 + 元数据管理 + 可插拔执行引擎 + 分布式存储抽象
它通过 解耦查询逻辑与物理执行,实现了“一次建模,多引擎运行”的灵活性,成为企业离线数仓的基石。
虽然新兴引擎(如 Trino、Doris)在交互式场景崛起,但 Hive 在 ETL、批处理、大规模数据加工 领域仍不可替代。
📌 学习建议:理解 Hive 架构,重点掌握 Metastore 作用、执行计划生成过程、Tez/Spark 引擎差异,这对调优和排错至关重要。
1103

被折叠的 条评论
为什么被折叠?



